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

[John Kent]

On 23/11/2010 10:22 AM, jdaggett at gate.net wrote:
>
> 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.
>

I was working on a scalable 6809 design I called System1609. I basically 
parameterized the address and data bus width so the data bus could be 8, 
12 or 16 bits and the address bus could be twice that, i.e. 16, 24 or 32 
bits.

The op code was shifted to the highest 8 bits of the op code word and 
the addressing modes were extended with longer addresses.
There were still a few problems to overcome, such as adding half carry 
bits and adding bus cycles to the multiply instruction, or substituting 
single cycle hardware multiplication which are often found in FPGAs 
these days.

The decimal adjust accumulator instruction needed to be parametrized too 
which I wasn't too sure how to do. a 12 bit word has 3 nibbles and a 16 
bit word has 4 nibbles so you need additional half carry bits..

There is also the issue of byte addressing on a 12 or 16 bit data bus 
version as you point out.

The lower bits of the op code could conceivably be used to implement 
register banks for the accumulators and index registers, say by having 4 
bits in a 16 bit word to select 1 of 16 index registers and 4 bits to 
select 1 of 16 accumulators in a 16 bit word. This would be reduced to 2 
bits or 4 registers for a 12 bit CPU. Registers would have to be post 
fixed with a number, eg, A0, B1, X3 and so on.

The issue however is in designing a parameterizable compiler and 
assembler that can be used to compile programs for the different size CPUs.

> 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.

John.

-- 
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent