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

[Frank Pittel]

I agree that a "coco4" doesn't have to be built around a "6809". As long as it
was compatible with a 6809 or had a 6809 mode. I'm thinking along the lines of
the 8088 to current version cpu. No reason to stall on the 6809 as a cpu. Areas
of possible improvement include "math coprocessors", graphics processors
increased address space, 16 bit data bus, dram refresh, etc.

Of course since I'm not the one that'll be implementing the changes (couldn't if
I wanted to) so it's easy for me to talk and in the end the person/people doing
the coding will make the decisions!

The Other Frank


On Mon, Nov 22, 2010 at 06:22:46PM -0500, jdaggett at gate.net wrote:
> 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.
> 
>   
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco