Retromaster’s Electronics Projects

…related to old computers and other assorted stuff…

New Project Started: Cumulus

Posted by retromaster on September 18, 2010

I haven’t posted in a little while, mostly because I was busy working on a new project (called Cumulus). It is yet another SD/MMC floppy emulator project, but with a significant twist: It aims to emulate the WD177x/WD179x series of floppy disk controller chips (FDC), too. So, in essence, it is aimed towards certain retro-computers that originally came without built-in floppy controllers (e.g. MSX, CPC464, Oric, Spectrum, etc.). Back in the day, to add a floppy drive to these computers, the user had to install/connect a FDC card to the expansion port. Therefore, it is impossible to use a floppy emulator like TFE or UFE with these computers without the appropriate FDC expansion, which can be difficult to obtain.

There are significant advantages to integration of FDC emulation within a SD/MMC floppy emulator. First of all, there is no physical floppy disk interface (the 34-pin connector) to worry about, which means that MFM-conversion is out of the picture. Furthermore, there is no floppy disk rotation constraint to satisfy, so writes are much easier to implement and SD card performance issues pose much less of a problem.

The challenge here is that the floppy emulator needs to be directly interfaced to the host system bus, so it is difficult (if not impossible) to get away with using just a microcontroller. Consequently, a clean design dictates that the floppy emulator be host-system dependent (due to different CPU bus configurations, expansion port pinouts, glue logic, etc.). Apparently, the whole FDC card needs to be implemented within the floppy emulator.

For a first implementation (as a proof of concept), I decided to target the Oric Atmos computers… Why Oric? Well, actually, completely by chance… Right around the days when UFE was first released, I had just obtained an Oric Atmos, and a couple of people asked me if UFE could be used with an Oric, which got me thinking, and that’s actually where I got the project idea from. I found out that full schematics of the Oric Microdisc interface were available (along with dump and disassembly of the on-board ROM), and to the best of my knowledge there were no existing SD card solutions that could work with the OS software available (which is seemingly quite impressive, btw).

So, I started working on the Cumulus design. Bearing in mind all the issues outlined above, I went for a CPLD (Xilinx XC95 series) and MCU (PIC 18F series) combination for Cumulus. The CPLD will effectively implement the bus interface of the FDC chip, together with all the additional glue logic usually found on a FDC card. The MCU will communicate commands and data with the CPLD and handle SD Card access and user interface functions. I am sure it will be a difficult combination to debug, but I think I am up to the challenge :).

I have already finished the schematics and PCB layout. Right now, I am at the prototype manufacturing stage, as can be seen from the scan above. There will also be an optional UI daughterboard with an LCD. This is not absolutely required, since the Oric console can also be used effectively to control the emulator. Hopefully, the project will be successful, and it will breathe a new life into these computers.


