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

[Bob Devries]

Whew!!!
and
HEAR, HEAR!

This sounds like the future of the Coco, and would certainly ensure that the 
old girl will out-last most of us.

Good writing, Joel.

From: "Joel Ewy" <jcewy at swbell.net>


> 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)
>>>
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco