I built the SDHC interface using a PIC18F25K40 which is on my main PCB along with all the other standard ACE chips. The interface relies on there being a ROM between e000-ffff to contain the low level code for communication between the Z80 CPU and the PIC, plus the new FORTH words which use that code. It doesn't really need much RAM as it only uses PAD as workspace but it would have been daft not to fill the remaining address space with RAM. The interface between the PIC and the SDHC card is done using a standard SDHC SPI board like this:
- sdhc.jpg (18.4 KiB) Viewed 5928 times
which is mounted externally and provides for 3V/5V level shifting plus GND, Vcc, Miso, Mosi, Sclk & Cs. There is a corresponding 6 pin SIL header on the main board.
The PIC connects to the ACE circuit using d0-d7, a0-a2, *RD, *WR and *IORQ. The address lines allow selection of the port which, in this case, is coded to 7. If it ever became necessary I could expand the decoded port range rather trivially by using a3 as well.
As for the new FORTH words they are:
LD, SV, BLD, BSV (equivalent to the tape LOAD, SAVE, BLOAD & BSAVE), RM (remove file), LS (list files in the current directory),
MKDIR (create directory), RMDIR (remove empty directory), CWD (change working directory - I'd have called it CD but I use hex almost exclusively), HOME (go to root directory), LDADDR (put most recent load/save address & length on the stack) and SDINIT (used for hot swapping SDHC cards). All are primitives.
Technically I went for minimal chip count so the only specific interface chip is the PIC. It relies on the PIC running at 64MHz which is fast enough for it to be able to poll its control lines and to sequence things at the correct points of the Z80 data sheet timing diagrams. Of course that means that all the code is written in assembler. I suppose I could have written the SPI stuff in C but assembler is more satisfying. Interrupts couldn't be used as they would consume far too many clock cycles and very quickly throw out the timings. The CPU acts as master and the PIC as slave in all communications. All very low-level-hobbyist-dirty. Happily, during development, I never ended up with two chips driving the same control lines at the same time. In part I did it all as a proof of concept.
On the filing system side, FAT32 is used so that data can be transferred to/from a PC. File names are 8.3 short form. The first block of each file acts in the same way as the tape header on an ACE in that it stores sysvars and load/save addresses and lengths. For dictionary loading commands the original ROM code is executed as a last step to ensure (e.g.) that all links are adjusted correctly.
Its pretty zippy too. It loads a 6KB Z80 assembler of mine in a couple of seconds.
That's all I can remember off the top of my head - if anything else occurs to me I'll post another message. I intended posting this sort of information on jupiter-ace.co.uk but, after recent events there, I've held off.