[Coco] CoCo 4/5 perspectives: close hardware emulation?

[farna at att.net]

Date: Fri, 26 Jan 2007 22:31:05 -0600
From: Joel Ewy <jcewy at swbell.net>
Subject: Re: [Coco] CoCo 4 (or 5) perspectives: close hardware emulation?

WARNING - LONG!!: I loaded the reply in Wordpad and edited/added comments. Long, but a LOT
of ground covered/summarized here!! I made it easy to follow, anyway...

FRANK (original msg) >
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 without 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. 

JOEL >   
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.  <snip>

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?

FRANK (new comments) >
Once a live CD implementation was permanently installed, boot time would be 
considerably less than on the live CD. Instead of a live CD, the Linux portion could 
be a custom distribution specifically to run the emulator. If you do that it would
have to be installed, then install the emulator portion of the code. Both could,
however, be packaged to auto install seamlessly, as if one program. I was 
thinknig a live CD with an installation option would be the most flexible -- one
could try it without installing first, or just run from a live CD if only wanting to
use it occasionally. 

FRANK (original msg) >
 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. 

JOEL >
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?

FRANK (new comments) >
Ultimately that would be the best case scenario, but as you pointed out, would 
take the most work. That might make the platform hardware dependent also --
it would only work with a specific motherboard and components. That's a big
no-no!! Using DOS or Linux as an underlying layer will slow things down, but a 
Pentium 166 will be so much faster than a CoCo3 it would still need a "throttle" 
to control speed. That will be most necessary for legacy software, but a great 
feature even for new programs written for it (if any). 

FRANK (original msg) >
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. 

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

FRANK (new comments) >
Well, the whole idea is to give Mr. Keil an incentive to do the work. I 
haven't used a CoCo in years, or even set up an emulator (something
I'm planning on doing soon is set up Keil's emulator under DOS6 on a
P166 laptop I have). But I'd be willing to pony up $50 to see something
like this get moving. This wouldn't just be an emulator, it would be an
integrated software approach to a "CoCo 5" that would also have
enhanced features. I'd like to see features from Art Flexer's ADOS3 as 
well as BASIC support for larger amounts of memory, ala "512BASIC".
The CoCo was fun to program on in BASIC! It was easy to learn, and 
easy to write little cutsom programs for specific tasks. That's why I 
would also want access ot the outside world via a programmable 
parallel port. That just seems like the easiest way without custom 
hardware. A Centronics parallel port is programmable similar to a PIA,
so could be used for anything. There used to be some PC devices that
used it to trip relays and such. 

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

FRANK (new comments) >
That is a great synopsis of this discussion. Since you guys are some of the
real programmers on the CoCo List, and know the CoCo very well, who
better to start an enhancement list? 

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

FRANK (new comments) >
Agreed. But the emulator code can be modified later for FPGA implemenation. 
The only problem with that is you're again tied to specific hardware. You need 
a big order to get prices down to hobbyist levels. If it can be made to support
a generic PC type multi I/O chip it just may work. Or use 2-3 FPGAs and burn 
all the hardware in except for a few discrete pieces. That would make a good 
kit machine -- boards with FPGA sockets with lands/traces for hand soldering 
discrete components and headers. 

But I like your earlier idea of just "taking over" a standard PC board  better. 
What about having the system on a flash card and use an IDE to flash adapter
to boot from? Would be a little slower than the instant CoCo "boot", but much 
faster than a hard drive, I would think. 

FRANK (original msg) >
Legacy support is a must, but is there a need to support the Speech/Sound pak 
AND the Orchestra 90? Which was most often used? I wouldn't worry about future 
support -- an enhanced sound capability could be an added feature of the "new" 
machine. 

JOEL>   
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.  
<snip>
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.

FRANK (new comments) >
Ease of implementation really doesn't matter. The last sentence above says 
what I really meant -- if no or little software supports either the Orch 90 or S/S
Pak, why bother with either? I think there are some music programs that use
one or the other -- that's the only thing I'd say to implement. Built-in sound can 
be an enhancement that anyone can use for new software. 

The big problem is who would use such a machine? Would enough people want
one to even be worth writing the software? 

What you'd have with an emulator as envisioned in this message is a PC looking 
machine that behaves like an enhanced CoCo. A $200 Pentium 4 slim machine
with another sticker on it (something like the Compaq EVO now at several 
remarketing places off-lease -- even at Tiger Direct -- 
http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=2659050&Sku=J156-4160; 
or something like this: http://www.surpluscomputers.com/store/main.aspx?p=ItemDetail&item=COM10623).
P2 and P3 machines are cheap enough now that either could be the "lowest"
supported machine, though I'd suggest a P2/266 be the target. Plenty of 
inexpensive laptops in that range. It wouldn't have to run significantly faster 
than a CoCo3 on the lowest recommended hardware, just run AT A MINIMUM
as fast as a CoCo3 in double speed mode. 

NitrOS-9 support would be an entirely different matter. If the legacy emulation is
good enough it should run. Then drivers can be added and/or the OS tweaked
to take advantage of the new hardware. Personally, I think it would be better 
to port NitrOS-9 over to a PC environment rather than add it on top of an
emulator and a basic OS sub layer. I'm not sure if porting would be as hard
as modifying drivers and such or not. If the emulation is successful, and the 
FPGA implementation starts after, the NitrOS-9 can be ported/modified
for the hardware implementation. Hmm... if it will run on the emulator, it
would run on the hardware though, wouldn't it? 

LOTS TO THINK ABOUT!! 

--
Frank Swygert
Publisher, "American Motors Cars" 
Magazine (AMC)
For all AMC enthusiasts
http://farna.home.att.net/AIM.html
(free download available!)