I've already covered some of the ins and outs of getting cassette data on and off a bee using an ordinary soundcard on a modern computer, resulting in being able to play games on a "cassette" bee. The next logical step is disks.
Microbees are able to run CP/M, a predecessor to DOS, which allows you to read and write floppy disks (and even hard disks), and run quite a lot of off-the shelf software, like Wordstar.
Some of my bees have floppy disk controllers, and are thus able to run CP/M. I have a couple of 3.5" double density disk drives, plus a box of blank disks and a single solitary CP/M "system" disk. My system disk is a bit iffy. I've been unable to make other system disks from it as I believe the "setsys" program is broken.
As with tapes, there is a cornucopia of MicroBee CP/M software on the internet, most notably at the Microbee Software Preservation Project. The issue is getting the software off the internet and into the Microbee. Disk drives are expensive, physically large, and fragile. The disks they take are getting increasingly difficult to get. There are, however, other ways to store disk data.
The obvious one is Compact Flash. Compact Flash cards are still widely available, due to their popularity with high-end cameras. They have an "IDE compatability" mode, whereby they pretend to be a hard disk. Late in the life of the Microbee, a hard disk model was produced, so there's a "BIOS" available for hard disks. There's been quite a bit of activity on the Bee Board (a predecessor to the MSPP) and the MSPP in getting Compact Flash cards to work, with reasonably mature software, thanks to the efforts of Kalvis. I also built some hardware about ten years ago, which never really made it to prime-time, as it was very flaky.
So early this year I figured I'd resurrect these efforts, with the goal of making an accessible "coreboard" that could replace the memory board on most-any Microbee and allow the machine to boot CP/M from Compact Flash. The Compact Flash card could then be read and written to on a PC, facilitating easy file transfer, both to and from the bee, and making a machine that's straightforward to play with and nicely self-contained.
There are a bunch of different Compact Flash interfaces already built for 8 bit systems. I've based mine on "GIDE", by Tilmann Reh. GIDE is supposed to go in the socket for your Z-80 CPU, allowing pretty-much any system with a Z-80 to have an IDE interface.
A google search on Compact Flash interfaces for 8 bit systems will show the degree of frustration that people have in getting them to work. Some cards work beautifully. Others just refuse to read, or write. I dove straight into these frustrations and I think I've worked a lot of the issues out.
Anyway, firstly, the hardware. My IDE interface uses a pair of 74HC646 registered transceivers, as per GIDE. These chips allow us to latch data going to and from the CF card, such that we can talk to a 16 bit card with an 8 bit CPU. Some (many?) cards are able to be put into an "8 bit" mode, but from reading accounts on the net, this isn't guaranteed to work from one card to another. In any case, the 16 bit interface is supported by all cards, as it's part of the IDE standard.
GIDE uses a pair of PALs to create all the enables and clocks for the registered transceivers, as well as do IO port address decoding. I rolled both these PALs into one Atmel ATF1502ASL CPLD. These chips have 44 pins, are available in a reasonably friendly PLCC package (through-hole via a socket), and run at 5V, so they play nice with the rest of the Microbee without mucking about with level shifters etc.
Here's a schematic for my IDE/CF interface:
While I was laying out a board, I also added memory (up to 512K of RAM and 128K of EPROM), and a floppy disk controller:
iTead, a Chinese low-volume board house. I was very impressed with the quality and price of the boards, but they took ages to arrive. Much wall climbing ensued. I then set about assembling a couple. The only challenging bit is the CF socket, which has pins on 0.635mm centres.
What this means is that cs and iord/iowr happen synchronously with one another, and as I was about to learn this isn't necessarily good. After much frustration I found the Sandisk CF manual, which shows timing diagrams for "PIO mode IDE":
Things got a whole lot more reliable once I removed iorq from the chip select logic. That ensured that chip select was asserted well before iord or iowr, and held active well after. It was still a little problematic though in that the chip select was activated for both IO and memory accesses, where it should really only be active for IO accesses. Also, further reading of the manual says that chip select should only be asserted _after_ the address lines are valid, not at the same time.
The solution to this lies in more logic. The Z80 (Microbee processor) holds iorq, rd, and wr valid for just over two clock cycles, asserting them just after the start of the T2 clock cycle, and deasserting them after the mid-point of the T3 clock cycle. Note there's always an extra "wait" clock cycle in the middle:
Then iord & iowr are:
/* cfiorq state machine - generates a 2 clock pulse starting first low going clock edge after iorq */
state0.d = iorq & !state0 & !state1 # state0 & !state1 ;
state0.ck = !clk ;
state0.ar = rst ;
state0.sp = 'b'0 ;
state1.d = state0 & !state1 ;
state1.ck = !clk ;
state1.ar = rst ;
state1.sp = 'b'0 ;
cfiorq = state0 # state1 ;
I've further restricted them such that they're only activated for specific accesses to the CF which probably isn't strictly necessary, but hey, it works.
/* iord */
iord = tfradr & cfiorq & rd
# datadr & !lh & cfiorq & rd ; /* only assert iord for task file, cs1, and first data read */
/* iowr */
iowr = tfradr & cfiorq & wr
# datadr & lh & cfiorq & wr ; /* only assert iowr for task file, cs1, and second data write */
So here's what my timing looks like in the flesh, on my lovely HP1652B logic analyser, which is nearly as old as the bee. Firstly a single 8-bit read, of the status register on the CF:
In any case, more detail at the MSPP, including source code for the PLDs, firmware for the ROM, and Kalvis' wonderful CF CP/M.