[Coco] Color computer these days...

[Joel Ewy]

Michael Robinson wrote:
> I checked out Ebay for the heck of it to see if I could find a 
> Coco 3 for sale.  Well, I found a coco3 with multi pak 
> interface WAY over priced.  Worse, I searched for 360k disk drives 
> and couldn't find any.  I have two 360k disk drives that are shot.  
>   
Probably somebody on this list could set you up with a 360K drive.  I
might be one of them, but ask Willard Goosey how quick I am at getting
around to sending people things I've promised.  Granted, no money has
changed hands, just a promise to send him an NE1000.  But I did locate
it and put it in a box.  And two years after promising him I would, I
did scan and PDF  the documentation for a Motorola 6809 CPU board.  So I
do eventually get around to it...  :)
> I can't get Gauntlet II to work over drivewire where I could
> theoretically pick up some disks and write the images to them
> if I had working disk drives.  Can I cheat somehow and get away 
> with using a modern 1.44 meg floppy drive as a substitute?  What 
> if I can find a 720k disk drive, will that work?  
I've used 1.44M drives as 720K drives on the CoCo for years.  I use them
with actual 720K media and don't attempt to trick them into thinking
that high density disks are actually low density.  This does simplify
floppy data transfers from modern PCs.  If you can find a 720K drive,
that will work as well.  The 720K disks may be the trickiest thing to
find.  Disk BASIC can be patched to use the second side so you have
drives 0,2 and 1,3 with two physical 3.5" drives, and (Nitr)OS-9 will
use all 720K with appropriate device descriptors.
> My disk 
> controller says hard drive specialists on it, but it doesn't 
> control a hard drive.
>
>   
Yup.  I've got one of those too.  Hard Drive Specialists was just a
company that made hard drive systems and floppy controllers as well.
> Anyways, what ever became of the MM/1 and the Tomcat?  I couldn't
> find any on Ebay.  
>
>   
I've got an MM/1 and a TC-9.  The MM/1 still works just fine,  (it
really is a fun little computer) but the TC-9 is (and always was) kind
of flaky.  Neither of those systems sold in anything like the quantity
of the CoCo, so I wouldn't expect to see many for sale on eBay or
anywhere else.  I know that Bob Devries has an MM/1 as well.  I also
have parts and bare boards to build memory and I/O boards for the MM/1,
for what it's worth.
> My nephew has a coco 2 and wants a coco 3 because he is aware 
> of the differences in capability.  I have a 512k coco 3 thanks 
> to cloud 9, but no 512k software for it.  At $50 for a coco 3
> from cloud 9 it may be worth it to order one through them.
>
>   
That's where I would go if I needed another CoCo 3.
> There is talk of coconet and projects that favor the rare 
> coco 1,2, and 3, what about dreams of a coco 4?  Could a 
> coco 4 be done?  What would it look like?  Would it have a 
> modern AT keyboard, a gig of ram, the original instruction 
> set of the coco3, plus say 100 or more new clock speeds?  
>   
I'm saving my pennies (yes, for me this will take a long time) to buy an
FPGA development board so I can play with Gary Becker's FPGA CoCo 3.  An
FPGA is a programmable logic device that can have whatever logic
functions you care to supply it with.  Gary Becker has added CoCo 3
compatible logic to an existing 6809 core to produce a CoCo 3 SOC
(System On a Chip) that can go into an FPGA development board.  The
board he is using is a Digilent Spartan 3, which is about $150 with the
bigger FPGA.  For that you get a 1M CoCo 3 that can drive a modern SVGA
monitor, and uses a PS/2 keyboard.  It has several configurable clock
rates from 1.78MHz up to an effective speed of about 21MHz which, for a
CoCo is pretty fast.  You can undoubtedly get higher effective clock
speeds with an emulator on a fast PC, but this is real hardware, and you
don't have to wait for a bloated modern OS to load up before you get
your CoCo on.

At this point this is no plug and play CoCo replacement.  To get the
full range of colors you need to modify the development board (though it
doesn't look like a difficult modification -- solder on a few
resistors).  To hook up joysticks and get sound out you would need to
build an analog board.  To even get the CoCo functionality into the FPGA
you need to install the 'firmware' from a PC, at least initially.  It's
definitely a do-it-yourself project, but the framework is there.

Is this a CoCo 4?  I don't think it quite is yet.  But it has great
potential.  First off, IMHO the moniker "CoCo 4" belongs to that earlier
generation of CoCo successors, such as the Tomcat and the MM/1.  I grant
you that in many ways they failed to live up to their promise, but I do
think they deserve a place in CoCo history.  I would tend to want to
refer to a modern CoCo successor as a "CC-Five" or maybe "NextGen
CoCo".  But whatever.

