[Coco] The Definitive Post on the CC-Five ;)

[farna at att.net]

I used Wordpad to edit my reply again........


Mark McDougall >
The only way I see is to realise the CC-Five as a specification.

However, I also believe that this specification *must* be written by a
person or persons who:
(a) have hardware experience, or better yet, FPGA experience
(b) understand the Coco, or more specifically the GIME.

Why? Anyone can "spec" a new computer. We all want enhanced graphics,
network capability, USB peripherals, mass storage and great sound. But we
also all want a new "Coco"; a backwards-compatible Coco, a platform able to
leverage off existing hardware and software (to some degree). It needs to
look like a Coco, feel like a Coco, and we need to be able to use it like a
Coco. Otherwise it's just not a Coco. And where's the point in that?

In order to achieve this, familiarity with hardware and the limitations of
the Coco/6809/GIME architecture is IMHO a must. James' comments in earlier
posts on enhancing GIME perfectly illustrate the approach that needs to be
taken - i.e. with consideration for what's there now.

Frank > 
I can agree in principle, but others shouldn't feel like they can't "sound off" with
their ideas. They just need to realize some of them aren't practical, even if
possible. We're definitely stuck with the GIME architecture if the desire is for
a CC3 compatible machine, and I think that's a must -- otherwise it's just
another computer. I think that CC1/2 compatibility can be considered secondary,
and really just "icing on the cake". If it takes more work, I'd say leave it out. For
the most part CC1/2 compatibility is assured because of the similarities with
the CC3, but there are a few things, like some obscure graphics modes that
were never used, that just don't need to be there. 

Mark McDougall >
I think at the heart of it, we're looking at a 6809/6309 running anywhere
between 0.89MHz and 3GHz. Do we play around with the instruction set? Do we
add an FPU? Maybe, but I don't think that's important at this point.

Frank > I wouldn't put a limit on clock speed at this point. It does need to
look and "feel" faster than a CC3, but that's about it. I'd definitely say it
needs to be 6809/6309 compatible. Adding to the instruction set may make 
it easier to use some of the added functions, or make it easier to program.
I'm sure there are things about the instruction set that some of the programmers
would love to see enhanced, but the key will be if it doing so will interfere with
backwards compatibility. If it won't, enhancements and/or new instructions
should be considered. 

Mark McDougall >
Fundamentally, there's no need to tie the CPU or any other clock to the
video. In fact, that's an annoying constraint. Designed properly, the CPU
can be clocked independently of the video and even the system bus.

Graphics. Yes, obviously we enhance the graphics. But we don't alter the
fundamental operation of the GIME. Or we design a new chip from scratch
which can look (to software) like a GIME. I don't know enough about the GIME
myself to comment further.

And don't forget, 32MB of 16.7 million colour display memory is pretty
useless when you're trying to shift data around with a 0.89MHz 6809 (to take
an extreme). We need to be realistic, and not try to design a 6809-powered PC.

Video output. VGA, again no-brainer. Easier than composite. PAL/NSTC, a
pain, but no major drama.  (moved from later in the original post)

Frank >
I agree! Any new machine MUST support existing video monitors, nothing special.
That's one good thing about using an existing platform. Emulation running on a
PC based platform can take advantage of standard hardware and the fact that
there is enough surplus CPU to prevent having to design new hardware. Using existing
standards drastically reduces development time and overall costs.


Mark McDougall >
Sound. I strongly believe Orch-90 and S/S Pak are a must. Regardless of the
fact that there's not much software around that uses it - it's what makes a
Coco a Coco! Again, I don't know much about them, but if the "stock" CC-Five
had these devices, is it enough to make new developers happy? I don't think
an SBLive64 is really appropriate for the CC-Five!

