[Coco] CC-Five (was Re: Pseudo CoCo4???) (LONG)

[Joel Ewy]

WARNING:  Extended musings about hypothetical enhanced CoCo compatible
follow.  This is not a short note.

I agree with Mark that any new hypothetical CoCo development would
probably more rightly be called a '5'.  I think that the MM/1, the
TC-9/TC-70, etc, were the fourth generation, regardless of what you
think of their success or failure as a successor to the CoCo.  They were
all more advanced over the CoCo 3 than the CoCo 2 was over the original
Color Computer.

It sounds like Frank is talking about something along the lines of  the
"Amiga Forever" CD, (which I have a copy of) which is considered to be
an officially licensed Amiga "computer".  I like emulators and I use
them some.  They do have a place in a world of cheap, ubiquitous,
powerful, commodity hardware.  I like the idea of a live CD distribution
that is customized and made as seamless as possible, in order to create
the illusion that the system you are using is running on bare metal.

But really, what are the things that keep us coming back to the CoCo
when we all have much more powerful computers?  Some of it may be pure
nostalgia.  For many of us the CoCo was our first computer, which
introduced us to whole new worlds of interesting people and ideas. 
Nothing wrong with nostalgia, but I think there's more to it than just
that.  If it was just nostalgia we'd be satisfied to plug it in every
now and again and play the old games and look at the old pictures and
see if the old tapes and disks still work.  But nostalgia alone can't
really account for HiColor displays, new arcade-style games, compact
flash interfaces, and superboards.

There's something qualitatively different about the CoCo experience that
the modern PC (Windows, Linux, or Mac) experience just can't replicate. 
For me there is considerable value in the relative simplicity and
immediacy of the hardware, and the system as a whole, including the
BASIC firmware and OS-9.  By 'immediacy' I mean both that the computer
is responsive and at my command within an instant of powering it on, and
that the details of the computer are hidden under far fewer layers of
abstraction, even under OS-9.  This is where emulators start to lose
me.  When I have to hit function keys and navigate menus to swap floppy
disk images, then use a separate utility to move data to real floppy
disks it makes the already tedious and error-prone technology of the
floppy disk just that much more annoying.  The upside is that you can
store a million floppy disk images on a modern hard drive, and you can
copy them and back them up with ease.  But the CoCo itself isn't
improved, just embedded within another, more complicated system.  And
you still don't have any intrinsically better way to remember what's on
all those floppy images.

