Disk swapping issues
Posted: Fri Jan 09, 2015 11:25 am
There are several reasons why it's difficult to swap discs in some games. The root cause itself is when a game sits in a tight loop waiting for input, be it a key or a disc change. Blowpipe, Chuck Rock and Xenon 2 all sit in loops of less than a dozen instructions; Blowpipe and Xenon 2 continually try to open a file and Chuck Rock continually checks for SPACE.
This has several side effects:
1. The Abort handler that corrects self modifying code is very likely to be entered tens of thousands of times a second if the code is writing into pages that contain code. IRQ's are off whilst the Abort handler is proxying the write
2. Any SWI's will turn off IRQ's, so the ratio of IRQ's being off to on rises. ie IRQ's are disabled more than they're enabled
3. The blitter is taking up most of the CPU cycles
(1) and (2) we can't do much about. Enabling IRQ's during the blit will however give a good chuck of CPU time back to allow IRQ's to be generated. To date, IRQ's have been off during the blit as its triggered by GraphicsV 1. I've found that enabling IRQ's whilst in GraphicsV 1 for any extended period of time seems to cause IRQ stack corruption, so they have to remain off whilst in GraphicsV code.
Investigating why the IRQ stack was being corrupt led me to the RTSupport module as being the culprit. Having then read the API documentation it seems like this module may be the perfect solution to the blitter IRQ problem.
Essentially what RTSupport brings to the table is pre-emptive multitasking, which it provides by hanging off the IRQ vector. This has some obvious issues in that code is called at random, however...for our purposes, it's an ideal location to put the blitter when we're generating our own 50Hz VSync, as the trigger for the 50Hz comes from TickerV which is IRQ driven. Rather conveniently RTSupport also allows code to be called at centisecond intervals.
For the next release of ADFFS, I've modified the GraphicsV 1 / Frame Pacing code and moved the blitter to a thread under RTSupport. This seems to have resolved the issue of swapping discs, however it now instantly locks the machine when a disc swap happens. I'm currently investigating why and hope it's resolvable, I also need to confirm that the IRQ stack corruption issue is resolved by moving the blitter out of GraphicsV.
This has several side effects:
1. The Abort handler that corrects self modifying code is very likely to be entered tens of thousands of times a second if the code is writing into pages that contain code. IRQ's are off whilst the Abort handler is proxying the write
2. Any SWI's will turn off IRQ's, so the ratio of IRQ's being off to on rises. ie IRQ's are disabled more than they're enabled
3. The blitter is taking up most of the CPU cycles
(1) and (2) we can't do much about. Enabling IRQ's during the blit will however give a good chuck of CPU time back to allow IRQ's to be generated. To date, IRQ's have been off during the blit as its triggered by GraphicsV 1. I've found that enabling IRQ's whilst in GraphicsV 1 for any extended period of time seems to cause IRQ stack corruption, so they have to remain off whilst in GraphicsV code.
Investigating why the IRQ stack was being corrupt led me to the RTSupport module as being the culprit. Having then read the API documentation it seems like this module may be the perfect solution to the blitter IRQ problem.
Essentially what RTSupport brings to the table is pre-emptive multitasking, which it provides by hanging off the IRQ vector. This has some obvious issues in that code is called at random, however...for our purposes, it's an ideal location to put the blitter when we're generating our own 50Hz VSync, as the trigger for the 50Hz comes from TickerV which is IRQ driven. Rather conveniently RTSupport also allows code to be called at centisecond intervals.
For the next release of ADFFS, I've modified the GraphicsV 1 / Frame Pacing code and moved the blitter to a thread under RTSupport. This seems to have resolved the issue of swapping discs, however it now instantly locks the machine when a disc swap happens. I'm currently investigating why and hope it's resolvable, I also need to confirm that the IRQ stack corruption issue is resolved by moving the blitter out of GraphicsV.