[Coco] COCO4 Emulator

[Mark McDougall]

RJRTTY at aol.com wrote:

> My point is  we
> could decide on a hardware configuration then write the code to emulate
> it  THEN build it.   The emulator is simply a means to an end and not
> the ultimate goal of the project.

Hey, if that's your intention then it's not a bad idea. It's just that the 
OP didn't mention anything about it.

IMHO though, if hardware were the ultimate goal, I'd approach it 
differently. I'd start work with an FPGA implementation rather than a 
software-based emulator.

Why? Because it's difficult to emulate hardware in software without having 
software to verify your emulation. Conversely, it's difficult to write a 
driver if you don't have reference hardware to talk to.

Using an FPGA, for example, you could interface your chosen ethernet 
card/chipset to the 6809 and write and test the NitrOS9 driver for it on 
that. That allows you to get to the stage of having a fully operational 
driver without having to verify your ethernet card software emulation.

Of course, there's no reason you couldn't develop both in parallel, as no 
doubt it's often easier and quicker to develop on a PC-based emulator than 
worry about transferring WIP NitrOS9 drivers to your FPGA. Maybe write the 
low-level ethernet drivers on the FPGA platform, then implement the 
ethercard in software on the PC (or even hook into the OS stack), which 
would allow you to develop the upper layers of the NitrOS9 network stack on 
the emulator.

FWIW I do speak from some amount of experience. My job sometimes involves 
designing hardware and then writing software to either run on it, or 
interface to it on a variety of platforms. I'm usually loathe to write a 
single line of code before the hardware is available and verified, but of 
course the realities of schedules etc mean I don't always have that luxury. 
We generally need to look at ways of paralleling the hardware & software 
development as much as possible, usually through a combination of 
simulation/emulation, ports of IP cores to similar evaluation platforms, and 
various evolutions of software which maximises re-use from production test 
to final driver. The idea is to minimise the amount of 'throw away' effort.

If people are serious about this project, then maybe someone needs to start 
documenting the requirements? Or at least decide on the ultimate goal first. 
Design by committee eh - that should be interesting! ;)

Regards,

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