[Coco] CUBIX on the CoCo?

[Dave Dunfield]

>Portal-9 can handle includes with no issues. Actually some of the OS code could be 
>ported to Portal-9 as libraries and allow one to build a custom system. 

The source code is currently organized with INCLUDEs, and in many cases conditionals
around them to include different drivers etc. for the various standard configurations
that I use. Since I already have a preprocessor which will resolve these, I really
don't see that it would be a big deal to port it to any assembler.


>What I see as the first major work in porting is the keyboard scan. Looks as if Cubix 
>is looking at a serial port and uses a serial mouse.

CUBIX does not use a mouse, and does not intrinsically know about serial ports or
matrix keyboards - all of this would be contained within the console driver. CUBIX
supports up to 8 character stream oriented devices. Dev #0 is normally a NULL device
(which is really easy to write :-) - the remainder accept calls to put/get/test for
characters. The mechanics of how those characters actually get in and out of the
system are left to the driver.


>Unless one adds hardware to the Coco, the OS will have to work with the PIA chip 
>and generate the scan and poll routines to use the Coco keyboard. After that writing 
>a driver for the WD1773 controller is the next hurdle. 

I assume scanning the keyboard will not be a big deal on the CoCo - For an ultra-simple
implementation, you could step one row for each call to the test-character function in
the driver. For fancier with timed keyboard repeat etc. You could run the scanner on a
timer interrupt.

Talking to a WD chip isn't all that hard, and I would assume that someone has already
done low level code for the CoCo disk controller. The only real issue I see here is
that CUBIX includes a FORMAT function, and for the WD chip you need to build up a
track image - in this case, I think it would be acceptable to overwrite application
memory with the track buffer - this would prevent FORMAT from being called within an
application program, but that is not really a common or necessary function.

The only reason FORMAT is built into CUBIX (instead of a loadable application) is so
that you can FORMAT a disk and DOWNLOAD the system utilities to it from a host without
having to have a previously existing CUBIX system disk (Makes it easy to get Cubix up
and running on new hardware).


>Portting the I/O range up to $FF00 is not that difficult. The Coco3 can have the 8K 
>ROM sit at $E000 with little difficulty as long as the upper 512 bytes do not contain 
>code. Ram then can be from $0000 to $BFFF. 

CUBIX needs to control at a minimum the SWI vector, which is located near the very top
of memory (within the upper 512 bytes) - I assume the CoCo leaves RAM in the I/O space
for the vector positions?  Ideally it would have top level control over all of the
vectors.

I/O at FFxx would not be a problem. (What resides at FExx?)

I just checked, and CUBIX currently occupies from E000-F9CC - allowing 512 bytes
to be reserved at the top, this leaves just over 1K for I/O drivers. If that is
not enough, we could either move the whole thing down a bit, or just put some of
the driver code just below $E000 (leaving the OS at $E000).


Another possible area of concern is that CUBIX was designed to be installed in ROM,
and therefore does not provide for a "boot sector" on it's floppy image. It starts
off with the directory and allocation map and does not have any "spare room" for
bootstrap. I am not  familier with how the CoCo boots, however it it is necessary
for it to have a bootstrap at the start of the disk, the easy solution is to logically
offset the CUBIX area by enough sectors to accomodate the bootstrap.


>That should get it to boot to a simple system. Being able to work with the full extent 
>of the memory map and working with the graphics of the basic roms would be a 
>nicity but not necessary at the beginning.

Agreed

Dave
-- 
dave04a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Collector of vintage computing equipment:
                http://www.parse.com/~ddunfield/museum/index.html