[Coco] hardware scrolling revisited...

[Steve Bjork]

On 12/2/2013 12:08 PM, John W. Linville wrote:
> This, of course, illustrates that in all likelihood the GIME designers
> had at least some interest in supporting the SG modes.  It is a shame
> that they ran out of time or design space or whatever.
There was a limit placed on not only the design of the GIME but on the 
CoCo 3 design as a whole.

While the CoCo community saw the CoCo 3 as a new and better version of 
the CoCo, it was really a just a cost reduced version of the CoCo 2.

That's right, the only way we got a new CoCo was because it was cheap to 
build than the last version.  The only CoCo what was not cheaper than an 
earlier version was the never released Deluxe CoCo. The Deluxe CoCo 
would have started a new "Home Pro" line of computers.  The Tandy 1000 
line did fill that void.

With the design goal to costing less than the CoCo 2, everything about 
the new CoCo 3 was watch over by accountants.  The size of the GIME, the 
RAM and even who was going to "patch" BASIC ROMs was down to keep the 
manufacturing cost below the Cost of a CoCo 2.

The ram size of 128k was key item in the list of new options for the 
system.  This double of the RAM size more about marking than any do with 
making the system more powerful.  "Twice the storage" was more about the 
Commando 64 than the earlier CoCo2 when it came to marketing.

When it came to the GIME there was a lot of design tradeoffs. Us game 
designers needed a sound system in the new CoCo.  Bit-banging the DAC 
while working on graphics was driving us nuts.  (Besides, we could never 
get good sound out of the CoCo without giving up most of the CPU cycles 
to the sound code.

The programmable timer with interrupt was a "sound" solution that only 
cost about 20% to 30% of CPU cycles fairly good music and sound effect.  
You take what you can get.

The limit of 16 color registers cam from two factors with the first 
being the bandwidth of the CoCo 3's memory system.  This was double over 
the CoCos that came before by going to 16-bit bus.  (Yes, the internal 
bus of the CoCo 3 is 16-bit.)  Even with doubling the bus, the memory 
data stream would only handle 4 bits per dot on a 256/320 across mode.

The second limitation was the number gates on the GIME design. There was 
only so much money could be spent on the manufacturing, so limits that 
size of the GIME.  But the other limit was thermal design power (TDP) of 
the chip.  As you know, the GIME runs a bit on the warm size.

The 64 color limit came from the 6-bit color palette registers.  But why 
not 8-bit for 256 colors?  Once again, it comes the the limit of the 
number of gates on the GIME.  There was no room on it for another 32 
bits of storage.  (2 Bits * 16 palettes.)

As for the infamous 256 color mode of the GIME, it was part of the GIME 
design at one time along with 256 color (8-bit) palettes. When they 
found that the palettes needed to be dropped to just 6-bit (64 colors), 
the Direct (256) color mode was dropped too. (Along with the output DAC 
going from 8 to 6 bits.) I never received any per-production GIME chip 
that had 8-bit palettes nor direct color mode.

The only CoCo 3 in the wild that may (but unlikely) have the 256 color 
direct mode is the per-production board that Al Huffman saved from 
Microware's house cleaning.

Remember, this 256 color mode was not every useful since it was 160/128 
blocks (dots) across.  That's right, it would have been a very low res 
screen.  (There is that memory bandwidth limitation again.)

Steve