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

[Joel Ewy]

Mark McDougall wrote:
> Frank wrote:
>
>   
>> Frank > ... 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? ;)
>
>   
I agree that a hardware CC-Five needs the capability of accessing
floppies.  At what level should the support be implemented?  On one
hand, I think it would make sense to leave any actual floppy support
out.  Provide the CoCo expansion port and one could just plug in a
legacy floppy controller.  Personally I see floppy disks as a necessary
evil.  They're so unreliable they drive me nuts.  So it would be nice to
see something like SD/MMC become the new direction for removable
storage.  And if you could implement a controller for it that is
register-compatible with the WD FDC, then you could fool BASIC into
thinking it was talking to a floppy controller, as has been discussed
previously.  If that could be switched out using internal MPI logic,
then a real floppy controller could be plugged into the bus when it is
needed.
>> 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.
>
>   
I agree that CDs aren't all that necessary, though if you have an IDE
interface, it's just a matter of software.  But I think Frank was
thinking about the emulator.
>> 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.
>
>   
If you have network support, IDE/CF support, and SPI/SC/MMC, you can
probably almost do without USB.
> ...
>> 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
>
>   
While browsing and email on a CC-Five would be righteous cool, I'd be
happy just to be able to mount file systems shared on a PC, say, a USB
memory stick.  Or be able to print on a shared USB printer.  Then you
don't need USB in the CoCo at all.  How much of this needs to be built
in to the FPGA though?  Maybe Cloud 9 could spin off the ethernet
adapter from the SuperBoard into an external network card that could
plug into a CoCo bus.  I don't know.  Just thinking about duplication of
effort.
>> 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.
>
>   
I second.
> ...
>> 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.
>   
My humble suggestion for the specification process would be that we
collect *specific*, *detailed* ideas from whomever can spit them out,
then run them by a small panel of highly experienced persons (I nominate
you (Mark McDougall), James Daggett, Mark Marlette, Boisy Pitre, and
John Kowalski :)) to weed out the ludicrous and terminally infeasible,
and we have a specification.  Or something like that.  No reason the
spec can't change when it turns out to be impossible.  I have been
gleaning some of the more specific ideas in a text file, and it sounds
as if Frank Swygert may be doing the same.

JCE