It's come along in bits and pieces since then, and today can support a number of Dragons running either Dragon BASIC mode or OS9. Read on for more information.
The network hardware consists of custom network cards using 5V serial comms based around the MC6850. Each card comprises minimal address decoding, direction select logic, the 6850 chip itself, clock circuit, 8K EPROM, network buffering logic and network station id logic. On reflection, the cards are a little overkill costing around £15-20 and could have some of the logic stripped out or at least improved (particularly the clock and station id circuits), however they are a reasonable starting point. They achieve about 15Kbaud across a single twisted pair - the board does allow faster rates though I think the software/hardware may have to change as I don't believe the polling of the device can be achieved fast enough.
A standard board has two 10W IDC connectors as it's interface, and typically is connected to a Dragon via an edge connector and then into the cartridge port. The board for the server is a little different depending on the network configuration, but will normally have only 1 IDC connector with the 8K EPROM removed. It will then need to be interfaced to the Dragon via some external address decode logic to enable it to be coupled in with the disk system. Two suggested address decoding methods involve either splitting out the cartridge port or piggy backing the CPU. Either method can be used to attach the server network card.
Click here to view the Network Card Schematic
The software itself is pretty modular and should a different design ever come into being by myself or anyone else, it should fairly easily port to a different packet protocol.
In addition to the DragonDOS commands set, two extra commands are implemented named LPRN or NPRN. These allow the use of a shared network printer attached to the server. After issuing an NPRN commands, all printer commands such as PRINT#-2 or LLIST are re-directed to the network and the data sent to the server's printer. The LPRN commands reverts to using the local machine's port. For BASIC programs this is transparent to the user, however machine code routines that print via the $800F ROM call or talk to the port directly cannot be intercepted. Calling the generic character output routine at [$A002] with the device set to -2 (254) will ensure the printer re-direction is actioned.
On the server machine, the server version of DNOS is also running taking full control of the Dragon, again this can be either a D64 or D32. The software merely monitors the network, and actions any network requests passed to it.
Generally, the system works well and is reasonably quick considering, especially if all you need to do is load a program and run. Data file io has not been optimised, and as such is a lot slower - someday I may get round to looking at this.
The network requires a minimum of 2 Dragons - 1 server machine and a network station. Up to 255 stations can in theory be connected, though 10 is probably a practical upper limit, I have only had 2 connected so far.
OS9 network support is a recent venture (the last couple of years on and off in fact) and as such has had little use or testing so I don't really know how robust or how well it will all work in normal use.
The OS9 network is combined with the DNOS one, to give a combined DNOS/OS9 network so in order to setup the network you will need a DNOS one to start with. The OS9 network is achieved by the addition of an OS9 server machine which rather than sitting on the network itself is linked to the DNOS server via a parallel link. How you achieve this link is up to you - either by back to back linking the printer ports or by additional PIAs or a combination of both. My setup uses the parallel printer port of the DNOS server and a spare PIA I have fitted to my OS9 machine.
A network station capable of running OS9 (ie. 64K RAM machines) can launch OS9 in the same manner as a normal Dragon would - by typing the DragonDOS command BOOT. An OS9 network boot disk in DNOS server's floppy drive will then launch OS9 on the network machine. Once into OS9 the machine can access all or a restricted number of the devices attached to the OS9 server ie. floppy disks, printer or even hard disk if you have one. This is achieved by a new file manager (NBF - network block file manager) and driver (NET6850). By loading device descriptors with the same name as those on the server machine you have immediate access to those devices.
On the DNOS server, an OS9 interface layer is loaded which simply intercepts the OS9 network requests and passes them on down the parallel link to the OS9 machine. The OS9 server also runs software to receive and process requests from the parallel port. In addition to this, the OS9 server is not tied to the network and can be used normally by running the server software in background - although if you only have floppy disks on the server this may not be effective as constant disk accesses will effectively halt the machine.
DNOS users can continue to use the system through the DNOS server, however there will also be the ability (will, because I haven't written it yet...) for DNOS users to use printer(s) attached to the OS9 machine - this will almost certainly need to be necessary if you have used the parallel printer port of the DNOS server for your link to the OS9 machine.
Again, the system works well, although the speed of the network link is noticeable, so any activity involving heavy disk io is not recommended (like the 'C' compiler). I have not had a chance to see how heavy network traffic affects the OS9 server, however accesses to my hard disk or ram disk are sufficiently quick that it should remain usable whilst serving the network.
An alternative to the OS9/DNOS setup shown in the previous diagram is to make the DNOS server diskless, and perform something similar to the OS9 software layer ie. pass DragonDOS disk requests to the OS9 machine as sector read/write operations. I use this method to avoid extra floppy disk drives/controller and it can simplify the hardware setup as you do not need to address decode in a network card in with a disk controller.
The DNOS server must have 64K RAM, or be able to map SRAM into the cartridge area. A standard network card can be connected on the DNOS server, identical to those used on the network stations, however the DNOS EPROM is replaced with some server startup code. This will request via the parallel link to the OS9 machine a copy of a modified DragonDOS, which it will load into the cartridge area in RAM mode, it will then auto-start it. The DNOS server can then talk to the OS9 drives as if they were it's own and start the network normally. The system then works much the same way as before. Of course, the dis-advantage to this is that the OS9 machine will have to deal with all the DNOS station's disk requests therefore preventing pratical use of that machine whilst the network is running.
If your main OS9 server connects to a PC via the PCShare project any network station running OS9 immediately has access to that as well - including the OS9 hard disk, and MS-DOS disks and devices.....
The OS9 network has more turned out to be a 'see if it can be done' project, how much use I will make of it remains to be seen. However, the next logical progression would be to enable the DNOS machines 'see' OS9 drives as their own thereby allowing DragonDOS files to be stored as OS9 files transparently - this would eliminate the problems associated with the diskless DNOS server, namely the OS9 machine being dragged down by floppy disk accesses - the DragonDOS files could be stored on the OS9 hard disk. Of course, if this were implemented at a 'network' level you could never get access to your files from anything but a network station - therefore I would probably embed it in DragonDOS itself by patching a RAM copy of the EPROM, you would then have a second Dragon - to all intensive purposes a stand alone machine which has a DragonDOS hard drive connected, almost a different project altogether.
November '96