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

[jdaggett at gate.net]

On 19 Nov 2010 at 19:57, Steve Ostrom wrote:

> 
> ----- Original Message ----- 
> From: "Frank Swygert" <farna at att.net>
> To: <coco at maltedmedia.com>
> Sent: Friday, November 19, 2010 4:54 PM
> Subject: [Coco] What would a CoCo successor have to have as a minimum?
> 
> 
> > 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.
> >
> >
> 
> Frank, I'm obviously not an expert, so maybe you can give me some reasons 
> for this statement.  What would be the reason for dropping features - any 
> features?  Are we limited by space, or are there compatibility issues?  Is 
> it lack of programming time?
> 
> 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.
> 
> -- Steve --
> 

Steve and all

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 programable to any size which overlays onto that 
desktop. Essentually 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 
beyound 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 seesions 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? 
 
These are just a few ideas I have mulled over for the past year or so and said what if!

I do think it is time now to start put in motion some of the ideas. maybe not all at once maybe 
some to start and grasually work otehrs in as some form of a project matures. It is fun in a 
way to just see how far you can go with an 8/16 bit processor. 

just my thoughts put down on electronic paper. 

james