[Coco] The Definitive Post on the CC-Five ;)

[jdaggett at gate.net]

On 28 Jan 2007 at 21:55, farna at att.net wrote:

> In order to achieve this, familiarity with hardware and the
> limitations of the Coco/6809/GIME architecture is IMHO a must. James'
> comments in earlier posts on enhancing GIME perfectly illustrate the
> approach that needs to be taken - i.e. with consideration for what's
> there now.
> 
> Frank > 
> I can agree in principle, but others shouldn't feel like they can't
> "sound off" with their ideas. They just need to realize some of them
> aren't practical, even if possible. We're definitely stuck with the
> GIME architecture if the desire is for a CC3 compatible machine, and I
> think that's a must -- otherwise it's just another computer. I think
> that CC1/2 compatibility can be considered secondary, and really just
> "icing on the cake". If it takes more work, I'd say leave it out. For
> the most part CC1/2 compatibility is assured because of the
> similarities with the CC3, but there are a few things, like some
> obscure graphics modes that were never used, that just don't need to
> be there. 

Frank

I think it is alright to sound off ideas. What will be needed is a collection of the ideas 
and a prioritization of them in implementation. The first step I need to do is finish a first 
pass GIME specification/design documant that I can do in the first pass. My intentions 
are to make the first pass as compatible as I can with the existig GIME with some minor 
improvements. In other words kind of walk before I run wild. 

Making a FPGA 100% drop in on the original COCO 3 may not totally be possible. The 
oscillator analog circuits could be done in a FPGA but may not be reliable. The one 
thing that I see as a hinderence is the S-Buss and the Z-Buss. For the S-Buss it would 
be more practicle to bring out the eight decode signals for external peripherals instead 
of encoding them and use the LS138 to decode those signals. Second is to drop the Z-
Buss and bring out all 20 address lines and use SRAM instead of DRAM. Ideally for 
future use would be to replace the DRAM controller with a dual port SDRAM controller. 
That way we could expand beyond the 2MB limit. To get the GIME to direct address 
2MB would only require the MMU to expand beyond a 16x6 ram toa 16x8 ram. Very 
easily done. In fact is done.

Also some things I wanted to do is to increase the vector table from $FFF1 down to 
$FFE0. At $FFF0/$FFF1 would be the 6309 trap vector, and then use $FFE0 to $FFEF 
as vectors for PS2 Keyboard, PS2 Mouse, and any other 6 vectors deemed necessary. 
In the FPGA this could be distributed RAM or even ROM.

I could go on and on. Right now I need to finish what I have started. I need to get 
something that is functional within a reasonable time frame. I am reviewing what work I 
have done in the past and kind of cleaning up some things to make it better. One thing 
that I have to do is make the MMU HDL code more transparent to FPGA. Currently it is 
coded at the Xilinx gate level and would not necessarily port over to other FPGAs. 

Keep sounding off on ideas. Eventually a consensus will be reached and a design will 
be born. I do agree that at first any FPGA will have to compatible with the existing 
software and hardware. Otherwise it is a wasted effort. 

james