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

[Roger Merchberger]

On 11/22/2010 11:39 PM, John Kent wrote:
>
> 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.

I have a simple, honest yet stupid question:

Why 12 bits? [[ Honestly, "Just Because" as an answer is perfectly valid 
to me... ;-) ]]

=-=-=

OK, I guess I have two... sorry 'bout that:

The current 6809 when dealing with 16-bit registers basically says "Grab 
half of Y, then go grab the 2nd half of Y, stick 'em together, and go 
about yer bidness."

Would it be easier if the "expanded 6809" had an expanded data buss to 
16 bits, such that: a) the CPU could just say "Grab Y and go" when it 
needs a 16-bit register, and b) as far as code goes, if one were to 
recompile / reassemble programs to realign 8-bit data on the 16-bit buss 
(assuming 0 for an MSByte, would it be easier to design if the 8-bit 
realigned data was just assumed to be 0x00** (where ** is the 8-bit 
data) but reads could still be had in a single operation?

Yes, I know that in the "8-bit code running in 16-bit mode" software 
would have to be recompiled, which is less than optimal... but it would 
get existing software 1) running faster (I'd assume), and 2) still have 
a software base for the expanded processor somewhat quickly, I would 
think to help pave the way for more true-16-bit software if there were 
working 8-bit examples running in the expanded mode of the CPU.

[[ I say this thinking of all the headaches WRT the 80286's 'protected 
mode' ]]

I also realize that that would "bloat" the software; probably on the 
order of 50-70% more (I would think the 2-byte opcodes like LEAY 
wouldn't grow) but if we're talking about a computer that can access 2+ 
Megs of RAM, a 40K program "bloating" all the way to 64K shouldn't be 
too much of an issue, should it? ;-)

I'm not trying to "teach grandmother to suck eggs" -- The only thing I 
know about FPGA's is how to spell it, and I've designed a grand total of 
1 GAL in WinCUPL (an 8-bit inverter) thus far. I still don't know if it 
works as designed, because I have to rebuild/format/etc. my programming 
station with DOS because I found out that my parallel programmer doesn't 
like WinXP even in any of the compatibility modes...

These questions really are to help me understand (in a Grade 6 manner 
;-) the complexities of a project like this. 'Course, on rare occasions 
the best ideas really are the stupid ones... ;-)

Thanks!
Roger "Merch" Merchberger