open bottom border possible in 60hz?

[evil]

Code: Select all

Line:
16: 60Hz vBLANK = false; 
25: 50Hz vBLANK = false;
34: 60Hz and mono screen start
47/63: 50Hz screen start (short/regular top border GLUE)
234: 60Hz screen end
247/263: 50Hz screen end
258: 60Hz BLANK 
308: 50Hz BLANK 

I'm confused by all the "just like regular lower border just with frequencies swapped" comments. You can read the table above top down:

If you're in 60Hz at line 34 the screen will start to display. If you're in 60Hz at line 234 it will stop displaying.

= you must be in 50Hz at the correct position on line 234 to keep displaying a "bottom border".

A 60Hz screen stops displaying (blanks) at line 258. You can enable a few more extra lines by doing a 60-50-60 switch there.

If you're using timers instead of counting lines, you need to count 234 lines of 508 cycles instead of 263 lines of 512 cycles to get to the right place.

Always test on real hardware. I know when I released "Fullast Vinner" Steem SSE did not emulate 60Hz VBLANK.

As mentioned, I did test on real hardware.

With Timer B as you certainly know, it will count "open" scanlines, and that's 200 with 50 or 60 Hz, so same MFP setup.
Then at the interrupt, instead of 60-50, it's 50-60.

It adds 23 lines in Hatari and the same on my STe+Medusa.

However, lines 1-3 are deformed both with my program and Neo Master. Not sure if it's my STe, scandoubler(s) or lame code.
As can be seen here: https://ae.dhs.nu/pics/low60ste_medusa.jpg

[TheNameOfTheGame]

One issue with the border code. I have text being drawn in the border, but it flashes randomly every 4-8 seconds as if the border didn't get opened on that refresh. I turned off the ACIA interrupt just to see if that was causing it, but it didn't change anything.

Here is the code:

Code: Select all

MYVBL:
	CLR.B 0xFFFFFA1B.W			|STOP TIMER B
	MOVE.B #199,0xFFFFFA21		|OCCUR ON LAST SCANLINE
	MOVE.B #8,0xFFFFFA1B.W		|START TIMER B
	move.l STORAGE,-(sp)		|to fall through to old vbl
	RTS

TIMER_B:
	CLR.B 0xFFFFFA1B.W			|STOP TIMER
	MOVEM.L D0/A0,-(A7)	
	MOVEA.W #0xFA21,A0
	MOVE.B #200,(A0)
	MOVE.B #8,0xFFFFFA1B.W		|START TIMER
	MOVE.B (A0),D0
WAIT2:
	CMP.B (A0),D0			
	BEQ WAIT2
|	CLR.B 0xFFFF820A.W			|INTO 60 HZ
	MOVE.B #2,0xFFFF820A.W		|INTO 50 HZ
	MOVEQ.L #2,D0
LOOP1:
	NOP
	DBF D0,LOOP1
|	MOVE.B #2,0xFFFF820A.W		|INTO 50 HZ
	CLR.B 0xFFFF820A.W			|INTO 60 HZ
	MOVEM.L (A7)+,D0/A0
	BCLR #0,0xFFFFFA0F.W		|ACKNOWLEDGE
	RTE					

A couple of questions as I don't understand the code totally.

1) In the vbl routine, it sets timer_b to fire at line 199. But then at line 199 when the timer b interrupt occurs, the timer b routine seems to wait for line 200 somehow.

Code: Select all

MOVEA.W #0xFA21,A0
	MOVE.B #200,(A0)
	MOVE.B #8,0xFFFFFA1B.W		|START TIMER
	MOVE.B (A0),D0
WAIT2:
	CMP.B (A0),D0			
	BEQ WAIT2

Could someone explain what is happening in the snippet above and why not just set timer b for line 200 in the vbl routine?

2) In the timer b interrupt code, after line 200 is reached in the data register, wouldn't another interrupt occur even though we are in the interrupt routine already?

3) There is a delay loop before the frequency switch. Going into 50hz then back to 60hz uses a 'MOVE.B #2" but going into 60hz then back to 50hz uses a "CLR.B". Are the cycle counts for those instructions the same, i.e. does the delay loop need to be adjusted depending on the freq switch type?

Trying to figure out why the text in the lower border is blinking every so often. I guess I could set timer b to trigger on line 1 and set the background color and then set it back to 199. Then I could set another color at the bottom line interrupt to see better if the border is actually closing as a cause for the blinking?

**Edit** yes, to test I now have the color changed for the overscan part to be different from the rest of the screen. When the blinking occurs, the color in the lower border changes to the same as the rest of the screen and the text isn't shown, so the timer b routine isn't opening the border on those misses. Must be a timing issue?

