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

[jdaggett at gate.net]

On 8 Jun 2009 at 16:15, Robert Gault wrote:

> jdaggett at gate.net wrote:
> > On 7 Jun 2009 at 23:20, Robert Gault wrote:
> > 
> >> Robert Gault wrote:
> >>
> >>> 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?
> >>>
> >> Sorry that should have been HRES=001 is 20 bytes per row.
> >>
> > 
> > 
> > And HRES 000 yields 16 bytes per row. 
> > 
> > WHile the register will hold the encoded bits, the actual decoder
> > for the horizontal resolution bits may not fully be implemented.
> > Having the register bits is small real estate on the die. The actual
> > decode and implementation takes more area and thus cost. 
> > 
> > The simplest usage of the HRES bits is to feed them into a 3 of 8
> > decoder and then use those as an address lines to ROM that is 8 by
> > 10 bits wide in size.  The output of the ROM then feeds a comparator
> > that takes the row bytes per row counter output as the other input.
> > When the two are equal then the vertical line counter is incremented
> > and the row counter reset. So what ever gets programmed into the
> > small ROM is what is displayed. 
> > 
> > james
> > 
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> > 
> 
> What I've been able to see with an actual Coco3 in Coco3 mode ($FF90),
> graphics mode ($FF98), and $FF99=5 (20-byte width, 4-color) follows.
> 
> The screen is a true graphics screen only for the middle 5-15 bytes of
> each horizontal line. Bytes 0-4 are unique in that they only have an
> effect on themselves. Bytes N*(16-19) - where N>0 - effect themselves
> and the next group of bytes at N*(20-24). The screen is not usable in
> any practical sense as pixels are not round but look like short lines.
> If there is any interest to be found here, it is a hint into the
> workings, or lack of, inside the GIME.
> 

Robert

That is interesting find. Yes there are settings that become meaningless. I 
do agree that they should have not been implemented if it is not going to be 
supported or of use. 

james