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

jdaggett at gate.net jdaggett at gate.net
Mon Jun 8 16:35:42 EDT 2009


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




More information about the Coco mailing list