sp193
commented
7 years ago I am having this feeling that the GS HSINT interrupt is working as it was supposed to be, but the GS documentation just didn't clearly document how to clear the interrupt condition on the GS. Perhaps it is a technical oversight because the chapter on "signal" seems to have been marked as a new addition (there's the vertical line along most of it, which indicates new changes).
Personally, I didn't get the GS interrupt to continuously assert if I re-enabled HSINT within IMR again after invoking EnableIntc. It doesn't make sense to me anyway.
If you examined the documentation for the SIGNAL cause, it states that "The interrupt state is cleared when the SIGNAL flag of the CSR register is cleared". The documentation for when 1 is written to the the SIGNAL bit within CSR is also unusual, compared to the other bits: "Old event is cleared and event is enabled".
According to this clause within the chapter titled "Outline on Signal Processing" that states "The GS can generate a signal (an interrupt) to the host", it is possible that the title of the chapter "signal" actually refers interrupt processing. After all, the signal event is only one of the three possible signal events (and one out of the five documented GS interrupt causes).
With DSEDB, I didn't get the GS interrupt going again by one write to GS IMR that enabled HSINT. I also needed to write to the SIGNAL (1) and HSYNC (4) bits within the CSR, within the GS interrupt handler. If this isn't done, then the interrupt isn't observed occurring again (according to the EE I_STAT register). I have tried making a single write to CSR by writing a 5 to it, and it works the same as writing a 1 before a 4. Writing only either a 1 or 4 to CSR does not work.
It also states that if the SIGNAL interrupt occurs again before the interrupt condition is cleared, then writing to the SIGNAL bit within the CSR will not clear the interrupt state. Instead, the SIGNAL event must be masked and unmasked with IMR, before that event will continue working. And indeed, we're probably also doing this (hence your additional call to GsPutIMR after EnableIntc), but for HSINT instead. I've tested that only HSINT must be re-unmasked for things to work.
This may be why SONY's libgraph actually masks all interrupts (0xFF00 is written to IMR) before the GS is reset. If that is so, then perhaps we should do the same for gsKit, and only unmask HSINT/VSINT when required (after EnableIntc). IMR is write-only, but we can use GsGetIMR to avoid masking/unmasking other events. The developer will have to clear the SIGNAL event and to re-enable the HSync event within the CSR from the interrupt handler as well.
rickgaiser
Jay-Jay-OPL
After the first OPL test builds multiple users have reported the screen positioning for 720p and 1080i is off by a lot. So in this pull-request I am again requesting to change the screen positioning for these two modes.
Also in this pull-request: