GOOD COMPUTER: FAT32
back in 2020 I had some time at home (!) so I built a little computer. this year I’ve also had some time at home (!) so I pulled it back out and started work on an SD card driver https://twitter.com/robn/status/1282642779269562368
as is usual for small embedded devices, SD cards mostly do the right thing for whatever bus they’re on (SPI in this case), but have some interesting quirks and timings. documentation is available in the form of the “simplified” specs, which are missing important details
of course I could get the full spec if I joined up, but that’s real cash money. and its kind of petty, because SD devices support PCIe, shit most hobbyists aren’t going near, and the doc has info about it, but omits important info for SPI, very much the “tinkerer’s mode”
so, as usual, we’re left digging around the internet for often outdated or incomplete documentation, and other people’s code, to suss out the details
http://elm-chan.org/docs/mmc/mmc_e.html http://www.dejazzer.com/ee379/lecture_notes/lec12_sd_card.pdf https://github.com/greiman/Fat16/blob/master/Fat16/SdCard.cpp
the main quirk seems to be that you need to run eight SPI clocks after deselecting the device to let everything settle. fine, nbd
anyway, a few hours later, the initialisation sequence is working and we can read block 0. in this case, a DOS MBR, with a pointer to a FAT32 partition
now comes the tricky bit!
following the first type 0x0c partition, we land on the FAT32 header, and we can dump some strings - version, label, system ident.
for now not validating anything, so a broken filesystem will just blow up, but like, why would you do that
last for tonight, loading the first block of the root dir and finding the dir entry for the file I left for myself
alas, filesystems require computing and combining lots of offsets, and this little 8-bit cpu is not exactly a mathematical powerhouse. lots more to do
originally posted on twitter at: https://twitter.com/robn/status/1481190626729533444