Post #1647247

Fast forward to yesterday. I'd worked out that this fault wasn't appearing when I used ASIC5 mode on an ASIC4. I'd also worked out that only the first chip was being selected. So, on a 2MB SSD with 2x 1MB chips, I was seeing the first 1MB twice. So, my device/chip select logic was wrong. I'd looked at the SDK, worked out that ASIC4 could address up to 256MB of data (A0-A27), and guessed that the device selection bits were at A28 and A29. And then I'd... not tested it properly? At least it seems that way. But although that's what seemed logical, that's not what was happening. That byte that gets sent back to ASIC4's Register 1? That sets the addressing window on ASIC4. Which then sets the position of the device select bits. The position of the bits can be moved! So... if _sizecode is 1 (32KB devices), the device ID will be at: 14 + 1 = bits A15 - A17 if _sizecode is 3 (128KB devices), the device ID will be at: 14 + 3 = bits A17 - A19 if _sizecode is 6 (1MB devices), the device ID will be at: 14 + 6 = bits A20 - A22 if _sizecode is 7 (2MB devices), the device ID will be at: 14 + 7 = bits A21 - A23 if _sizecode is 11 (32MB devices), the device ID will be at: 14 + 11 = bits A25 - A27 if _sizecode is 13 (128MB devices), the device ID will be at: 14 + 13 = bits A27 - A29 So, if I send back 13 to ASIC4 Register 1, the device select bits will always be at A27-A31, no matter how big the SSD actually is. Likewise, if I send 1, it'll truncate every chip to 32K. Why haven't I included _sizecode of 14 for 256MB? Because I couldn't get it to work. It completely ignores those upper bits and only ever selects the first device/chip. I don't know if there's a secret way to get that working, but it's not documented. As no 256MB #Psion SSDs exist, I might not know for a very long time.