Overscan - difference between methods

[Cyprian]

Hi All,

I'm just trying to do a simple screen without borders. I found two different a bit method how to do that DHS Evil's and James Ingram's.
First one has no stabilizer due to STE only, what is clear for me. One thing puzzles me - they use a bit different timing.
Evil's part, uses 12 cycles between write to the same registers, James Ingram's 8 cycles. Does it matter?

thanks
Cyprian

DHS Evil's code

Code: Select all

		move.b	d7,$ffff8260.w			; Left border
		move.w	d7,$ffff8260.w

		dcb.w	90,$4e71

		move.w	d7,$ffff820a.w			; Right border
		move.b	d7,$ffff820a.w

		dcb.w	26,$4e71

James Ingram's code

Code: Select all

		move.b	d3,(a1)			; Left border
		move.b	d4,(a1)

		dcb.w	90,$4e71

		move.b	d4,(a0)			; Right border
		move.b	d3,(a0)

		dcb.w	13,$4e71

		move.b	d3,(a1)			; Stabilizer
		nop
		move.b	d4,(a1)

		dcb.w	12,$4e71

[ljbk]

Hi !

Sync switches timings do not have the same "tolerance" for each of the 3 cases involved in a no-left no-right border.
That tolerance also depends on the wake up state of the machine.
But this is mainly important for the first "move" that sets the temporary value in $FFFF820A or $FFFF8260.
The second one can come 8 cycles later, 12 cycles later, 16 cycles later ... and this should not have any consequence for most if not all machines.
Of course there is a limit to that delay.
As an example the right border removal (60 Hz setting) must happen at a precise pixel, not one nop before and not 1 nop after, and that instruction should not be preceeded by a pairing instruction like exg otherwise it will not work with some wake up states (like the Nostalgic Mega Demo Main Menu).
The return to 50 Hz can happen 8 cycles after, 12 cycles after, 16 cycles after, 20 cycles after, it will not change anything.

Paulo.

[Cyprian]

thanks Paulo, now it's clear for me.
one more question regarding top and bottom border. what is their "tolerance" for the first move with the temporary value and also second "restore" move?

[ljbk]

thanks Paulo, now it's clear for me.
one more question regarding top and bottom border. what is their "tolerance" for the first move with the temporary value and also second "restore" move?

Top and bottom border timings are much larger.
The change to 60 Hz must occur after the spot related to right border openning.
The change back to 50 Hz has to occur quite some nops after, after the place where you have the "stabilizer" and the left border switch.
If you are not synched doing a bottom border openning, you should place a certain amount of nops between the two so that depending on the timer B interrupt jitter the 60 Hz and 50 Hz switches occur at acceptable places.
Some programs, like Octalyser, allow you to specify that number of nops to avoid flickering.
Of course, the best is to have a timer B interrupt at the end of line 198, synch with the $FFFF8209 counter during the next, and normally last, line and do a timed synch switch.
But this costs time and sometimes is not possible if you have other priority interrupts, like digisound for Octalyser.

Paulo.

[Cyprian]

Many thanks Paulo

currently I start my procedure on VBL, next do some stuff within 15,000 cycles, open top border, do one synchro with $FFFF8209 open left/right and finally bottom border.
Overscan with Timer A/B and its jitter is the "next level" of magic, I'll try it later.

[evil]

currently I start my procedure on VBL, next do some stuff within 15,000 cycles, open top border, do one synchro with $FFFF8209 open left/right and finally bottom border.
Overscan with Timer A/B and its jitter is the "next level" of magic, I'll try it later.

Hello,

the reason I use 12 cycle writes instead of 8 is to save registers and a less fragmented border/effect code distribution over the scanline.
The fragmentation comes from the need to pad with 4 cycles in between two of the frequency switches (forgot if it was left or right, but I think right) if you do 8 cycle writes.

So, it's a compromise of saving registers and getting two "clean" streaks of cycles rather than stealing two more registers (and worse, address registers!) plus getting more code fragmentation.

Both methods have their pros and cons, chose the better one for the occasion I'd say


About waiting 15k cycles from VBL is no good as you already figured out, setting up a Timer-A to trigger just before the top border isn't very difficult.
You set the Timer-A data to #97 and start it off with #4 prediv.

Someone wrote on the Hatari list about a non-functional overscan and sent a source (was that you perhaps?). I noticed the 15k cycles wait there as well and made a "mini fullscreen setup" source with Timer-A to mail back, but it looks like I forgot about it.

So here's a download link: http://files.dhs.nu/files_source/full_ste.s

[ljbk]

Hi !

The use of timers to open top border has to be done very carefully otherwise the code will not work on all STs.
Some CPUs are faster than others. So if you assume that all MFPs are equal and work with the same frequency a constant timer delay will correspond to a variable number of cycles due to to a faster or slower CPU clock.
4 cycles (1 nop) too much or too little is enough to mess up your top border removal routine.
I found out about this a few weeks before releasing The Overscan Demos back in 1990. I tested the program on a friend ST with Spanish TOS 1.02 (and a CPU @ 8.021247 MHz (this i did not know)) and none of the 9 fullscreens worked ...
That is why i had a timer test then to fill a value that would be different on my 8.0071 MHz ST and on the other one. That is how i got my demo to work on both and i was only starting the timer 45 lines after the start of the lower border.
So if you use a timer, you should reduce the timer delay to the minimum and start the timer when you are synchro with $FF8209. But even in that case i advice to add a timer test.
Of course there is also the STOP method: you STOP the CPU and an exception will start it:
STOP $2100 => HBL
STOP $2300 => VBL
STOP $2500 => MFP interrupt
When the CPU restarts, the jitter will be very small and so you can open the top border with ease.
You can also combine both methods:
- a timer to get to 1 line or 2 before the top border should be open;
- 1 or 2 STOP $2100 to get to the proper HBL before the one where you should do the 60/50 switch

The choice between having registers or not to do the sync switches is a part of a fullscreen code design. You can even have one part of the fullscreen with registers and another part without.
The big advantage of using the 8 cycles case is to have more CPU time, even the 4 cycles of the left border removal and stabilizer are sometimes useful.
No registers at all case mean 3*32=96 cycles to do the switches.
No address registers case means 3*24= 72 cycles to do the switches.
Faster case means 48 cycles to do the switches with 2 nops in between so 56 cycles maximum.
As each nop/4 cycles occurs every line, we have almost 0.8% CPU to use or not for every nop during the fullscreen display lines.
This might be important or not, it depends on the fullscreen (part).


Paulo.

[Cyprian]

that's really interesting Paulo. definitely you should prepare an article (here on AF) about that difference between CPU/MFP clock and how to determine it. I read somewhere that there are also different MMU types, which has an impact on top border (13 vs 29 lines), it would be cool to have and info how to determine that also.

Evil, that was me, I had and issue with overscan - US TOS with his 60Hz fooled me a bit
Thanks for that "full_ste.s". I played around with your code and with different overscan method on STE and produced some a new code: Mixed mode - Evil's vs James Ingram's (screen 1); new STE overscan mode - James Ingram's code with Evil's no stabilizer idea(screen 2); and funny scrambled mode (screen 2).

I need to check deeply that "new STE overscan mode", I'm not sure about it's stability. It uses 3 register and only 32 cycles.

Code: Select all

	REPT 227
		move.b	d7,(a1)			;Left border
		move.w	d7,(a1)
		dcb.w	90,$4e71
		move.w	d7,(a2)			;Right border
		move.b	d7,(a2)
		dcb.w	30,$4e71
	ENDR

Final outcome is that there is no one method to open left/right borders, e.g Evil use different spots that James Ingram.

FS_STE2.png

FS_STE3_B.png

FS_STE3.png

[evil]

Thanks for that "full_ste.s". I played around with your code and with different overscan method on STE and produced some a new code: Mixed mode - Evil's vs James Ingram's (screen 1); new STE overscan mode - James Ingram's code with Evil's no stabilizer idea(screen 2); and funny scrambled mode (screen 2).

Hi,
I forgot about the discussion for a while. But it looks like you found a third overscan mode: one with true 416 pixel display. No screen shift to the right, no right-border stabilizer garbage, but a clean 416px mode.

Question: Is the linewidth still 224 bytes?

I'm pretty sure Hatari would need fixing to support that mode as well.

[Cyprian]

it's 230 bytes per line overscan and actually, odd lines are a bit shifted. Unfortunately I had no time to play with my STE and to fix that shift, therefore I'm still sure about stability/usability that overscan method.

FS_STE3_B.png

[troed]

it's 230 bytes per line overscan and actually, odd lines are a bit shifted. Unfortunately I had no time to play with my STE and to fix that shift, therefore I'm still sure about stability/usability that overscan method.

FS_STE3_B.png

Works on ST and STE?

It's been "a few" years since I wrote my first fullscreen, but it was one of the really early ones (and not based on anyone else's source code - although I had hints on 71Hz needed to remove the left border). I've always been of the opinion that I didn't use a "stabilizer" - and scrapped my own code when I became a member of SYNC and used the group routines instead.

My version didn't suffer from the [same] non-stabilizer issues I saw in Omega's fullscreen or TNT Crew's death of the left border though - but it wasn't tested on many STs. I investigated the evolution of using a stabilizer here on the forum just a few months ago: http://www.atari-forum.com/viewtopic.ph ... 3&start=78

Judging from Steven Seagal's comment at the end, isn't that what you see as well?

[Cyprian]

I only checked it on my STE and Mega STE. I have also very old short 520 ST without floppy, I'll check on them.

[metalages]

that's really interesting Paulo. definitely you should prepare an article (here on AF) about that difference between CPU/MFP clock and how to determine it. I read somewhere that there are also different MMU types, which has an impact on top border (13 vs 29 lines), it would be cool to have and info how to determine that also.

Evil, that was me, I had and issue with overscan - US TOS with his 60Hz fooled me a bit
Thanks for that "full_ste.s". I played around with your code and with different overscan method on STE and produced some a new code: Mixed mode - Evil's vs James Ingram's (screen 1); new STE overscan mode - James Ingram's code with Evil's no stabilizer idea(screen 2); and funny scrambled mode (screen 2).

I need to check deeply that "new STE overscan mode", I'm not sure about it's stability. It uses 3 register and only 32 cycles.

REPT 227
move.b d7,(a1) ;Left border
move.w d7,(a1)
dcb.w 90,$4e71
move.w d7,(a2) ;Right border
move.b d7,(a2)
dcb.w 30,$4e71
ENDR

Final outcome is that there is no one method to open left/right borders, e.g Evil use different spots that James Ingram.

I am wondering if some overscan scheme can fix my current problem :

currently I follow the Evil DHS Ste frame

Code: Select all

move.b	d7,$ffff8260.w			; Left border
move.w	d7,$ffff8260.w
dcb.w	90,$4e71
move.w	d7,$ffff820a.w			; Right border
move.b	d7,$ffff820a.w
dcb.w	26,$4e71

But in this case there is a space in the left of the screen where the color 0 appears I would say on 16 pixels ?)
this is annoying because I use the trick where the background is made of a repetition of lines on 8 colors, an then use the colors change to modelize a graphic pattern => in this case, when "moving" the background the effect on color 0 space on the left is not very nice.

Do you have any advice to avoid this problem ? (another overscan frame or something else ?)

[evil]

I am wondering if some overscan scheme can fix my current problem :

currently I follow the Evil DHS Ste frame

Code: Select all

move.b	d7,$ffff8260.w			; Left border
move.w	d7,$ffff8260.w
dcb.w	90,$4e71
move.w	d7,$ffff820a.w			; Right border
move.b	d7,$ffff820a.w
dcb.w	26,$4e71

But in this case there is a space in the left of the screen where the color 0 appears I would say on 16 pixels ?)
this is annoying because I use the trick where the background is made of a repetition of lines on 8 colors, an then use the colors change to modelize a graphic pattern => in this case, when "moving" the background the effect on color 0 space on the left is not very nice.

Do you have any advice to avoid this problem ? (another overscan frame or something else ?)