I'm not trying to slam emulators, just spell out where they fail for
me.  If an improved CoCo were distributed as an emulator on a live CD, I
would want the live CD to be as stripped-down and dedicated to CoCo
support as possible.  I would want it to boot in a hurry and then get
out of the way, while still providing good support for the underlying
hardware in a way that could be accessible seamlessly from within the
emulated CoCo environment.  FreeDOS would boot very quickly on modern
PCs, but doesn't have support for USB, doesn't have very good network
support, et cetera.  DSL ( http://www.damnsmalllinux.org ) runs well on
older PC hardware, and is fantastic on fast machines.  It still takes a
while to boot (though less time than most), but it has good hardware
support, and can run entirely from RAM on machines with >= 128M RAM,
which is a very CoCo-like thing to do.  Memory is so cheap these days
that unless you are doing video editing or running software or operating
systems that are morbidly obese, virtual memory is just a performance
drag.  One more example of CoCo immediacy that we've lost.

What I would prefer to yet another emulator is a fifth-generation
CoCo-compatible implemented in FPGA(s).  This would have the benefit of
being upgradeable with newer generations of programmable logic devices,
but not dependent on any particular CPU (or FPGA) vendor who may decide
on a whim to quit developing or discontinue essential components.  But
it would also restore the immediacy that the CoCo has.  It would be a
'real' computer, but one that could change and grow.  It would be
eminently hackable, and would provide much the same potential to be a
vehicle for learning that the CoCo always has.  I attribute most of my
technical knowledge to the fact that when I got into computers with the
CoCo, you _had_ to learn something about the computer in order to get
anything out of it, because it wasn't all done for you already.  An FPGA
CC-Five would be the same way.

One of the cool things about modern FPGAs is that you can change the
logic function as fast as you can write to SRAM.  This means that you
can multi-task _hardware_.  Any well-designed FPGA CC-Five should have
at least one block of logic partitioned for hot-swappable virtual
hardware modules.  This dynamic reconfigurability means that old CoCo
functionality that might be considered obsolete need not immediately be
implemented in the base system.  Even modern PCs are still bound to some
degree by design decisions made with the first IBM PC.  Simplicity could
be gained by leaving out features that probably aren't going to be used
much any more, while designing sufficient modularity into the system
that they could be reimplemented and plugged in by those who value that
compatibility. 

There are many computationally intensive functions that could be
implemented more efficiently in random logic than in software running on
a general purpose CPU.  FPGAs are sometimes used in supercomputing
applications for this very reason.  So rather than writing CoCo software
to en/decode JPG files or .MP3s, things like that could be implemented
as a modular hardware-accelerated function.  There are already open
source cores on opencores.org to do a lot of this kind of stuff.

Another downside to emulators is that PC hardware is becoming
increasingly difficult to hack.  Back in the days of the ISA bus, mere
mortals could realistically build their own expansion cards to plug into
the PC.  If you can find a reasonably fast PC that still has a 16-bit
slot or two, you could conceivably hook up your own hardware to it,
whether it's CoCo hardware you want to interface with the emulator, or
just some gadget you'd like to control with CoCo software.  But I don't
think that any currently manufactured PCs still have ISA buses, and
there aren't inexpensive, hobbyist-oriented PCI project boards (that I'm
aware of).  That leaves serial ports and parallel printer ports, and
those are disappearing as well.  This is another example of immediacy,
accessibility, and simplicity that a real, hardware CoCo has, and
emulated CoCos, along with the PCs that host them, increasingly do not.

There are already FPGA 6809 computer implementations available under GPL
which could form the starting point for a CC-Five project.  The CoCo
user community has been touted so often as to make it a cliche.  But
it's true that users sharing technical information has been a hallmark
of the CoCo world.  Something like this could really be a community
collaboration.  And there's no reason it has to be either real hardware
or enhanced emulation.  The best of both worlds would be a single,
community-developed specification for a CC-Five that could be
implemented both in traditional emulation software running on PCs, and
in an HDL running on FPGAs.  This way programmers would have a single
platform to write to, and users would have an array of options for
embodying it in hardware.

I've got a basement full of PCs of all varieties, and an attic that is
filling up as well.  It would be great to have a better-integrated
emulator I could use to turn some of those machines into CC-Fives.  But
I'd really prefer to do it while saving up to buy a couple FPGA boards.

Since I've already rambled on for far too long, I might as well just add
a few ideas for what a CC-Five might look like, if I had my way:

Design principles:  simplicity, accessibility, modularity. 
Compatibility with older CoCo hardware is desirable, but can be
sacrificed where it adds undue complexity.  But careful planning could
mitigate against the effects of incompatibilities if older functionality
could be swapped in and out of the system in real-time in the place of
new systems that the old software doesn't use.  Avoid feeping
creaturism.  The aim is to produce a better Color Computer, not
something unrecognizable.  If the CoCo has a feature, it's OK to make it
better, but few wholly new features should be added to the base system
specification. 