Frank >
I disagree with this. The only programs that support these two devices work great
(still with some sound, they aren't silent!) without them. Someone used to make
a music program... Lyra?... that could squeeze eight instruments out of a CC3
and Orch-90 pak. That's the only serious program that used it, but I doubt 
anyone is that interested in it any more. If it's possible to incorporate one or
both into the design without a lot of added overhead, it certainly won't hurt. 
But it's a "nice to have", not necessary, function. Flagging it as that now will
help later when/if decisions have to be made to trim things down. I do contend
that an easy to use/prgram sound function (prefereably stereo) is a necessity 
for any new machine. Why not SB64? It's the PC standard, which will make it
cheaper/easier to support. 

Mark McDougall >
Mass storage. A no-brainer. Everyone wants IDE/CF/SD/MMC. That means 40-pin
header and/or CF adapter and/or SPI. Been done a hundred times before.

Frank >
As you said, no-brainer! But how many IDE devices (not types) need to be supported? 
Two at a minimum, but with separate or the same controller? Is there any reason a HD 
and CF card reader can't be on the same IDE controller/cable?

What about a floppy drive? I don't think it's really needed except for transferring old
software. Most of that is available on CD and/or virtual floppies now though. So is
there a real need? With CF/SD/MMC cards I don't see why -- they can be used to 
transfer between machines, CC5 or any other modern machine. That would make 
transferring back to the CoCo harder, but then there's DriveWire and serial 
transfers...

Since I mentioned CD, the new machine should be capable of at least reading
a CD. It's not absolutely necessary -- transfer from CD to memory card using
a PC then to the CC5. 

Mark McDougall >
USB. A bone of contention with every "retro" project (not just the Coco).
IMHO, *great* to have, but demanding on the host CPU. Yes you can add a USB
micro to do most of the work, but then you need to define a proprietary
interface between it and the FPGA. Or it takes a lot of real-estate inside
an FPGA. Neither choice ideal. But it *would* be nice. I don't see this as
make-or-break - and can be left for later.

Frank > 
I'm not so sure about not make-or-break. I'd MUCH rather see this than the 
Orch-90 or S/S Pak if something had to go! The main reason is so many standard 
peripherals use USB now. USB thumb drives can be supported instead of a
memory card if something had to go. Heck, with USB support just get a 
USB memory card reader and plug in! With so many inexpensive USB devices
out there, I think it's a must in order to keep peripheral cost down. Communicating
between the main CPU core and a dedicated USB controller can be through 
something like an IDE interface. That would make memory devices easy, 
but wouldn't work well for a printer. Have you tried finding an inexpensive
printer with a parallel interface lately? They don't exist!!! USB to parallel 
cables are a bit pricey, and I doubt they will be around much longer. 

Mark McDougall >
Network. Again, nice to have, but together with protocol stacks, demanding
on the host. Yes it has been done on smaller micros, but IMHO they're little
more than technology demonstrations. But I feel the consensus is that
networking is a must.

Frank>
Is it? Networking just gives an easy way to transfer between machines. I
don't see a lot of networking going on with these new easy to program fun
machines. I see this as a nice to have as you do, and something that 
should be flagged as such. 

Mark McDougall >
Legacy interfaces. Cartridge port, joysticks, analogue ports, etc. I don't
think anyone would argue that they're a must as well. Throw in a few extras,
such as PS/2.

Frank>
The legacy interfaces simply aren't necessary. Joystick support that works and
looks like a Tandy stick is necessary (and a must for backwards compatibility),
but the actual ports aren't. Face it, all the legacy hardware is old and won't
last long if heavily used now. Who's going to manufacture replacements? 
Current hardware needs to be supported instead. 

The only thing I can see as having somewhat of a need for is the cartridge
port. The CoCo design has some drawbacks though -- to easy to blow the 
chip. Since parallel printers are hard to find now, but multi I/O chips still
support a parallel port, I again offer that as an interface with the outside 
world rather than a direct connection with the bus. Think of it as half of
what most people built to put in the bus anyway -- a PIA card with buffers. 
Maybe enhance BASIC to make it easier to program the I/O lines? The 
only problem with that is interfering with compatibility. Maybe we need a
compatible DECB and a DECB+. With all the enhancements, software written
on the new machine isn't likely to run on a CC3 anyway. It could be 
written to, but that's easy enough. 

Mark McDougall >
Of course, the whole point is to have collaboration by the coco community on
the design. Everyone gets to add their $0.02, but unless someone with the
experience I've outlined takes charge of the specification, IMHO it'll
remain unattainable and end up going nowhere.

So what can we do with a spec once it has been drafted (aside from endless,
circular arguing I mean)? Software emulation will no doubt be easiest, but
will facilitate CC-Five software development. FPGA implementation will come
next - most likely in the form of portable HDL and realised on a few dev
kits. Lastly, depending on the amount of interest and effort already gone
into it, hardware - whether they be "personality" boards for dev kits or
purpose-built PCBs for the CC-Five.

Frank > 
Definitly need to hear from the "old guard" and hard core CC users! They will
be the first ones wanting such a system. 

The good thing about "building" it under emulation first is that it can always be
translated to an FPGA. All the bugs and feature suite can be worked out first.

I think you meant "and" instead of "but" when talking about facilitating software
development... 



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