During the 90's, I co-designed a fair amount of additional hardware for the Dragon and wrote quite a bit of software (both under BASIC and OS9) to make use of this additional hardware. Some of it was extensively used, other parts less so. By the time my interest moved away from the Dragon I had created a small network of Dragons (and CoCos), linked via a D64 (housed in a PC/AT case) to a Windows 98 PC using an 8-bit parallel port.
Unfortunately, with most of the hardware built on stripboard and my soldering skills probably not quite up to scratch much of the hardware is no longer functional. However on these pages you will find all the information I've managed to gather about the projects, including software in the hope they may be useful to the Dragon (and CoCo) community.
A lot of the information on individual projects appeared in NDUG (National Dragon Users Group [UK]) Up2Date disk magazine and is presented here in it's original form, augmented by additional software, diagrams and documentation. I am indebted to Ray Smith (Up2Date Editor) for the diagrams which were drawn by him for the Dragon's PMODE 4 screen which I have since converted to GIF files for this page.
I have tried to put the information about the projects in chronological order below along with some background information and links to more detailed information about each item. Many of these have been recently updated (March 2015) to include additional software, photos and schematics.
Dragon Cartridge Port
The primary access point for adding additional hardware to the Dragon (or Coco) is via the cartridge port connector. This brings out the key address and data lines from the processor and provides a simple mechanism for adding a single IO device as described in. This article describes how to connect up a Motorola MC6821 PIA to the cartridge port (two of which are used inside the Dragon for general IO). In my design, I used a cut down Tandy edge connector board and wire wrap to bring the signals out to 2 40W IDC connectors.
An alternative approach is to piggy back a board under the CPU using a 40 pin wire wrap DIL socket.
Most of the hardware for projects I worked on were located on a dedicated expansion board which consisted of a large piece of stripboard, originally sat above the main board in my D64 (the width of the machine). The board was connected to one of the 40W IDC connectors on the cartridge port, with the other routed to the DOS cartridge.
As further hardware was added onto the main board, I began to encounter random crashes - this was believed to be as a result of the additional load (and length of wiring) hanging on the processor signals. As a result an additional board was added which sat between the cartridge edge connector and the DOS cartridge/expansion board which provided buffering of all key signals.
At it's completion, the board housed 3xMC6821 PIA chips, a real time clock, dedicated sound chip and IDC connections for one of my network cards. In order to accomodate this additional IO (and given the decode provided by the cartridge port is taken up by the DOS cartridge) dedicated address decode logic is on the card. Ultimately this provided 8 additional IO regions in the area normally occupied by PIA echoes:
Both of the 8-bit ports provided by PIA #2 were routed to 2x20W IDC connectors I cut into the side of the Dragon's case in a pin configuration compatible with the BBC micro. I used this type of 8-bit parallel protocol to communicate with a number of different machines including the BBC Micro, Commodore 64 (includes assembler source) and ultimately to a PC which formed the basis of my PCShare project. The software advantages of using this type of communication over serial are that it's very fast and pretty much error free.
PIA #3 was used to connect to my RAM expansion board which was initially designed to provide a 128K (static) RAM disk for OS9. This was a separate stripboard, connected via 2xIDC ribbon cables. Due to space constraints inside the Dragon, I think this actually lived outside, sat on top of the case. It was latter expanded via an additional board to support 4x128K SRAMs, of which 3 were populated.
The 'A' side of PIA #4 was connected to an 8-bit Analogue to Digital (ADC) convertor whilst the 'B' side to a similar Digital to Analogue (DAC) convertor and formed the basis of my audio sampling project. Whilst the article covers the sampling basics, what it doesn't mention is that this project evolved into something which exercised pretty much every resource on the Dragon. When completed, I'd created a mouse driven GUI (which took up most of the 32K lower RAM) which allowed 8-bit audio samples to be recorded into the 384K SRAM expansion memory, replayed out and saved/loaded from disk. Furthermore the upper 32K of DRAM on the D64 could be used a a simple audio echo unit.
It's fairly well known in Dragon circles that the standard power supply is very much right on the limit especially on a D64 with a disk cartridge fitted and I was very much aware of this whilst bolting on all this additional hardware.
Greenweld Electronics are a UK electrical components supplier and back in the early 90's not only did they ship the standard fair of chips, discrete components etc. but they used to have in batches of "one off" type items that originated from kit being sold off or decomissioned and quite a few of these featured switched mode power supplies (SMPS). Some way into the building of my expansion board I picked up one such item that I used to replace the PSU on my D64.
The Dragon back board, which houses the power supply regulator and TV modulator is designed such that these functions are isolated from each other so the board can be readily cut down the middle. This enables the modular part of the board to be left in place and allow a substitute PSU to be dropped in. Here is the end result.
This dispences with the external transformer, instead mains is brought directly into the Dragon via a new power switch. The +/-12V and 5V rails are then brought out to the main board and linked across to the regulator board.
I've always been interested in networking and connecting machines together so given that I'd managed to acquire a number of Dragons and Cocos by the mid 90's I began looking at how I could connect them together. One of the other reasons is that I had plans at the time to use a Dragon 32 to control a model railway system and (having only 1 disk system at the time) wanted some way of being able to load software onto that machine without resorting to tape.
As a result the Dragon Network was born (along with the Dragon Network Operating System - DNOS). Today you can achieve much the same result using the Drivewire system which is significantly simpler - in terms of both hardware and software to use. One of the interesting differences though between these two systems is that my network protocol worked at a file based level - that is the requests over the wire were to read/write a distinct file as opposed to Drivewire which works at a sector level. This means that from a network client point of view it doesn't ever need to care about the disk file system being used at the server end (this is similar in a way to Tormod Volden's DWLOAD drivewire client). This opened up interesting possibilities such as the storing of BASIC files on an OS9 file system (or any file system for that matter). As a result one of possibilities is that my DNOS could be adapted to use Drivewire and provide a nearly complete DOS independent OS for a Dragon.
As part of the network development, I also produced a basic DOS extender module which intercepted sector level calls and redirected them to the parallel port - this could potentially lend itself to something similar under Drivewire to allow native DragonDOS disks to be read by the client.
I planned to attach CoCos to the network but I have significantly less experience of the organisation of the Tandy BASIC ROMs than I did with a Dragon, plus most of my software was for Dragons. As a result it seemed the best approach was to try and perform a CoCo to Dragon conversion job which fundamentally resulted in replacing the CoCos ROMS with Dragon ones and rewiring the keyboard matrix to match that in a Dragon. As a result, both my CoCos could be fitted with a Dragon network card.
PCShare started out life as a college project, it's original aim was to accomplish something very similar to that which the Drivewire system does today - the storing of virtual disks (in this case OS9 only) on a PC except it utilised 8-bit parallel communications instead of serial. This incurred a much higher overhead in terms of hardware complexity than the Drivewire system which utilises serial.
Originally an MS-DOS application, PCShare eventually ran as a fully fledged 32-bit Windows app providing:
I have redesigned my main PCShare page to include all the software and design information I have on this project because there was a lot of work involved in this and I hope it is still of use.
One of the ideas that struck me having now played around with the Drivewire system is that it could be possible to connect PCShare up to it and make use of some of the features that Drivewire doesn't yet offer. My early thinking is that the drivers on the PC side of PCShare (which were modular) would be adapted to act as a TCP/IP server. Drivewire clients could then (using the network layer provided by Drivewire) comunicate with it that way.
Here are some other more "stand alone" projects.
At the height of my Dragon projects, I had a D64 with 3 floppy drives, two additional expansion board wedged in over the main board and an expansion RAM pack sat on top of the case. I felt it was probably time to try and tidy this lot up and box it all into a PC style case. Here is the end result of my Dragon In a Box project. It's certainly tidier but looking back in hindsight (especially now I've had to pull most of the custom hardware out of the machine to get it function) I kind of miss just having the original machine. Putting it back though would be quite hard since I don't have the cases, covers etc. for the disk drives, floppy controller etc. Maybe one day I'll try though.
Dragon Train Control
Sadly not a lot has survived this particular project despite there being a lot of hardware involved - I found precious little of my schematics for this and the disk holding the software was corrupted (along with it's backup). However I have collated what I have about my attempts to create a Dragon based Train Control system.