Yes, chained power supplies may be an issue. Delayed resets could be possible - I'm not sure exactly what is needed on that reset line - it might be a H,L,H transition, not just a rising pulse. This might end up being a schmitt trigger or a 555 circuit.
I'm eagerly awaiting heater fixing the exz80 exerciser, but meanwhile, I have had a crazy idea. How cool would it be to be able to access the SD card files directly from CP/M?
I think it is possible. There are 6 simple commands the sd card driver uses:
Start reading file names
Read next file name
Open a file
Read n bytes
Write n bytes
Close a file
I just wrote some quick code in spin to capture an OUT to a nominal port (70H) with n=0 to 255 passed to that port.
Then a tiny .MAC program in CP/M and I can capture that and use a 'case' command to go to the right pub.
Reading file names should be easy, so a DIR of the sd card should be possible.
But reading and writing files may be more difficult. The problem is you can't read the file in pieces as the sd card driver can only have one file open at a time, and it already has the disk image file open, so it can't open another one.
How could this be solved?
1) is there an sd card driver than can have two files open at once (probably not).
2) buffer the entire file in CP/M memory. The machine code might be only 1k and CP/M sits right at the top of memory, so files up to 55k or so could be copied in this way.
3) use the rest of the sram chip, up to 448k as the buffer. But then you can't use it for anything else.
I'm moving towards 2, as the only file in CP/M I can find that is huge is wsprint.ovl (147k). The rest are mostly <30k.
Thoughts would be most appreciated.
' r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD
' this method relies on the SD file using contiguous sectors !!! Packed 4 x 128 bytes per 512 byte sectors
err := \sd.readSDCard(sd_block_number, @disk_buff, 512) 'read the block! (complete 512 bytes)
' r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running)