Expansion bus

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
User avatar
DavidHK
Posts: 29
Joined: 25 Aug 2019, 12:59

Re: Expansion bus

Post by DavidHK » 24 Sep 2019, 19:20

I am currently trying to add the expander to my emulation and I am a bit confused about the MISO lines, maybe I am mixing up the logic levels. As far as I understood from the schematics, the four MISO lines would be pulled high by default, I assumed that to be a 1. To send data from the first SPI port I just set its bit to 0. (That is, I switched from 0x0f to 0x0e).

But the function SYS_SpiExchangeBytes_v4_134 seems to expect all bits set to 0:

Code: Select all

  ld([0]);                      C('Get MISO')#24+i*12
  anda(0b00001111);             #25+i*12
  beq(pc()+3)                   #26+i*12
  bra(pc()+2)                   #27+i*12
  ld(1)                         #28+i*12
And indeed, when I switch to 0x00 for the MISO input in my emulation it seems to recognize the answer. Why would the other three bits be zero as well, does SPI use active low for its data lines or did I miss something else?

Edit: Oh, reading the thread again, it looks like I missed the part where the resistors were patched from pull-up to pull-down...

User avatar
marcelk
Posts: 400
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk » 24 Sep 2019, 21:27

DavidHK wrote: I am currently trying to add the expander to my emulation
Great!!! All current emulators corrupt memory when running code for the expander board. Beware that inside every SDC/MMC card there is a microprocessor with complex behaviour waiting for you! Currently my experimental CardTest program goes through most of the init dance. And for sector reads it verifies the 16-bit checksums (but I'm tempted to drop that part). Even the MCP27S13 GPIO chip isn't very straightforward.
Edit: Oh, reading the thread again, it looks like I missed the part where the resistors were patched from pull-up to pull-down...
Yah, the schematic needs an update. The change to pull-down resistors helped simplify the software a bit. I'm not convinced it can stay this way: every document I read recommends pull-ups, because the card might not have a pull-up transistor for their data out line. My SDCard breakout board doesn't buffer this line either, so I may have been lucky with the card I'm testing with. This is certainly not a mature design yet.

User avatar
DavidHK
Posts: 29
Joined: 25 Aug 2019, 12:59

Re: Expansion bus

Post by DavidHK » 25 Sep 2019, 21:19

Attached is a screenshot with my work-in-progress so far. Now I have to find out what the issue is, maybe I didn't build the image of the "SD card" properly. At the moment my implementation is far from complete, I am just giving the minimal answers that CardTest.gcl seems to expect -- I don't even calculate CRCs yet.

Edit: Of course I couldn't stop there, I created another image and now I do get "Vol.ID 0200 OK". But no directory listing so far. Oh well, another day...
Attachments
gigatron-sdcard-emu-01.png
gigatron-sdcard-emu-01.png (9.54 KiB) Viewed 400 times

User avatar
marcelk
Posts: 400
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk » 25 Sep 2019, 22:04

Nice, the ctrl instruction is talking to something! My init code is in a flux of changes, not at all pretending to be correct and/or complete and/or well organised. As long as it gets better that's fine with me... What I see in your screenshot is that it doesn't detect a card type (I have V2 now which should display as 02 instead of 00). For detecting V2 cards, the CardTest program needs a correct echo of the 0xAA byte in the CMD8 message. Here it doesn't receive that, but then continues anyway and probably uses the wrong addressing method (byte addressing i.s.o. block addressing). That conversion function (SectorToByte) is broken at this moment. But even if it works it will probe garbage anyway because it shouldn't have gotten there. I think in the end it doesn't see the 0x200 sector size from what is supposed to be the first sector of the primary partition.

[Edit: ReadVolumeID is currently checking for the 0x200 sector size, not the 0xAA55 signature as I wrote earlier.]

User avatar
DavidHK
Posts: 29
Joined: 25 Aug 2019, 12:59

Re: Expansion bus

Post by DavidHK » 26 Sep 2019, 16:43

Don't worry, I don't expect CardTest to be more than what the name says -- a test. ;-) But I try to join the test by keeping my emulation somewhere close to the current proposals. And I am also aware that the emulation will not be able to substitute testing with a real SD card -- at least where the SPI protocol is concerned.

