[Coco] Any news on the so called CoCo4 or NextCoCo projectthatBjork was heading?
fwp at deepthought.com
Wed Nov 17 17:15:32 EST 2010
Is there a reason that the coco4 has to be the end of the line? Any problem with a
I've grown fond of using drivewire instead of an actual physical floppy on my coco3fpga.
The only way to beat it would be wireless. :-) The cartridge roms can be loaded into
flash and run from there. It wouldn't take much flash memory to hold a LOT of roms. It
also shouldn't be to hard to build a "joystick to usb" converter and connect them that
way. A usb adaptor of some sort may be the best way to add a cartridge port(s).
The other Frank
On Thu, Nov 18, 2010 at 07:52:56AM +1100, Mark McDougall wrote:
> On 18/11/2010 2:47 AM, jdaggett at gate.net wrote:
> >One suggestion that I would throw out that has already been suggested.
> >Instead of one board do all have several boards that plug into a main
> I'm going to have to disagree with this one. In fact, I would argue
> that it is *almost* a step backwards to the days of discrete chips.
> There are three problems I can see with this approach.
> 1. Connectivity. Any time you take signals off-chip you're
> constrained by the physical circuit and I/O count that have been
> designed into the system. You actually *lose* flexibility because
> you can't arbitrarily connect any two parts of the system.
> 2. Speed. Moving data on/off chip slows things down, not only in
> terms of raw clock rate, but also the fact that you need to shuffle
> data across in organised bus protocols. Even more-so when off-board
> connectors are involved.
> 3. Cost. Several boards with several FPGAs will always be more
> expensive than a single board with a single FPGA.
> I can see what you're trying to do - future-proof the design in
> terms of expandability. But that's very difficult to do - I'd even
> argue impossible - the way technology moves so quickly.
> It's more difficult than you would think to simply connect two
> (different) FPGAs together these days. With both core and I/O
> voltages changing and coming down all the time, it becomes a
> nightmare of multiple power rails and level translation. As well as
> the obvious cost implications, this also further reduces
> connectivity. Trust me, been there.
> I would argue that it's not difficult to predict the medium-term
> requirements of a Coco4 project. You can get FPGAs now large enough
> to run several complete Coco3FPGA instances at once in parallel.
> Once you've implemented the CPU, there really isn't much that
> consumes a lot of resources. Add the obvious I/O - VGA, PS/2, USB,
> SD/MMC, some sort of joystick interface, some sort of network,
> sound. Then add 1 or 2 expansion connectors for cartridge port
> (extremely expensive to add) and maybe legacy floppy (again,
> expensive to add for dubious gain).
> That'll do anyone for years to come. Beyond that, re-spin the board
> when the time comes. It's likely that technology has moved along far
> enough that it'll be cheaper than trying to expand the original
> design - smaller, faster FPGAs with different power requirements,
> new media/bus standards, new video standards, etc.
> And it's not as if the Coco4 project evolves particularly quickly! ;)
> Just my $0.02 worth...
> | Mark McDougall | "Electrical Engineers do it
> | <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
> Coco mailing list
> Coco at maltedmedia.com
More information about the Coco