Cumulus 6502 Bus Working

Cumulus Test ROM running on Oric

Cumulus LA Debugging Setup

Over the last week I worked on debugging the Cumulus 6502 interface. One of the shots above shows a small test program (coloured bars in hi-res graphics mode) I wrote for testing. The program resides on the 28C256 EPROM on the Cumulus board and is executed by the Oric on reset.

The problem with the Oric bus turned out to be due to the 74HCT221-based circuitry on the Cumulus board. This circuitry generates a couple of signals from the 6502 O2 signal coming from the Oric. Those signals are in turn used for controlling some Oric bus-related signals such as 28C256 output enable. The pulses generated by the 221 were too long, actually about twice the length specified in the datasheet.

I managed to solve the problem by manually adjusting the component values until I got proper the pulse widths. The problematic circuitry actually comes straight from the original Oric Microdisc schematics, with one difference: The original circuit uses an LS variant instead of the HCT that I used. According to the datasheets, there does not seem to be a difference, but I may have missed something.

There are still some problems though. Sometimes the Oric does not properly reset, most likely due to Cumulus affecting the reset sequence. Sometimes there is some wave interference on the video output. Other times, the video output looks as if the Oric never switches to the high-res mode, remaining in text mode (I get coloured bars, but longer). I’ll probably conceive a shorter program to reproduce these issues and debug using my current setup with the logic analyzer.

Advertisement

Oric Atmos Repair

Repaired Oric Atmos Mainboard DRAM Closeup

Repaired Oric Atmos Mainboard Full View

It seems I keep hitting roadblocks with the Cumulus project. Fortunately, I was able to overcome the obstacles once more.

Couple of days ago, I tried the Cumulus prototype board with an Oric Atmos. The intent was to test whether the 6502 bus interface (the onboard ROM) was working properly. Needless to say, I was not surprised when it did not work the first time :). I spent the better part of an evening trying to figure out with the logic analyzer where the problem was. The Atmos booted fine when Cumulus was detached, though.

So, the next morning, I just try to boot the Oric with the Cumulus board detached, and it does not work! Most of the time, it just gave some scrolling horizontal bars on the left side of the screen. Other times, there was just garbage on the screen.

I was quite dismayed, but I also thought that the Oric was not beyond repair. I first checked the 6502 with the logic analyzer, and the reset sequence and the first instructions seemed to execute fine. I double-checked the contents ROM with a programmer, which were also fine. Then, I went on to verify the RAS/CAS/W signals going to the DRAMs. This, together with the fact that the video sync signals were fine, indicated that the custom ULA chip was fine. I was quite relieved by that, as it would be nearly impossible to source (except from another working Oric).

The only things left were the DRAMs, which are, incidentally, the most common sources of problem on these older machines. A quick check confirmed that the IMS2600 chips on the machine were actually the same as the very popular 4164 DRAMs. So, I went out and luckily found a shop that somehow still carried them… Started replacing the chips one by one with sockets, and upon replacing the second one, I got the familiar Oric BASIC screen. What a relief!

So, basically, I am still not sure if it was the Cumulus board that caused the problem. The DRAMs on these aging machines are prone to breakage anyway, so it might have been a coincidence, as well. Anyway, I tracked the problem with Cumulus down to some circuitry based on a 74HCT221 that generated a couple of signals from the O2 clock output of the 6502. I actually copied the circuit over from the original Microdisc schematics, but it seems on my prototype, the pulse widths of the signals generated are much too long. I may actually build a small test circuit with a just 74HCT221 on it to play around with and test the circuitry.

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.