[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-0001.gif>