A Compact Flash implementation on an FPGA is dead simple because it is a parallel interface. In fact, it is an ATA protocol just like an HDD. At least in terms of reading and writing sectors.
The IBM 1130 had 321 word sectors (642 bytes) which I mapped into adjacent 512 byte sectors. The rest was trivial.
However, I didn't have to create a file system or have any ability to work with it on a PC. The 1130 had its own file system and I was just implementing the underlying hardware.
Yes, my uCOM currently uses a CF card interface I built based on Grant Searle's original designs (
his CP/M design, specifically), with a few extra features like bus buffering etc, so I have a working BIOS with the low-level routines (including blocking/de-blocking) to operate the CF card with no problems, but not having to write them myself or watching how they came together I have very little true understanding of the basics of the CP/M format - I don't know what I don't know, if you know what I mean, so I don't know what's possible and what isn't - hence the question regarding whether or not it's possible to 'convert' CP/M files into FAT32/Windows files (and back) on the fly between the host and SD card, and why I'm now hitting the books hard to learn more about the subject.
If I couldn't come up with some other way to do things, I would use the Linux 'dd' command to read and write the CF. Turning the raw image into a recognizable file system (FAT32) would be done in code somehow.
Tools exist already for Linux and Windows (
cpmtools) that do this - I can take the CF card out of the uCOM, plug it into my PC and read/write the CP/M drives and files (almost) like a native Windows drive. If I could remove cpmtools from the equation, however, it removes another potential point of failure in the system (at some point, cpmtools will probably disappear or stop being compatible with the latest OSes, etc).
CP/M is the file system, all the BIOS does is read and write sectors. You could easily map an entire CP/M drive into a named file if you could deal with the allocation table in FPGA code. I might use a small core and some assembly language to do this mapping. It seems rather complex to do it in hardware but maybe not. You can use 512 byte sectors in CP/M, the code for packing and unpacking is easily obtained and was written by Digital Research. I haven't thought about it in years. Maybe it came with CP/M 2.2
Yes, I've been reading about CP/M's file system earlier today (The Programmer's CP/M Handbook by Andy Johnson-Laird) and it's clear that the way the file system works is embedded deeply into BDOS and the BIOS, so it's not looking likely that what I want to do is possible without some major refactoring of CP/M's source code - a rabbit hole I certainly don't have the time or experience to dive down.
Anyway, I'm massively jumping the gun by worrying about what I can and can't achieve with the SD card's format - I've first got to get an interface up and running that allows the host to read and write SD card data at all. I'm considering using
this project on OpenCores to establish an SD interface in the FPGA. I know nothing about the Wishbone interface, so that's something else for me to learn about, but I don't think I actually need it and might be able to remove that part from the project, as the Z80_Bridge module in the FPGA should be able to handle the data and command flow between host and SD interface without a Wishbone bus.
Once I get some form of data read/write access to the SD card for the host, I can then start thinking about DMA into a DDR3 buffer and working out what's required to get CP/M working. Right now, though, I'm researching the basic concepts.