Share the post "The history of ESXDOS, the DivMMC and the DivMMC EnJOY!"
Originally posted on World of Spectrum in 2012, and reproduced here with the kind permission of Ben Versteeg.
These are the stories behind esxDOS, the most popular operating system extension for the ZX Spectrum with DivIDE or DivMMC mass storage interface, and behind the DivMMC and DivMMC EnJOY! interfaces.
With interviews with the main developers of these great products – they must be in the spotlight – here are their names:
Miguel Guerreiro – main developer of esxDOS
Mario Prato – designer of the DivMMC interface
You will get to know all the dirty details of the esxDOS development – about victories and setbacks.
And you will get all there is to know about how the DivMMC and DivMMC EnJOY! interfaces came to life.
A must read for everyone who is interested in the ZX Spectrum in the 21th century!
I am Ben Versteeg, manufacturer of the DivMMC EnJOY! interface.
EnJOY the story!
esxDOS is a firmware for the DivIDE, DivMMC and DivMMC EnJOY! mass storage interfaces.
‘Firmware’ in this case means the BASIC extensions for the ZX Spectrum which are stored in a ROM chip, to control the functions on the mass storage interfaces.
Back to before the start of the DivIDE interface
As many know, the DivIDE interface has been most widely used mass storage interface for the ZX Spectrum for the last decade.
Although the DivIDE has its roots way back in 1995, the best known version, the DivIDE 57c, was sold from 2005.
For years ‘FATWare’, another firmware, was used mostly on the DivIDE.
But esxDOS was actually thought up a few years before the DivIDE came to fruition!
Where did esxDOS get its name from?
ESX is an abbreviation for “Enhanced Speccy eXperience”
First esxDOS was named ‘ESX DOS’, then ‘ESXDOS’, but when Miguel Guerreiro made ESXBOOT for the ZX-One FPGA core (a modern ZX Spectrum clone project), he decided to capitalize the DOS and BOOT, hence esxDOS and esxBOOT.
Miguel doesn’t actually care how its written, but as he used ‘esxDOS’ the most, let’s keep it with that notation!
What was the development of esxDOS started for?
esxDOS was aimed for an interface that never got finished, known as “Project Backbone”.
This project was a collaboration between Miguel and LaesQ (Neil Laws).
Unfortunately there are no photos of that project available, but there is some documentation, in which you can see how some features of esxDOS came to light!
Project BackBone V.0.1 documentation (2001):
---------------------- Project Hardware Specs ---------------------- For +3 ONLY Small Portable Setup: Just the Speccy + PSU 1 x (or 2) IDE HDD (Internal) 1 x ATAPI CDROM SounDrive Compatible Soundports 2 x DD FDD (Can be HD but must be supported by old FDC765) (1 Internal, 1 External) General use Kempston port (IN #1F) Kempston Mouse Via PS/2 Mouse Support NMI Function button Custom ROM in ROM-A DRAM in ROM-B with write protect feature (Contains OS) 2 x RS-232 Serial Ports (56k Max) 1 x Parallel Port 1 Sinclair Joy Port (67890 format) I/O Slot Still Available For Further Upgrades That Won't Fit Inside The Case Special System Port (#F7) ---------------------- Project Firmware Specs ---------------------- USR 0 mode from boot NMI Function Software - Debugger - Snapshot Function Both HD and FD use FAT format Full TR-DOS support from BASIC ------------------- Compatible Hardware ------------------- FD - Can be DD or HD, but must support READY signal. HD - Any IDE drive that supports LBA. CDROM - Any ATAPI compilant drive. ------------------- Compatible Formats ------------------ Real Spectrum Disk Support For: - +D disks - TR-DOS disks Emulator Files: - TAP - TRD/SCL - SNA/Z80 -------------- Command Syntax -------------- Loading from various devices - LOAD D1"Filename" - Load Filename from Disk drive 1 LOAD D*"Filename" - Load Filename from Last Disk Drive used LOAD H1"Filename" - Load Filename from Hard Drive 1 LOAD H*"Filename" - Load Filename from Last Hard Drive used LOAD S1"Filename" - Load Filename from Serial Connection LOAD * "Filename" - Load Filename from last device used - Default H1? DIR: CAT (duh) CHDIR: GO TO *"dirname" CHDRIVE: GO TO *"h2:" FORMAT: FORMAT h1 (duh) -------------------------- ROM and RAM in More Detail -------------------------- ROM: ROM0 - BIOS - HDD detect/format options - PSX type bootup (?) - Main FDD/IDE/Serial routines - Checks for flag on sysRAM if set skip all BIOS boot seq thus goes straight to 48 basic (reset) - if shift (or RMB on amouse) pressed on reset enters BIOS anyway - checks disks for OS then loads it (checks floppy then HDD1 then HDD2) - more more more ROM1 - 48K Basic SysRam: RAM0 - DOS - .TAP file redirection for normal LOAD (and SAVE? not sure) Use some comand to select .tap file and another to select pointer in .tap (POINT?) - DOS services (open file, read/write sectors, etc, etc, etc) - DOS in ram: more commands/funtionality can be added - LOAD d1/2(fdd);h1/2(hdd);s1/2(serial) - serial 56Kbps support for both rs-232 ports will allow easy send/receive files with zmodem protocol for compatibility with terminal progs on pc etc of course it'll work on speccy<->speccy too - .z80/.sna Snapshot loading (i dont like'em... but we can put it in) or we can make .z80 the default for the snapshoter xcept we must ask what screen is active - try and make kgb work with .TRD and .SCL so no need to use real turdos disks all the time (should work... .scl worked on +d kind of... +d got no file pointer) - rst8 trapping means a +D emu for well behaved progs should be possible (theres that one by dom morris for +3 except it uses page 7 so it suxx) - buffers for sectors/debugger screen corruption - just got an idea thatd rock, a bit o work though: if u type ie: LOAD h1"" u get a nice file requestor with amouse support! as we got ram we can save the bit of screen that the requestor will use then restore it! this would be sooooo nice! - swap partition - virtual memory up to 4Mb RAM1 - Snapshotter/Debugger/Resident Progs - Resident? Possible IM 1 trapping so we can have 'TSRs' - ex. TSRs: AY background player, key shortcuts for basic and system progs/im 1 soft (ex: key shortcut to show 48k keyboard layout)
What happened to Project Backbone?
“I think Real Life ™ got in the way at the time, and then the DivIDE was out, so we decided to develop for it instead.”
So Project Backbone stopped, and esxDOS development was continued for the DivIDE instead.
The first version of esxDOS
The very first version of esxDOS was v0.5 BETA, which was released privately in 2005.
Reason for this small group of users was that it was very buggy and incomplete.
But it already had FAT16 write support and TR-DOS emulation, but not from .TRD files.
At that time it was mainly a proof-of-concept version, and it was not as modular as the esxDOS that exists today.
Due to it being released to a select few, and to the innovations it had at the time (FAT write, TR-DOS emulation), it was even deemed a hoax/vaporware by some people!
You can find a video showing this version on YouTube:
Miguel is thinking of uploading this historic version to www.esxdos.org.
TR-DOS emulation in the early versions
“I started to mess around with TR-DOS emulation back in 2000 on the +D.
I made a $3d13 wrapper called “KGB” – it could load real TR-DOS disks, but not software using custom loaders, etc.
I never released KGB publicly as I wanted to make it support other disk systems (D80, MB02+), to sort of make it a “standard” TR-DOS emulator for the speccy scene. I sent the source to some people so they could code drivers for those other disk interfaces, but then I got bored with it.
I think I still have the source code somewhere.
From this venture I gained a lot of insight on how to emulate TR-DOS. When the DivIDE came out with traps for the $3dxx (TR-DOS) area, I thought – this is the perfect platform to emulate TR-DOS on! I talked and had a lot of help from Faster/TNL and JTN/4D regarding custom loaders, and pretty soon I had custom TR-DOS loaders working on esxDOS 0.5.
But, as I didn’t have virtual disk support back then, you had to have a LS-120 ATAPI floppy and copy the .TRD image sector by sector to the floppy to make it work (the LS-120 could not read TR-DOS disks directly).”
With what gear was esxDOS developed?
Miguel started coding esxDOS on the ‘BeOS’ operating system which used an eeprom emulator (that LaesQ made) that allowed him to quickly test the ROM. This was invaluable at the time – back then there were no emulators supporting the DivIDE!
The most undesirable accident…
Unfortunately Miguel had an hard drive crash. As there were no backups, he had to rewrite most of it..
“To be honest I don’t recall what triggered the crash – I do remember it was logical, not physical. I remember I was using BeOS at the time, and there was some file system corruption. I ran the checker, it ran for a long time, then it threw some error and said that it couldn’t fix it. I stopped using BeOS then.
It was hard, but it wasn’t the first time.
I think I lost interest in speccy/esxDOS for 2 or 3 years, then it came back (it always comes back).
Nowadays I do backups.”
Perseverance pays off
When the DivIDE became popular there were different firmware’s, like FATWare, +DivIDE and some others.
FATWare was read-only but the most easy one to use, and it had an NMI menu. Hence it was the most popular one.
People started asking for write-support on FATWare, but it was never picked up.
So the DivIDE with FATWare was very popular, but that combination was not yet ‘complete’.
esxDOS was referred to a couple of times on World of Spectrum during that time, but it was consequently said it was not yet released and in early beta state.
Finally, thanks to Miguel’s perseverance, a topic on World of Spectrum showed up in 2009 where esxDOS beta v0.7.3 was announced – this was very good news to many!
This version came was not yet completely stable, but still some well-known developers embraced it and started to work with it.
The first stable release
In 2012, the year the ZX Spectrum celebrated its 30th birthday, Miguel announced the first official and stable version of esxDOS: v0.8.0!
It turned out this development was made possible because of one very special reason:
“Most of the esxDOS v0.8.0 release was coded in 1 week while I was home sick with malaria!”
Some bad situations simply to turn out for the best it seems!
Who helped with this first stable release?
All esxDOS code was done solely by Miguel, with the following exceptions:
- UB880D (.SK): NMI Browser, fixed/optimized some routines, made config file parser and some commands (ls, etc.), helped define a lot of the API (FAT Seek for example)
- LaesQ (UK): .dskprobe command
- Gasman (.UK): Some .commands (DivIDEo, etc.)
- Velesoft (.CZ): .snapload command maintenance, some other commands, TR-DOS patches and many bug reports
Miguel tells some more about these guys:
“LaesQ has been a major source of motivation, support and ideas throughout all these years. He also provided me with most of my hardware (including my +D and DivIDE, which I still have to this day). He also codes from time to time – .dskprobe is an essential tool for me.
UB880D is the reason you have an NMI Browser in esxDOS today as I never cared much for that functionality in the past (nowadays I can’t imagine myself without it!). He also fixed and optimized the FAT seek routine (which was hard work), made lots of useful commands, and I always check with him regarding system calls and general architecture definition. Sometimes we disagree on some things, but in general it’s a quite healthy collaboration He’s put so much work into esxDOS, that it’s safe to say that it’s his work too.
Velesoft is the Bug Master I can always count on him to test and find bugs, and submit patches/ideas. He helped a lot during the TR-DOS testing phase and is designing the ultimate interface for esxDOS.
Regarding the DivMMC version, it just wouldn’t have been possible without Alessandro Dorigatti and Phil Ruston (V6Z80P designer).”
Right now Miguel’s doing some major ‘revamping’, and he is preparing the release of the API to the public.
After that he will work on LFN (long file name) support (yes! what we are hoping for!).
Oh, and on a side note: by now Miguel’s coding environment has evolved thru BeOS, MorphOS, Linux, Windows until OS X!
What is Papaya Dezign?
Underneath the website esxDOS.org you will find the name ‘Papaya Dezign’
Papaya Dezign was formed back in 2000. It is a group composed of Miguel, LaesQ and K-0s, who together also did a couple of other stuff like the diskmag ‘Subliminal Extacy’.
That diskmag is still found here: www.pouet.net/search.php?what=subliminal+extacy&type=prod.
Some other productions from Papaya Dezign:
Miguel continues to tell:
“Laesq, me and K-Os were part of Raww Arse group. As we were kinda doing our own things at the time, we created Papaya Dezign (as a sub-divison of RA) to release the stuff that we did alone.
K-Os is our graphic artist.
Check out this link: http://web.archive.org/web/20091018195405/http://geocities.com/ResearchTriangle/4535/
There’s the first OS I did for the speccy, it used a serial link to PC to load/save files, and later used the PC’s mouse too.
I do want to do other stuff (non OS coding) when [esxDOS] v1.0 is released.”
I’m curious about that!
What is Papaya Labs?
Papaya Labs and the (currently unavailable) website www.papayalabs.co.uk is LaesQ’s: he’s the hardware man.
Miguels personal background
He wouldn’t want to tell me; he just explained:
“This would take an entire book! ”
The DivMMC development started from an e-mail Miguel Guerreiro sent to Alessandro Dorigatti on 5 may 2012:
I’m the author of ESXDOS (http://www.esxdos.org), a firmware for the Speccy DivIDE interface. I was wondering if you’d consider “emulating” a DivIDE together with your 48k core (but with SD device instead of IDE I guess). I could then make version of ESXDOS that would run on v6z80p+. Just an idea
Miguel explains who Alessandro is and what v6z80p+ means:
“The V6Z80P+ is a FPGA board [multi machine emulation board], and Alessandro made “perfect” 48/128 Speccy cores for it (the Zx-One core). As I travel a lot, it would suit me to have a small, easy to carry Speccy/esxDOS testing platform – the V6 was perfect for this, but it didn’t support the DivIDE due to using an SD card slot.
Alessandro was a bit busy, but a couple of months later he contacted me and we started to work/test a lot to get it working.
The idea was to use the ZXMMC+ part for the I/O, and the DivIDE memory mapping.
This meant that an esxDOS port would be really easy, as all I would have to do was code a SD/MMC I/O driver. Alessandro even contacted Zilog (the author of the DivIDE), to get his “blessing” and help.”
Alessandro’s reply on 7 august 2012:
“If we’ll get the whole thing working it will be a very interesting hybrid I think it would be a “DivMMC”
Miguel continues the story:
“This was the day that the DivMMC was named and booted correctly for the first time.
I could then start coding the SD/MMC driver.
Checking my mails I got it working (for SD/MMC cards) in under 2 days.”
2 days later Miguel sends out an email:
“…Here’s esxDOS v0.8.1 BETA version for Alessandro’s hybrid DivIDE+ZXMMC (which, it turns out, will be a real interface soon)…”
“The hint to “will be a real interface soon” was because Velesoft was interested in making an interface for real spectrums.
I got SDHC cards working the following day.”
Miguel then sent the version with SDHC card support to Alessandro for testing.
“After this Alessandro bumped the memory from 32K to 512K max.
Then Alessandro started to refactor the ZX-One core, time passed, and we also contacted Velesoft in order to get new ports for the SD I/O – the ports used by the ZXMMC+ were incompatible with a few devices.
We got the answer from Velesoft: “
“result: use new MMC ports #E7 and #EB:
– port #1F for writing can be replaced with new port #E7 for writing
– port #3F replace with new port adress #EB”
Miguel continues again:
“A couple of months earlier Alessandro was contacted by Mario Prato asking if he could make a DivMMC interface for real spectrums.
Alessandro was still refactoring the FPGA core (to make it more portable, etc), and the development of the “DivMMC” stalled.
Velesoft tested the DivMMC version of esxDOS using a real ZXMMC+ together with DivIDE memory mapping and it worked.
The rest you already know. Mario Prato made the DivMMC interface based on the (at the time) state of the FPGA DivMMC prototype.”
And for Mario Prato’s turn to tell his story:
“Regarding the Divmmc: all was born from a conversation between me and Alessandro Dorigatti who wrote the vhdl code for the spectrum clone inside the v6z80 board.
He and Miguel had the idea of an “hybrid” interface, the fusion of divide and zxmmc.
There are other ideas, like a working 128K menu and basic (like plus-d), from the hardware point of view I wrote all the code, what is missing is the esxdos part, Miguel have some issues with dot extension commands..
I’d like a spi rtc also, and in the future a ethernet interface with encj chips from microchip ”
This all took place during 2013.
And as you can read, there were still plenty ideas with these people, so let’s hope for exciting updates in 2014!
But, there is one more development related to the DivMMC, by … me!
The DivMMC EnJOY!
My original goal: a redesign of the DivIDE
In April 2013 I posted a topic in the World of Spectrum forum about new hardware projects for the ZX Spectrum I had in mind for 2013 and 2014.
One of the ideas I had was the development of a new DivIDE interface.
The DivIDE 57c version used obsolete parts like GAL chips and Compact Flash cards.
So I was looking for a replacement for these.
The most logical step would be to use one modern ‘CPLD’ instead of the three GAL chips, and some card adapter that supports SD cards.
On 15 April 2013 user ‘phoenix^ra’ replied (I didn’t know Miguel Guerreiro back then):
I sent him a message asking for more information.
He replied, but somehow I was so busy with other ongoing things, I didn’t read his reply well enough to be triggered to action.
After two months, in June 2013, I discovered the new DivMMC interface by Mario Prato.
This surprised me as I hadn’t heard more about that on World of Spectrum, so I thought.
Mario Prato didn’t have a World of Spectrum back then; discussion about the DivMMC was on another forum.
I was even more surprised reading that there was an adapted version of ESXDOS for the DivMMC.
Now I understood what phoenix^ra was talking about in April, and I found out only then that he was the main developer of esxDOS.
The DivMMC – a breakthrough
I immediately though the DivMMC is a breakthrough for the ZX Spectrum:
- It finally gets rid of the Compact Flash cards, and hence a separate CF card reader isn’t needed anymore
- The interface is designed with modern parts only
- The interface has the very much appreciated ESXDOS firmware
So I contacted Mario for more information.
He didn’t seem to have large production of the DivMMC in mind, so I asked if I could use his design and continue from there, as I wanted to include a joystick port on the interface and do some minor changes.
Why the EnJOY!?
When developing the new interface during June, I came up with the name ‘DivMMC EnJOY!’, hinting to the integrated joystick interface and to make a clear difference with Mario’s original design.
And I hope future users will EnJOY! this new interface!
Before the end of June I had a prototype design ready and ordered the boards at my regular Chinese supplier.
In July the boards arrived, and within a day the first interface was ready:
The first ready DivMMC EnJOY! interfaces I offered to people who were very helpful during the process and some bugfixes, including Miguel Guerreiro and Mario Prato.
After getting an enthusiastic reply from Miguel, I couldn’t resist asking him more about how ESXDOS came to life. You will find all about that in the next chapter.
But first let me tell you about some technical background of the DivMMC and DivMMC EnJOY!.
The DivMMC is a hybrid of the DivIDE and another interface, the ZXMMC.
The DivMMC memory mapping is compatible with that of the DivIDE, but instead of only 32KB on the DivIDE at least 128KB SRAM is present, up to 512KB (but there is no application which uses more than 128KB at this moment).
The SD card control is similar to that on the ZXMMC, but the more compatible ports #E7 and #EB are chosen.
The I/O routines from the ZXMMC can be used, found on internet, only with other ports.
The memory paging port is compatible with port #E3 from original DIVIDE, but there are more ram pages available.
esxDOS is a modular operating system, which means the only difference between the version for the DivIDE and DivMMC is the device driver.
Hence esxDOS releases for DivIDE and DivMMC are always in sync!
The communication with the SD cards takes place through an hardware ‘SPI port’ built into the CPLD.
Transferring a byte to/from the card requires only a single OUT or IN instruction, which takes 16 Z80 T-states.
The maximum data transfer rate is 218 KB/sec!
The DivIDE interface had some compatibility issues with the ZX Spectrum 48K.
The DivMMC EnJOY! doesn’t have this problem, but needs one extra configuration option for support of the ZX Spectrum 128K (‘toastrack’).
Until now the DivMMC EnJOY! seems fully compatible with any ZX Spectrum!
The next era
As Miguel is working on long file name support, and others can pick up the modular development of DOT commands, mouse GUIs, DivMMC addons like an Ethernet interface, Real Time Clock, etc, there is a lot more to come.
But the DivMMC with esxDOS are the foundation of these new developments!