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

[James Hrubik]

On Jun 7, 2009, at Sunday, June 7, 2009 - 12:06 AM, Robert Gault wrote:

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

I simply typed in the listing you supplied:

10 HSCREEN2: POKE&HFF99,5 : You can also use ,4 and ,6
20 PALETTE1,25:POKE&HFFB0,7
30 FOR M=0TO15:LPOKE &H60000+M,128: FOR T=0TO400: NEXT T,M
40 FOR M=0TO 3:LPOKE &H60010+M, 64: FOR T=0TO400: NEXT T,M
50 GOTO50

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

I must not be looking at what is actually happening on a real CoCo3  
screen correctly, either.  I knew I was in over my head when I turned  
on the CoCo and actually typed in a BASIC program for the first time  
in over a decade. <G>

>
>> 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.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

---------------------------------------------------
-----Items below rated "R"; parental discretion advised----
---------------------------------------------------
"Brilliant minds, like productive gardens, flourish under the  
influence of bullshit."
---------------------------------------------------
  From the sayings of Grampa Jim, Copyright 2006.
Unauthorized use of my stuff may cause senility.