[Coco] 6 Chip ^809 Computer -> Kipper SBC

Francis Swygert farna at att.net
Sun Mar 15 02:10:57 EDT 2015



Date: Sat, 14 Mar 2015 09:14:52 -0400
From: Gene Heskett <gheskett at wdtv.com>
To: coco at maltedmedia.com
Subject: Re: [Coco] 6 Chip ^809 Computer -> Kipper SBC
Message-ID: <201503140914.52655.gheskett at wdtv.com>
Content-Type: Text/Plain;  charset="utf-8"

On Saturday 14 March 2015 03:38:56 RETRO Innovations wrote:
> Looking over the schematic, I'd recommend using a '138/'266 combo to
> decode the address space into 6 chunks and not bother with fully
> decoding the address space for the UART.  It takes a lot of ICs to do
> this, and I feel another option will yield the same benefit.

Jim, this exactly the thinking that resulted in the coco shipping with an 
address decoder that only decoded in slices $20 wide.  So the on-board 
I/O used up $40 bytes when in fact it needed $08 bytes to service the 
two PIA's.

IMO, a full decode to  each $04 byte wide slot is the only way to go. 
That doesn't have to add to the width of the kipper buss IF the addons 
also contain the full decoder.  Just doing the full decode alone makes 
room for 14 more I/O spaces 4 bytes wide in the $FF00-$FF3F space below 
the FDC. That would be 7 ea 4 byte slots from $FF04 to $FF1F, and 7 more 
from $FF24 to $FF3F.

That alone would triple the working I/O space the coco3 has now.
========================

Yes, but this is mainly a controller/experimenter board, and wasn't intended to be a full fledged general purpose computer like the CoCo. It has many other limitations as it is, so I'd think limiting it to 7 or so add-ons wouldn't be a big problem for a minimal chip count board. If it was intended to be a general purpose computer then there are other things that it should have as well (such as video and keyboard on the main board), and the chip count would need to go up accordingly. 

 
Frank Swygert 
Fix-It-Frank Handyman Service 
803-604-6548 


More information about the Coco mailing list