Examples (and counterexamples):  The CoCo can produce sounds.  So better
built-in sound hardware would be a natural improvement.  The CoCo has a
video display.  More colors and higher resolution are good
enhancements.  The CoCo never had USB, and that probably shouldn't be
part of the base specification.  But the CoCo does have an expansion
bus, and perhaps it could be enhanced in some way that could maintain a
degree of compatibility (so we can plug in the old floppy disk
controller), and could also facilitate adding more modern hardware (like
USB and Ethernet).  The CoCo did have one built-in mass-storage
interface -- the cassette port.  This is for removable, non-volatile
storage, and it uses a connector that requires very few pins.  Perhaps
it could be replaced in the base design with an MMC interface, which has
some of the same qualities.  The interface is apparently fairly simple
as evidenced by:  http://uanr.com/sdfloppy/  The bit banger is lousy. 
Stick a UART in there.  It shouldn't be too hard to add logic that can
bypass the UART if necessary so that software that used the bit banger
could still work.  It probably wouldn't be too feeping to specify an
IDE/CF interface as part of the base system.  It wouldn't add much extra
hardware, but would give each system a lot more usability out of the box
than the CoCo ever had.  And add some MPI functionality to the bus.  And
that's it for new stuff.  Really :)

Specifics: 

CPU:  There is enough use of the 6309 in existing CoCo systems that it
would be nice to be able to specify this as the base CPU model for the
CC-Five.  As far as I know, all the existing FPGA designs are for the
6809, so there would be some room for improvement there.  But CC-Five,
development version 0.8 might just use an existing 6809 core.  If a
complete 6309 implementation is too difficult, maybe some select 6309
instructions and registers could be added along the way to full 6309
compatibility.  I think TFM is a must for a machine like this.  Perhaps
the next generation could even improve on the 6309.  Floating point
coprocessing can be implemented as a logic module, but probably
shouldn't be part of the base specification.

Video:  Even at much higher clock rates, the CPU in the CC-Five will be
modest by today's standards.  And simplicity and stepwise improvement
are important.  So the video display should be something that could be
used effectively, while being a significant improvement over CoCo 3
graphics modes.  Maybe something like 640x480 12-bpp.  That would come
in under .5M for a screen and give 4096 real colors.  I don't know. 
It's tempting to want to use an SVGA video card, but then you'd have to
add an ISA (or worse, a PCI) bus interface, and the things aren't at all
straightforward to program, and the complexity goes through the roof. 
Just a simple display like the CoCo 3 has is the way to go.

RAM:  The memory interface should be able to use some kind of reasonably
available PC memory module that provides at least 4M per stick. 
Probably, for something designed by hobbyists, 72-pin SIMMs would be the
easiest to work with.  They're still fairly available, though they may
be getting a little harder to find new, and they can be found with
4-128M per unit. 30-pin SIMMs would be easier to interface, but they're
even harder to find in 4M and above, and you'd have to use more of them,
which means more complicated physical hardware.  The more complexity we
can shove inside chips and prefabricated modules the better.  Memory is
one area where emulators have the advantage.  The MMU function will have
to be enhanced to address a larger memory space.  Paul Barton has worked
out the logic for that.  I would think that 64M would be quite a bit of
space for CoCo programs to play around in, even with a .5M video
display.  It's too late tonight for me to work out what that would do
the size and shape of the DAT, but that's easily computed.  Perhaps it
would be nice to add extra task registers to reduce multitasking
overhead in NitrOS-9.

Firmware:  Here I guess we would have to take a cue from the emulators
and insist that everybody supply their own ROM if you want to run
(D)ECB.  Of course the machine logic will probably have to live in
non-volatile memory, and there will probably have to be a separate
memory for program code.  Flash is undoubtedly the choice.  Perhaps the
firmware shipped on the system could be a glorified monitor of some sort
that could boot NitrOS-9 from CF/IDE.  Or better yet, just copy it
directly to RAM from flash ROM with a single TFM instruction.  If you
have a Microsoft BASIC ROM image, the firmware could also find that in
the root directory of the CF/IDE, or in a cartridge plugged into the
bus, and execute it on power up, perhaps dependent on a switch on the
case (turbo sw?), or a key held down at start time.  Maybe make the ROM
monitor program able to update the firmware flash ROM from CF/IDE, so
the hardware could be distributed with only the monitor, and customers
could their own ROM-based operating systems by simply copying them to CF
from a PC.  Maybe add an option to snarf them from a real CoCo 3 using a
serial cable.  Enhancements to BASIC could be done the way they always
have been, by adding code that patches the existing system.  NitrOS-9 of
course evolves more organically.  I have found a public domain tiny
BASIC for the 6809 that I plan to use in a Motorola 6809 Exorciser
board.  Perhaps something like that could serve as the seed for a
community-developed replacement for the MS BASIC.

