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

[Gene Heskett]

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.
It would also exacerbate, by adding drivers needing sysram buffers, the 
sysram shortage we have in Nitros9 now.  That needs to be put on a diet, 
probably by adding another 8k block of ram as driver I/O space, mapped 
in and out by the individual driver asking for its own 8k buffer space.  
But that is/was the basic idea behind level 3.  Just more "fine grained" 
and probably slower because the data then has to be copied to wherever 
its needed.

So lets not repeat the same cost driven mistakes that were made with the 
CoCo's from day one.  Lets do it right this time.

The reins of this are out of my hands of course, so all I can do is raise 
a hand & wave for attention, jumping up on a rickety soap box when I 
can.

That and my chip books are all out-dated, I expect if one searches deep 
enough, that we can get one chip, 10x faster 100% CMOS solutions to the 
decodeing problem than what I have data on.  In a surface mount package 
for under a buck.

> I recommend the !IOEN line on the expansion port (Kipper Port?) be
> made an input, and that input can be used to map the entire memory map
> of the main board out of the memory map.  That way, additional cards
> can easily move all of the RAM/ROM, and IO out of the way for other
> stuff (Full 64kB of RAM, etc.).  The MMU idea floated could be on a
> secondary card, and constrain the mapping of the UART to a specific
> set of registers in the c000-dfff space.  It brings the IC count down
> to 7 from 9 in the v1 unit.
>
> Of course, IOEN might be sacred, in which case my idea is not as
> workable.  But, having a pin like that would offer a way to move all
> or part of the onboard memory out of the memory map.
>
> Jim

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>