Cumulus Further Progress

Cumulus Oric DOS Boot

Cumulus doesn’t work quite reliably yet, but here is a screenshot of it booting into Oric DOS.

I’ve implemented the seek/step/restore commands, together with the read sector and read address commands. This seems to be the bare minimum for the Microdisc ROM to boot the OS. Unfortunately, there is a random error with the Oric Bus that causes miserable crashes (the screen filling up with garbage, etc.). When it does not happen, I can get the Oric to boot the OS. Most of the time, it does not work, though.

Getting to this stage took a fair bit of debugging and some important modifications. My original CPLD implementation contained an almost exact replica of the original Microdisc schematics. I found out that this did not work very well with the CPLD in some cases. For example, the WD179X contain an edge-trigger /WE input that controls writes to internal registers. This, however, is a problem with an XC95 CPLD, because signal transitions in the /WE line (gated clock into register flip-flops) cause random glitches. My guess is that this behaviour is due to the much higher speed of the CPLD compared to the 74-series logic chips used in the original Microdisc design. The solution here is to use a single, system-wide clock (the CPU bus clock) into all flip-flop clock inputs and use the /WE line only as an enable control. Similar issues arose also in the interface between the MCU and the CPLD, and the solution was the same.

Anyway, getting back to the currently unsolved problem I mentioned above… I modified the original Microdisc ROM to create a test ROM that will hopefully help me debug the issue. It uses the original routines in the Microdisc ROM to continuously read sectors from emulated floppy into RAM and it compares them against copies stored in the ROM. This test ROM usually works fine for several sectors, but eventually, and invariably, I see the same bus glitches occurring with this setup as well. Hopefully, I’ll soon solve this issue and I’ll have a first working prototype of Cumulus in my hands.

Cumulus Progress

Cumulus with Microdisc ROM

Here is the Atmos with the Cumulus board displaying the “insert system disc” message running the original Microdisc ROM.

Getting to this stage took a fair bit of debugging. First, I had to further tweak the MAP signal timing to make sure that all RAM accesses (including the hidden upper 16k) worked fine. Then I needed to solve a couple of problems with the CPLD code (minor changes, but critical for operation, nevertheless).

At this point, the LA shows that the CPU is stuck in an infinite loop, waiting for an IRQ, right after the first command having been issued to the WD1793. This is perfectly normal, as the floppy controller emulation code (on the PIC side) is not in place yet. That is the first item that I will be addressing in the upcoming days.

On a side note, I have also solved the instability and video flicker issues I mentioned in a previous post. It turned out to be due to the original Atmos power adapter not being able to provide enough juice to power both the Atmos and Cumulus, causing the 5V line to oscillate. Switching to an adapter with a higher current rating (1A at 9V DC) solved the problem. So, apparently, Cumulus will not require a separate power supply connection, but a single, more powerful supply will be required to power both from the Atmos DC power jack.

The debugging process here on this project also gave me the idea to design and build a specialized logic analyzer for projects such as this one. It would be very wide (perhaps up to 48 or 64 channels), but not very fast. It would be intended for the expansion connectors on retro computers, perhaps in a pass-through fashion, by means of custom-made adapters. A SDRAM module could be used for deep storage and a small MCU for USB communication with a PC host. A small FPGA would handle the capture operations and provide and coordinate access to SDRAM storage. Presence of an FPGA would also make triggering very flexible.

Cumulus Prototype Assembly Progress

Cumulus Prototype Board Assembly Progress

Here is a picture of the Cumulus prototype board in its most current state. It is almost fully populated, except for the socket for the 28C EEPROM (I’ve run out of suitable sockets, it seems) and the HCT221 circuitry for MAP signal timing. The CPLD is available through JTAG and the PIC is accessible through ICSP. It took a while to get to this stage, as quite a few things got in the way and others simply went wrong… but now, everything seems to be back on track.

So, what were the problems? First of all, my JTAG Cable decided it won’t work any more… It may have something to do with all the abuse it had to withstand . Upon building a new one, I got the CPLD connection to work. Very good.

Then I went on to trying the ICSP connection to the 18F46K20, which did not work (to my surprise). So, I spent about a week, debugging on and off, where I checked all the connections, available schematics, etc. The Microchip starter kit schematics had a 8.2V zener diode on the MCLR pin, (my first thought was that was what was missing), but it ultimately turned out to be unnecessary with the PicKit 2, as long as PIC 18F K Series configuration was selected in the software. Finally, I built a couple of very simple boards, basically only with the PIC and ICSP connector on them, just to test the connection to PicKit 2. Those boards worked absolutely fine… Another round of checking, and it turned out that the problem was a fault on the Cumulus prototype board, where the PGD pin had a tiny short to ground. I have no idea how it slipped the first time, but it did. Anyway, now, ICSP is working fine.

So, now I can proceed in two directions. I can finish populating the board, write an Oric test program to the EEPROM (something simple that prints out a text message) and test that the Oric Bus interface is working fine. I can also go on with the UI board, and get the LCD and buttons on it to work, which should be very helpful with the debugging. Hopefully, whichever path I take, things will go a bit more smoothly this time.

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.

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.

A2601 Running First Game

A2601 Rev B Running Keystone Kapers

Here is the A2601 board running Keystone Kapers in demo mode. At the moment, the game ROM image is stored in the FPGA, because I had some problems with getting the on-board flash memory to work. Once I solve those issues and add the MegaDrive pad support, the electronics side of the project will be complete. Then, the final item in the project will be preparing the case to fit the board in.

A2601 Board Populated

A2601 Rev B Homebrew PCB Assembled

A2601 Rev B NTSC Color Bars Output

I’ve (mostly) finished soldering the new A2601 board. The Xilinx Impact software recognizes the on-board FPGA and Configuration PROM through the parallel port JTAG cable, so I am able to download designs into the FPGA. Just for testing, I’ve uploaded a small design that outputs some NTSC color bars through the composite video port, and it seems to work fine.

It seems some more work needs to be done to get the A2601 FPGA design to work with the new board, though. It has been quite a while since I last worked on this project (judging from the dates on the files, almost three years), and during this time FPGA software (i.e. synthesis, simulation, etc.) has moved on. So I need to remember all the little bits and pieces and fix a few things here and there to make sure that the design works fine in the simulator again (it previously did). Once the design works in the simulator, it should be fine in the FPGA.

An Older Project Revisited: A2601

A2601 Rev B Homebrew PCB After Etching Top Side

Having made quite a bit of progress with UFE, I’ve decided it’s time to take a little break from it while I wait and see how recent developments in the manufacturing front pan out (sorry, cannot give details on that yet). So, I am now revisiting a never-before-released project of mine that is almost five years old now.

The project is an ATARI 2600 clone on FPGA, including 6502 and TIA cores in VHDL and dedicated PCB layout, all developed by me. The design fits in a 100K gate Xilinx Spartan 3E, and works quite well in the simulator. The PCB design contains the FPGA, resistor-ladder DACs for video and audio, custom joystick input ports and flash memory for storing ROMs. Few years ago I even built a prototype. It worked well, but unfortunately it did not survive, since my PCB-making techniques were not as advanced back then…

So, what’s new this time around? Basically, a reworking of the PCB layout that fits in a smaller case and contains a single input port for a Genesis/MegaDrive gamepad instead of custom-wired pads. I’ve ended up choosing MegaDrive pads because they are commonly available, very easy to drive and they contain the necessary auxiliary buttons (start/select etc.). I’ve already started manufacturing the board and the photo above shows the work in progress. Hopefully, all will go well and next time I’ll be posting working photos of the board…