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

Mark McDougall msmcdoug at iinet.net.au
Sun Jan 28 01:13:05 EST 2007


"I speak of none other than the Coco that is to come after me, a computer
whose operational parameters even I am not worthy to compute..."

Since I've been chiming in randomly I thought I'd gather my opinions into a
single, incoherent rambling...

But before I start - to the detractors who dismiss our discussions as "pie
in the sky" stuff that's been doing the rounds for years - I say "so what"?
If we're having fun just talking about it, then where's the harm!?! Feel
free to dutifully ignore our postings. ;)

As can be expected from any group larger than 1, people's wants and
expectations are going to differ. In the case of the CC-Five, those wants
range from software emulation on windows/linux, to turn-key, instant-on
emulation on a suitable PC-based platform, to stand-alone FPGA
implementations that can be retro-fitted into a Coco 3. Not to mention every
conceivable combination of the above. And that's fair enough.

So, how do we achieve this?

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.

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.

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.

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!

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.

Video output. VGA, again no-brainer. Easier than composite. PAL/NSTC, a
pain, but no major drama.

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.

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.

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.

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.

I'd also like to think that emulation authors like David Keil would get on
board, but sadly I doubt it - and this is in no way a reflection on them. I
just don't think it's something that would interest them - but that's just
my opinion and I could be totally wrong. I think it's up to us in the
current coco community to move forward with this.

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.

I've no doubt this group has the knowledge and enthusiasm to realise a
CC-Five in some form or another. It'd be great to see a CC-Five kit
available some day, complete with Nitros-9 support, bundled with a
256-colour version of "Glove" with Orch-90 sound and S/S Pak speech.

"Yellow wizard is it!"

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"



More information about the Coco mailing list