Dragon Network Project

Introduction

The primary purpose for the network was to create a DragonDOS compatible network environment to use with a Dragon 32 which was to be located in the attic, away from my main machine. At the time, I also only had a single disk enabled machine and this also enabled me to explore my interest in networking.

Fundamentally, the Dragon Network Operating System (DNOS) is a re-implementaion of DragonDOS but for a network based system. 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 opens 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.

Once I had DNOS up and running I moved onto extending the network to support OS9 in a number of (and in hindsight somewhat overkill) configurations that I'll attempt to describe later.

The fine detail of the Dragon network is captured here in the Dragon Network Specification which I co-authored in 1992-96.

I have tried to collate here all the documents, design notes and crucially the software I wrote in support of this on this page. There is quite a lot of it.

Hardware

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.

Here is a network card using the above CPU piggy back configuration (the 6809 would sit in the empty 40 pin socket). This board has an 8K SRAM bank fitted and was used during development of the OS9 based network. The flying black lead connected to the cartridge port EXMEM line for address decoding..

Network Software

Dragon Network Operating System (DNOS) V1.1

DNOS V1.1 was finished at the end of 1992. This is the 4K and a bit of software which resides on the 8K EPROM sitting on each network station. Central to the operation of the Network (and replacing the disk command processor at jump vector $C004) is the Network Command Processor. This provides the key routine of issuing a command packet plus any parameters to the server, waiting for and retrieving the response back, validating the results and passing them back to the caller. All the higher level DNOS calls make use of this to issue network requests.

DNS provides a set of DragonDOS compatible commands, and machine code jump table to talk across the network. All disk io operations are passed to the server, which then performs them on it's own floppy disks. As it stands, the only commands not implemented are the data file FREAD/FWRITE functions although data file access is provided through the extended OPEN/PRINT# type commands although it is not that efficient. DNOS will run on either a D32 or D64.

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 worked well and was 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.

Here is (I believe) the complete source file set for the network code base. This is held as a mixture of DASM/DREAM assembler files and for the server BASIC startup code.

DNOS.ZIP

and here is the DNOS User Manual (this was converted from a fairly ancient DOS word processor so the formatting is somewhat skewed)

OS9 Network

This section covers the extensions I made to the network to support OS9.

Network Clients

I'll start off with discussing the network station/client side of things because that is relatively straightforward in comparison with the server side of things. The starting point for each station is the standard DNOS equipped network card.

DNOS implements the DragonDOS BOOT command which is used to start OS9. It does very much exactly the same thing as the DragonDOS equivalent - issue the read sector calls to pull in the OS9 bootstrap code, except these calls are issued across the network. With a suitably modified OS9 boot disk in the server, this will load a network enabled OS9 boot module (NBOOT) which effectively comprises a stripped down Network Command Processor with enough logic to continue to issue read sector requests. Again, we are still in DNOS territory here - NBOOT can now load the rest of the OS9Boot file into memory prior to it starting OS9 proper.

For OS9 networking I created a new OS9 File Manager - the Network Block Manager (NBF). This implements the standard OS9 I/O set - open, close, read, write etc. This manager is supported by a NBF device driver - NET6850, which is effectively a port of the DNOS Network Command Processor. Therefore for the most part, the NBF manager forms up command packets which it then passes to the NET6850 driver to issue to the server. Finally there are the device descriptors, these serve a special purpose in that they must be named identically as their counterparts on the server. So for example to access floppy drive /d0, an NBF associated descriptor, also called d0 must be loaded into memory. The NBF system allows access to any OS9 device on the server be it RBF (disks etc.) or SCF (printers, consoles etc.).

NBF als exposes the Network Command processor to applications via the OS9 Getstat interface. This allows applications to issue bespoke, non file related calls across the network. One use made of this is with a custom clock module (NETIME) which allows the system clock to be set from the network server. This is automatically invoked via a modified SYSGO module.

During development, I also created an RBF device which used the DNOS sector read requests. This allowed me to load software on the network stations during testing of the higher level protocols.

Network Server architecture

Conceptually what I was after here was a combined DNOS/OS9 network, that is it could accomdate both BASIC and OS9 clients. That raised a bit of a major problem as in order to have a single network server, what I'd need to do is implement either the DragonDOS file system under OS9 or OS9 under DragonDOS. Instead of tackling that, the approach I chose was to have two servers in the system leading to a configuration similar to the following:

