[Coco] CoCo 4/5 perspectives: close hardware emulation?
Joel Ewy
jcewy at swbell.net
Sat Jan 27 16:50:08 EST 2007
farna at att.net wrote:
> 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?
> ...
> 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... 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...
>
> 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.
>
>
Yeah. Damn Small Linux ( http://www.damnsmalllinux.org/ ) would be a
great starting point for this. The 'frugal' install option installs the
50M CD image to a small partition on the hard drive. To upgrade to the
latest version, you just boot with the latest live CD and do a new
frugal install, which just overwrites the old image.
Maybe you could package the distro with a number of pre-compiled kernels
that do less auto-configuring at boot time. How many differently
configured kernels could you put on a CD? Have the users pick the
kernel that best matches their hardware, and leave certain less-used
drivers as loadable modules. That might cut the boot time down a little.
> 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!!
I was really only about a quarter serious about that one. But see my
reply to Andrew Ayers about ROMOS. That would keep the BIOS in the
system, but boot FreeDOS from ROM. ( http://rayer.ic.cz/romos/romose.htm )
> 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).
>
The conventional wisdom is that it's infeasible for hobbyists to develop
their own PCI cards. But how difficult would it really be in comparison
to things we're already suggesting. I'm not suggesting hand-building
our own PC boards, but just designing the simplest possible PCI card
with nothing but the bus interface logic and a big flash ROM. The ISA
version of this would be easy enough that even I could do it (probably
even make my own PCB.) So if we're talking about an emulator running in
FreeDOS booting from ROM on an "older" system (one that still has at
least 1 ISA slot) it could be done quite easily. Switch on your PC, you
get a Power On Self-Test, and it loads up the CoCo emulator in an
instant. Put a Gig of CF on the IDE bus and you can do away with noisy
hard drives. Dig out an old packet driver for an ne2000 or 3Com
Etherlink or whatever, and add PC-LANMAN (or whatever) and you've got
some kind of rudimentary network support. So, if you don't have USB
support in DOS, you can share a USB drive over the network from another
PC. Not a half-bad way to use up that old P-III while you save for an
FPGA. :)
> 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...
>
> 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.
I've used Keil's emulator just a bit. It is pretty nice.
> 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.
But really that's just CoCo emulator + ADOS3, which is quite available
already. But I guess you're talking about a custom distribution that
would have all this stuff pre-packaged.
> 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.
>
>
The problem with using the parallel port in order to get away from
custom external hardware is that you often will still need to add
external hardware. For instance, if you wanted to be able to read a
CoCo game cart over the parallel port you would have to at least put
address latches on a board with an edge connector. You'd need to output
the 16-bit address in two separate bytes, assert a R/W signal, (and
probably also E clock?) and then latch the data byte, and finally read
it over the parallel port. By the time you've gone to all that effort,
you might as well just design a "geek port" as an ISA card.
OK. How about this? An FPGA CoCo would need an analog section at
least, probably on a separate board. Call it a CoCo personality
module. A PC-based emulator could benefit from an expansion card that
would add the ability to interface some real CoCo hardware, at least as
an add-on option. And one way to make a really slick, very fast-booting
dedicated CoCo emulator out of an old PC would be to boot a
FreeDOS-based emulator from ROM using something like ROMOS. I see synergy.
1. A completely software next gen CoCo emulator that runs in FreeDOS
and boots from floppy, USB, CD, or whatever.
2. A modular CoCo personality board as an ISA card with various
sections that can be populated for different configurations. It includes:
*1 A 40-pin header to plug in a CoCo cartridge on a short ribbon cable.
*2 ADC/DAC for joystick in / sound out. This includes stereo audio amp
which can be bypassed in PC config with a cable running to AUX input on
PC sound card.
*3 RS-232 level translators and serial connector(s)
*4 SPI connector for removable SD/MMC floppy surrogate
*5 PS/2 keyboard interface
*6 Flash ROM
*7 VGA driver / connector
For use in a PC, it would normally have *1, *2, *4, and *6 populated.
For use with FPGA boards, it would have everything populated. Maybe
some of this could be on an optional daughter board that plugs into
headers to make a sandwich.
3. An HDL implementation of the next gen CoCo for FPGA, which uses the
above personality module
4. An embedded PC emulator, which uses the above personality module
(partially populated)
This would provide lots of configuration options, but would eliminate
duplication of engineering effort, while maintaining compatibility.
> ...
>
> 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.
The FPGA guys make it sound like you can cram a whole bunch of CoCo into
modern FPGAs. And keeping the costs low is why I suggest a (possibly
dual-use PC/FPGA) CoCo personality board in conjunction with
off-the-shelf FPGA development/training boards instead of a completely
integrated solution.
> That would make a good
> kit machine -- boards with FPGA sockets with lands/traces for hand soldering
> discrete components and headers.
>
>
I think what I'm suggesting would be more kit-like and less
consumer-oriented. The no-hassle plug and play niche would be nicely
filled by the live CD emulator. The personality board is something that
could probably be designed and manufactured on a small scale. If at
least parts of it could be used in both FPGA and PC systems, it would
increase the potential market.
> 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.
>
>
CF does boot pretty fast, but it isn't as instantaneous as a directly
addressed flash ROM. I don't think CF cards support UDMA, for instance,
so the max transfer rate isn't as high as for hard drives. OTOH, there
are no physical heads to thrash around, so track-to-track seek times are
negligible. Most importantly in my mind, they're silent, tiny, have no
moving parts to wear out, and consume much less power than
electro-mechanical hard drives.
So booting from CF would be a nice, nearly embedded solution. But ROMOS
+ CF for mass storage would be about the best you could get on a modern PC.
> 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>
> ...
> 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) >
> ..
>
> The big problem is who would use such a machine? Would enough people want
> one to even be worth writing the software?
>
>
This whole endeavor is really based on hobbyists scratching their own
itches, and then collaborating with, sharing with, selling to other
itchy hobbyists. I wouldn't recommend anyone get into the business of
trying to sell software or hardware in the 2007 CoCo market unless you
really want to do it for its own sake. Maybe you can make some money as
a fringe benefit. Personally, I would be willing to pay at least
$40-$50 for the PC-configured CoCo personality card outlined above, if
that came with an enhanced ROM-based emulator. I'd probably pay $100
for the full FPGA configuration, plus another $1-200 for an FPGA
development board, assuming that the FPGA CoCo 'firmware' is Open
Source. I paid about $250 for a CoCo 3 in 1986. I don't think I could
pay more than $300 total for a next gen CoCo in FPGA. But if I could
start out by plugging a <= $100 CoCo personality card into one of the 17
PCs I recently pulled out of a dumpster (Pentium I - Celeron 900), and
then add the FPGA later, I would see that as a nice upgrade path.
> 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.
>
>
I run Vavasour's emulator on a P-133 laptop. Works pretty well.
> 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.
I know that (Nitr)OS-9 6809 works in Vavasour's emulator, and I believe
that 6309 works in MESS. (Maybe others too).
> 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.
There again you'd be porting assembly language code to a different CPU,
which would be quite hairy I think. You'd also need programmers who are
fluent in both. I think it would be much easier to alter the existing
drivers to support new hardware features.
> ...
>
> --
> Frank Swygert
> Publisher, "American Motors Cars"
> Magazine (AMC)
> For all AMC enthusiasts
> http://farna.home.att.net/AIM.html
> (free download available!)
>
JCE
More information about the Coco
mailing list