[Coco] Embedded coco

[jdaggett at gate.net]

On 19 Dec 2003 at 10:14, peak at mail.polarcomm.com wrote:
 
> For a really simple address decoder we could use a 74ls138 
> chip with its inputs connected to the top 3 address lines 
> (A13,A14,A15). Each of the output pins of the "138" would then
> be a decode signal for an 8k Byte block(8k x 8 = 64k). Some 
> of these decoded blocks are the same as a real coco.:
> $8000-9FFF(Ext Basic Rom),
> $A000-$BFFF(Basic Rom),
> $C000-$DFFF(Cartrige Rom-CTS).
>  The actuall coco did in fact use a 138 chip in a similar way 
> but instead of connecting it to the CPU's address pins 
> directly it was connected to 3 pins of the SAM/GIME which 
> performed some pre-decoding. This pre-decoding is only one of 
> the SAM or Gime chips functions and a small one which can 
> easily be duplicated without actually needing a SAM or Gime 
> chip. I will work on that and get back to you with a TTL 
> version.
> Eric
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Eric

The S-Buss off the GIME chip or the SAM chip is not as simple as you may think. In 
The CoCo 3 the GIME chip keeps track of where the processor is addressing at 
least form $8000 through $FFFF. There are built in address decoders. Due primarily 
to the lack of pins the GIME encodes the chip select lines so that an external 3 of 8 
decoders is used to give you the 8 chip select lines. I guess they had extra die 
space and did not want to extend the GIME chip beyond the 68 pins. The next 
standard size PLCCpackage is 84 pins.

The same could be said for the SAM chip in the CoCo 1 and 2. The next standard 
size DIP package is 64 pins. 

The address decoders used in the SAM and GIME chips can be duplicated in a PLD 
to give you anywhere from 8 to about 15 or more chip selects. 

james
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco