Forums

Charles doc mentions that values read from the scanline port range from whatever(cant remember) and the same with the hpos. How did he get the values that the ports returned.... did he write a program which graphically displayed the results returned on the screen. Another thing is that it doesnt mention the scanline numbers returned from a PAL machine, since a PAL machine has a 312 line screen I wonder what numbers are returned on that. Another thing is the hpos. Maybe someone could write a program which checked those ports constantly and when a change occured write the value somewhere like ram or sram. Then the person could dump the ram and see the results, of course only MikeG could do something like this , you could probably write to an address like 0x4000-0x7FFF as his SRAm based cartridges could be written to there and I doubt a program this small would take up more then a kilobyte. It would be intersesting to see the results returned on the different systems and would help us better understand these two pretty undocumented things.

Quote

> Charles doc mentions that values read from the scanline port range from whatever(cant remember) and the same with the hpos. How did he get the values that the ports returned.... did he write a program which graphically displayed the results returned on the screen. Another thing is that it doesnt mention the scanline numbers returned from a PAL machine, since a PAL machine has a 312 line screen I wonder what numbers are returned on that. Another thing is the hpos. Maybe someone could write a program which checked those ports constantly and when a change occured write the value somewhere like ram or sram. Then the person could dump the ram and see the results, of course only MikeG could do something like this , you could probably write to an address like 0x4000-0x7FFF as his SRAm based cartridges could be written to there and I doubt a program this small would take up more then a kilobyte. It would be intersesting to see the results returned on the different systems and would help us better understand these two pretty undocumented things.

Interesting point, I'll give that a try.

I imagine a system in PAL mode would have to return positions corresponding to the equivalent screen position on a NTSC system, in order to maintain compatibility, but it's worth finding out what the real behaviour is.

Mike

Quote

> Charles doc mentions that values read from the scanline port range from whatever(cant remember) and the same with the hpos. How did he get the values that the ports returned.... did he write a program which graphically displayed the results returned on the screen.

Yeah, that's what I did. The values are from the Genesis, switched into the SMS display mode.

Quote

> Another thing is that it doesnt mention the scanline numbers returned from a PAL machine, since a PAL machine has a 312 line screen I wonder what numbers are returned on that.

In my docs, I mention how the V counter changes it's value briefly after VBlank starts (the 'jump' thing). For a PAL machine, this change is probably just larger, so that a V counter value of $FF corresponds to line 312.

Quote

> Another thing is the hpos. Maybe someone could write a program which checked those ports constantly and when a change occured write the value somewhere like ram or sram. Then the person could dump the ram and see the results, of course only MikeG could do something like this , you could probably write to an address like 0x4000-0x7FFF as his SRAm based cartridges could be written to there and I doubt a program this small would take up more then a kilobyte. It would be intersesting to see the results returned on the different systems and would help us better understand these two pretty undocumented things.

I've found that when you have the Genesis fully in SMS mode, the H counter doesn't work. Maybe it's only valid when the lightgun is plugged in, or if the lightgun control bits are written to. (port $3F if memory serves)

When Mike ran my port-dumping program on an SMS 2, the ports that were for the H counter always returned zero.

My Homepage

Since you cant read potr $3f maybe when they "init" bits 5 and 7(according to a doc i read once) it returns something in ports $DD. For example, if you write 0xFF to 0x3f, maybe the lightgun bits on port $DD go low to specify a lightgun is plugged in. How this is achievable Im not sure, but how else could you detect for a lightgun? Maybe when a lightgun is plugged in, bits 6 or 7 instead of being high, are low. So now instead of telling the game that the gun has received white input by switching bit 6 or 7 low, it sets it high instead. Or maybe you cant detect when a lightgun is plugged in at all. It seems strange to me that the hpos on the VDP (port 7F) wouldnt work because a lightgun wasnt plugged in..unless Sega hacked it in or something. I've also never seen a lightgun game which knows that the lightgun wasnt plugged in, as you could use a joypad for all the games i tried.

Maybe it only returns hpos values for valid lines of the screen, 0-192, im pretty sure you would have updated the display in the VBLANK, maybe only reading the values during vblank. If that was the case then it would always return 0, because you are updatin the screen during vblank when the hpos isnt valid or something.

ANyways its pretty interesting and intriguing stuff, to have some rock solid information from a real SMS would be very handy :)
0Jason Starr0

Quote

> Interesting point, I'll give that a try.

> I imagine a system in PAL mode would have to return positions corresponding to the equivalent screen position on a NTSC system, in order to maintain compatibility, but it's worth finding out what the real behaviour is.

>
> Mike

Yeah it would be interesting. One would think most games wouldnt bother with any scanline values outside of 224. Im also pretty sure the scanline port doesnt return the bottom or top periods of a vblank cycle as if you make the SMS start drawing on anything other then line 0 and you will get some weird results on games which hscroll with line interupts. So if it only reports 0 as being the first line being drawn it stands to reason itwill only return lines that will be drawn and the vblank lines . Although Charles VDP doc says the VDP in a NTSC machine returns 261 values per frame which means it returns top,bottom borders etc. So it is weird, if that is the case.
-Jason Starr-

Author	Message
PolestaR Guest	Scanline and Hpos Posted: Thu Mar 15, 2001 7:24 am
PolestaR Guest	Charles doc mentions that values read from the scanline port range from whatever(cant remember) and the same with the hpos. How did he get the values that the ports returned.... did he write a program which graphically displayed the results returned on the screen. Another thing is that it doesnt mention the scanline numbers returned from a PAL machine, since a PAL machine has a 312 line screen I wonder what numbers are returned on that. Another thing is the hpos. Maybe someone could write a program which checked those ports constantly and when a change occured write the value somewhere like ram or sram. Then the person could dump the ram and see the results, of course only MikeG could do something like this , you could probably write to an address like 0x4000-0x7FFF as his SRAm based cartridges could be written to there and I doubt a program this small would take up more then a kilobyte. It would be intersesting to see the results returned on the different systems and would help us better understand these two pretty undocumented things.

Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Posted: Thu Mar 15, 2001 7:31 am
	Quote > Charles doc mentions that values read from the scanline port range from whatever(cant remember) and the same with the hpos. How did he get the values that the ports returned.... did he write a program which graphically displayed the results returned on the screen. Another thing is that it doesnt mention the scanline numbers returned from a PAL machine, since a PAL machine has a 312 line screen I wonder what numbers are returned on that. Another thing is the hpos. Maybe someone could write a program which checked those ports constantly and when a change occured write the value somewhere like ram or sram. Then the person could dump the ram and see the results, of course only MikeG could do something like this , you could probably write to an address like 0x4000-0x7FFF as his SRAm based cartridges could be written to there and I doubt a program this small would take up more then a kilobyte. It would be intersesting to see the results returned on the different systems and would help us better understand these two pretty undocumented things. Interesting point, I'll give that a try. I imagine a system in PAL mode would have to return positions corresponding to the equivalent screen position on a NTSC system, in order to maintain compatibility, but it's worth finding out what the real behaviour is. Mike

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Thu Mar 15, 2001 2:19 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote > Charles doc mentions that values read from the scanline port range from whatever(cant remember) and the same with the hpos. How did he get the values that the ports returned.... did he write a program which graphically displayed the results returned on the screen. Yeah, that's what I did. The values are from the Genesis, switched into the SMS display mode. Quote > Another thing is that it doesnt mention the scanline numbers returned from a PAL machine, since a PAL machine has a 312 line screen I wonder what numbers are returned on that. In my docs, I mention how the V counter changes it's value briefly after VBlank starts (the 'jump' thing). For a PAL machine, this change is probably just larger, so that a V counter value of $FF corresponds to line 312. Quote > Another thing is the hpos. Maybe someone could write a program which checked those ports constantly and when a change occured write the value somewhere like ram or sram. Then the person could dump the ram and see the results, of course only MikeG could do something like this , you could probably write to an address like 0x4000-0x7FFF as his SRAm based cartridges could be written to there and I doubt a program this small would take up more then a kilobyte. It would be intersesting to see the results returned on the different systems and would help us better understand these two pretty undocumented things. I've found that when you have the Genesis fully in SMS mode, the H counter doesn't work. Maybe it's only valid when the lightgun is plugged in, or if the lightgun control bits are written to. (port $3F if memory serves) When Mike ran my port-dumping program on an SMS 2, the ports that were for the H counter always returned zero. My Homepage

PolestaR Guest	Posted: Fri Mar 16, 2001 12:48 am
PolestaR Guest	Since you cant read potr $3f maybe when they "init" bits 5 and 7(according to a doc i read once) it returns something in ports $DD. For example, if you write 0xFF to 0x3f, maybe the lightgun bits on port $DD go low to specify a lightgun is plugged in. How this is achievable Im not sure, but how else could you detect for a lightgun? Maybe when a lightgun is plugged in, bits 6 or 7 instead of being high, are low. So now instead of telling the game that the gun has received white input by switching bit 6 or 7 low, it sets it high instead. Or maybe you cant detect when a lightgun is plugged in at all. It seems strange to me that the hpos on the VDP (port 7F) wouldnt work because a lightgun wasnt plugged in..unless Sega hacked it in or something. I've also never seen a lightgun game which knows that the lightgun wasnt plugged in, as you could use a joypad for all the games i tried. Maybe it only returns hpos values for valid lines of the screen, 0-192, im pretty sure you would have updated the display in the VBLANK, maybe only reading the values during vblank. If that was the case then it would always return 0, because you are updatin the screen during vblank when the hpos isnt valid or something. ANyways its pretty interesting and intriguing stuff, to have some rock solid information from a real SMS would be very handy :) 0Jason Starr0

PolestaR Guest	Re: Scanline and Lazer Horizontal position Posted: Mon Mar 19, 2001 7:11 am
PolestaR Guest	Quote > Interesting point, I'll give that a try. > I imagine a system in PAL mode would have to return positions corresponding to the equivalent screen position on a NTSC system, in order to maintain compatibility, but it's worth finding out what the real behaviour is. > > Mike Yeah it would be interesting. One would think most games wouldnt bother with any scanline values outside of 224. Im also pretty sure the scanline port doesnt return the bottom or top periods of a vblank cycle as if you make the SMS start drawing on anything other then line 0 and you will get some weird results on games which hscroll with line interupts. So if it only reports 0 as being the first line being drawn it stands to reason itwill only return lines that will be drawn and the vblank lines . Although Charles VDP doc says the VDP in a NTSC machine returns 261 values per frame which means it returns top,bottom borders etc. So it is weird, if that is the case. -Jason Starr-

Forums

View topic - Scanline and Hpos