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.

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.

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?

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.

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?

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.

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.