PTPlayer / Vertical Blank Interrupt / 060

[DanielAllsopp]

Hi!

I've just tried my RoboCop build out on some real hardware to see how it's looking and I've come across the following issue: when I the ptplayer audio initialised using '_mt_install_cia' and I start playing a mod file, the scrolling completely breaks, and the blitted objects all seem to go haywire.

Example here, the first part of the video shows how the game runs without the audio initialised and playing a mod, the second part with:

[ Show youtube player ]

This was recorded on FS-UAE, but the result is exactly the same on a 060 A4000 machine. I can only guess it's some sort of PTPlayer interrupt (level 6 I think) clashing with the vertical blank interrupt I have refreshing the display (level 3 I think).

No issues with a plain A1200 setup on FS-UAE, and I'm trying to get my A1200 hardware up and running to check that but in the mean time, does anyone have any pointers as to why this might happen?

Cheers,
Daniel

[roondar]

I'm not entirely sure what causes this. I was thinking it might be a race condition between the interrupts, but given it's a protracker interrupt that causes the issue it seems to me that the race condition should not occur every frame (because the interrupt will not occur on the same scanline between frames). So that doesn't really make much sense.

It almost looks like some register isn't being properly saved/restored between the interrupts. Which would also be weird as the ptplayer you're referring to stacks all registers.

One thing that might certainly cause issues though, is that the interrupts on A4000's with fast accelerators can sometimes trigger multiple times in a row before the motherboard's slow interrupt acknowledgment gets processed. This would be the case if the interrupt ends too quickly (for instance, it's in fast memory or the cache).

Generally this can be fixed by acknowledging interrupts twice in the code instead of once (both in the PT Player and in the other interrupt code). This works because CPU access to chip memory/custom chips is slow enough to let the acknowledgment propagate before the CPU returns from the exception.

[paraj]

Try to disable int2 and 6 (so PT interrupts won't fire), if that fixes it interrupts are the cause. @roondar has good suggestions, especially "It almost looks like some register isn't being properly saved/restored between the interrupts" -> Look at your own interrupt routines, maybe they assume some registers have specific values (usual culprits being a4 or a6).

[DanScott]

VBR ?

Do you have the value of the VBR? This needs to be passed to the player init

[DanielAllsopp]

Thanks all, I'll go across my code with a fine tooth comb and see if anything pops out at me.

Originally Posted by DanScott

VBR ?

Do you have the value of the VBR? This needs to be passed to the player init

Yeah, I think I'm passing on the correct VBR to the player init. That stuff is all handled by Photon's startup code but I will double check everything.

Thanks for the pointers everyone!

[DanielAllsopp]

So a bit more information:

- The VBR is getting set correctly via Supervisor() if the CPU is != 68000
- As far as I can see, all of the registers are being saved/restored (but I will be going over this again)
- If I install the vertical blank interrupt before I install the PTPlayer interrupt then the player doesn't initialise correctly and no sound is output at all.

I'll check on Gorman and continue my analysis...

[mc6809e]

How much time does your vblank int handler take? Is it being delayed excessively by frequent lvl 6 ints generated by the player?

Have your vblank handler change the background color at the very end if your routine to see just when it competes relative to the rest of the screen.

Instead of vblank ints, maybe you can use the copper to trigger an int at the end of the last displayed line. This will give your handler more time.

[DanielAllsopp]

More thinking out loud and trying anything... am I setting up my vertical blank interrupt correctly?

 
;-----
; install interrupt
move.l VBRPtr,a0
move.l #VerticalBlankInterrupt,INTVECTORL3(a0)
move.w #$c020,INTENA(a6)

VerticalBlankInterrupt:
  movem.l d0/a6,-(sp)
  lea CUSTOM,a6

  btst #5,$1f(a6) ;check if it's our vertb int.
  beq.s .notvb
  *--- do stuff here ---*

  bsr UpdateFrame

  *--- do stuff here ---*
  moveq #$20,d0 ;poll irq bit
  move.w d0,INTREQ(a6)
  move.w d0,INTREQ(a6)
.notvb:
  movem.l (sp)+,d0/a6
rte

[StingRay]

Interrupt setup is OK. Does the "UpdateFrame" routine save/restore all used registers?

[DanielAllsopp]

Originally Posted by StingRay

Interrupt setup is OK. Does the "UpdateFrame" routine save/restore all used registers?

Yeah, I've checked and checked again. It's something to do with the blitter... everything seems to be fine with the sprites, but the blitter is doing weird things

This is what the output looks like on the A4000 (060):



This is the same executable on the A1200 with standard config:

[Galahad/FLT]

Does your blitter code expect $dff000 in A6 just like your level 3 interrupt?

And is your blitter waits before or after your BLTSIZE activation?

[a/b]

Set-up is ok if you preface it with e.g. $7fff to INTENA (disable everything, and btw calling exec's Disable() won't do the job properly). If you only do $c020 to INTENA, you are enabling VBL int3 but also leaving the rest as is (e.g. inherited from system, which has several other interrupts enabled).
I'd also do $0020 to INTREQ (in your case it doesn't matter I guess, but in general you might not want your interrupt to trigger right away because request bit was pre-set).

[mc6809e]

Your interrupt handler looks like it checks for the possibility of another interrupting event. Are there other events that cause an int3 like the blitter? If other int3s are possible, what happens to old vector to handle those ints? You don't save the old vector when installing your own.

[Galahad/FLT]

Originally Posted by a/b

Set-up is ok if you preface it with e.g. $7fff to INTENA (disable everything, and btw calling exec's Disable() won't do the job properly). If you only do $c020 to INTENA, you are enabling VBL int3 but also leaving the rest as is (e.g. inherited from system, which has several other interrupts enabled).
I'd also do $0020 to INTREQ (in your case it doesn't matter I guess, but in general you might not want your interrupt to trigger right away because request bit was pre-set).

He already does $0020 to Intreq with the moveq #$20,d0

[Galahad/FLT]

Originally Posted by a/b

Set-up is ok if you preface it with e.g. $7fff to INTENA (disable everything, and btw calling exec's Disable() won't do the job properly). If you only do $c020 to INTENA, you are enabling VBL int3 but also leaving the rest as is (e.g. inherited from system, which has several other interrupts enabled).
I'd also do $0020 to INTREQ (in your case it doesn't matter I guess, but in general you might not want your interrupt to trigger right away because request bit was pre-set).

He already does the $0020 to INTREQ with that moveq #$20 at the end.

[a/b]

Yep, but not while installing the interrupt handler (that's what I had in mind). If request bit is not cleared, interrupt might trigger right after you hit INTENA (for VBL doesn't matter much, but in general...).

[StingRay]

Originally Posted by DanielAllsopp

Yeah, I've checked and checked again. It's something to do with the blitter... everything seems to be fine with the sprites, but the blitter is doing weird things

Is the blitter setup done correctly, most importantly modulo and mask registers?

[phx]

Originally Posted by DanielAllsopp

when I the ptplayer audio initialised using '_mt_install_cia' and I start playing a mod file, the scrolling completely breaks, and the blitted objects all seem to go haywire.

But the music is playing flawlessly? Did you check the correct player routine is called on a level 6 interrupt?

Sounds like there is something timing-critical in your VERTB-handler which cannot tolerate losing the CPU for the few raster lines the player needs. Also note that the ptplayer interrupts will always be at different frame positions. It is not synchronised with the video in any way.

Originally Posted by DanielAllsopp

- If I install the vertical blank interrupt before I install the PTPlayer interrupt then the player doesn't initialise correctly and no sound is output at all.

This is also very strange. Do level-6 timer interrupts happen at all in this case? Is the player routine called? Who calls _mt_install_cia? Is is called from the level-3 interrupt or from the "main" program? And this also happens only with 060 systems?

Generally the player should work fine with level-3 interrupts and I'm testing with my A3000/060 all the time. All my games are coded in a way that most of the engine is running in a VERTB-interrupt.

[DanielAllsopp]

Sorry guys, I've had the weekend off coding (things like this demotivate me immensely) but will pick up and try and get answers to your questions over the next couple of days. Thanks for all of your suggestions and input, I appreciate the help.

I won't let it defeat me

[DanielAllsopp]

Hi! Hopefully I've got some answers to your questions below, if not I'll try again in the morning. Here's a couple of files anyway:

Intro Executable
Level Executable
Startup Code

Thanks again for any help!

Originally Posted by Galahad/FLT

Does your blitter code expect $dff000 in A6 just like your level 3 interrupt?

And is your blitter waits before or after your BLTSIZE activation?

Yeah, A6 should always contain $dff000. I purposely don't use that register for anything else, but forcing it just to check results in the same issues.

Regarding the blitter waits, I tend to wait before I setup the blitter registers, so well before the BLTSIZH(a6) activation.

My blitter wait code is a macro and looks like this:

WAITBLITTER:macro
	tst.w (a6)			;for compatibility with A1000
.wb\@:	btst #6,2(a6)
	bne.s .wb\@
	endm

Originally Posted by a/b

Set-up is ok if you preface it with e.g. $7fff to INTENA (disable everything, and btw calling exec's Disable() won't do the job properly). If you only do $c020 to INTENA, you are enabling VBL int3 but also leaving the rest as is (e.g. inherited from system, which has several other interrupts enabled).
I'd also do $0020 to INTREQ (in your case it doesn't matter I guess, but in general you might not want your interrupt to trigger right away because request bit was pre-set).

I already have the $7fff to INTENA set in my startup code, so it's done before I do anything else like creating the other interrupts. See my startup.s file above.

Originally Posted by mc6809e

Your interrupt handler looks like it checks for the possibility of another interrupting event. Are there other events that cause an int3 like the blitter? If other int3s are possible, what happens to old vector to handle those ints? You don't save the old vector when installing your own.

I don't think other level 3 interrupts are possible, as I've disabled them in my startup code with $7fff.

Originally Posted by StingRay

Is the blitter setup done correctly, most importantly modulo and mask registers?

That was my first thought, but if that was the case wouldn't the blitter setup be incorrect for standard 020 systems where the issue doesn't occur?

Originally Posted by phx

But the music is playing flawlessly? Did you check the correct player routine is called on a level 6 interrupt?

Yeah, the music plays flawlessly, but I'm not sure how to check the player routine is being called correctly on a level 6 interrupt

Originally Posted by phx

This is also very strange. Do level-6 timer interrupts happen at all in this case? Is the player routine called? Who calls _mt_install_cia? Is is called from the level-3 interrupt or from the "main" program? And this also happens only with 060 systems?

Generally the player should work fine with level-3 interrupts and I'm testing with my A3000/060 all the time. All my games are coded in a way that most of the engine is running in a VERTB-interrupt.

_my_install_cia is installed from the main loop, and not the level 3 interrupt for the VBL. It seems to be only 060 systems, but I can't be sure. I guess I could check with 030 / 040 systems in FS-UAE but I don't have real hardware with those CPUs.

I've tried the very latest version of player too, and called _mt_music from the VBL interrupt with the VBLANK_MUSIC set to 1. Same issue too