I'll have to cleanup my code a bit before posting (I currently have square eyes)
Please don't feel shy to throw whatever you have in Contrib/xopr/ and offer a pull request!
But what about a generic expansion port/bus for memory-mapped peripherals?
I think you can also do that if you want? What specific peripheral are you planning to hook up this way (and how would it deal with 64K programs)? We could always add breakouts for the signals on this board. If not for devices, you can solder blinkenlights to them... Many possibilities.
You are right, I'm just thinking about this out loud. But to be specific, I am thinking about GPIO, real time clock with battery backup, maybe storage device. Regarding 64k programs, do you mean mapping at, lets say, last 1kb? Peripherals could have memory range above 96k, starting at 0x30000, ending at 0x3FFFF, similar to the last 1GB on 32-bit x86 system. But I need to get myself a kit and play a bit with real hardware to have a better understanding and more informed suggestions.
Looking forward! Fully functional GPIO is demonstrated earlier in this thread, and memory cards must be accessed in SPI mode as well. As you can see, we flipped back and forth between memory mapping or not. At this moment the concept boards hinge upon the 'ctrl' instruction instead. Clock chips seem to prefer i2c, but nobody has dived into that yet. It would be nice to see your results on that. After all, once we're writing into a file system, we need timestamps...
First messages exchanged with a physical memory card. "Reset" (aka CMD0) puts the card in SPI mode. "Version" (aka CMD8) is the canonical method to check if the card is ok. The printed reply bytes come from the card and are of the expected value (0x01).
For this test I used GCL instead of LCC as originally planned. Next task is to read the boot sector and find the primary partition's root directory.
P.S.: Inlining of pictures in forum messages is broken for some reason. For follow-up on that, see this thread.
[Edit: A few hours later we can correctly initialise the card and detect the card type...]
On the note of expansion bus, what would make more sense
I believe there is no single best way, and all will work. It's more a trade-off between 1. effort you're willing to put in, 2. usefulness of the result and 3. how close you want to stay with the Gigatron concept (minimal and simple hardware). Early in this thread we opted for SPI as the expansion bus concept to try first, instead of rolling our own, because it looked like a reasonable landing spot in that spectrum.
My card test program can now navigate the FAT32 structures to find and read the root directory. There's some 32-bit arithmetic needed for that, and I sorted out the last few bugs while on my way to the Cambridge Retro Computer Festival. Surprisingly, upon arrival it worked without further changes .
Here's the hex dump of the directory's first sector. The first 8 bytes are the volume name: GIGATRON
Now with formatting of the entries, and reading more sectors from the same cluster. Tested for exactly 1 card, and block loading is still done byte by byte. Improvements are needed in both areas. Video: https://youtu.be/N4Suhzn2foM
I suspect the slower part while listing the entries is actually the 32-bit to decimal conversion for the file sizes.
I guess I would have been too lazy and just outputted the size in hex.
Indeed, but once you set your mind to it... The hardest part was to squeeze that conversion into the 96 bytes of a typical code segment. But it exists now, and it sure will come in handy later again. And... I learnt a new algorithm while making it: Double dabble (which I subsequently didn't apply...)