[Coco] Why do a next Gen CoCo? was Any news on the so called CoCo4 or NextCoCo

Mark McDougall msmcdoug at iinet.net.au
Thu Nov 18 19:16:17 EST 2010


On 19/11/2010 9:50 AM, Steve Bjork wrote:

> As you can see, the CoCo4.com project was all about unlocking modern
> computer technology in the same the computers did back in the 80's.
> Something that modern computer designers just don't do any more.

I think it would be relatively safe to say that the majority of people are 
interested in a solution that lies somewhere between Steve's vision and that 
of Aaron & myself?!?

Anything beyond what Steve is describing is, IMHO, so far removed from a 
Coco as to be pointless. I'm not 100% sure of Steve's specifications but I 
would imagine that his BASIC language is more of an extension to DECB than a 
completely new language?!?

At the other end of the spectrum, going beyond an FPGA design would entail 
building the Coco 4 from discrete components. Again, I don't think anyone 
would seriously contemplate this, for a number of reasons including cost and 
limitations of what could be achieved.

Given the above, I would propose that any coordinated "Coco 4" project would 
entail the following:

(1) Specify a hardware design that is feasible to implement in an FPGA but 
also meet the requirements of Steve's vision. The FPGA design would not have 
to be done in the immediate future, but rather 'restrained' so that it could 
be done down-the-track keeping in mind the limitations of the hardware 
attached to it. I don't think this would be *too* difficult to achieve since 
IIUC the Coco 4 wouldn't be too far removed from current Coco 3 abilities. 
Add more resolution, more colours, sprites, blitter... ???

(2) Specify a BASIC language and extensions that are feasible to implement 
on the chosen processor for the FPGA version of "Coco 4". I would imagine 
that may simply be a 50MHz 6309? Or not?

Once we can agree on a common specification, we can each go in the direction 
that serves our interest. Those interested in a software solution could 
choose, for example, to implement the "coco 4" natively on modern OS'es. 
Others may choose to emulate the proposed "Coco 4" hardware and develop the 
language on top of that (which would certainly benefit the FPGA proponents 
and increase compatibility).

Those interested in a hardware solution could start on development down that 
path. Or wait until it is more feasible - cost and technology-wise - if that 
proves to be the case. Even a common FPGA design could have different 
form-factors and interface to different peripherals - legacy or modern. 
Depending on what people want to do.

With a common specification, it *may* be possible that software developed 
for the "Coco 4" is able to run on both? Or perhaps the software solution is 
a "superset" of the common specification, and some programs wouldn't run on 
the FPGA? A bit like Coco1/2 & 3 for example.

Of course we all know the jokes about design-by-committee. And of course 
this is not a short-term project by any means. I'm not sure it's even 
feasible. I'm just putting it out there.

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"



More information about the Coco mailing list