**Edit2** changed the timer b code to be the PAL version i.e. switching to 60hz then to 50hz and ran Steem with UK TOS rom. The blinking went away, so looks like a timing issue with the NTSC case.

[troed]

With Timer B as you certainly know, it will count "open" scanlines, and that's 200 with 50 or 60 Hz, so same MFP setup.
Then at the interrupt, instead of 60-50, it's 50-60.

It adds 23 lines in Hatari and the same on my STe+Medusa.

However, lines 1-3 are deformed both with my program and Neo Master. Not sure if it's my STe, scandoubler(s) or lame code.

Thanks - indeed I did not understand you used Timer B in line counting mode

I'm guessing the reason for the deformed scanlines being that you stay in 50Hz for too long and manage to trigger the next line as being in 50Hz instead of 60Hz. This timing is (slightly!) different on 60Hz lines compared to 50 which is why the same code might work for 50 but not 60.

[thomas3]

NameOfTheGame:

1) the author is doing something unnecessary by setting timer B again in the lower border routine. If they didn't kill their interrupt right at the start of the routine (the clr.b instruction) they wouldn't have to set timer B again at all. (Look at the next part of the routine - it waits on the timer B counter to sync to the start of the next scanline). I guess they just used 200 as an arbitrary value, but they may not have understood quite what they're doing.

2) no - because the counter starts again at 0. Incidentally, this means that they also leave timer B set at the end of the vbl - dirty, and is something that has caused me weird issues at various points in the past...

3) why don't you put a raster in your timer C (just set the BG colour to something at the start of your TC routine, and then back to normal at the end). I wonder if the failure of the border routine you speak of corresponds to where the timer C is occurring at the same time roughly as, and therefore interfering with, the timer B and knocking the timing out . You'll see straight away if this is the case.....

[TheNameOfTheGame]

NameOfTheGame:

1) the author is doing something unnecessary by setting timer B again in the lower border routine. If they didn't kill their interrupt right at the start of the routine (the clr.b instruction) they wouldn't have to set timer B again at all. (Look at the next part of the routine - it waits on the timer B counter to sync to the start of the next scanline). I guess they just used 200 as an arbitrary value, but they may not have understood quite what they're doing.

Yeah, I don't think that was a good way. I changed it to as below. Do you see any problems with it?

Code: Select all

MYVBL:
	CLR.B 0xFFFFFA1B.W			|STOP TIMER B
	MOVE.B #200,0xFFFFFA21		|OCCUR ON LAST SCANLINE
	MOVE.B #8,0xFFFFFA1B.W		|START TIMER B
	move.l STORAGE,-(sp)		|to fall through to old vbl
	RTS

TIMER_B:
	CLR.B 0xFFFF820A.W			|INTO 60 HZ - PAL case
|	MOVE.B #2,0xFFFF820A.W		|INTO 50 HZ - NTSC case
	OR.L	D0,D0
	OR.L	D0,D0
	MOVE.B #2,0xFFFF820A.W		|INTO 50 HZ - PAL case
|	CLR.B 0xFFFF820A.W			|INTO 60 HZ - NTSC case
	BCLR #0,0xFFFFFA0F.W		|ACKNOWLEDGE
	RTE

2) no - because the counter starts again at 0. Incidentally, this means that they also leave timer B set at the end of the vbl - dirty, and is something that has caused me weird issues at various points in the past...

Can you explain that part about leaving timer b set at the end of the vbi? I don't understand it.

3) why don't you put a raster in your timer C (just set the BG colour to something at the start of your TC routine, and then back to normal at the end). I wonder if the failure of the border routine you speak of corresponds to where the timer C is occurring at the same time roughly as, and therefore interfering with, the timer B and knocking the timing out . You'll see straight away if this is the case.....

I tried with evil's code he posted earlier in the thread and it blinks also. As I mentioned I turned off the ACIA interrupt to test and it still blinks.

So I think it is timer C. I can't really turn it off as HDDriver uses it and the program I am working on uses it. It is just the system timer routine, I hadn't changed it to anything custom. Can the timer C interrupt be masked in some way prior to the frequency switch?

Thanks for the help. I haven't worked with interrupts too much in the past so I am learning some new things.

[TheNameOfTheGame]

Went ahead and put in a short Timer C routine to try out your suggestion.

Code: Select all

TIMER_C:
	eori.w #4040,0xffff8240		|change color
	move.l STORAGE+4,-(sp)		|to fall through to old timer c
	rts

I made a short video of the issue with the modified Timer C.

https://youtu.be/UNg76ZbWkR0 - PAL
https://youtu.be/tLvLDCcz-yY - NTSC