From the network perspective we have an assortment of clients - both DOS and OS9 hanging connecting to what is essentially still a DNOS network server. DNOS network requests are handled locally however the server software has been extended to foreward OS9 network requests to a second machine which is running OS9. This performs the requested action and passes the results back down the link.

The key thing here is the link between the two servers, in theory it could be part of the network but this would add an exceptionally high overhead so instead I used a dedicated parallel port link. The OS9 server in this configuration was to be my main D64 housing my custom expansion board. Using one of the spare parallel User Ports, this was connected to the DNOS server, another D64 but this time via the parallel printer port which has the 74ls244 buffer chip removed (allowing bi-directional operation).

DOS Extender

Arguably a bit of a distraction but... the above is the ideal configuration however you will recall that earlier I mentioned I only owned one disk controller. Therefore in order to deploy this configuration I needed to adapt this slightly.

Typically the network cards in the server do not have the DNOS EPROM fitted as it loads everything from disk. In this configuration, the network card fitted to the DNOS server has the EPROM slot fitted but is replaced a DragonDOS ROM plus (what I term) a DOS extender. DOS ROMS are normally initialised by the BASIC ROM look for a signature code at $C000 (the letters 'DK'). If detected, they jump to a fixed initialisation routine in the ROM. However in addition to this, DOS ROMs (well DOSPlus anyway) also look for a similar signature code, this time at $E000 (the letters 'EI'). This allows for an additional ROM to be fitted and initialised in the same manner. Making use of this then, the DNOS server EPROM has a copy of DOS plus my custom extender. This intercepts normal DOS calls to the controller and redirects them to the parallel port where they can be actioned by the OS9 server. From an application level then, this translation is seamless.

On my system I never quite got to this end point, instead the network card was fitted with an 8K SRAM chip and I used to download a boot strap module from tape which would then request the ROM image via the parallel link.

Network Server Software

As you can imagine there is a fair amount of software components needed to make this happen. I'll start with the additions needed to make the DNOS server (this is the machine running DOS not OS9) handle OS9 requests.

The DOS Extender (EXTEND.BIN) sits in the upper 8K of the cartridge area at $E000, ideally flashed on EPROM above DOS. On my diskless DNOS server, it can provide patches to DOS to redirect the sector calls over the parallel link. If this isn't an option (as per my development system), I load a small loader binary BOOTLD.BIN which can request the OS9 server send across the DOS + Extender image (held on the OS9 file system).

The DOS Extender provides the packet level driver services (effectively replicating the Network Command Processor) for the parallel link via an indirect jump table. So even if a DOS is resident on the machine, this software is still required.

The SERVER.BAS and SERV.BIN files form the existing DNOS server. The BASIC component has been modified to attempt to load two additional binary files NETOS9.BIN and NETUDF.BIN. These add additional dispatch table entries to the server such that when network requests are received which aren't handled by the core DNOS code, they are passed onto these modules. NETOS9.BIN handles OS9 I/O requests (open, close, read write etc.) which are dispached as requests via the DOS Extender to the parallel link. NETUDF.BIN is responsible for user defined requests, currently just the network time request from OS9.

Now to the OS9 side of things...

At the interface level, I have created another OS9 File Manager, Sequential Block File Manager (SBF). This operates much like SCF except it provides the ability to transfer larger blocks of data in one transfer request as opposed to a byte at a time. SBF provides a fairly simplest interface, only really implementing the read/write calls which allow for a buffer of data to be read/writter. The PIA21 device driver performs the actual transfer to/from the MC6821.

Network requests are processed by the NET_SERV process. This waits for inbound packet requests from the parallel interface and reads in the packet header which identifies the type of request being made. NET_SERV will then fork a helper module to perform the actual request, waits for it to complete then resumes polling.

Two primary helper modules are required for a functionality. The OS9NETIO process actions OS9 I/O requests received from the interface whilst the OS9NETUDF processes user defined requests (currently a request to fetch the current system time).

If the server also needs to handle DragonDOS sector requests, a further DNOSNETIO process is required. Finally if the DOS Expander is to be loaded via the OS9 server, the NETPBOOT process is used.

That just about covers it, the archive below should contain all the source code for the software I've just outlined.

os9-network.zip