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

[Mark McDougall]

Frank wrote:

> Frank > I wouldn't put a limit on clock speed at this point. 

My (obviously not too clear) point was exactly that! I was trying to say
we need some sort of CPU that is at least instruction-set compatible
with the 6809...

> Mark McDougall >
> Sound. I strongly believe Orch-90 and S/S Pak are a must. 
> Frank >
> I disagree with this. 
	(snip)
> Why not SB64? It's the PC standard, which will make it
> cheaper/easier to support.

Not quite sure how supporting the SB64 will be "cheaper/easier". Both
the Orch90 and S/S Pak are already emulated in MESS. If it's hardware
you're talking about, then how so? Unless you intend putting a PCI
controller on the personality board.. ???

FWIW the AY-3-8910/13 in the S/S Pak is a common audio chip used in
countless video arcade games of the time. Granted, it's mono, but I'm
wondering if existing Coco software has realised its potential?

In any case, as long as legacy peripherals are supported, I'm not going
to discourage the *addition* of any features. If someone hooks up an
SB64 to the CC-Five, then great!

> 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?

CF cards must support "TrueIDE" mode by default. There are numerous CF
adapters that plug into a standard 40-pin IDE cable/header. ATA
standards support 2 IDE devices on the same controller. Adding a 2nd
controller is nothing but FPGA real-estate. The opencores IDE
controller, for example, takes 739 LEs on an EP2C35, or 2.2%.

> What about a floppy drive? 

I knew I'd forget something! Yes, IMHO a floppy drive is mandatory. Yes,
you can always transfer disk images via CF etc etc, and I'd imagine that
that is how most people will normally use it, but having the option to
connect a real Coco floppy drive (or even PC floppy) is ideal. Surely
you'd want the option of booting a real Coco floppy on your CC-Five? If
only at retro-meets if nowhere else? ;)

> 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.

Not high on my list of priorities, since a CF/SD is more than adequate
and much more convenient.

> Frank >
> 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.

Don't forget that for every USB device you're plugging in, you *also*
need a driver for it - either coded in 6809 assembler or emulated to
some degree on whatever USB micro you choose or - in some cases - a
combination of both. No such thing as a free lunch.

> Communicating
> between the main CPU core and a dedicated USB controller can be through
> something like an IDE interface. 

Not sure we're on the same page here. If you put a USB micro on an FPGA
board you'd simply wire it directly to the FPGA via whatever mechanism
the micro supported. For example, on the EZUSB you might use the GPIF
interface. Next choice is specifying the software interface between the
Coco and the USB micro. At one extreme you might have a packet-based
interface that requires a sort of "USB protocol stack" on the Coco where
the USB micro does little more than handle the physical and datalink
layers. At the other extreme you could handle different device types
within the USB micro and present each device as a legacy device to the
coco - drives look like coco drives, keyboards look like coco keyboard
maps, etc.

> 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.

You don't want browsing and email on your CC-Five??? :O

> 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.

I disagree. I want legacy ports on my CC-Five, so I can plug in a Tandy
joystick, a CocoMax? scanner, even a cassette recorder. Of course a PS/2
keyboard and X-arcade stick are just as crucial.

> 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. 

??? What's easy to blow up? We're talking new hardware here. Old design
problems need not be an issue...

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

Of course! I'm not advocating that I or anyone else hijack the project
and dictate what's in or out. My only stipulation is, as I outlined
earlier, people with real-world hardware experience and intimate
knowledge of the Coco need to be the ones who ultimately decide what is
and what isn't possible, within the spirit of the project.

It's going to be a non-trivial, iterative process.

> 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.

Unfortunately, software emulation doesn't really assist greatly in the
hardware implementation, given a suitably detailed specification.
Granted, software emulation *may* reveal short-comings or bad ideas in
the specification, but isn't much help at all when it comes to
developing hardware - *except* when it is used to run tests in parallel
with hardware under design.

For example, an FPGA implementation would be derived directly from the
specifications, rather than being "translated" from the software
emulation. Software emulation is a completely different paradigm -
different problems, different solutions.

Regards,
Mark