New Project Started: Cumulus

Cumulus Rev A1 Homebrew PCB (After Etching)

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.

Advertisement

A2601 Page Up!

A2601 Complete View Running Donkey Kong

I’ve finished the first version of the A2601 project. I’ve created a new page giving details on the project, including several photos, screenshots, videos and schematics. Complete VHDL sources are released under GPL (including a novel 6502 core).

A really mindboggling issue that I needed to solve during last week was corruption of the FPGA configuration bitstream when the on-board Xilinx Configuration PROM is programmed with a design. Naturally, the A2601 board is setup so that the Configuration PROM will automatically configure the FPGA on powerup. However, it seems that, after this, if one tries to re-configure the FPGA using the JTAG interface, the configuration bitstream will become corrupt (in fact, Xilinx Impact will report a verification failure). Apparently, the only way to overcome this problem is to keep the Configuration PROM blank during development, and only program it with the final design when it is ready.

Ironically, I had already encountered this problem a few years ago when I was first working on the A2601 design. I had identified the problem then and worked around it. Too bad I forgot all about it and had to spend a few days figuring out the same things all over this time again…

I also worked a bit on adding PAL video output support to A2601. I did obtain some color images but nothing proper yet. The major hurdle here is that I am trying to obtain PAL signals using a NTSC crystal, frequency multiplied by 16. It should be possible in theory, but there is something obviously missing, still.