Microdrive replacement using Flash memory

Introduction

The way I see this, it should be something physically similar to the Microdrive, or at least in keeping with the Rick Dickinson designs of the time. It will connect to the drive connector on the Interface one and to all intents and purposes will appear to be a microdrive to the Interface.

Obviously, I could look at the source of FUSE to see the details of the microdrive emulation, but I'd like to figure out as much as I can myself before going there.

Possible issues and workarounds

• The major limitation will be that a microdrive is limited to 128k. I believe the best way to get around this will be for the device to emulate the full 8-drive configuration and have a virtual cartridge loaded for each position.
• Storing the data. From thinking about it, I think the best solution would be a FAT32 filesystem on the flash storage medium, with each virtual cartridge stored as a standard emulator MDR file. These are pretty close to the physical format of the drives with pretty much the main difference being that the data preamble is not stored in the file.

Thoughts on implementation

• Controller: Some kind of microcontroller is going to be needed - The particular model will have to be chosen depending on how complex the final design will be and will have to be within reasonable cost parameters. I have an Arduino board lying around which I've never got the chance to start working with, so perhaps that might be a good place to start - The Atmel ATMEGA168. It has plenty of IO lines and should be cost-effective.
• Physical interface: Having 8 buttons on the unit for each cartridge with multicolour LEDs underneath would provide the best tactile and visual indicator for drive status. An unloaded drive would be unlit. A loaded but inactive drive would be green and a loaded active light would be red. The button would be held down for perhaps 3 seconds to initiate an eject process if the drive is in loaded-inactive state. There might be an override for an active drive, like a 5 or 6-second button press to force an eject.
• Graphical interface: A display of some sort would be almost mandatory to select cartridge files, which would be loaded by selecting a file, perhaps with up and down buttons or a scroll-wheel and pressing the button of an unloaded drive. Whether this would be a simple 2 or 4-line character display, or a repurposed mobile phone display (ideally QVGA or close to it) would probably be determined mostly by cost and the difficulty of driving the display. You would think that simple character displays would be pretty cheap by now, but they don't seem to be. A 4-line display with scroll-wheel would probably be the best compromise between cost and usability.

Technical objectives

The drive will have to interface to and emulate the following signals on the drive PCB connector:

• ERASE: The ERASE signal is driven high to activate the erase head. The emulation will need to take care of clearing the data underneath the virtual heads.
• R/W: Write signal is active low.
• COMMS OUT and COMMS CLK: This is an important one to get right as it controls the drive selection and drive motor. In the real device it also enables power to the LED and erase head. Drive selection is implemented by using a 1-bit shift register. As the drive takes a bit in to its shift register, it sends its own one out to the drive beside it. As a result the bit travels from drive to drive. The code in the interface 1 ROM selects drives by sending out a fresh set of 8 shifts, with the set bit landing on the preferred drive. In theory all 8 drives could be activated by shifting 1s into each drive's shift register. What happens on a real setup when this happens? I doubt you get the equivalent of RAID 1 mirroring, but there must be some kind of conflict somewhere that may need to be modelled by the emulator, do the signals on DATA 1 and DATA 2 merge together like a logical OR operation, or would the next drive in the chain sink the incoming current from the previous drive when a 0 is sent and act more like an AND operation?
• WR PROT: The emulator should provide the user with the ability to mark a virtual cartridge as write protected and this will present itself accordingly on this pin.
• DATA 1 and DATA 2: Data is written to and read from the microdrive as frequency modulated signals with one data byte for each head, meaning that two bytes always have to be transferred. The Interface 1 will take care of presenting these to the Spectrum in the correct order. I think the signals on the DATA 1 and 2 lines are the serialised bits for the bytes going to each track on the tape. I need to throw together an LPT port logic analyser to get a quick view of what's happening here. It's a question of detail as to whether the device will record and play back the preamble data, or will it take it as granted that it's going to be the Interface 1's standard data and just discard and recreate it as required.

Designs

Technical breakdown - Click here for a detailed analysis