19 Responses to “New Project Started: Cumulus”

  1. Ian said

    I’ve been searching for an Atmos floppy drive for years ~ having sold my original many moons ago. I was wondering today if it was possible to use an SD card as a modern “floppy” with the Oric in the same way as some C64/Spectrum cards and *bing!*, Google found your page – incredible! Good luck with the project (and if you’d like anybody to help road test the new interface using SEDORIC or other OS, drop me a line… :-).



  2. retromaster said

    Ian, I am glad to see that my new project has already attracted someone’s interest :). It is now in a fairly advanced stage, but still far from a working prototype. Please do check back frequently to follow the project’s progress, I usually post once every few days when a project is in full motion…

  3. It’s not really that complex, especially with a processor in there to do most of the grunt work. Check out my site for a 95% working WD179X implementation in HDL…

  4. retromaster said

    It’s not really that complex, …

    Sure. VHDL sources are less than 200 lines, and that already includes quite a bit of Oric related logic. That said, the interface between the MCU and the CPLD can be a bit of a problem to debug, and I expect that to be the primary challenge in this project. We’ll see…

    Btw, I had some difficulty navigating your site, and I did not manage to find the WD179x HDL implementation you mentioned… Any direct links?

  5. Ian said

    Good progress with the board, despite that pesky JTAG interface. I’ve knocked up some concept sketches of what the finished item could look like here:

    (with more than a nod to the original!)

  6. The site is in dire need of a re-design, or at least, needs some web pages to complement the forums. Everything is shoe-horned into the forums atm, which makes it very difficult to find stuff – or even work out exactly what PACE actually is!

    Even this is hidden in the TRS-80 implementation atm…

  7. retromaster said

    @Ian, very nice job with the sketches πŸ™‚ I guess a significant part of Oric’s attraction has always been about the looks. Something not to overlook…

    @Mark, I did guess it was hidden in a computer implementation, but I was too lazy dig for it, honestly. I’ll look again later. The site does give me the impression of having a lot of content, though, despite being difficult to navigate.

  8. Sorry, seems I can’t post comments with links… ?!?

    Trying again…

  9. retromaster said

    Looks good. I’ll examine more closely later.

    The implementation you posted is targeted towards interfacing with a real floppy drive, of course. Mine will directly interface with a MCU that will handle SD card access. As I pointed out previously in my post, that arrangement has significant advantages, assuming that using SD cards was what one wanted in the first place.

  10. On the contrary, whilst interfacing with a real floppy is something I’m looking to do eventually, the initial aim was to interface to anything *but* a real floppy. So far I’ve only interfaced to parallel memory (flash, SRAM), and an earlier version to SPI flash.

    Interfacing to an MCU with SD card, as you rightly point out, has significant advantages and has always been on my to-do list! However right now I lack the hardware to interface to an external MCU and have considered using a soft-core processor in an FPGA instead…

  11. retromaster said

    the initial aim was to interface to anything *but* a real floppy.

    Mark, it’s interesting that you say that, because judging from your VHDL sources, the “drive interface” section of your wd179x entity seems to exactly match a real floppy drive interface (34-pin stuff). So, I am guessing that, to interface to flash memory, you’ve had to place some kind of basic “converter” in between the flash memory and the virtual wd179x.

    Which is good, if one’s aim is to faithfully replicate the wd179x itself. What I am aiming for is something slightly different, though. I do not intend to implement a wd179x replacement, but a replacement for the whole section of hardware (incl. the drive itself) based on the wd179x instead.

  12. Yes, the “converter” is simply a de-serialiser, a few lines of HDL.

    You’re right, the back end does match a real floppy, in part because I do want the option to use real floppies at one point. But in doing this, it also decouples the WD179X implementation from the media emulation; allowing different media to be used on different platforms for different purposes with the same core. I did the same thing with my (Commodore 64) 1541 emulation, which actually was at one point connected to an SD card, and at another, to a PC application streaming G64 images.

    But I see where you’re coming from and for your purposes, I can understand the approach you’re taking. In fact, for my very first implementation (of the 1771/3) I took a similar approach; whilst I emulated the controller register interface, a used a (soft core) microprocessor to emulate both the controller and media without even attempting to replicate the real thing, or even separate the two. For a black-box product, that’s perfectly adequate.

    My ultimate aim is little different; to develop IP that can be used for different purposes on different hardware. FWIW I’m still in the “proof-of-concept” phase and have not yet produced a “commercial quality” product with it.

    Good luck!

  13. VaclavPe said


    We made something similar (and even more) for Sharp MZ-800. Please have a look here

  14. retromaster said

    VaclavPE, nice project. It looks like you have followed a slightly different approach: You have a smaller CPLD than the one I am using but (much) more powerful MCU. And you did implement quite a few peripherals, which is also nice.

    In fact, I do own a Sharp MZ-800, so perhaps one day, I may even try to build your project, too :). Time being the limiting factor here, of course.

  15. VaclavPe said

    Actually, the card is in fact first development version.The schematic can be changed a little bit. And on the board, there are some mistakes. So, the plan is to add PS/2 port for mouse (we have some “mouse-able” software – apps and games – developed in former Czechoslovakia), let USART1 be on FT232 and connect USART3 to MAX3232.

    Currently just emulation of WD279x works the way that Sharp feels like it has real floppy and all older software works without changes. Quick disc is used to boot into so-called SD repository manager. In one branch there is Ramdisc emulation.

    Missing is emulation of SIO (to use kermit to exchange files with PC), porting of lwIP stack and to implement protocol similar to the one in GPRS modems.

    You would be the first foreign user of the unicard πŸ˜‰ Up today only 4 cards are known to be working. I sold about 10 bare PCBs.

  16. chaky said

    For completeness I add that the first working prototype of our UNIcard for MZ-800 originated a year ago and was based on ATmega64 microcontroller.
    Here are photos of the original prototype just prior to its disassembly (it was a terrible bunch of wires πŸ™‚

  17. retromaster said

    Now, that looks like a prototype, indeed πŸ™‚

    It’s nice to be able to see the history behind the development of projects like this. In fact, that’s one of the reasons why I started this blog: To keep track of my own progress and the problems I needed to solve, and show the process and the project background to other people, as well.

  18. Dbug said

    Hi, great work so far as I can see πŸ™‚

    I’m the webmaster of, and on our forums we have/had intense discussions about how best to find a replacement to the hard to find Microdisc systems, and of course the possibility of having a SD based system has been discussed quite a lot.

    Quite a number of people tried to build interfaces for the Oric, but they all stopped at some point mostly due to the fact that something that works one One Oric may very well not work on another one.

    In my particular case I have a Microdisc that works perfectly on one of my Atmos, it works on my Pravetz, but it totally fail to work with my second Atmos and my Oric 1.

    One of the reasons is – as you already found out I guess – that the bus timings are very flaky, they tend to be either shorter or longer, but also “not well defined” so on some machines instead of having a neat impulse you get a rounded or variable shape which is not correctly detected by the hardware.

    Once upon a time, when the Oric owners bought a Microdisc, sometimes it was not working with their machines. So Oric was asking the user to send back both the machine and the disk units, and they would be “paired” by tweaking the values of resistors and condensators until the system works. Nough said, if you get an oric and a disk unit from two separate sources, the probability that they actually accept to work together is not that high!

    I sure hope you will manage to get a fully working system, and in case you decided to start a limited production batch I’m pretty sure that a number of people would be ready to pay for it – I know I would πŸ™‚

    Something reliable, compact, that plugs on my oric and makes it easy to select a virtual floppy from a SD card is something I’ve been waiting for a long time!

  19. retromaster said

    Hi Dbug. Although I am not really familiar with the Oric scene, I think I’ve seen your name in quite a few places. It’s nice to hear from you.

    To be honest, I did not really know about the flaky bus timings issue of the Orics. The bus timing behavior exhibited by the Atmos I own is quite consistent. Nevertheless, I do understand that this behaviour may differ drastically from one Oric to another…

    In any case, I do not see this as a good enough reason to abandon an interface project such as Cumulus. However, I now realize that it’s important to make the signal timings (actually just the MAP signal, it seems) as adjustable as possible. Furthermore, it would be ideal if I could come up with a practical method that would enable people to make the adjustments themselves.

    And I should add that this is not a commercial project from my point of view. It is very likely that I will open all sources related to the project once it gets to a working stage.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: