[Coco] CoCo 4 (or 5) perspectives: close hardware emulation?

[Fedor Steeman]

Hi guys and thanks for some great responses,

I think that before we decide on how is going to program what in what
language, we should make a more or less abstract model of the emulator
software. AFAIU, a piece of hardware can basically be regarded as a set of
components exchanging signals. In object-oriented software design, this can
be expressed as a set of object exchanging messages or events. There are
very useful diagramming methods like UML that very effectively can
illustrate such a software design, so that it is also understandable to
those not involved in programming.

I have attached a very simple and very rough beginnings of a design model
for a hardware emulator for a CoCo1/2. There is a lot missing, but the most
essential components (CPU, SAM, VDG, RAM,...) are there.

The great things about this approach are the following:
* We can discuss an abstract, but surveyable model of the hardware that
almost immediately can be implemented in any OO programming language, be it
Java, C++, or what have ya.
* Hardware experts that are not ardent programmers can evaluate the design
and point out hardware limitations.
* Division of labour: One or two persons (or more) can work on one component
while other persons (or teams) work on others, whenever they have time...

Also, a lot of components we might consider incorporating, have already been
emulated in one form or another, so we can save time by reusing these. A lot
is in C, so that is easy enough. If necessary, we can decompile any intel
assembly code using software like boomerang:
http://boomerang.sourceforge.net/

What do you guys think?

All the best,

Fedor

On 27/01/07, Joel Ewy < jcewy at swbell.net> wrote:

>

> farna at att.net wrote:

> > ...

> >

> > The only thing I would like to be out of the picture is Windows. I know

> most of us have a Windows machine, but it doesn't have to run Windows. I'd

> rather see the emulated CC5 run under Linux or a free version of DOS. That

> would give it a "background" OS to run the hardware wihtout bogging the

> virtual machine down with lots of unnecessary layers between the VM and

> background OS. Basically use one of the emulators that run under Linux now

> and strip the OS down to only what's needed, or use Jeff Vavasour's DOS CC3

> emulator as a start. DOS can also be stripped down a bit.

> >

> With Open Source, as with other areas of my life, I'm a strong adherent,

> but not a fundamentalist.  I can see considerable value in the idea of

> distributing a live, bootable medium (CD, Flash, whatever) that could be

> run on a PC without touching any existing OS, but which also has the

> option of being installed permanently.  This just can't be done with

> Windows, though it could coexist nicely with Windows.  I would prefer a

> totally Open Source emulator, but even if it is commercial, it could be

> distributed with an Open Source OS as long as it isn't compiled into it.

> > The good thing about starting with Jeff's emulator is that the source

> code is readily available and it's freeware. The bad thing is it's written

> in Intel 16 bit assembly. This as done to make it run fast, but running

> under Windows slows it considerably. I doubt many here could modify Intel

> assembly code.

> >

> > A better starting point would be David Keil's emulator (

> http://discover-net.net/~dmkeil/coco/coco3.htm<http://discover-net.net/%7Edmkeil/coco/coco3.htm>).

> It already has support for some added features. It would be much easier to

> build on his work, but it's written in 16 bit Intel code also.

> >

> > That would make MESS the logical choice (actually XMESS -- the Linux

> version of MESS). The only problem there is that it ould be best to trim the

> system down and make a full custom version, and that's prohibited by the

> legal statement that comes with XMESS. That might have to be tolerated -- at

> least it's in code that some of the people here can write in.

> >

> The problem with Linux is that it takes a little while to boot in a

> live-cd-type situation where it has to do a lot of hardware detection

> and autoconfiguring.  Not a long time, but it ain't nuthin' like

> powerin' on that CoCo, man.  But once it gets up and running it's hard

> to beat for stability, and it can be almost completely configured

> away.   FreeDOS would boot in seconds on a modern PC, but wouldn't have

> nearly the hardware support that a modern Linux kernel does.  No USB,

> poor networking.  DOS didn't compare well with the CoCo back in the day

> (at least in terms of price/performance), the only real benefit you'd

> get from it now is the ability to take advantage of the speed of the

> underlying hardware.  I guess it also would put up little resistance

> against an emulator program that wanted to directly manipulate the

> hardware, but why reinvent that particular wheel?

> > There is another option -- re-write Jeff's emulator in C++ and use it.

> That would be a big task in itself, unless there's some sort of code

> converter out there. Even then there would be a lot of de-bugging to do.

> >

> Yeah, this would take a lot of work.  But it sure would be the best

> long-term solution to CoCo emulation.  Here's another idea.  This one is

> admittedly pretty wild.  What about a CoCo emulator that runs natively

> on PC hardware without benefit(?) of any underlying OS?  Something that

> could be burned into a flash ROM in place of the BIOS, which would boot

> immediately, just like the CoCo.  There are already emulators written in

> x86 assembly.  Of course this would be completely infeasible because of

> all the hardware differences that the BIOS ROMs are there to abstract

> away, and the fact that even something as small as a CoCo emulator is

> still probably much too large to fit in a PC's flash ROM, and you'd

> still be faced with supporting all the good hardware that one would like

> to take advantage of (but at least you wouldn't have DOS and the

> interminable BIOS POST to get in your way).  Lots of other reasons it

> wouldn't work.  But wouldn't that rock?

> > I saved the best for last! Why not get the group here to definitize the

> requirements for a CoCo5, then approach David Keil about modifying his

> emulator to meet that definition? A group interested in purchasing the

> enhanced version for a reasonable price each (I would say $50 USD would be

> fair) would be an enticement. But there's no need to approach anyone until a

> consensus on what is needed/wanted is reached.

> I don't know about others, but I have a pretty low price threshold when

> it comes to software.  I'd buy an emulator for $20, maybe as much as

> $35-$40 if it was *really* cool.  But I can get a real, physical CoCo

> shipped to me from Cloud 9 for about $50.  If it was in the $5-$15 range

> I'd snap it up on a whim without thinking about it.  I might even buy an

> extra copy to give to somebody.  That's just my take on it.  I'm sure

> everybody's budget is different.  So many times I have seen a cool

> program or piece of hardware that I wanted, but just couldn't justify

> spending the money for.  Then later, when I'm in a position to buy, it's

> no longer available.  Maybe it would be worth seeing how may people

> would bite at what price points.  Somewhere in there is a sweet spot.

> Such information might be useful for other prospective CoCo programmers

> as well.

>

> I think you're quite right that hammering out a specification for

> desired features would be a necessary first step.  There seems to be

> considerable interest in FPGA-based "real" next-gen CoCo hardware (and

> in fact Mark McDougall is already working on it), and also a general

> consensus that enhanced emulation is a good complement to (and perhaps

> testbed and development environment for) any new dedicated CoCo

> hardware.  Sockmaster, I, and others have come up with a few ideas for

> some enhancements we'd like to see, that are logical extentions of the

> CoCo 3's existing capabilities.  Maybe I could summarize those ideas in

> a new thread where people could beat on them with blunt instruments.

>

> But I definitely think that the specifications should be shaped by what

> can be implemented in FPGAs by hobbyists.  The do-it-yourself, hobbyist

> culture is the CoCo way.  If it's specified for implementation in an HDL

> on real silicon, the emulation can come out first and provide a tool for

> developing the hardware version.  This will also ensure a bigger

> installed user base.

> > Legacy support is a must, but is there a need to support the

> Pseech/Sound pak AND the Orchestra 90? Which was most often used? I ouldn't

> worry about future support -- an enhanced sound capability could be an added

> feature of the "new" machine.

> > ...

> >

> Well, judging from the schematic, the Orch-90 hardware should be nearly

> trivial to implement, and at least some portions of it could be shared

> with that of the S/S Pak.  (Audio amp, address decode logic, ROM,

> probably even DACs.)  I think that the S/S Pak would be the more

> interesting capability to provide (interesting from the perspective of

> arcane and fascinating, but possibly also in terms of providing support

> for existing software), but since the Orch-90 hardware is so blitzin'

> simple, I don't think it would cost much to include it as well.  And

> arguably it is more useful in these days where sound on computers is

> mostly a matter of playing back digitized samples.  It might be a little

> bit of a challenge to integrate them seamlessly together in the way I

> have in mind.  I'm not sure.  If the S/S Pak is too difficult to

> emulate, then the Orch-90 by itself is the logical choice.  But if the

> S/S Pak can be done, why not throw the Orch-90 in as a bonus.  Assuming

> the 6-bit DAC is still in, such a CoCo would be able to support just

> about any existing CoCo program that can produce a sound.  And having

> good built-in sound hardware would surely be an enticement to future

> programmers.  One of the problems with the CoCo was always that all the

> good hardware was optional, and relatively few people bought it, so

> relatively few programs took advantage of it.

>

>

> JCE

>

>

> --

> Coco mailing list

> Coco at maltedmedia.com

> http://five.pairlist.net/mailman/listinfo/coco

>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Coco.gif
Type: image/gif
Size: 4347 bytes
Desc: not available
Url : <http://five.pairlist.net/pipermail/coco/attachments/20070127/02bec77d/attachment.gif>