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

[Robert Gault]

James Hrubik wrote:
> Hmmm.  HSCREEN2 is only 320 pixels wide. 
Either you did not see the original message in this thread or you have 
not considered that the value in $FF99 was changed. The screen is no 
longer in the HSCREEN2 mode.

> Line 30 says you are poking 
> 128 into the first 16 pixels of the hires screen.

Not so. The value POKEd into $FF99 (5) indicates that this is a four 
color mode. The first 16 bytes were set but not the first 16 pixels.

> Is T a counter?

FOR T= is a time waster that delays the setting of the pixels so you can 
watch what is happening.

>  I 
> though perhaps the program was grabbing 400 as the decimal number of 
> pixels in the row, so I changed it to 319, but it did not change the 
> display.  Line 40 says you are poking 64 into pixels 17-20, then 
> executing the T loop again.

Again not so. Line 40 sets data in the 17th - 20th bytes not pixels.

> 
> What has me puzzled now is that line 40 seems to be executing before 
> line 30, in that pixels 0-3 turn black, then there are 16 red ones, then 
> another 4 black, etc.  After 16 black "dashes" are laid down in the top 
> row,
Line 40 can't run before line 30. I can't explain what you think you are 
seeing.

Here is the main point.

> 4 light blue "dashes" get laid down in the second row 
> SIMULTANEOUSLY with the last 4 dashes in the top row; the last 4 dashes 
> in the top row are also the same light blue instead of black.  That is 
> where the second row at the left side comes in being generated.

How can a loop which runs four times and sets one byte per pass change 
eight bytes.

> 
> So I am seeing the program itself specify laying down 16 pixels of one 
> color, followed by 4 pixels of a second color.

Exactly.

>  On screen, however, I 
> see it lay down 4 pixels of one color followed by 16 of the second 
> color, and possibly suffering some sort of line overflow before it gets 
> to the end of the HSCREEN2 row.

You are not looking at the program correctly. Each pass through the 
loops put one byte of data on the screen. The number of pixels set 
depends on the color mode. If the screen is 2-color then one pixel has 
color A and 7 pixels have color B. 4-color is 1 vrs. 3. 16-color is 1 
vrs. 1.

> 
> Maybe more commenting of the listing would help solve this??  What did 
> you want it to do??
> 
> 

I want the program to do exactly what it looks like, set one screen byte 
per loop pass. The question is why is the second loop setting two bytes 
per pass, one on each side of the screen.

Note that this is not one of the approved Tandy HSCREEN modes for the 
Coco3. These modes are twenty bytes wide and have either 2, 4, or 16 
colors depending on the value used for $FF99.