6809/6309 Eurocard CPU System

During the development stage there is a requirement to convert 6809/6309 assembly into binary OS9 modules. Thankfully OS9 is well structured and the number of modules needing changes is relatively small. Apart from the bootloader and kernel modules there are also driver modules for serial ports and disks that need changing or writing from scratch. To do so I use the Virtual Color Computer (VCC) emulator on a Windows system (https://github.com/VCCE/VCC).  It is provided in both source form and binaries. It can also be run on Linux platforms.

The emulator allows you to hook up 4 virtual floppy disks and 2 virtual hard disks. I've installed the NitrOS9 operating system which has lots of nice code with it including a modified assembler that will generate 6309 code. Just what I needed to create a set of adapted OS9 modules from existing source code.

VCC works with disk files (.dsk) for floppy or (.vhd) for hard disks. Files can be extracted or inserted into these virtual disks by using Toolshed (https://github.com/nitros9project/toolshed). You can also create blank virtual disk files using this tool. Alternatively there is a  Windows tool called Floppymaintenance (http://flexusergroup.com/swtpc/Downloads.htm). The latter option uses a nice looking GUI but I have had issues using it.

If you are looking for a crosscompiler that can create OS9 modules from source then LWTOOLS is recommended (https://www.lwtools.ca/).

Details of setting up  NitrOS9 can be found online (https://lcurtisboyle.com/nitros9/nitros9_docs.html). A quick online search will feature some guided youTube videos as well.

In fact NitrOS9 is a further development of OS9 developed and maintained by the Color Computer community and has many upgrades. It would be a logical next step to adapt it.

Source code for the first part of the OS9 kernel (OS9p1) adapted for the CMS9639 is published on GitHUB (https://github.com/sorenroug/osnine-java/tree/master/os9software/cms9639). The binary file is available at https://www.sardis-technologies.com/oth6809/cms9639.htm.

I took the binary file as is and removed the Boot loader part at the beginning of this file and added my own Boot module. (The CMS9639 Boot module is not well documented but seems to use a SCSI controller as a disk interface to a Winchester hard disk which I don't have). In order to manipulate binary files I use ImHex (https://imhex.werwolv.net/) which includes a 6809/6309 disassembler (amongst many).

The CMS9639 part 1 code is different than the 'stock' OS9p1 code. This not only has to do with the details of the MMU but also because the CMS9639 has a nice way of capturing the postbyte which follows the SWI2 system calls. The postbyte indicates which system call is requested. Other systems have to capture this byte from user space and adjust the program counter so that upon return the location with the postbyte is skipped. The CMS9639 does this in hardware and makes the postbyte available in a dedicated memory location accessible only in the system state (see memory map on page 1 of the schematics).

Secondly there are a few memory copy routines between tasks and since this has to work between tasks there is a significant overhead of switching. The CMS9639 removes the instructions for copying and uses the memory-to-memory functionality of the DMA controller with different tasks for source and destination.

It seems I have implemented these hardware ideas correctly because I can see (with the use of a Agilent 16802A logic analyser) the system calling the Boot module which loads the so-called OS9boot file from disk (well CompactFlash in my case). Afterwards I can see the processor starts to execute the OS9p2 code which is the second part of the OS9 kernel. There is no dedicated CMS9639 version of OS9p2 so I have used a standard one at this stage (https://github.com/sorenroug/osnine-java/tree/master/os9software/dragon128).

I do get an error upon changing directories to the default /H0 disk as indicated on the Init module which is loaded during Boot time. I suspect there is an issue with my bespoke disk driver module which has not been tested too well.

OS9 is hard coded to use 256 byte sectors which is half of what IDE/PATA/CompactFlash filesystems have. I tried to be clever to put two 256-byte sectors into one 512 byte sector using a cache. For now I will just use one half of a 512 byte sector which makes things fast and simple.

After updating the disk drive to use every other byte of a 512-byte sector and ironing out several bugs OS-9 booted on the system console as shown below. The hardest error to find was an indexed store of the B register which turned out to be unindexed (I forgot the 0,U) which corrupted the least significant byte of the D.POLL variable. As a consequence the system would go haywire after receiving interrupts ...

Great to see this!

In he Init file I have set 0x0FBFFF as the Top of RAM.

There are no floppy disks specified yet, I still have to write the driver.

The modules needed for booting are listed above and have standard names. Exception is IDEdrv which is the RBF type driver for the IDE board that was hooked up to a 512Mbyte ComplactFlash card.

All these modules (minus the MDir one) are part of the OS9boot file that is loaded by the low level boot loader that together with OS9p1 resides in EPROM.

For creating the boot disk I made a full system disk using VCC and used a small python programme to bulk up the 256byte OS9 sectors that make up the virtual hard disk file (.vhd) to 512-bytes simply by inserting a 00 byte every other byte in the disk effectively doubling the disk size. This programme code is attached for info.

Virtual hard disk files are just binary files that contain sector data starting with Logical Sector Number 0. No added information so it is easy to manipulate them.

To create a Compact Flash card with the modified OS9 boot virtual hard disk I used a Compact Flash to USB adapter and a well known writer called BalenaEtcher (https://etcher.balena.io/) but there are many other solutions. Upon selecting the modified virtual hard disk file BalenaEtcher gives a warning about missing partitioning table. Just ignore and continue and it will write the data to CompactFlash.

Next step is to test the Clock module and integrate the RealTime Clock which has a battery so it would be good to automate getting date&time at boot time. The RTC I use is the DS1302 which has a rather horrible serial interface which is asymmetric between Read & Write cycles. Initially I had hooked it up to some PIA lines but the code to bitbang the RTC was large and slow so I ended up doing a Verilog implementation which takes care of all the bitbanging and presents a set of registers containing date& time info (see memory map on the schematics).