[Coco] A faster "Real" CoCo Re: General Memory Question about speed

Mark McDougall msmcdoug at iinet.net.au
Wed Jan 16 22:35:37 EST 2008


Dave R in Illinois wrote:

> After thinking about this last night, I think it would be best we lean
> "away" from the development boards, and perhaps scale it back some to lower
> parts total/cost. 

You'd be hard-pressed to do a small run of custom-PCBs and components for 
less than the price of some of the FPGA development boards out there!

> I guess the first thing to do would be to hammer out a list of goals here,
> then try to accomplish one by one. 

That's a big part of the problem - on this mailing list alone there are 
several "camps" with different goals and ideas about how best to achieve 
them. Aside from the technical considerations, cost and experience is also a 
factor in each decision.

> I was thinking perhaps a CoCo 2 /
> 3 hybrid. With both a dedicated VDG from the coco2 and the GIME from the
> Coco3, with a simple hw based switch. 

A case in point - would it be fair to say that your goal appears primarily 
to be a faster, backwards-compatible coco with a simple, relatively cheap, 
design leveraging off existing coco components?!?

I would venture to suggest that, although your goals share much in common 
with the others I have read about here, a lot of people are also interested 
in enhanced graphics, for example.

The main problem I see with your concept is that you need to make a lot of 
hard decisions up-front, and the functionality is more-or-less "set in 
stone" once you commit to a PCB.

Myself and others have suggested going down the FPGA path. Aside from 
suitable, cheap development kits readily available, it offers maximum 
flexibility and customisation options. It allows more and easier interfacing 
options with a wide range of modern peripherals that do not necessarily have 
to be designed-in from the start. It also allows an incremental development 
path, from basic coco 1 functionality through to full-blown coco3 and 
beyond. It's also much easier for a group to collaborate on the development.

The down-side to an FPGA solution of course if barrier to entry (experience 
wise) and the amount of work that is required to get to square 1. Having 
said that, Gary Becker's design might be a good start, although I haven't 
had much success porting it to another platform.

Just food for thought...

Regards,

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



More information about the Coco mailing list