[Coco] What do you make of this non-approved HSCREEN mode?

[Robert Gault]

jdaggett at gate.net wrote:
> On 3 Jun 2009 at 21:12, Robert Gault wrote:
> 
>> Anyone who has looked at the middle chart on page 18 of the Coco3
>> service manual will have noticed that there are missing entries. I and
>> other Coco enthusiasts have expanded this table to fill in the missing
>> entries.
>>
>> It seems to me that there are two alternating series of screen widths
>> in bytes. Expanding on what is given by Tandy, the chart logically
>> would be:
>>
>> HRES2 HRES1 HRES0  Width in bytes
>>   1     1     1         160
>>   1     1     0         128
>>   1     0     1          80
>>   1     0     0          64
>>   0     1     1          40
>>   0     1     0          32
>>   0     0     1          20
>>   0     0     0          16
>>
> 
> This is true for BP = '1', HVEN = '0' , and COCO ='0' bits. That is the Coco3 
> is in graphics mode and that the Horizontal Virtual screen is not set and we 
> are not in the COCO compatible mode. 
> 
> 
>> I've tested the new entries and not all work for all color
>> resolutions. For example 160 bytes of 2 colors requires a screen 1280
>> pixels wide which could be beyond the capabilities of the Coco3.
>>
> 
> Correct there are two modes that exceed the pixel per line maximum of 
> 640 pixels. In addition to what you mentioned there is 128 bytes per row 
> and 2 colors will yield 1024 pixels. In either of the two cases 
> 
> It is hard to say with 100% certainty as to what will be displyed in there two 
> modes.
> 
> 
>> Here is a program in Basic that demonstrates something weird with the
>> "new" 20byte width screen. I'd love to hear comments about what might
>> be happening with the hardware that could cause what I, and hopefully
>> you, see.
>>
> 
> Simple. The Coco3 video section reads video memory in so many bytes 
> per row based on the settings of the HRES bits. Graphics mode differs from 
> character mode with the setting of the HRES bits. In text mode HRES1 is 
> ignored and essentially CRES0 bit along with HRES2 and HRES0 
> determine the number of bytes per row that a screen will show. This again 
> is also dependant on the setting of the COCO bit and the HVEN bit. In both 
> graphics and text mode the HVEN will override any HRES settings to 256 
> bytes per row. 
> 
> Setting the HVEN in text mode is useless and also causes funny things to 
> happen as RSBASIC may be writing video data at a different bytes per row 
> setting. The GIME chip has a lot of little things that needed clean up with a 
> third pass that never was done. Some video resolution modes should have 
> not been allowed in either graphics or text mode. 
> 
> james
> 

So, ignoring the comments that don't apply to the program in question, 
you are saying there are bugs in the GIME design?

Do you think that in Coco3 graphics mode an HRES=000 is 20 bytes wide or 
just too buggy to be anything?