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

jdaggett at gate.net jdaggett at gate.net
Sun Jun 7 19:28:40 EDT 2009

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 

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


More information about the Coco mailing list