Odds and ends:  I have an old CoCo 3 case left over from when I
repackaged one in a mini-tower.  At the time I did that it made a lot of
sense to enclose all the cables and power supplies in a single case. 
But what I lost was the self-contained compactness of the original CoCo
(which really had already disappeared the minute I started adding
hardware to it.)  But an FPGA CC-Five could conceivably fit inside the
CoCo case again, with much more functionality contained in a little
space.  It would be very cool if a new hardware CoCo compatible had the
option of living in a case (whether old or newly manufactured) roughly
the size and shape of the CoCo.  Any new design should have an AT/PS/2
keyboard interface, at least as a standard option.  But it would also be
nice if it could make use of the original CoCo keyboard.  But of course
all it would take is a different mounting bracket and it could be used
with a standard PC case.  One could probably stuff the workings of a
MicroATX or MiniITX power supply into a CoCo case if you take it out of
its housing and make some custom mounting hardware.  It would certainly
be nice if the whole thing ran cool enough to do without cooling fans. 
Just another thing the CoCo had going for it that modern PCs usually
don't is that it runs quiet.

I'd love to see people collaborate on something like this.  I think that
what I'm suggesting is sufficiently more powerful than existing CoCo
hardware to be worth pursuing, but not so outlandishly complicated as to
put it beyond the reach of what we CoCo hobbyists could accomplish.  I
think it would preserve much of what is great about the CoCo, while
addressing some of its real shortcomings.  It would not be a modern PC,
and it would not pretend to be.  But it would be a far more capable
platform, which would be liberated from the confines of specific
integrated circuit technologies.  It could become more powerful as
programmable logic technologies advance, and it could be adapted by its
users to meet their needs, not the needs of some corporate marketing
department, while preserving the CoCo heritage into the future.

I think that the specifications for the base system should be open and
shared, and should be possible to implement using FPGA project boards
that are available at relatively low cost, plus whatever additional
interface and glue hardware would be necessary to make a real computer. 
(That might be a commercial product right there -- a CoCo interface
board that plugs into something like one of the Burch Ed boards, and
adds a DRAM interface, some analog hardware, a CoCo bus interface, and
appropriate connectors.)  But specific implementations of the community
design (whether as a software emulator or realized in hardware) could be
proprietary and commercial.  And of course, there would be plenty of
opportunity for people to sell software, and hardware peripherals.

For what it's worth.

JCE

Mark Marlette wrote:
>
> I think we need to skip the CoCo4 and got right to a 5. ????
>
> Mark
>
>
> At 1/21/2007 12:22 PM, you wrote:
>
>> At 12:08 PM 1/21/2007, you wrote:
>> >--===============0322145043==
>> >
>> >Just a thought here... I haven't played with MESS yet, one of those
>> >"when I get some extra time" things. But as I recall it can work
>> >with added features such as hard drive support, and run in a full
>> >screen mode (sort of a "letterbox" mode)... What I'm thinking is why
>> not package a "live"
>> >CD with everything to run like a CoCo3 but make a few enhancements
>> >(like HD support, faster clock speed, access to some of the PC
>> >peripherals)? It's cheaper than doing it in hardware since there is
>> >so much cheap PC hardware out there now.
>> >
>> >--
>> >Frank Swygert
>> >Publisher, "American Motors Cars"
>> >Magazine (AMC)
>>