OS_Byte 19 issues
Jeffrey Lee (213) 6048 posts |
OS_Byte 19 has been causing me a few issues recently, and I can’t quite decide on the best way of solving it. The problem I’m seeing is as follows:
So the problem in a nutshell is that OS_Byte 19 doesn’t have a way of dealing with situations where VSync IRQs are temporarily unavailable – whether due to something like SYNCLOST handling on OMAP, or even something like the fact that VSyncs will almost certainly temporarily stop during a mode change. Possible solutions I can think of include:
Looking at the above options, I’m leaning towards option 3. Anyone have any other preferences? |
David Feugey (2125) 2709 posts |
2 be 3 |
Jon Abbott (1421) 2652 posts |
Option 2 – it fits in with the GraphicsV design and future proofs multiple displays. ADFFS uses 2 to achieve 50fps so if you do go with that option, we’d need to confirm ADFFS doesn’t break it when it suppresses the non-50Hz VSyncs that it’s internal frame pacing code is generating. From your code perspective, if ADFFS’ blitter was running (ie you’re playing a game) when you issue GraphicsV 1, it will immediately return essentially NOPing the call, so I think that would work for you as it sounds like it’s the VSync wait actually occurring that’s causing the issue. I don’t have an OMAP machine to test this unfortunately, I don’t even know if ADFFS works on OMAP, I think it failed when you tried it last, so this may be academic. Things have moved on in the upcoming beta release, so it does need testing at some stage. Happy to assist where I can with RiscPC/Iyonix/Pi/Pi2 ROM testing to ensure there’s no knock on effect for gaming. |
David Feugey (2125) 2709 posts |
Completely agree on this point…
Just need to test :) |
Jeffrey Lee (213) 6048 posts |
Note that option 3 doesn’t prevent multiple displays from being used. It’s just slightly harder to use if you want to wait for a certain display. The wait loop in OS_Byte 19 is actually a good place we could allow callbacks to be triggered (if it’s safe to do so, i.e. SVC stack was empty on entry). Moving the wait loop into the drivers would prevent us from doing that (not that I have any intention to make such a change at the moment – but it might be nice for the future). There’s also an option 5, which I forgot to list, which is to add a timeout to OS_Byte 19. But that’s a pretty horrible solution, so I doubt we’d want to go with that.
There shouldn’t be any knock-on effects, other than a reduced chance of stuff hanging. Looking at the code, I think it’s even possible for OS_Byte 19 to hang if the screen blanker activates – the kernel only checks if the screen is blanked at the start of the wait loop. So if it starts to wait for VSync and then the screen blanker module blanks the screen (which is done from TickerV, not from a VSync IRQ) then the loop may only terminate once the screen is turned back on again. |
Jon Abbott (1421) 2652 posts |
In my ignorance, I thought that was already occurring. So besides OS_Byte utilizing WFI it sounds like OS_Byte 19 is stalling everything, not just the app that’s issued the SWI? Perhaps OS_Byte 19 should be threaded so it can hand control to Callbacks and have the Callback handler pass back to all apps waiting on OS_Byte 19 when the IRQ occurs.
That would explain the random hang I see when the screensaver kicks with games running. |