ScrollVPort called from VBlank interrupt

[paraj]

Sorry if this is basic stuff, I'm not used to being "system friendly"
I'm working on hopefully optimizing WHDLoad version of TornadoAGA a bit (https://eab.abime.net/showthread.php?t=117092), so this isn't my idea of good code, and also note that ROM is fixed to kick40068.A1200 (i.e. "3.1 A1200/A4000"), so I only care about that version here (though general comments are welcome).

A tester (Aardvark) report two crashes that occur in what I from crash dumps think is the following situation:
- Game is calling LoadRGB32 to update palette
- While that's happening, vblank interrupt occurs and installed interrupt handler calls ScrollVPort (to handle camera shaking, I think)

I assume this is crashing because this kind of update/change is not allowed (doesn't seem unreasonable that OS would not having internal locks to support this operation).

My questions:
- Does above sound reasonable (i.e. likely cause for crash)
- How do I best fix it with minimal effort/without changing how game works too much?

For the last part, game originally updated display by doing:

WaitTOF(..)
LoadRGB32(..)
ChangeVPBitMap(..)

WaitTOF would have made it very unlikely that LoadRGB32/ChangeVPBitMap would have ever interfered with ScrollVPort in interrupt routine, but I guess it's still theoretically unsafe.

I patched out WaitTOF in effort to increase frame rate (maybe I'll-advised, but game really needs all the help it can get), so I would like to avoid it (and if it's not 100% safe, I would like better solution).

Would it be sufficient to wrap LoadRGB32 call in Disable/Enable or is that too terrible, what about ChangeVPBitMap? I guess safe route would be to move ScrollVPort() call from interrupt context, but that would make "shaking" worse that it was when update rate is lower..

[Thomas Richter]

Originally Posted by paraj

- While that's happening, vblank interrupt occurs and installed interrupt handler calls ScrollVPort (to handle camera shaking, I think)

ScrollVPort is not interrupt-callable. Actually, there are only very few Os functions that are. From what I remember, Signal() and PutMsg() are interrupt-calllable, and that is already almost the complete list.

Originally Posted by paraj

- Does above sound reasonable (i.e. likely cause for crash)
- How do I best fix it with minimal effort/without changing how game works too much?

What about sending a signal in the VBLank IRQ (please use a struct Interrupt and hook it into the exec list), and then check in the main program whether the signal has been received? You can still do the ScrollVPort() then if the signal bit is set. WaitTOF() blocks the calling task, this is probably not what you want - by checking the signal, you could do something else (advance the game logic) while the signal is not yet there.

Originally Posted by paraj

Would it be sufficient to wrap LoadRGB32 call in Disable/Enable or is that too terrible, what about ChangeVPBitMap?

No, that doesn't work either. ScrollVPort may or may not run into a semaphore, and blocking an interrupt from ObtainSemaphore() does not work. It surely runs into a semaphore under an RTG system.

[paraj]

Originally Posted by Thomas Richter

ScrollVPort is not interrupt-callable. Actually, there are only very few Os functions that are. From what I remember, Signal() and PutMsg() are interrupt-calllable, and that is already almost the complete list.

Thanks for confirming, "unfortunately" it apparently worked well enough in practice that it's now my problem once I'm changing stuff (I'm sure you know this issue...).

Originally Posted by Thomas Richter

What about sending a signal in the VBLank IRQ (please use a struct Interrupt and hook it into the exec list), and then check in the main program whether the signal has been received? You can still do the ScrollVPort() then if the signal bit is set. WaitTOF() blocks the calling task, this is probably not what you want - by checking the signal, you could do something else (advance the game logic) while the signal is not yet there.

Problem is that original game logic is running at ~5fps but screen shaking would be done at ~50fps.

Originally Posted by Thomas Richter

No, that doesn't work either. ScrollVPort may or may not run into a semaphore, and blocking an interrupt from ObtainSemaphore() does not work. It surely runs into a semaphore under an RTG system.

Since this is whdload slave (always running "soft-kicked" 3.1) AGA game, RTG does no come into play. As long as LoadRGB32 would never break Disable state I guess it would work (dirty as it is..)

[Thomas Richter]

Originally Posted by paraj

Problem is that original game logic is running at ~5fps but screen shaking would be done at ~50fps.

Create another task, send the signal to this task, and call ScrollVPort from this second task.

[paraj]

Originally Posted by Thomas Richter

Create another task, send the signal to this task, and call ScrollVPort from this second task.

Ah, of course, don't know why I didn't think to spin up another "thread" Thanks

[Olaf Barthel]

Originally Posted by Thomas Richter

ScrollVPort is not interrupt-callable. Actually, there are only very few Os functions that are. From what I remember, Signal() and PutMsg() are interrupt-calllable, and that is already almost the complete list.

What about sending a signal in the VBLank IRQ (please use a struct Interrupt and hook it into the exec list), and then check in the main program whether the signal has been received? You can still do the ScrollVPort() then if the signal bit is set. WaitTOF() blocks the calling task, this is probably not what you want - by checking the signal, you could do something else (advance the game logic) while the signal is not yet there.

Back in the Kickstart 1.x days, it was common enough to call LoadRGB4() or SetRGB4() from interrupt code, e.g. for use with images that would use palette cycling. Sadly, this seemed to work so well that it didn't cause crashes or lock-ups almost all the time that developers considered it a dependable approach. Bonus: the palette change was triggered from the vertical blanking interrupt, which means that the change was perfectly smooth.

Commodore had the devil of a time walking back this "feature" and crash-proofing it when called from interrupt state with Kickstart 2.04.

The robust and correct way involves a Task context. If I remember correctly, even the original Deluxe Paint got this right (perhaps after having exhausted all other alternatives first).

[Thomas Richter]

Originally Posted by Olaf Barthel

Back in the Kickstart 1.x days, it was common enough to call LoadRGB4() or SetRGB4() from interrupt code, e.g. for use with images that would use palette cycling. Sadly, this seemed to work so well that it didn't cause crashes or lock-ups almost all the time that developers considered it a dependable approach. Bonus: the palette change was triggered from the vertical blanking interrupt, which means that the change was perfectly smooth.

I remember fighting this function in the graphics.library, and this had several consequences as of today graphics also depends on a semaphore in this regime. What the original code did is to check whether the stack pointer was in the region of the supervisor stack as indicated by exec, and then bypassed the semaphore - which of course did not work with various hacks and tweaks that attempt to relocate the SSP to fast memory. What it's currently doing is checking the status register to find this out. Within P96, I made the decision to simply not support this anymore. If the code is called from supervisor mode, nothing happens. The entire access to VGA registers is too delicate (requiring access to a port and a data register to be written one after another) to allow any direct communication with the chip without proper serializing the access.


IOWs, just don't do that.