You can see the Timer C seems to drift down the screen. Not sure why it is not stable. Maybe that is an issue?

If you look carefully, you can see the game name blink every few seconds. Harder to see on the NTSC version but it is there.

[TheNameOfTheGame]

From the videos, can someone let me know if timer C is supposed to 'roll' like that?

On the PAL video, I can see the blinking on the lower border text happen every time right before a timer C color changes goes by.

[thomas3]

Hi, sorry! Yes, the rolling is fine. Bear in mind you're running this at 60hz.

You've definitely hit the issue that your timer C/HDD stuff is interfering with the timing of your timer B. At this point, I can't advise I'm afraid on whether this is fixable - I'm a demo guy who only uses timer C in extreme circumstances, and then never with other interrupts.

I seem to recall though that HDD access during border removal is a problem. A few people have done stable lower border removal with floppy access, but fairly sure they won't have used timer C at the same time.

Troed or Evl will know

[Cyprian]

Went ahead and put in a short Timer C routine to try out your suggestion.

Code: Select all

TIMER_C:
	eori.w #4040,0xffff8240		|change color
	move.l STORAGE+4,-(sp)		|to fall through to old timer c
	rts

I made a short video of the issue with the modified Timer C.

https://youtu.be/UNg76ZbWkR0 - PAL
https://youtu.be/tLvLDCcz-yY - NTSC

You can see the Timer C seems to drift down the screen. Not sure why it is not stable. Maybe that is an issue?

If you look carefully, you can see the game name blink every few seconds. Harder to see on the NTSC version but it is there.

can you try with this "bclr"? It should allows to invoke Timer B interrupt before Timer C is ended

Code: Select all

TIMER_C:
	bclr #5,0xFFFFFA11.W		|TIMER A ACKNOWLEDGE
	eori.w #4040,0xffff8240		|change color
	move.l STORAGE+4,-(sp)		|to fall through to old timer c
	rts

[tin]

The Timer C in 50Hz moves down because 4 Timer C‘s take ever so slightly longer than one 50Hz frame does (different timing sources), hence the „slowly sliding down“ effect.

Regarding the stability of the lower border with Timer C in place - I‘d suggest to use the trick that‘s used in Bitmaster’s Screen Plus ( https://github.com/ggnkua/Atari_ST_Sour ... een%20Plus or the newer version https://github.com/ggnkua/Atari_ST_Sour ... h/scrplus2 ): just provide a safe zone for your IRQ (e.g. trigger it 20 lines or so earlier) disable interrupts and then busy wait for displayed line 200 in your irq rout, then open the border.
That way the Timer C will _still_ disturb your IRQ, but not the part that _actually_ opens the border - as in: the IRQ might trigger later than planned (because the Timer C or the DMA is busy and suppresses it for a few scanlines), but the busy wait will then find the line you‘ll need to open the lower border in time, anyways.
Burns a lot of CPU, so demo coders usually don‘t do that, but for sth that really needs Timer C it‘s a feasible solution Bitmaster did there.

[TheNameOfTheGame]

can you try with this "bclr"? It should allows to invoke Timer B interrupt before Timer C is ended

Code: Select all

TIMER_C:
	bclr #5,0xFFFFFA11.W		|TIMER A ACKNOWLEDGE
	eori.w #4040,0xffff8240		|change color
	move.l STORAGE+4,-(sp)		|to fall through to old timer c
	rts

Ok, I tried this, thanks, but it still flickers the text in the lower border.

The Timer C in 50Hz moves down because 4 Timer C‘s take ever so slightly longer than one 50Hz frame does (different timing sources), hence the „slowly sliding down“ effect.

Regarding the stability of the lower border with Timer C in place - I‘d suggest to use the trick that‘s used in Bitmaster’s Screen Plus ( https://github.com/ggnkua/Atari_ST_Sour ... een%20Plus or the newer version https://github.com/ggnkua/Atari_ST_Sour ... h/scrplus2 ): just provide a safe zone for your IRQ (e.g. trigger it 20 lines or so earlier) disable interrupts and then busy wait for displayed line 200 in your irq rout, then open the border.
That way the Timer C will _still_ disturb your IRQ, but not the part that _actually_ opens the border - as in: the IRQ might trigger later than planned (because the Timer C or the DMA is busy and suppresses it for a few scanlines), but the busy wait will then find the line you‘ll need to open the lower border in time, anyways.
Burns a lot of CPU, so demo coders usually don‘t do that, but for sth that really needs Timer C it‘s a feasible solution Bitmaster did there.

Thanks, I will try this out soon. I need to read it and understand the code.