Topic: Dragon 64 Repair Log  (Read 3763 times)

Author Message

0 Members and 1 Guest are viewing this topic.

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1190
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Dragon 64 Repair Log
« on: May 04, 2014, 08:04:08 AM »
As part of my current drive to de-clutter and clear the decks I finally got round to looking at this beastie...



...which had been sat on the floor for well over a year, possibly two.

I bought it as faulty (my favorite feature) for a very small amount of cash for a D64 (which are pretty rare) and here it has sat. Dragon Data went bust not long after the D64 was released, so am not sure if this is a very early one, or a very late one.



I has taken me so long because the power supply it wants is weird, it expects 8.5VAC and 28VAC (yep AC) in via a 9 pin D connector on the rear.



I did look into the schematics and it seems that the 28VAC is not something I could ignore as it is used to generate the +12V and the -12V and I seem to remember this was used in the video generation circuit. On some systems you can possibly ignore the highest voltage power supply if all it is doing is providing 12V for the RS232 port.

Getting a transformer to provide these very non-standard voltages seemed extremely unlikely but something occurred to me, a transformer with taps for 30v and 9v is not hard to find. These all seem to be rated at 240V input, to get the 30V and 9V output, but if you take the input as 220V the figures shift downwards a notch and you get pretty much what this thing wants. It probably isn't that critical anyway as the voltages go straight into an internal power supply board that feeds into voltage regulators so there is almost certainly a lot of headroom, and the mains may or may not be 220V anyway as it varies somewhat.

The end result was I didn't bother, mainly because i found an original Dragon 32 PSU on eBay in the UK for a tenner and picked it up the last time I was over.



Next step - video, this only produces composite video or RF, take it or leave it, no RGB option, which is surprising really. The neatest option seemed to be to take one of those AV-micro USB leads that every camera comes with, and no one ever uses, to make up a proper lead.



Putting them all together got me this ...



...it starts off all red, then within a few seconds the green sections turn green.

I had had the lid off before...



...and  was very confident this would be a DRAM error, as it had already had one of the 8 DRAM chips replaced in the past.



This has 8 64kbit chips, each chip contributing a single bit to every single byte, so the loss of one chip will break every single byte the machine tries to deal with. The result of this will be a wedged machine as it literally cannot do anything. This is bad for faults but not bad for troubleshooting as each chip has its own data line. I was hoping that the scope would show one with no activity on its output, but all were buzzing away and looked healthy.

So I hooked up the Fluke 9010A and my 6509 pod to the CPU socket to do a full test on the buses, followed by RAM tests, expecting to see one bit per read/write stuck high or low.





The bus test passed which proved there were no stuck data, address or control lines on the system, so just to confirm the fault was still the same I hit the "Run UUT" button ...



... which uses a reference CPU in the Fluke Pod to attempt to run the board. I was expecting to get the same screen of rubbish, but ...



...it lives, the fault was a dead CPU, pretty uncommon.

The 6809 pod for the Fluke is unusual compared to other pods as the reference CPU is external, as the 6809 came in both 6809 and 6809E formats, so the pod user provides the reference CPU in a ZIF socket and some dip switches to configure it for the right type...



...dropping the reference 6809E CPU into the board socket proved there was nothing else going on and the board could live without life support.



As an end note - it turns out that the pattern I was getting initially...



...is exactly what a Dragon will put out when its CPU socket is completely...



..empty!
« Last Edit: May 05, 2014, 04:48:55 AM by Womble »
Sic Transit Gloria Atari

Offline AndyRCM

  • >=))))º> GO FEED THE FISH! <º((((=<
  • Administrator
  • Amiga 4000
  • ******
  • Posts: 9644
  • Kudos 50
  • Gender: Male
  • Manic Jet Set Willy
    • View Profile
    • Retro Computer Museum
Re: Dragon 64 Repair Log
« Reply #1 on: May 04, 2014, 08:17:50 PM »
Well . . . now you have me mate - as MUCH as I absolutely love your arcade repair logs . . . repairing computers/consoles you will have me forever! ;)
Seriously nice work mate.

A
"I could see the faces of those who led pissing themselves laughing" - Funeral Pyre by The Jam

Offline questor

  • user
  • Amiga 4000
  • *
  • Posts: 862
  • Kudos 38
  • Gender: Male
    • View Profile
Re: Dragon 64 Repair Log
« Reply #2 on: May 06, 2014, 12:04:43 PM »
I've repaired a fair number of Dragons in my time - nearly all of them have been dead CPUs - commonly caused by inserting/removing cartridges whilst powered on.

Oh - and that serial number is quite low in the production run.

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1190
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Re: Dragon 64 Repair Log
« Reply #3 on: May 08, 2014, 12:26:15 PM »
Thanks for the info, makes sense considering the CPU's placement. Will have to retrobright this next summer, a D64 should be light grey, not C64 beige.
Sic Transit Gloria Atari