[Coco] Re: OS-9 as Replacement for DECB.

[Boisy G. Pitre]

Stephen,

I have analyzed this topic thoroughly over the years, and have come  
to the following conclusion:  the CoCo 3, as designed, cannot easily  
accommodate internal expansion except through the cartridge port,  
without vastly changing or extending the hardware.  The only truly  
"easy" way to expand the machine is through the cartridge port.

You are talking about changing the very essence of what the CoCo 3 is  
when power is applied.  This is certainly an interesting topic, and  
there are a lot of possibilities to be explored.  For instance,  
instead of a BASIC interpreter, one could have the CoCo come up into  
an interpreter for another programming language, take on the  
personality of a terminal, become a debugger, etc.

Having NitrOS-9 as the basis of such a personality change can be done  
(I allude to the NitrOS-9 ROM Kit that Cloud-9 sells).  Given that  
NitrOS-9, even in the barest of configurations, will take up at least  
12K, that leaves only about 20K for applications.  This isn't nearly  
as bad as it sounds, because a LOT can be done with 20K if you write  
in assembly.  If you take out IOMan, SCF and all the other stuff  
below and write your own I/O routines, then you can reap enormous  
space savings.  The obvious advantage to using NitrOS-9 is that it  
provides services for memory allocation, process creation and  
scheduling, and other services.

Thinking along those lines, there are two approaches that you can take:

1. INTERNAL STORAGE SOLUTION
The ideal solution in your case would be to perform such an  
enhancement without modifying the CoCo 3.  Currently, the only way to  
store permanent code on the CoCo 3 is through the 32K ROM.

There are several approaches in place that could bust that barrier.

A. Software solution - The use of compression would allow more data  
to fit into the 32K area, but you have to weigh that against the  
decompression routine itself and the space it would save.  A best  
case estimate is that you could get 2:1 compression and house 64K  
minus the decompression routine.  Time would have to be invested in  
researching the appropriate compression technology to use, and weigh  
time/space costs.

B. Hardware solution - What would be necessary is a small board with  
flash and appropriate logic to implement a "switching register".   
This 8 bit register would be mapped into an appropriate memory  
location in I/O space.  Ideally, one would POKE a value into this  
register and select a 32K bank.  With an 8 bit register providing 256  
possible unique values, that means a flash the size of 32768*256, or  
8MB, could be supported.  There would be some hardware modifications  
needed to fit this into a CoCo 3.  The ROM would not necessarily need  
to be removed, but one or two pins would need to be clipped, and  
additional wires would need to be soldered to address and data.   
Actually, it might make sense to desolder the ROM and in its place,  
put this plug-in board in place.  There may still be additional wires  
that need to be connected to other parts of the CoCo 3 motherboard.   
Also, programming the flash in-circuit would present certain  
challenges that may need to be met by having additional logic and  
programming steps.


2. EXTERNAL STORAGE SOLUTION
Such an approach would eliminate the need for you to open the CoCo 3  
or touch it with a soldering iron.  Ideally, one could have a "flash  
pak" cartridge that would plug into the side of the CoCo using the  
footprint of a shortie pak for minimum visual obtrusiveness.  This  
could work much the same as the hardware solution above, except that  
a smaller memory window might be mapped into the cartridge space at  
$C000 (the SuperIDE currently uses this method for its 64K flash part  
-- 16K at a time can be viewed at $C000-$DFFF).

The cartridge approach makes it seamless, since the ROM inside of the  
CoCo 3 is already programmed to detect the presence of a cartridge  
and jump to a predefined memory location if it exists.  This "hook"  
would allow you to totally change the personality of the CoCo 3 into  
what you want.

In effect, the external storage solution is what the SuperIDE and HDB- 
DOS are about.  If you want a more transparent (i.e. invisible)  
solution, then going for internal storage is the way to go.


CONCLUSION
If you want to intricately change the personality of a CoCo 3 and  
your application can fit in a small footprint, then yank out the 32K  
ROM and write custom software that will reside in that space to do  
whatever you want, or use NitrOS-9 as a basis for your environment  
and write software around that.  I'm not sure how successful you  
would be in implementing the Disk BASIC environment running under  
NitrOS-9 and put all of that in ROM with the limitations in place --  
that would certainly be a challenge.  However, I cannot think of a  
more fun way to experiment with your CoCo.