What Gary Becker has done is to duplicate the essential functionality of
the CoCo 3 in an Open Source Hardware Description Language.  Aside from
clock speed and a few modern niceties his system isn't much improved
from the CoCo 3.  However, Gary has made the Verilog source code
available, so what he has done can easily become the starting point for
new development by the CoCo community, improving on the functionality of
the original design.  Better graphics, better sound, even built-in
co-processors are possible.  It would be possible to integrate the
emulated GIME's MMU with the emulated 6809, and add bigger address
registers that know how to stuff the MMU registers so you can access the
memory address space linearly.  (Though doing something like this would
be complicated in this instance since the 6809 is implemented in VHDL
and the rest of the CoCo hardware is in Verilog...)

In addition, there are free/Open Source cores for all kinds of
functionality that could be implemented alongside the CoCo functions if
there are enough spare gates in the FPGA.  Things like hardware .MP3 or
JPEG decoders for instance.  So even if the CoCo's CPU remains limited
to a relatively modest clock rate in the 10s of MHz, it would be
possible to build special functions into the hardware that do in
dedicated logic things that would ordinarily take a much faster CPU to
do in software.

Even a few modest improvements would give us a lot to play with.  We've
all seen the high color displays on the CoCo 3 that switch between
multiple screens and/or re-stuff the palette registers during horizontal
retrace or vertical refresh.  Sockmaster's Hi-Color viewer is amazing. 
It would run much faster at 21MHz.  But what if the computer could have
3 or 4 sets of palette registers that it could switch automatically
without software intervention?  What if it could flip between graphics
screens in the same way?  With something like this, the high color
graphics modes could be used for games and other programs rather than
just for still (if flickery) images.  The logic to do this shouldn't be
that obtuse, and it wouldn't alter the fundamental structure of the
system. 
> How could a 64 bit coco compatible computer be designed?  
> These days there are pic micro controllers that could 
> probably emulate the 6809BE no problem.  I think the biggest
> compatability hurdle would be the Microware/Microsoft rom
> code.
>
>   
I'm not sure a PIC could emulate the 6809 in real time, but the CPUs in
desktop systems certainly can.  D.M. Keil's emulator actually does
already implement extra graphics modes, including a 256 color mode, if
I'm not mistaken, though I'm not aware of any software that actually
uses it.  I also know that Steve Bjork and others have been discussing a
software-based Next Gen CoCo platform.  The fact that nobody has
apparently taken advantage of the extra features of Keil's emulator
highlights the reality that the CoCo world is far too small to afford
further fragmentation.

There has been a lot of discussion on this list in the past about
whether future CoCoid development should focus on software-based
emulators or HDL-based hardware (like the FPGA CoCo 3).  One advantage
of the software approach is that everybody has a modern computer that is
probably plenty fast to emulate a CoCo (though not all at the same
speeds...)  One advantage of the hardware approach is that it can stand
alone, and it retains some of the good qualities of the CoCo that we've
lost over the years, such as instant power-on and power-off, with
practically zero boot time.  I use emulators as well as real CoCos, but
I don't find emulators to fulfill all my CoCo needs, so I really want to
try the FPGA CoCo as well. 

I believe that the CoCo community needs both emulated and hardware-based
Next Generation CoCo systems to fill different roles and needs.  What
the CoCo community most emphatically does not need is 3 or 4 completely
different, incompatible systems.  Nobody will write new software
supporting new features if the already small CoCo world fragments itself
into even smaller factions.  This is one area where cooperation, not
competition, is called for.  Compatible software emulators and FPGA CoCo
systems would strengthen each other, providing a single platform for
potential programmers.  Incompatible systems would be a disaster.  In
fact, this is a lesson we should have learned from the first crop of
would-be CoCo successors.

I would plead for those developing new feature-added CoCo emulators to
resist the temptation to go wild with outlandish features.  Sure, a
program running on a modern PC can do basically anything a modern PC can
do.  But if that program is meant to be in some way a "CoCo" it must
bear some resemblance to the CoCo we know, otherwise why constrain
yourself to CoCo compatibility at all?  The whole point is to leverage
existing CoCo experience and expertise, to integrate existing software
with new programs that weren't possible on previous CoCo generations,
and maybe to engage in a game of "what if" -- to see what things could
have been like if Motorola had taken the 6809 one step further, and
Tandy invested in another custom chip design...  Add features.  Make it
better.  But keep it recognizable as a descendant of the CoCo, and maybe
even take into consideration whether the enhancements could easily be
implemented in an FPGA CoCo.  Doing so would add more potential breadth
and depth to any design you finally create.
> Color computers seem to be getting rare, especially Coco 
> 3's.  The Tomcat and the MM/1 seem to be gone.  I guess 
> the 68000 took over, but even that is gone now.
>
>   
There are Commodore Amiga implementations in FPGA.  It wouldn't be
outside the realm of possibility to think that a future FPGA design
could execute both 6809 and 68000 code and could run software written
for the CoCo and the MM/1 and TC-70.  Possibly even CD-i.  Maybe that's
getting a little fanciful, but I think such a thing could be done.

JCE
> The following is the only coco 3 for sale at a reasonable price 
> that I have been able to find on E-Bay.  I'm tempted to bid on
> it, but how do I know that it works?
>
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MEWAX:IT&item=260328354693
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>