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

[Joel Ewy]

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). 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