[Coco] A faster "Real" CoCo Re: General Memory Question about speed
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...
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
More information about the Coco