Expansion bus

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
jwolfram
Posts: 18
Joined: 07 Jan 2019, 20:11

Re: Expansion bus

Post by jwolfram »

I've not understand the card detection code completely but I have looked at a former project of me (AX82). SD cards (also SD V2) are addressed "per byte" and SDHC cards "per sector". They differ in the answer of CMD58. SD cards will return with bit 6 is zero and SDHC should return a result with bit 6 is set to one. So probably the wrong sector is addressed on SDV2 cards. The statement of xopr that a SDHC card works may be also a hint.

In the meantime I will try to test a SDHC card...

Joerg
jwolfram
Posts: 18
Joined: 07 Jan 2019, 20:11

Re: Expansion bus

Post by jwolfram »

A test with a 4GB SDHC card seems OK. I copied mosaic.gt1 to the card and renamed the file to system.gt1 and now all seems to be OK. But I have seen that the CMD58 result on the screen is still 00. As far as I know, bit 6 should be set for SDHC cards.

And there are further ideas... With adding two additional functions:

- read back the last written expander control byte
- read the state of the MISO lines

we should be able to use the free CS2,3 and MISO2,3 lines with two diodes (from CS [C] to MISO [A]) and two pull-up resistors as a software controlled I2C master interface.

Joerg
Attachments
gt_sd2.jpg
gt_sd2.jpg (94.8 KiB) Viewed 10015 times
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

Don't trust the output too much :-). This is still code that was supposed to work on one specific card I had at hand. And it appears to work on several, but for the wrong reason. I best address it when I can resume with the GTOS shell.

I like the idea of turning 2 of the ports into a single i2c port. Could you provide a sketch on how you have that in mind?
jwolfram
Posts: 18
Joined: 07 Jan 2019, 20:11

Re: Expansion bus

Post by jwolfram »

My first draft has the advantage that it don't need any modification on the expansion module. One disadvantage are SCK pulses during I2C communication. This is because SCK must be set to one to read the status of the MISO lines. If the SS line is high (SPI slave is not selected), this should be no problem. Otherwise there is need for a small glue logic which helds SPI-SCK down if SPI-SS is HIGH.

Joerg
Attachments
i2c.png
i2c.png (1.12 KiB) Viewed 9981 times
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

Do you mean that any i2c transfer shouldn't be operated in parallel with SPI0/1 activity? That's not an unreasonable constraint. If software can handle it, there's no need to add hardware for it. The mantra still stands.

Anyway, in this schematic, SS2/3 must be kept low during SPI transfer so that MISO2/3 read as low. That's because the SYS function for SPI transfer doesn't have any room for masking instructions that can isolate the correct MISO bit. Instead, it decides upon all of them being zero or not what the incoming bit must be. That is also why we now have pull-down resistors on the MISO lines. Is such low-low state a safe idle state for the i2c bus?
jwolfram
Posts: 18
Joined: 07 Jan 2019, 20:11

Re: Expansion bus

Post by jwolfram »

I think, there are two ways. The first needs additional hardware, for instance 3 AND gates.

MISO2 = (CS0 & CS1) & SDA
MISO3 = (CS0 & CS1) & SCL

this ensures that MISO2/3 are low during SPI transfer.

On the other hand it should be possible to held SCL and SDA low in idle state. The only restriction is that there can't be a second master on the I2C bus. The trick is to switch first SCL to LOW and then SDA after the stop condition of the current transfer. This prevents the slaves to recognize a new start condition at this time.
At the beginning of a new transfer SDA must go to HIGH before SCL does so the slaves will get a (unnecessary) stop condition before the transfer starts with a start condition.

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

Re: Expansion bus

Post by marcelk »

If there's another master on the i2c bus, there isn't much we can do. As I understand it, we have to become responsive to its clock. That's the same problem we faced with PS/2 and that we ran away from.

But given that SPI software support is still ploughing on I believe we have time to get it right. i2c support looks harder to me, but a very good use of those two ports.
Hans61
Posts: 102
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Expansion bus

Post by Hans61 »

I recreated the original with all changes. You can find everything here:
https://github.com/hans61/Gigatron-TTL/ ... ansion128k
For Marcel and the new "dev128k7.rom" and everyone who wants to avoid GALs.
gigatron-with-expansion-dualdrive.jpg
gigatron-with-expansion-dualdrive.jpg (1.03 MiB) Viewed 1192 times
lb3361
Posts: 360
Joined: 17 Feb 2021, 23:07

Re: Expansion bus

Post by lb3361 »

Hans61 wrote: 19 Feb 2023, 11:58 I recreated the original with all changes...
Congrats. I like the simplicity of your dual drive fix!
Post Reply