The 224 byte STe-overscan will have 8-9 pixels less in the left border than the right, showing background colour instead.

I guess you need a regular ST overscan with hires stabilizer to hide the bgcolour completely. It'll fill the entire left border and black-out pixels at the stabilzer in the far right border (monochrome output active instead of RGB). If you do a medres stabilizer the background colour will still be visible.
A few years back I did some crude measurements with all wakestates on STfm and also STe, Hatari to compare.
https://ae.dhs.nu/hatari_overscan/

Now I see an error in the tests, it's possible to open the lower border one more time to gain two extra scanlines (total of 47 in the lower border) - hi Troed!

Anyway code for a ST overscan line with hires stab:

Code: Select all

		moveq	#2,d7
		lea	$ffff820a.w,a5
		lea	$ffff8260.w,a6
		
		dcb.w	12,$4e71
		move.b	d7,(a6)
		nop
		move.w	d7,(a6)
		dcb.w	89,$4e71
		move.w	d7,(a5)
		move.b	d7,(a5)
		dcb.w	13,$4e71
		move.b	d7,(a6)
		nop
		move.w	d7,(a6)

Please note that Hatari doesn't emulate the blackout from the stabilizer, it will show the background colour instead. Not sure how other emulators does.

[metalages]

The 224 byte STe-overscan will have 8-9 pixels less in the left border than the right, showing background colour instead.

I guess you need a regular ST overscan with hires stabilizer to hide the bgcolour completely. It'll fill the entire left border and black-out pixels at the stabilzer in the far right border (monochrome output active instead of RGB). If you do a medres stabilizer the background colour will still be visible.
A few years back I did some crude measurements with all wakestates on STfm and also STe, Hatari to compare.
https://ae.dhs.nu/hatari_overscan/

Now I see an error in the tests, it's possible to open the lower border one more time to gain two extra scanlines (total of 47 in the lower border) - hi Troed!

Anyway code for a ST overscan line with hires stab:

Code: Select all

		moveq	#2,d7
		lea	$ffff820a.w,a5
		lea	$ffff8260.w,a6
		
		dcb.w	12,$4e71
		move.b	d7,(a6)
		nop
		move.w	d7,(a6)
		dcb.w	89,$4e71
		move.w	d7,(a5)
		move.b	d7,(a5)
		dcb.w	13,$4e71
		move.b	d7,(a6)
		nop
		move.w	d7,(a6)

Please note that Hatari doesn't emulate the blackout from the stabilizer, it will show the background colour instead. Not sure how other emulators does.

Thank you for your feedback
Considering the fact having 3 gaps instead of 2 is not convenient and that Hatari does not emulate the black pixel of the stabilizer, I will try a more software approach : try to animate the remaining plane in a "subtractive" way rather than "additive" in order to move the background colors range from 0-7 to 8-15. It would allow me to have a stable color in the left border.

About steem sse : the display only shows 384 pixels cutting the more extrem borders.

[thomas3]

Newer versions of Steem allow you to set "large" or "maximum" border size. "Maximum" actually shows you more than Hatari to the left border, but displays the blackout differently.

[metalages]

About Steem SSE : I have noticed a difference compared to Hatari + my stock STe.

I have set the line width to 256 bytes (using line offset in order to add 256 - 224 bytes).
At each line I write $ffff8207 register to reorder bitmap display.

In Hatari + my STe, it works when I write this register just after the left border opening while in Steem SSE I need to write it just before the left border opening.

[Cyprian]

About Steem SSE : I have noticed a difference compared to Hatari + my stock STe.

I have set the line width to 256 bytes (using line offset in order to add 256 - 224 bytes).
At each line I write $ffff8207 register to reorder bitmap display.

In Hatari + my STe, it works when I write this register just after the left border opening while in Steem SSE I need to write it just before the left border opening.

It would be a good idea to let Steven know

[metalages]

Is Steven present on the forum ?

[Cyprian]

Is Steven present on the forum ?

Unfortunately not anymore.

But he is active there: https://sourceforge.net/p/steemsse/forum/bugs/