For all the retrocomputing fun and games we encounter in our community, there are a few classic microcomputers that rarely receive any attention. Usually this is because they didn’t sell well and not many have survived, or were simply underwhelming machines that haven’t gathered a huge following today. One that arguably falls within both camps is the Dragon 32, a machine best known in those pre-Raspberry Pi days for being the only home computer manufactured in Wales, and for being nearly compatible with the Tandy Color Computer due to both machines’ designs coming from the same Motorola data sheet. Repeat restorer of retrocomputers, [Drygol], has given a Dragon 32 the full restoration and upgrade treatment, offering us a rare chance to take a look at this computer.
The Dragon arrived with a pile of contemporary books and software, but no power supply. A significant modification was made to the internal PSU board then to allow it to work with an Amiga unit, and the black-on-green Dragon text came up on the TV screen. Recapping and a replacement for a faulty op-amp fixed poor video quality, then it was time for a 64K memory upgrade with some neatly done bodge-wiring. Finally there’s a repair to the very period-looking analogue joystick, and a home-made interface for the more common Atari/Amiga style sticks.
The Dragon may be only a footnote in the history of 8-bit home computing, but with its good expandability and decent quality keyboard it perhaps deserved to reach more homes than it did. This appears to be the first time a Dragon has featured here, though its Tandy CoCo cousin has made it into a few stories.
I own a Dragon 32. The joysticks are an… interesting… design choice.
Good grief, I remember having joysticks like that. They were horrendous! My D32 was only a fiver off a schoolmate though…
They were great for flight Sims though as they didn’t have a spring to return to centre.
I had a joystick for my APPLE //e that used a method to switch the auto-center spring in and out.
Tatung Einstein factory was almost in Wales! Just a few miles from the border.
Great restoration effort. He did well.
There was one thing I would have done differently.
I would have put a multi tap transformer into a project box and used the original regulator rather than strip it out completely.
It’s an interesting design and I can see where it lost market.
SRAM was so expensive then that it was never used in home computers.
DRAM was still expensive, especially faster DRAM so home computers of that era were generally around the 4kB mark so this computer stands out with its 32kB RAM.
The DRAM chips were actually manufactured as 64kbit (8 chips for a byte width) but had failed during the manufacturing process so were sold as 32kbit chips.
Anyway the extra cost of the large RAM came at the expense of other features that the market desired.
What the home computer market wanted was good color graphics. The competitor to the Dragon 32 and Tandy CoCo was the Commodore VIC 20. I had one of these. The VIC 20 was on the time line between the Commodore PET and C64.
The VIC in VIC 20 stands for Video Interface Chip and that ASIC graphics chip gave the VIC 20 far better looking color graphics capability over competitors still using the generic 6845 derivative Cathode Ray Tube Controller (CRTC).
Other failings of the Dragon is that most of it’s limited graphics capability was not even accessible from its Microsoft extended BASIC. The CoCo addressed this issue with later releases but the Dragon didn’t.
The 6809 CPU was also slow at 0.89MHz. It did have some advantages in it’s architecture but I doubt they were utilised in it’s porting of BASIC.
Later and more successful home computers had a dedicated ASIC graphics chip or a combination of the generic 6845 derivative CRTC and a Gate Array Logic / Programmable Logic Array / Complex Programmable Logic Device ( GAL / PAL / CPLD ) to enhance the graphics capability of the CRTC.
That’s what happens when you base your design from a reference design that was just proof of concept.
Then there was the TI-99/4 and TI-99/4A which when running console BASIC programs were for the most part actually running code for the 9918 or 9918A Video Display Processor, which had 16K of RAM, while the RAM directly usable (with BASIC) by the 16 bit CPU was only 256 bytes. With BASIC, the CPU mostly acted as a data shuffler. The way stacks and pointers were handled made some operations super quick, even in the really slow double interpreted console BASIC. Extended BASIC ran directly on the CPU without having to go through Graphics Programming Language first. ExBASIC is *much faster*. 3rd party BASICs are even quicker than TI ExBASIC due to having even more optimization of using the CPU directly instead of leaning on the VDP.
TI was working on a custom 8 bit CPU to directly run GPL code, but they weren’t getting the job done so the design was hastily modified to shoehorn in the 9995 16 bit CPU, a modified version of the 9900 to fit it to an 8 bit RAM and DATA bus, along with some other compromises. That presaged the way Intel would modify the 16 bit 8086 into the 8 bit bus 8088, though IBM would start their Model 5150 design from that point rather than starting with an all 8 bit system then having to adapt a 16 bit CPU to it.
I had 16 kilobyte SRAM cartridges for storage. Like an SSD, or more like a USB drive today, except you had to turn the computer off to switch cartridges. MSX computers had, they were very expensive and I don’t think very many were made. I got them cheap in some kind of sale.
Shame he reworked the internal PS, building a new external PS from scratch would have been an interesting project in itself, maybe next time, he’s definitely got the skills.
I had, and still have in the attic somewhere, a Dragon 32. I used it to gain experience with 6809 code as I was looking for a job in the arcade game creating industry at the time. Sadly the jobs didn’t pay anywhere near as much as those requiring Cobol at the time. Which was a shame as I seldom used more space to create a 6809 game than I used in just a Cobol Identification Division.
The Dragon 32 was my first computer. Games were a bit crap and Dragon Data shortly went bankrupt. The Microsoft BASIC was reasonable and the 6809 was a glorious CPU. Many years later at college we studied 6809 which I was fluent in. We built a ‘fire alarm’. Mine spoke!
About a month ago I ordered PCBs from JLCPCB using Grant Searle’s simple 6809 design. Worked perfectly. Need to build some peripherals now.
They once had a room full of these at Coventry University to teach assembler programming. Somewhere I still have photocopied instructions for the assembler cartridge!
There was also one of these in a glass cabinet (along with various other computer oddities) half way along a corridor in Cardiff Universities queens (Engineering) buildings. Its only reading now about how it was built in wales that its presence makes more sense. Its probably all been binned by now to make way for a self service costa machine or something.
Oh, to have so many excess Amiga PSUs that *that’s* your alternative.
The Dragon 32 was the first computer I ever owned. Eight year-old me loved that machine! I went on to the C= +/4 and then the Atari ST. I always seemed to get the unpopular machines.
Hi guys,
this site is new to me – congratulations – it’s obviously up to date.
My portfolio consists of about 20 Dragon – including 64 and Tano, and approx. 7 CoCo3.
The storecof cassettes ist at about 1.200 plus many 5.12 disks.
Still searching the Claw!
Based in Germany it is difficult to get individual contact – for the time being – to supporters of Dragon.
If anyone has the ability to help me buying Dragons Claw Inwould greatly appreciate that.
Cheers
Franz Mörsdorf – Frankfurt am Main
If anyone has a working Dragon 32 or Tandy Colour Computer, and wants to get into 6809 assembler, Rodnay Zaks wrote a complete manual for the 6809.
If you fancy doing this, you can quickly run up a working assembler using JavaScript in a browser, use that to generate the object code, and then figure out a way to transfer the code over. If there’s an RS232 serial interface on the Dragon or TCC, that will simplify the job enormously. Assemble your code in your JavaScript assembler, then port the bytes to the RS232 on the target machine.