[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