Expansion bus

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

xopr wrote: 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!
jurkstas wrote: 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.
jurkstas
Posts: 20
Joined: 05 Aug 2019, 17:06

Re: Expansion bus

Post by jurkstas »

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.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

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...
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

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...]
Attachments
Update....
Update....
IMG_5410.jpeg (359.79 KiB) Viewed 8251 times
CardTest.gt1
(660 Bytes) Downloaded 338 times
CardTest.gcl
(14.39 KiB) Downloaded 337 times
First messages
First messages
FirstWords.jpg (214.85 KiB) Viewed 8297 times
jurkstas
Posts: 20
Joined: 05 Aug 2019, 17:06

Re: Expansion bus

Post by jurkstas »

This is impressive.

On the note of expansion bus, what would make more sense: PC/104, Apple 2 style (w or without decoding on the motherboard), S-100, something else but standard or something custom for Gigatron?
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

jurkstas wrote: 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.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

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 :o.

Here's the hex dump of the directory's first sector. The first 8 bytes are the volume name: GIGATRON
Attachments
Rootdir.jpg
Rootdir.jpg (490.36 KiB) Viewed 8224 times
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

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.

Screenshot attached:
Attachments
Listing.jpeg
Listing.jpeg (242.25 KiB) Viewed 8177 times
User avatar
DavidHK
Posts: 31
Joined: 25 Aug 2019, 12:59

Re: Expansion bus

Post by DavidHK »

Wow, very nice! I guess I would have been too lazy and just outputted the size in hex. ;-) So I guess sooner or later I should get to soldering again to have access to files.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

DavidHK wrote: 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...)
Post Reply