[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

>