Unless you were lucky enough to be able to afford a floppy disk drive, you probably used cassette tapes to store programs and data if you used pretty much any home computer in the 1980s. ZX Spectrum users, however, had another option in the form of the Microdrive. This was a rather unusual continuous-loop mini-tape cartridge that could store around 100 kB and load it at lightning speed, all at a much lower price point than a floppy drive. The low price came at the cost of poor durability however, and after four decades it’s becoming harder and harder to find cartridges that work reliably. [Derek Fountain] therefore set out to make a modern Microdrive emulator that stores data on SD cards.
Several projects already exist to replace Microdrives, but they typically also need the ZX Interface 1, a serial/network expansion module that’s becoming equally hard to find. Hence [Derek]’s choice to make his emulator a completely standalone system that directly plugs into the Spectrum’s expansion port.
The system is housed in a 3D-printed enclosure that holds two PCBs. Three Raspberry Pi Picos run the show inside: one to hold the ZX Interface 1’s ROM image and interface with the Spectrum’s bus, another to simulate the Microdrive, and a third to run the user interface and communicate with the SD card. The user can choose between eight tape images stored in .MDR format by using two pushbuttons and a rotary encoder, with a small OLED display showing the machine’s configuration.
While you might think that three dual-core 133 MHz ARM CPUs would run circles around the Spectrum’s Z80, it actually took quite a bit of work to get everyting running properly in real time. The 3.5 MHz bus clock rate gave the second Pico precious little time to fetch the required bytes out of its flash memory. Its RAM was fast enough for that, but too small to hold all eight tape images at the same time. In the end, [Derek] settled on using a separate 8 MB SPI DRAM chip that could easily keep up the data rate, with the Pi just using its GPIO ports to shuttle the data around.
All source code and extensive documentation are available on Derek’s excellent blog post and GitHub page. Be sure to also check out [Jenny]’s detailed review and teardown if you’d like to know more about the weird and wonderful Microdrive system.
Thanks for the tip, [Andrew]!
That’s really cool and all, but.. Why does the Speccy so much love? It’s not a great computer, actually. 😕
Nostalgia.
I understand. Poor guys, though. They have had deserved better nostalgia memories. IMHO. 😔
Ah yes, the dead flesh keyboard, capstone rollers chewing up precious original game tapes and finding the time when the only telly in the house was not being used by adults to watch corra or enders , takes me right back.
It’s capstan, not “capstone”.
And it did not work like that, eating tapes. Do some research before you post.
Because it introduced the sons and daughters of truck drivers, coal miners and steel workers to home computers, whereas the offspring of lawyers and teachers got C64 and up.
My younger brother had a ZX and it’s internal BASIC would parse and evaluate a string variable’s expression. The C64, with the tease of a real keyboard, had a crummy BASIC that couldn’t do that. Go Sinclair! Ra, Ra.
I had several Zx computers and was proficient at coding, but when the rich kid next door got a C64 and her dad asked me to teach her I found the failings with the C64 BASIC and ended up deferring to my own machines. Nearly married that girl too.
I’m a son of postman. Hardly a middle class job, but I had a C64.
It made a generation who can code
A bubble before proper consoles, who all know
That the games you get today, may be very flash
But there’ll never beat the thrill
Of getting through Jetpac
Hey Hey, 16K, What does that get you these days?
You need more than that for a letter
Old Skool Ram Paks are much better.
MagicMiner !!! …and even Elite ran on it
ManicMiner*
We had played arcade games from the 70’s and saw the spectrum being advertised. I for one would weight up spend 10p on an arcade game which limited me on what I had in my pocket. While at the ZX you’d pay £4.99 make sure it was a game you’d want to play an unlimited amount of times. The zx81 was for us to learn to program and ant attack. So like cars and manufacturers we stick with what we know. I was also a spectrum competition player.
Bear in mind that many people in Britain were flat broke in the ’80s due to the economic conditions at the time, and the Speccy was the only computer many people could afford. If you had a choice between a ZX Spectrum and no computer at all, what would you choose?
Commodore plus4 on an epic fire sale discount. Unfortunately.
Spectrum BASIC is the primary reason the UK has a competitive IT industry.
You’re right. It’s incredibly limited, but those limitations sparked huge creativity and that is exactly why a lot of us still enjoy the challenge of it.
It was the computer that many people were introduced to computing. In the UK, in many countries of southern Europe. And later in Estern Europe via many clones.
People, especially in the early 80s were very tight financially in these countries. A computer was expensive, and the ZX was… Accessible.
I think there’s a whole community that would question that. The Spectrum had its faults and limitations but it is a well understood machine and people wrote software that drive the hardware to its limits to make great games and software. There is still a lot of nostalgia or there for the humble speccy.
It was my first computer. Yes, it was built down to a price, and it had many weaknesses, but I still loved it, it taught me a lot, and it was the start of a path that ultimately led to a career in IT. And I lusted after an Interface 1 and a Microdrive, though in practise their unreliability would probably have driven me mad.
100% agree with everything in this comment!
You always hear about the unreliability of the microdrives and everyone repeats it when writing about it. Reality was that it worked fine and a big improvement over cassette tapes. I had microdrives for the zxspectrum and still own a QL and I never had any problems with them. I still have my QL and believe it or not some microdrives still load after all these years. You just had to handle them right. Never touch the tape, never remove them when the motor is still spinning and always put them back in the protective sleeve after use.
Hi there! While I’m not Spectrum owner (merely had an ZX81 as far as Sinclair goes), I can partly relate to this, I think:
My first computer I got was a Sharp MZ series “Personal Computer”, which had an Quick Disk option.
While it wasn’t a real diskette, but more like a magnetic record (one track in a spiral), it was *much* better than a datasette.
But even here, there’s a difference.
Real datasettes had a higher quality tape inside, resulting in a better signal-noise ratio. This made less error-correction necessary.
That’s something many users didn’t know, maybe. A real datasette drive does store square waves on a cassette. They’re still audible signals, but have sharp edges, as if a cassette recording was being overloaded (but not distorted).
So if smart kids used these dual cassette hifi stereo deck to make copies of their datasettes, they ended up with inferior copies using sine wave.
If it wasn’t for the schmitt-trigger cirvuit in the and the error correction in the home computer, it wouldn’t even work properly.
Another factor is the number of dublicated/repeated data blocks. The cassette routines in computers like the Sharp MZ-80K/700/800 did tend to use a lot of them, to counter poor quality cassettes. That’s why loading times were so poor. On homebrew titles, at least, which used tapecopy and other programs to re-write the programs from RAM to cassette.
Commercial, pre-programmed datasettes did likely have less duplicates, thus. Their magnetic tape was good enough.
The common speed of 1200 Baud wasn’t that bad, actually. It was a good compromise between speed and ruggedness. If it was slower, wobble/warble etc. would hit data blocks. If it was much faster, the signal-noise ratio would be worse.
There’s no such thing as a square wave in the analog world. There is always a finite time needed to transition from one state to another. What you get is a bunch of sine waves summed, and over/undershoot at each transition. The limiting factor for digital tape was the media, so even a high quality tape couldn’t cope with components greater than between 12 and 16KHz. The CUTS tape standard used 8 cycles at 2400Hz for a one, and 4 at 1200Hz for a zero. Later, faster standards used fewer cycles and higher frequencies to increase speeds but they were still limited to the audio capabilities of a cassette. HiFi copying thus worked just fine PROVIDING you set the recording level high enough and used decent tape.
“…just fine PROVIDING you set the recording level high enough and used decent tape”
Well isn’t that just what Joshua was trying to say with the focus on “smart” kids who wanted to make a quick copy, but failed to setup their equipment properly. Now combine that with a stereo head reading a mono (missing 15% of the signal) then recording it back to the other tape, again with a stereo head making a stereo track which will be read by a mono head, which also notices another 15% in signal strength loss due to the gap.
Then there is the issue of the head alignment. All things combined, there are a lot of things that can go wrong and did for many kids. A perfect recipe for a high error rate. I won’t even mention the possible introduced speed related errors, dolby suppression, expensive metal tapes versus the intended type-I (because home computers were designed to use the cheapest tapes type-I tapes, since these were the only kind of tapes available during the development of these devices but also the most practical ones regarding signal recording levels. Noise itself was never an issue, the signal on the tape was either a positive or negative flux, saturation recording at it’s purest. And last but not least, the high-speed dubbing… reducing the signal even more if the cheap deck doesn’t compensate for the required higher bandwith.
The fact that you could make quick copies using you home hifi equipment was the main reason kids kept trying, but not everyone was successful. And whether it did or didn’t work and how we look at the subject 50 years later, is mostly based upon personal bias. Which is never a good base for any discussion.
The fact that commercial production houses used ordinary audio equipment to copy the tapes also proves that it was possible AND that these professional know what they are doing but also keep in mind that their setup wasn’t ordinary household boombox (cheap) hifi audio gear.
… and refelt them if required. I still get some original cartridges to work, occasionally!
I had a floppy drive for my spectrum. Took some assembly programming and loading in video memory to get some programs running from disk that would normally load from tape. Loads of fun then
The main problem with them these days is that the felt pad under the tape tends to perish with age. The issue, and potential solutions, was covered in the latest edition of The Spectrum Show: https://www.youtube.com/watch?v=pqM3aAq-UiU
Why on Earth would you want to hold 8 tape images in RAM? You have an SD card that is WAY faster than the Spectrum, never mind the original microdrives (even a small, cheap SD card should be able to handle 6MB/sec, that’s all 64K of memory in 1/90th of a second). A small, in memory cache of a few sectors per drive should be plenty.
Even the cpu on the sdcard is more powerful than the speccy
The Pico which does the IO isn’t connected to the SD card reader. There aren’t enough GPIOs. The SD card is attached to the Pico which does the UI. So in order to read a byte directly from SD card, the request and response would need to be transmitted over the Pico to Pico link, which is fast, but not that fast. Also, although 6MB/sec is good in theory, the overhead of the SPI bus transaction and FatFS filesystem means it’s not possible to read or write a particular byte in a particular MDR file anything like that quickly
The Interface 1 ROM software reads individual bytes from the tape using Z80 IN and OUT instructions. Those complete in around 11 Z80 T-states and the Pico needs to respond inside that timeframe if it’s to run without slowing the Z80 down with WAITs.
Caching a few sectors at a time makes no sense on a loop of tape which is read sequentially. While the motor is on, the blocks are flowing under the tape head one after the other. If you had a cache you’d just spend your time constantly feeding it regardless of whether the data was needed or not.
A Pico has two cores. One core can talk to the SD card (or other Pico) while data is being read by the Spectrum on the other core. The reason you’d want to cache a few sectors at a time is due to the setup time and bursty-ness of the SD card (you want the data available well in advance of the Spectrum requesting it, and you have the file system and address setup overheads to allow for). You’d effectively be performing interleaved reads or writes (one cache block being filled while the other is being processed). SPI is also much faster than the Spectrum (you should be able to run it at well over 1Mbit/sec, and a microdrive runs at 160Kbit/sec).
Both cores are in use. One is handling the Z80’s IN and OUT instructions, the other is managing user interface issues (status, cartridge inserts, ejects, write protection, etc.) That Pico is also running 2 PIO programs, one for low level comms to another Pico, and one driving a level shifter’s direction. There isn’t much spare processing or GPIO capacity in it.
It’s very easy to point to a particular piece of a complex project and say “why on Earth would you do it that way? That’s so inefficient!” But in practise, getting everything working together requires compromises. Having all 8 MDR images immediately accessible in an external RAM chip was one such compromise.
You’ve got enough spare cycles (and free pins) to read an SPI RAM chip. If you can do that then you can read the SD card directly (most SD cards can be read/written in SPI mode), or via an SPI link to another Pico. UI issues need only be dealt with very much slower than you need to service a Z80 IO request or SPI data stream, so you should be able to fit them in the time between sector transfers easily enough.
I understand that any project needs design compromises, but at the same time upping the parts count should be avoided and it seems to be a particularly weird thing to add.
Again, you need to look at the whole picture. If I had the SD card reader on the Pico which does the IO then it might well be able to access the MDR file contents directly. I still doubt it because the FatFS layer would slow it down dramatically, but it might work. But such an arrangement would mean that the Pico which does the user interface would need to multimaster the SD card with the Pico doing the IO, and the Pico doing the IO would need absolute priority. (If the user interface were to hog the SD card for more than a few microseconds a Z80 instruction risks going unserviced.) That might be a solvable problem, I don’t know.
Maybe you’re right. Maybe I didn’t hit the optimum solution with regard to part count. If that’s your criteria for a successful project, and a cache for all online microdrive data seems to you to be a particularly weird thing to add, then I guess we just have to agree to disagree.
I am not a speccy guy but why did you choose to not build a Spectrum-1 replacement? If they are getting expensive and rare and not all that reliable then a new and improved Spectrum-1 seems like a worthy project for the community. As to using 3 Picos. I have looked deep enough if that was the optimal solution or not but I do work as a software engineer and understand some things that others might not.
1. Hardware is cheaper than time.
2. If you are building one cost of parts is often the least of your worries.
3. Does it meet requirements? Done.
Your project and your requirements so if it works for you then great. If you want to call it done and get on with your life. Good. If you want to try and make it more efficient or add new features that is also fine.
You are paying the bills and putting in the time. So if you are happy they can in the words of my friends in the UK “bugger off”.
BTW and idea you might like is you could use a Pico-w and use wifi to update the files from your PC without having to swap MicroSD cards. You could even make a web interface and control it from a tablet or phone.
Just and idea. Nice project and thanks for sharing it.
“You could even make a web interface and control it from a tablet or phone.” A ZX Spectrum version of the FujiNet device is needed (and I suspect someone is working on it by now)…
I love the SWD hack on the 2 outer Picos. Those black wires with male headers soldered on them look like something I would/have hacked together for debugging my Pico projects :)
It always amazes me to see people building peripherals for decades old computers with computers of far greater power, I think I now know how V’Ger came into being.
+1
And now let’s imagine that V’Ger’s ancient radio signal was the sound of a datasette! :)
No seriously, there’s a relationship.
RTTY, Packet-Radio and so on use similar audio pairs (Mark/Space).
My old RTTY keyboard (Tono Theta 7000E) supports “Kansas City Standard”, for example.
While it’s primarily intended for cassette storage, it can also be used on-air, I believe.
There’s a lever to switch between KCS and RTTY.
I’m surprised it takes 3 picos to do this, and more that it hasn’t got an SD card slot to load from.
Have a read above about how it all works, or the original site. And it does have an SD card slot.
The company which produces Zynq-like MPSoC silicon in an affordable RPi-like package with decent tools will conquer the market. National Instruments made a Zynq-based system for classroom use, but the toolchain is unaffordable for most, and the hardware wasn’t anywhere near cheap.
There are numerous applications where a CPU isn’t fast enough to do what an FPGA can. This would be a perfect use case for such a device.
Me and my da built a gpIO interface and connected it to IBM pc to upload/download code. Was cool. :-)