Listing the directory works, now I have to tidy up some code for the emulation.
Attachments
gigatron-sdcard-emu-02.png
gigatron-sdcard-emu-02.png (10.14 KiB) Viewed 363 times

User avatar
DavidHK
Posts: 29
Joined: 25 Aug 2019, 12:59

Re: Expansion bus

Post by DavidHK » 26 Sep 2019, 19:06

I have now pushed my work so far to my branch (I haven't made a pull request yet, I don't think it is finished at this state).

https://github.com/dhkolf/gigatron-rom/ ... f/libgtemu

One thing I am not quite happy about is the SD card image. You need not just a partition image but a full disk image. I followed these instructions for Linux: https://www.adayinthelifeof.nl/2011/10/ ... sk-images/ But it would probably be very cool to have a Python script that can create such a file without needing loopback devices and so on.

User avatar
DavidHK
Posts: 29
Joined: 25 Aug 2019, 12:59

Re: Expansion bus

Post by DavidHK » 29 Sep 2019, 16:43

I have now pushed a further change to my emulation work branch that adds a virtual MBR in case the image file starts directly with a FAT32 header. A pure single-partition FAT32 image without an MBR can usually be created easier (by more tools).

The next few weeks I probably won't be able to do much coding, afterwards I will try to polish the SPI/SD card interface some more -- and I guess write-access would also be necessary.

User avatar
marcelk
Posts: 400
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk » 29 Sep 2019, 18:48

DavidHK wrote: The next few weeks I probably won't be able to do much coding, afterwards I will try to polish the SPI/SD card interface some more -- and I guess write-access would also be necessary.
I don't see FAT32 writing arriving by that time frame. FAT32 writing is more complicated than reading, and not required for booting. By the time the SDC/MMC boot process is properly consolidated in a ROM, we're looking at the end of the year. The good thing is that from that moment on, writing capability can later be loaded from the card. No need for a ROM update to gain such capability.

natevw
Posts: 3
Joined: 12 Jun 2019, 18:58

Re: Expansion bus

Post by natevw » 23 Nov 2019, 01:54

Got my PCB months ago (thanks!) and the rest of the BOM from Digikey a few weeks ago, and trying to catch up. (BTW, if anyone would find the Digikey BOM useful, let me know and I can extract it from the rest of the order and share.)

Before I start soldering, I wanted to confirm that the tweaked resistor values and bodge wires documented in viewtopic.php?f=4&t=64&start=50#p804 are still the most current game plan as far as h/w side goes?

User avatar
marcelk
Posts: 400
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk » 23 Nov 2019, 09:27

natevw wrote:
23 Nov 2019, 01:54
Before I start soldering, I wanted to confirm that the tweaked resistor values and bodge wires documented in viewtopic.php?f=4&t=64&start=50#p804 are still the most current game plan as far as h/w side goes?
That is correct.

On the software side, some heads-up:

Between ROM v4 and the current DEVROM a little bug got squished out: by accident the SYS_ExpanderControl function in ROM v4 steps upon zero page address $0081. If your program grows sufficiently large (as CardTest.gt1 has done), you may have expanded your variables there and get unexpected results. I now provisionally relocated that to a safer location in zero page ($002b a.k.a. sysArgs7) until I find a better solution. (It will have to relocate again, because this location is also used for the pen color in Tiny BASIC, and it must stay like that once that gets its own SSD/MMC support.)

Second, after recent refactoring CardTest.gt1 is currently half broken. Recovering this is next on my list. I want to evolve it into a mini command line, but also have a card boot option in the ROM. That needs a bit of rearrangement.

Post Reply