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

[Frank Swygert]

Since I'm trying to establish a baseline, I'm going to answer everyone in turn. I'm not going to worry about who said what, just mix the comments and answers under the appropriate point.

The main goal is to define something that would be suitable for software AND hardware so they would be compatible. Not much point in thinning the already thin "herd" of potential users by having two incompatible systems.

> >  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.
COMMENTS:

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

I agree that there should be 100% Coco 3 compatibility plus adding extra
features that people want in the Coco4.  Not every good program ever written
for the Color Computer was written for the Coco3.  Some will not run on the
Coco3.  Many run using artifacting, and a few run on semi-graphics modes.
Why make a conscious effort to exclude these?  If there is space, why not
have full Coco1 and Coco2 compatibility modes in addition to the Coco3?
Just curious about your reasoning.

Must be compatible with everything, there is no real limitation, which
hinders most emulators is the environment where they are not emulating.


REPLY:

The main issue is ROM and FPGA space. The CC3 can only access so much ROM, and to make it compatible you have to have some of the old ROM code. I'd rather see the code re-written than patched in like the CC3 does, but that might be unavoidable.

Every time a computer is truly upgraded there is always some compatibility loss in order to make room for new features. That's what we're facing here. On the emulation side it's not as big an issue, but on the FPGA side the bigger the FPGA has to be (and higher cost) to have all the extras in it. This is something the two systems could diverge in though -- CoCo 1/2 compatibility in emulation, not in FPGA.

My main view is that the upgraded computer is mainly being designed so that the system can be expanded and new programs written, not as much for nostalgia. Keeping CoCo3 compatibility as a least common denominator still gives a wide software/user base to work from and keeps the "look and feel" of the CoCo going. The emulation method could just have a menu option to switch to CC1/2 mode, but that might require a re-boot. The main objective for the emulation is NOT to run under an OS like current emulators, but to make the underlying OS as transparent as possible and have it boot up similar to a CoCo. Ideally a casual observer would never know the underlying OS even existed, though I think there should be a utility menu that bypasses the emulation and goes directly to the OS for general maintenance purposes. That may not be necessary though.



> >  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.
COMMENTS:

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...

REPLY:

None really -- point taken! The main problem here is that the connector should be compatible with the FPGA system. This depends partially on the capabilities of the DE-1 board (for now). The emulation could use a USB connected satellite board emulating one of the DE-1 expansion ports. If the ports are somewhat configurable maybe one could be programmed similar to an LPT port. Those development boards usually don't have LPT ports, but that's still a good port to consider. It's really just an 8 bit  bidirectional I/O port.

> >  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.
> >  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.
Item 3 and 4 are pretty much combined now.

COMMENTS:

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.

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.

REPLY:

Exactly!! There has to be some kind of floppy emulation if not a physical drive. This could be a problem with FPGA real estate, and may be another diverging point -- FPGA with real floppy, emulation with an emulated floppy. I think we're pretty much agreed that as long as software with disk access routines can be made to work the floppy can be eliminated. Even something like DriveWire/CoNect doesn't need to be built in -- the SDHC card readers should work for physical transfers. It may be that the best thing to do with the programs with their own disk routines is to patch them though. I know a few have been patched to run from a hard drive.



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

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.

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...

In hardware (FPGA) I think it would not be all that difficult to keep backward graphics
compatibility. The INIT1 register has 5 unused bits. So you establish one bit to be COCO3/COCO4 switch. That invokes a mux to determine which set of the 8 registers is active at FF98 to FF9F. Therefore the current video registers are redefined depending on the state of a bit. Rather simple task even for software I would think.
Currently bit 0 of INIT1 register is the task bit. This allows either one or two tasks. Using bits 1 and 2 would allow 8 tasks to be switched in and out. Combined that with bit 7 as a super coco bit, there still is three unused bits to control functinality of what ever. Also there is essentially two unused bytes in the FF9x range that are used by others that can be redfined for a super coco use or left for memory expansion beyond 2 Meg as it is now basically used.
As for VGA, 800x600 is not a real issue or even 1024x768. That resolution becomes your
desktop. Now you have a window that is programmable to any size which overlays onto that desktop. Essentially what a modern PC or MAC does. By reusing existing registers in the FFCx/FFDx range can lead to lead to one or maybe two or even three hardware windows on the desktop at anytime. This is all doable in hardware. Not certain about software as that is beyond my expertise. For SECB this may not be useful unless you have multiple processors and enough memory to assign each window an associated processor and then in SECB you could run multiple sessions at the same time. Multiple hardware windows have probably better uses in OS9. Along with more than two tasks, potentially greater computing power or at least better use of time while other processes are waiting on peripherals.
Also one could expand each of the FIRQENR and the IRQENR registers to add two more
IRQ sources to each register. Or even concatenate the two and make them 16 bit priority
IRQ controller.
The biggest one for any FPGA hardware that I have yet to see mentioned and am somewhat
surprised to not see it pop up. Why not a 6309 in an FPGA?

REPLY:

My thoughts on resolution are go for as much as we can and still be accessible from BASIC. Memory, processor load, and FPGA limitations are the limiting factors. Since it can be done in FPGA easy enough, BASIC programming becomes the limiting factor. If the older graphics modes can be supported without losing advanced features then they will. The 6309 is probably the best to shoot for as far as processors.

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

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.

REPLY:

My 512K/1MB comment is mainly referring to BASIC access. The new machine should support as much memory as practical, 4MB or 8MB, mainly for Nitros use. Hooking into that much for BASIC and maintaining BASIC compatibility might be an issue. Of course I'd be okay with BASIC programs requiring some patching to work.

> >  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...
COMMENTS:

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

REPLY:

How many programs actually use the Orchestra 90 pak? Of those how many NEED it? I don't think any really need it. Maybe advanced sound can be written in without compatibility. Who would be concerned about compatibility??

> >  Okay, what am I missing??
COMMENTS:

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.
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...

REPLY:

The main issue is that we really do need the two systems to be compatible, 100% if possible. So what limits the FPGA version will also limit the software version and vice-versa. That's the only way to ensure they are compatible with each other.


-- 
Frank Swygert
Publisher, "American Motors Cars"
Magazine (AMC)
For all AMC enthusiasts
http://www.amc-mag.com
(free download available!)