After experimenting with a number of schemes to utilize mass storage based on current flash technology, I found the 4d Systems uDrive is one of the best I've tried. 4d Systems makes a micro-DRIVE (uDRIVE-uSD-G1) that is a tiny (postage stamp sized) interface to micro SD memory cards (yes, the kind used in many cameras, cell phones, and other hand-held devices.) It has a in-line 5-pin (.1" centers) male plug at the bottom, so the interface to it is simple.
What makes it relatively easy to use is the "GOLDELOX-DOS" firmware that is incorporated in this tiny device. In particular, there are three "commands" that are most useful: dump the contents of the micro SD card directory, read a file from the card, and write a file to the card. There is more to GOLDELOX-DOS than just that, but I seldom use anything else. The 5-pin interface is ground, +5v, Tx, Rx, and reset. So, it can be hooked directly to many UARTs that are found in older systems. The micro SD card serves as a sneaker net between these old computers and modern day PCs. All that is required is the uDrive, a micro SD card, and one of these multi- function card readers that can be plugged into a USB port. The USB card reader is used to manipulate the content of the micro SD card on the PC side. These readers can be purchased for anywhere between about $6 and $20.
GOLDELOX is better than many of the other firmware "systems" on the market, because it provides straightforward handshaking between the uDrive and the host system. I have tried a device that implements a serial interface to a compact flash module, but there was no handshake at all, so timing during up- and downloads became a serious problem. Very unpredictable results. There is another device available that incorporates an FTDI interface chip (mentioned on my Web site). It is designed to provide a legacy serial port to a flash memory stick (also know as a "thumb drive"). This device uses hardware handshake, and presents a serious programming challenge (interrupt driven software REQUIRED).
The only disadvantages that I can think of for the uDrive is that it is NOT compatible with the newer HC flash memory cards (the company claims that it will be in the future). This is not a problem so much from the capacity standpoint, but merely because non HC memory cards are becoming harder to find now. Standard (non HC) micro SD cards are 2 GB, or smaller, in capacity. This is an enormous amount of storage as far as older microcomputers are concerned. The micro SD card is formated with a FAT filesystem, because that is what GOLDELOX wants to see.
The other disadvantage is that handshake is implemented by passing short bursts of data between the uDrive and the host computer. The receiver "ACK"s after each is read properly. The length of these "packets" is user selectable at up- or download time, but the maximum size allowed is 50 bytes. Not only is this a relatively small amount of data, but 50 is a *very* strange number. I've found that from a programming point of view, a binary quantity is far easier to use, so I wonder why 50 and not 64? I've ended up using 32 in my software, only because it is easier -- certainly NOT faster. This disadvantage can be offset to some extent by bumping up the baud rate of the interface. However, many older systems are limited in the speeds available via the UART hardware. It seems to me that the uDrive baud rate capabilities far outstrip those of most older, legacy systems.
The advantages of the uDRIVE-uSD-G1 far outweigh the disadvantages, and I've had great success with one on a 10 MHz Z80 SBC that I designed. It provides a great way to move files to and from the Z80. The "hard drive" on the SBC is a compact flash module with IDE interface.
I'm posting the code I've written to read from, and write to, the uDrive from the Z80, as well as display the contents (sort of a directory, but not nearly as fully featured) of the micro SD card. These are works in progress, and not intended to be polished applications. I only put them here to serve as a way for others, who may be interested in using the uDrive, to get started. If you fix, or improve, the code, please get a copy to me!
Also, go to 4d Systems' Web site (www.4dsystems.com.au) to find more detailed information on the uDrive and the GOLDELOX firmware documentation.
My directory display application is flawed in that it dumps the directory provided by GOLDELOX into memory, before it displays it. Obviously, a large directory (approaching 60k bytes) will cause a Z80 system crash. Most processors are not fast enough to format and display it on the fly while it is coming from the uDrive (no handshake here). If you figure a way to do that, I'd like to hear about it.
I know that there are some situations where my read application fails. I have not figured out why yet. Most of the time it works fine.
I haven't had a great deal of experience using the write application yet, and I have not seen it fail at all. It may be the best of the lot?
I'm thinking about writing a utility that would do a dump of the 512b blocks on my compact flash "hard drive" (IDE) to 512b blocks on the uDrive. I need a back-up/restore function of the "hard drive", and these little micro SD cards have such enormous capacity. Perhaps that would be a good way to back up the content of the compact flash? It would probably be very slow, however.
Have fun, and remember -- I'd like to hear about improvements and fixes.