[Coco] What would a CoCo successor have to have as a minimum?

[jdaggett at gate.net]

On 21 Nov 2010 at 16:58, Aaron Wolfe wrote:

> this makes me wonder, should a "coco 4" just use a different or
> additional processor?
> since our targets are fpga and emulators, we aren't really tied to
> processors that exist in silicon.  we could add a 68000 or create some
> sort of hybrid 6809/68k type of thing.
> probably a lot of work, but sounds like it would be difficult to see
> significant improvements to graphics if we don't change something in
> the architecture.

A 68K cpu core does exist now. 

A 6809 cpu core does exist now.

A hybrid does not but is not out of the question as doable. 

A hybrid would merely extend the memory bus interface logic from 8 to 16 bits. Also would 
need like the 68k an upper/lower byte control bits. maybe some more things that I have forgot 
about. 

Off the top of my head I don't find this to terrible to implement. Considering there are 8 bit 
stores and loads as well as 16 bit store and load opcodes. There may be a more indepth 
rewrite of the existing 6809 cpu core to handle this. I don't see it impossible. 

>From a time to have something available, either a 68k or a 6809 soft processor would be 
essential. Any hybrid will need time to code and test and verify. A longer development cycle 
that is worthwhile to investigate feasability.

Yes a coco4/5/6/7/...... would not necessarily have to be restricted to a 6809 processor. 

It all boils down to what do we define a system to be. Initially the real wants were to:

1) use current monitors due to the lack of older CGA monitors and their limitations.

2) use of modern keyboards and mice. Either PS2 or USB would be acceptable.

3) more ram. 2Megabyte. The OS9 users can take advantage of this expanded memory over 
DECB users. This is basically the limitation of DECB and not the hardware.

4) 4 MHz back then was the dream speed. 

5) 8 bit color. 


These are what comes to mind without going back over archived messages and researching 
this thread. All are doable now in some form. 8 bit color in any screen larger than say 
160x200 with motion is a bit more difficult to achieve. Most of the rest is very doable and 
more than likely done on other systems. 

So it now leaves the ultimate decission on a direction. WHat I wnce proposed years ago was 
to do a GIMEII chip that would interface to a 6809/6309. The first pass would allow 1, 2, 3 
and 4 with no problems. There are a couple of hurdles to cross over. One being the limited 
pin out of the current GIME chip does not allow for the expanded memory address lines. 
There fore no real plug in retrofit to the existing coco3 board. Even if I were to use the 
"TEST" pin (# 39) and/or the oscillator pins, a suitable replacement would cause the user to 
desolder the PLCC socket and solder in pin headers to accept the newer GIME chip board. A 
plugin sollution to the PLCC socket is a labor intensive one and not reccommended. 

This now leaves the only other solution in a new PCB. If one is to do another PCB, it is better 
to make it smaller and cost effective. One means of cost effective sollution is to incorporate 
the CPU in with the GIME chip. SRAM instead of DRAM. All this is still doable. All this is now 
being persuued for at least my own use and wants. All are willing to share. That is why I really 
am hesitant to call my project a coco4. More like a coco3+. 

just some thoughts 

james.