Linked to another recent thread... if you want to support FAT, then I suggest just using FatFs. It's become fairly good and it just works. It's written in portable C. http://elm-chan.org/fsw/ff/00index_e.html
Ah, thanks SiliconWizard, I'll take a look at that later. The only requirement I have for supporting any of the FAT varieties is that I can access it from Windows 10 with no middle-man software, otherwise I might as well not bother, but FATfs should be okay I guess.
Of course you'll still have to implement the low-level access to SD cards. I have the SD spec (been working on that lately), as far as I've read in it, access in SPI mode is required to be available in all card types except SDUC cards. SDUC cards are those with higher capacity than 2TB - I doubt you'll be using them for a system such as this one, and also given their current price. But be aware that the SPI mode only gives access to a small subset of the SD commands, and while you can absolutely use it to read and write the card and implement a file system, it's pretty inefficient. The end result would be pretty slow (although, compared to typical storage available at the time for 8-bit computers, that'd still be pretty "fast" ).
I'm not looking to implement an SPI interface to the SD card - I'm going full 4-bit SDIO for the reasons you've identified.
As a thought, I find it kinda odd to design a relatively complex and powerful system (graphics controller, storage management) - using subsystems (such as a 32-bit soft core) that are much more powerful than your main CPU. Interesting, certainly, but an odd project in my book.
Well, you have to remember that this project is a bit of a Frankenstein's monster. It started out with me learning about electronics whilst building a simple 7-chip Z80 computer on a breadboard. I've wanted to push my limits constantly since starting the project and, in a great example of feature creep (or project bloat, if you prefer), I now have a stackable, modular Z80 computer made with SMD components on custom PCBs and with up to 4MB of memory running CP/M from a CF card and with a hardware-accelerated GPU providing further IO opportunities (like PS/2, USB HID, HDMI output, etc). It certainly isn't a well-planned project, just a hobby that I'm following to its conclusion (when the help runs out or I just can't progress any further).
The features I'm adding to the FPGA are for my uCOM, but equally can apply to anyone else wanting to add one of these FPGA GPUs to their DIY system - be it an 8-bit system or something beefier. I'd certainly like to move on to the Motorola 68000-series when I'm done with this Z80.
FAT32 will go up to 4GB,
No, no, ... no.
FAT32 can support partitions up to *2 TB* (with a cluster size of 64 KB.)
Ah - my misunderstanding there. Okay, so FAT32 can be used on SD cards up to 2 TB in size?! That makes the argument for supporting exFAT or FATfs less compelling in my opinion, but only if the complexity of supporting those more modern filesystems is significant, I suppose.
The limitation is for file size. Max file size in FAT32 is 4 GB. Not at all the partition size. So unless you're going to write individual files that are larger than 4 GB (which would definitely look odd on an 8-bit system), you may never have to bother.
That said, if you use FatFs as I suggested, the library supports FAT12, 16, 32 and exFAT, so you'd be all covered.
Indeed - it does weaken the argument for messing around trying to support greater than FAT32. What I might do is stick to FAT32 initially, then upgrade to FATfs once I know more about what I'm doing.