[Coco] What would a CoCo successor have to have as a minimum?
zmerch-coco at 30below.com
Fri Nov 19 18:51:12 EST 2010
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
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
> 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
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
Roger "Merch" Merchberger
More information about the Coco