Debugging an Issue with a Dragon 32
(Blank Green Screen Problem)

A few weeks ago I was looking for something on ebay, and came across a Dragon 32 computer which was sold as “For Parts – not working”. Nostalgia took the best of me, I placed a bid and won it.

For some context, the Dragon is the reason (and the sole culprit  for better or worse) I now have a career in I.T. , I wrote my first Basic,  and later assembly program on one, back in the 80’s) and although it was never as popular as the ZX Spectrums or the C64, this little home computer, was considered a programmer’s machine at the time, not only because of it’s full sized keyboard, but also due to the hardware inside. The Motorola 6809E, introduced in 1978, was very advanced for its time, and is still very much in use today.

The box arrived after a couple of days, I unboxed the unit, put it on the workbench, connected it to a cvbs monitor, and powered it up. I was greeted with the familiar green screen, but not the usual text. Something was definitely working, but for some reason, the boot process was not finishing.

I flipped the Dragon over, to access the four screws that hold the cover shut, and after a second or two of hesitation (the Dragon still had the factory seal, so prying it open, felt a bit wrong…for two seconds that is).

The first thing I wanted to check after ensuring the supply voltages were all present and correct,   was the reset switch and related circuitry. The switch was definitively not working well, so I brought out the schematics (courtesy of Steward Orchard  from http://archive.worldofdragon.org) who I really cannot thank enough.

The reset circuit is situated on the bottom left of the above image, you can hover your mouse on it to zoom.

Even though the reset switch was playing up, the reset circuit appeared to be fine. I also learned from the schematic that A7 is pulled down, to ensure no writes are performed to the SAM during reset. This also explained why when I was checking the resistance between the Address lines and ground, A7 showed a slightly lower value than its peers.

Next I brought out the oscilloscope, and tested that none of the data / address lines were “stuck” on the 6809. Everything appeared ok.

Next on the list were IC 16 (74LS244) and IC 13 (74LS273)

I noticed that the wave form on pin 3 (MD0) of IC 13 was very strange, the rise time was very slow compared to MD1…MD7, and the amplidude was also wrong. MD0 data line connects directly to pins 14 of  IC 8, and IC 43, the RAM.

Connecting the scope to Pin 14 of IC’s 8 and 43 confirmed the issue. The waveform  was completely different from the waveform on Pin 14 of all the other RAM IC’s. Since the MD0 line is shared by both IC’s, the culprit could either of the devices, however, since the boot process seemed to be stalling at a very early stage, I went for IC8, the “lower” RAM IC.

I removed the IC very carefully, and since I had 4116 spares, I just cut the legs off the I.C. using a small side cutter tool, and removed the pins one by one. Attempting to remove the IC as a whole can work too if you are VERY patient, but you will risk bringing up a track or two from the pcb in the process. In this case, I would very much rather sacrifice the 4116.

The fire breathing dragon was alive again.

I keyed in a few instructions, to make sure everything was working OK, and it was. So I brought out my homemade “CAS” player, connected it to the Dragon, issued the CLOADM command and loaded the old classic “Whirlybird Run“. After a couple of minutes, I was flying a helicopter and shooting down flying saucers using a $2 “Arduino Joystick”. But more on this in another post soon.

[metaslider id=807]

The full schematic diagram for the Rev 2 board, without which this repair would have been all but impossible,  can be downloaded in PDF Format Here.

Full credit for the schematics goes Stewart Orchard at World of Dragon who has now also published them on his own github page here