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

[John Kent]

Hi Roger,


On 23/11/2010 4:25 PM, Roger Merchberger wrote:
> I have a simple, honest yet stupid question:
>
> Why 12 bits? [[ Honestly, "Just Because" as an answer is perfectly 
> valid to me... ;-) ]]
>
> =-=-=
>

The PDP-8 has a 12 bit data bus ....
The only real reason is that it is an intermediate size between 8 bit 
and 16 bit and a multiple of 4 bits.
The CPU can be scaled depending on the memory size you want to use so it 
saves on FPGA resources.
Minimizing the number of bits also maximizes the speed of propagation of 
the carry bits in addition and subtraction.

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

In your scheme 16 bit read writes would also have to be word aligned 
which means realignment of the program data structures as well as 
instructions which is a major job. You could have a 16 bit bus interface 
unit, to fetch two bytes at a time rather than one and have it sort out 
instruction alignment which I think would be a better scheme.i.e. use 
the least significant bit of the Program Counter to determine 
instruction byte alignment or the least significant bit of the Effective 
Address to determine if the 16 bit read or write is word aligned or not.

My 6809 design is premised on the fact that in the first cycle you fetch 
the instruction, the second cycle you decode the instruction while 
fetching the next byte, the third cycle depends on the instruction, but 
might fetch the low byte of a 16 bit address or calculate an index 
address. The internal CPU sequencing and scheduling is geared to the 
byte wide nature of the instruction fetches.

To use a 16 bit Bus Interface Unit, would require a major redesign of 
the core in order to keep up with the rate of delivery of the 
instructions where as extending the size of the data and address buses 
maintains the over all structure of the design.

John.

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