[Coco] Embedded coco

[jdaggett at gate.net]

Eric

What I will need is to be able to read large amounts of data. This will be banked 
switched and stored in flash. About 1Mbyte of data. 
That is partially why I am interested in expansion. 

Why the 6809E instead of the 6809 is that a 6309E could be used instead of the 
6809E. Maybe more attractive. 

The 6x09 needs ram at least in the lower 256 byte block initially. And the upper 16 
bytes need to be mapped in preferably as rom. These are no problem

To use $8000 to $FEFF as rom and $FFF0 to $FFFF the PLD equation is simply 
this:

X0 =  A15*/A14
   +  A15*/A13
   +  A15*/A12
   +  A15*/A11
   +  A15*/A10
   +  A15*/A9
   +  A15*/A8
   +  A15* A14* A13* A12* A11* A10* A9* A8* A7* A6* A5* A4 

Where /Ax is not Ax

This can probably be simplified using Demorgan's Theorem but not worried about 
that now. 

A15, A14 and A13 yes can decode each 8L block of the memory map. You can use 
these address lines and some externa lor gates and decode larger blocks say 16K 
or 32 K. A PLD is neater though and less real estate. 

Base on an old 6803 SBC board you can put on a 4.5 by 6 card the 6809, a 6821, 
two 2Kx8 EPROMs and a 2Kx8 ram an RTC, a regulator and a simple serial port. 
Along with that headers for address port expansion and PIA ports headers. 

I would rather move up to a 8Kx8 for the ram and either 8Kx8 or 32Kx8 for he 
EPROM or even EEPROM. 

As for clock source and what ever is not a real big problem now. Only that the 
crystal will need to be 4X the buss rate. 

james

On 19 Dec 2003 at 10:14, peak at mail.polarcomm.com wrote:

> James
> If you want a lot of space for soft/firmware thats ok. You 
> can use a rom at $2000. Doing so will not prevent someone 
> else from using ram at this location. At the top of the 
> address space we simply "must" have rom at least temporarily 
> because that is where the CPU looks for its Interrupt and 
> Reset vectors! There are several ways to place a Rom in that 
> space. The way the real coco did that is to make the CPU 
> think it is looking at that space but actually reading 
> locations in the Basic Rom at $8000-$Bfff. This is an old 
> trick called "ghosting" which is really just Incomplete 
> address decoding but the coco did that whith special LSI 
> chips (SAM/GIME).
> 
> 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.
> Clock; OK a simple one chip with crystal E and Q clock is 
> fine. Go ahead and put that in the schematic. A 
> 3.58Mhz "Color burst" Crystal is both abundant and cheap. 
> However a 1/4 "Color burst" is not so how about a crystal 
> with a divide by 4 counter after it or just a common 2MHZ 
> crystal instead.
> Eric
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco