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

[John Kent]

There is flash memory on the DE1 board and there is 8MBytes of SDRAM 
which to the best of my knowledge is not used.
Access to extended memory can easily be achieved by mapping in another 8 
bit page register in I/O somewhere to extend the memory.
This would remain backwards compatible with the CoCo3 as the register 
would not need to be modified for existing programs.

The overheads of SDRAM access may make it slower than the SRAM on the 
DE1 board. It is possible to implement a cache out of internal memory 
rather than using the internal FPGA memory for ROM. The cache would 
speed up both SDRAM accesses and Flash memory and would even allow you 
to share the memory with multiple CPU cores. I'm not sure what the 
capacity of the DE1 Cyclone 2 FPGA, but I'd imagine its pretty similar 
to the the XC3S1000 Spartan 3 on the Xilinx Digilent board. I had the 
idea that Gary's CoCo3 only used about 2/3rd of the capacity of the 
Spartan 3 FPGA. The CPU uses only a relatively small proportion of the 
FPGA, so it should be possible to implement a multi CPU version of the 
CoCo3. NitrOs9 could then be updated to include inter processor 
communications and you could conceivably schedule tasks to run on 
different CPU.

This is probably not of much interest to those who just want to run 
games, but does provide an opportunity to those who are interested in 
extending the capability of the operating system.

FPGAs are much slower than you average PC with clock speeds around 
100MHz as opposed to 2 or 3 GHz, however, The FPGA can be incrementing 
the Program Counter of the 6809 at the same time as it's performing some 
ALU function or calculating a register offset.  Also the PC has to 
execute multi-cycle instructions to interpret the 6809 instruction, 
(albeit piplelined) so even with the most optimized assembler code, you 
are talking about many cycles and many instructions to do what the FPGA 
does in one cycle.

Then there is power considerations. A PC CPU consumes in the order of 
100W which at 1.1V is about 100A. The FPGA board by comparison can be 
powered off a 500mA USB socket at 5V, so the FPGA wins hands down from a 
power efficiency point of view.

There is also scope to integrate a Floating Point Unit in a CoCo4 to 
speed up floating point maths, so there are lots of things you can do to 
enhance the CoCo3. It depends on whether people want to extend their 
ability and knowledge or whether they are content with the nostalgia for 
the good old days, which is fair enough. I have no quibbles with that.

John.


On 21/11/2010 12:48 AM, Mark McDougall wrote:
> On 21/11/2010 12:16 AM, Frank Swygert wrote:
>
>> The main issue is ROM and FPGA space. The CC3 can only access so much 
>> ROM,
>> and to make it compatible you have to have some of the old ROM code.
>
> Gary Becker's Coco3FPGA can only access so much ROM.
>
> An FPGA can access an arbitrarily large ROM/RAM.
>
>> On the emulation side it's not as big an issue, but on the FPGA side the
>> bigger the FPGA has to be (and higher cost) to have all the extras in 
>> it.
>> This is something the two systems could diverge in though -- CoCo 1/2
>> compatibility in emulation, not in FPGA.
>
> I think people are overestimating the resource requirements of the 
> FPGA. Things don't necessarily scale like some people imagine. It's 
> generally more-so the resources off-chip that are going to be more 
> expensive.
>
>> The emulation method could just have a menu option to
>> switch to CC1/2 mode, but that might require a re-boot.
>
> Yup, that is probably most likely.
>
>> If it were USB, it would have to have a nice abstraction layer, as USB
>> is a right pain to program for, if memory serves...
>
> Depends if you're the host or the device, and which device you choose.
>
>> Exactly!! There has to be some kind of floppy emulation if not a 
>> physical
>> drive. This could be a problem with FPGA real estate, and may be another
>> diverging point -- FPGA with real floppy, emulation with an emulated 
>> floppy.
>
> Floppy emulation does not require a lot of resources. Look at Minimig, 
> which runs on the DE1. It does twice what Coco3FPGA does. It has twice 
> as many processors, much better graphics, floppy emulation, etc.
>
> And the DE1 has quite a small FPGA for modern day standards.
>
>> The main issue is that we really do need the two systems to be 
>> compatible,
>> 100% if possible. So what limits the FPGA version will also limit the
>> software version and vice-versa. That's the only way to ensure they are
>> compatible with each other.
>
> Or we specify "must have" and "would be nice to have" requirements 
> that provide a lowest common denominator for cross-compatibility.
>
> Regards,
>

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