10 March 2024, 18:47 | #1 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,316
|
ScrollVPort called from VBlank interrupt
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: Code:
WaitTOF(..) LoadRGB32(..) ChangeVPBitMap(..) 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.. |
10 March 2024, 19:06 | #2 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,501
|
Quote:
Quote:
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. |
||
10 March 2024, 19:37 | #3 | ||
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,316
|
Quote:
Quote:
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..) |
||
10 March 2024, 21:34 | #4 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,501
|
|
11 March 2024, 07:46 | #5 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,316
|
|
11 March 2024, 08:14 | #6 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 548
|
Quote:
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). |
|
11 March 2024, 08:35 | #7 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,501
|
Quote:
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. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
VBLANK wait in C | 8bitsten | Coders. Language | 6 | 02 March 2023 12:05 |
Blitter interrupt during VERTB interrupt | phx | Coders. Asm / Hardware | 38 | 01 October 2021 19:54 |
ScrollVPort double buffer problem with garbage pixels | balrogsoft | Coders. General | 5 | 29 May 2014 12:31 |
RTG and chipset vblank rate | Mad-Matt | support.WinUAE | 8 | 26 July 2011 12:16 |
CIA timer interrupt handler called twice during mod playback | absence | Coders. General | 5 | 16 March 2009 18:55 |
|
|