OS-9 Level II for Dragon 128 (Beta)

The Dragon 128 was an unfinished project at the time Dragon Data went bankrupt. It was designed to have from 256 KB RAM up to 768 KB, and run OS-9 Level II.

The disks listed below come from the Dragon Archive. They have been converted from the DMK format to DSK to make them easier to use in other emulators. The Pascal and C compilers are the same as was sold for the Dragon 64, but the BASIC09 on the system disk is a modified 80-column edition.

OS-9 C Compiler (beta-c-compiler.dsk) (327,680 bytes): Two-pass compiler (cc1). Configured to use /d0 for include files.
OS-9 Graphics Demo and Source (beta-graphicsdemo.dsk) (327,680 bytes): Sources for the graphics driver including OS-9 DEFS files.
OS-9 Level 2 v1.1 System Disk (beta-os9-system.dsk) (327,680 bytes): Contains an early version of Level II. OS9p2 is edition 13. /d0/sys/errmsg is an executable module.
OS-9 On The Dragon 128 V1.pdf (OS-9_On_The_Dragon_128_V1.pdf) (30,786,172 bytes)
OS-9 Pascal Compiler (beta-pascal.dsk) (327,680 bytes): Identical to the version sold for Dragon 64.

Source files

These source file have partly been reverse-engineered and then augmented with text from assembly listings contributed by Richard Harding.

Sequential Character File Manager (scf): Sequential Character file manager handles interaction with terminals, printers, modems etc.
System definitions (sysdefs.128): The sysdefs file contains the characteristics of the specific architecture, such as the definition of the MMU, devices etc.
Systype file (systype.128): Systype defines the CPUType and CPUSpeed.
Term Device Descriptor (term): Has been adapted to SCF line editing extensions

Basic09 modifications

The screen device driver has many graphics operations. Dragon Data had therefore made modifications to add the graphics primitives as extra keywords in Basic09. The application looks for a sub-routine module called "graphics". These are then available directly.

PROCEDURE fill2
DIM col:INTEGER
FOR col=0 TO 2
  gclear
  CSET(8,1,2,4)
  graphics
  if col = 2 then 
    move(142,142)
    circle(74)
  endif
  MOVE(20,200)
  COLOUR(2)
  DRAW(" T0 D40 T-90 D20 T-90 D20 T90 D20 T90 D140 T90 D40 T90 D20")
NEXT col
END

Disk format

In the DMK format the disk images have 1274 sectors and 16 sectors per track according to the identification sector. 80 tracks x 16 sectors would give 1280 so there are 6 sectors missing. Track 0 has only 10 sectors. The purpose is to be able to read older FM formatted floppy disks. After the conversion to DSK format six unformatted sectors appeared in the first track and I moved them to the end to make it possible to read the disk. I then increased the number of sectors to 1280 and did a dcheck to verify integrity.

Memory Management

The following is mostly a theory based on reading the disassembled source code.

The Dynamic Address Translation is implemented with a 6821 PIA using 4 KB blocks. During the initialisation the pins on the PIA's A-side will be set to "OOIIOOOO", where O=output and I=input. The lower 4 bits implement the task register. The upper two bits (6 & 7) are for activating the MMU. At poweron, the registers in a 6821 are all zeroes. As described later, the ROM must be present at $C000 to $FFFF to be able to boot OS-9 and 00 in bits 6 & 7 ensures this. Later in the initialisation, bits 7 & 6 are set to 1 & 0, which activates the MMU. Dragon Data has chosen the SysTask to be $80, and the entire byte is written to the PIA, which keeps the MMU active. Additionally, the user tasks (1-15) are ORed with the SysTask, and therefore also have bits 7 & 6 set correctly.

There are four bits in the task register. It appears that the ROM is actually placed at $FC000. When bit 7 is 0 in the PIA, then the fours bits are all forced to 1 and the same if bit 6 is 1. Therefore only the combination of 1,0 will allow the DAT to have an effect.

Bit 7 actually triggers the NMI to the DMA CPU (which is the initialise transfer routine). So it's held at 1 conventionally to allow the DMA CPU to behave normally... hence the task number 'Orring'. Bit 6 when high does force the top 64k of the 1Mb address space. And the DMA CPU always sees task 0's map.

Boot sequence

The Dragon 128 has a 16 KB ROM. The interrupt vectors are at the end, so in order to be able to boot, the ROM must be available at $C000 to $FFFF. The DAT initialisation sets up the task registers to map a block of RAM at $0000, memory-mapped graphics at $6000 and two blocks of ROM at $E000 and $F000. The lower half of the ROM is ignored and contains only rts statements. The next part of the initialisation configures the devices and then puts "OS-9 is loading - please wait ...." on the screen.

The address space is scanned for RAM and ROMed modules. The "Init" module is linked. If "OS9p2" is available then it is executed otherwise F$Boot is called. On the Dragon 128 F$Boot is called. This system call links a module called "Boot" and calls it. The 128's Boot links a module called "bootdev", which is a device descriptor for a 40-track floppy disk. It looks up the driver name (wd2797), and calls a seventh entry-point, which does the boot. I.e. reads sector zero on the floppy disk, identifies the location of the boot file (OS9Boot), and loads it into memory.