[Coco] What would a CoCo successor have to have as a minimum?

[Roger Merchberger]

On 11/19/2010 05:54 PM, Frank Swygert wrote:
> Assume we are talking about advance hardware features and advance ROM.
> I'm not asking for everything you'd like to see, but what would be the
> minimum requirements -- the least common denominator/best compromise.
>
> 1. CoCo3 compatibility. Drop CoCo 1/2 semi graphics and artifacting
> modes. The main purpose is to provide advanced but easy to program
> features while maintaining a decent software base, not run everything
> ever made for the CoCo line.

Right - I'd even "somewhat agree" with dropping CoCo1/2 compatibility 
and saying the CoCo3 was the new "base machine" for compatibility issues.

> 2. An easy to program I/O port of some kind. Doesn't have to be
> cartridge port compatible, just needs to be easy to program. I recommend
> the Centronics parallel port (LPT) which is still on most motherboards
> as it reduces hardware needs, but a USB satellite connector would be
> acceptable.

If it were USB, it would have to have a nice abstraction layer, as USB 
is a right pain to program for, if memory serves...

> 3. Some way to access a physical floppy drive for those rare occasions
> reading or writing a physical disk is necessary. This could be via
> something like CoNect or DriveWire built in or run as a utility
> connected to another PC, but the ability to connect a physical drive
> would be preferred.

Personally, I don't see this as a necessity - once all the old floppies 
are in a digital format (.DSK or what have you) why need the floppy 
drive at all? As long as there are working floppy drives on PCs with 
emulators, the data would be available to the unit.

Personally, I'd standardize on SD cards - they're cheap, they're 
everywhere, they're easy to interface to (there's already interfaces for 
the CoCo and Model 100/102/200 among others) and some even have USB 
interfaces built-in so you don't even need a reader on the PC.

What I would see as a necessity would be a (at least nearly) flawless 
floppy emulation layer, so programs that have their own disk access 
routines would still work well on the hardware.

> 4. Switch the primary storage system to either HDSD cards (HD readers
> are backwards compatible to standard SD, but standard SD won't read an
> HD -- I've seen mostly HD cards in retail stores) or USB drives. No need
> for a floppy all the time any more, but there is a need to transfer
> and/or store data physically.

I are stewpit. I should have kept reading.. but I stand by what I say 
about not including any form of hardware floppy interface.

> 5. Higher res graphics that are easy to program. Something standard --
> maybe just 640x480 VGA.

I agree, but why not aim for (at least) 800x600? That's been a standard 
for almost 1.5 decades now, and every monitor I've ever seen (including 
my Sony Wega tube TV) supports it.

> 7. Easy access to 512K to 1MB of memory for programs. Something like the
> old "512KBASIC".

Personally, you're thinking too small -- I'd say at least 4 or 8 Meg, 
maybe with the possibility of multiple banks automatically backed up to 
Flash, rather what Steve Adolph designed into ReMem for the Tandy 
100/102/200 laptops.

> 8. Ochestra 90 pack built in, and also improved. I guess I really mean
> an improved version that's also backwards compatible. Or how important
> is compatibility? Only a few things used it...

I would say "stuff the compatibility" at least hardware wise, but if 
there were a software compatibility layer, I'd say "Bonus!"

> Okay, what am I missing??

I've been reading (OK, a few I've been skimming) these responses, and 
it's kinda reminded me of the Amiga Vs. Atari ST advocacy wars of the 
90's, but with more intelligent discourse and more civility... ;-)

Maybe I'm full of condensed milk, but in the hardware versus software 
debate, why not have *both*?

Let the hardware geeks plan out what is possible in the hardware (even 
if it isn't done yet) and create the specification. Then the software 
geeks write a custom emulator to emulate what's possible in the hardware 
that you can run on your PC. Personally, I'd say "Opensource the whole 
shebang" & run with it, but if at least the software emulator was open 
source, then there'd be a better chance that the software would run on 
whatever platform you wanted, be it Linux, MSDOS, Winders, MacOSX, etc. 
DOS & Linux would be great for the "Boot straight into the emulator" 
crowd as it's easier to pare those OSs down to bare minimums, OSX and 
Winders versions would be better for the "I wanna check my email & get 
my identity stolen on Facebook while I tinker with the emulator" crowd.

[[ Yes, I'm kidding (mostly) on the last one... ;-) ]]

If the hardware gurus say 640x480 is the best to hope for out of the 
hardware, then so be it, but if it doesn't take much more logic blocks 
for an 800x600 or 1024x768 VGA core, then aim for that first & then code 
the emulator to match. Likewise, don't code the emulator for a 4Meg 
memory map if the hardware geeks say 8Meg is nearly as easy and takes 
few resources...

Yes, the PC emulator could go much faster than the hardware, but as long 
as code created in the emulator ran in on the "upgraded" FPGA hardware 
that would be awesome.

Again, I'm obviously the idiot here because I'm not smart enough to 
contribute to either camp, but to me that just seems like the best 
"all-around" compromise... but maybe I just haven't had enough beer 
yet??? ;-)

Laterz!
Roger "Merch" Merchberger