[Coco] CC-Five (was Re: Pseudo CoCo4???) (LONG)
Mark McDougall
msmcdoug at iinet.net.au
Tue Jan 23 03:35:37 EST 2007
jdaggett at gate.net wrote:
> Which FPGA would be the best to implement a Coco 1 on?
Now you're getting all religious! :)
99.8% of my experience is Altera. I do own 1 Xilinx dev board that I'm yet
to play around with.
This is one reason why I think a 'spec' rather than a specific hardware
platform is the way forward. That way, the design can be kept nice and
generic, and people can choose dev boards and hence silicon vendor (or a
purpose-built board) as finances allow. Obviously some boards will
necessitate some features to be absent, depending on available peripherals.
For example, for my own work, I can target most of my projects to any of a
Nanoboard NB-1 with an EP1C12, a DE2 with EP2C35 & LCD controller, or my own
board with EP2C35 and VGA/composite output. Earlier incarnations could also
target Xilinx parts on the Nanoboard. My TRS-80 emulation emulates a floppy
drive via SPI flash on the NB-1, whilst on my board it will be via CF on a
FAT file system.
I also like the idea of a 'spec' enabling software emulation development to
afford availability to those for whom a dev board is out of the question,
and also aid in software development.
> This is mainly due to board construction. After about
> 400K gate densities, FPGAs are in BGA packages and that would require contract
> assembly houses to make the boards and upward to 6 layer boards for routing
> issues.
It's not really I/O we need - certainly available QFP packages afford enough
of that already. I think you'll find available QFP packages are already
several times larger than that required for a Coco implementation. We may
never need to go BGA until that's *all* you can buy. Sticking the FPGA on a
daughter-board like the Nanoboard also alleviates the problem somewhat.
> Taking John Kent's System09 as a start would be nice. While the SoC peripheral
> are mapped for Flex OS, I doubt that mapping them to the COCO I/O range is all
> that difficult.
I'm using John's CPU09 as a basis for my Coco 1, and have started on my own
implementation of the 6883 and 6847. There's also plenty of opencores stuff
for things like real UARTs, IDE controllers etc for enhanced capabilities.
I also think that maintaining 100% compatibility with the Coco would be nice
if at all possible - enhancements are then 'switched-in' as required.
Failing that, build options are the next preference.
Whilst my own Coco implementation is a fair way off yet, my intention is to
release it to the public domain when it's sufficiently complete. Of course,
there's the GIME to tackle next for a real work-horse, but it's a start at
least.
Regards,
--
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
More information about the Coco
mailing list