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

[Brian Blake]

My ONLY concerns with this list of features is the part Roger mentioned
about the s/w with their own disk access routines (i.e.: Gold Runner 2000,
etc...). They should not be left out.


Brian


On Fri, Nov 19, 2010 at 6:51 PM, Roger Merchberger
<zmerch-coco at 30below.com>wrote:

> 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
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>