Hi
@nitr8! Any chance for a release as a christmas gift, or will we have to patiently wait for 2020? Anyway, great work! Can't wait to replay all Doom chapters and the newest Sigil with my WUPro Controller
I was used to release new binaries (DOL's) and i was definitely working on something new at the start of December last year.
Then i came across a really weird bug which is actually coming from libOGC and causes either a Decrementer Exception or Interrupt Exception - both which are related to Decrementer Handling by libOGC.
Background:
Porting libOGC to the RVL-SDK is nothing hard at all. It basically is a reverse-engineered SDK which has been working on, since back in the Gamecube days. It basically depends on NEWLIB (libC, libGLOSS, libM etc...) but it also depends on libGCC (runtime) which provides a function ("__udivdi3") for calculation of the time support routines and this also means that it effects the Decrementer.
The RVL-SDK which provides it's own runtime library, doesn't have stuff like "__udivdi3". Instead, it uses the function called "__divdi2" and therefore may calculate "wrong" timer settings. This was my first thought, back over a year when i first came across this ridiculous behaviour - BUT I WAS WRONG.
When i came back to work on those ports, starting in December, i ran into this problem again. I was at testing state and suddenly DOOM crashed with libOGC's "Decrementer Exception" screen and remembered very quickly what was going on.
So what i tried, was writing only a very simple printout (printf) program that shows me some variables from the "__lwp_wd_settimer" function and the result was kinda frustrating...:
With this knowledge, i tried other things, which included modifying libOGC to load the MetroTRK debugger and then compiling the very same simple printout program under MWCC (RVL-SDK C-Compiler) and POWERPC-EABI-GCC whilst starting the debugging unter CodeWarrior.
BOTH ELF's crash at the very same point with the very same exception even before they reach the MAIN() function and they BOTH give the same exception through the debugger: DECREMENTER.
I have no idea what is going on but from what i have read about PowerPC and the Decrementer yet, it seems to me, the Decrementer (which is always counting down) is getting wrong values from the time calculation in BOTH situations (MWCC & GCC) which means, that the libOGC code definitely has bug - even within it's official release.
Anyway.. I wasn't lazy the last few weeks. I completely decompiled 4 libraries in order to get the debugger to run under GCC (which was useless because it simply compiles the required MWCC libraries using GCC without any problem). Those were the UART library, the TRK library, the library containing OSReport and the NDEV debugger driver library.
The main goal which currently must be achieved is either: DISABLE the decrementer interrupt or FIX the bug or feed the decrementer with some values BEFORE it counts to ZERO. In the first case, the decrementer would STILL cound below "ZERO" (which it shouldn't). If the Decrementer reaches ZERO, it sends an exception notification out which then is being caught by the Processor if it executes it's current instruction to the end. Then it gives the final exception that you would see on the screen.
In the second case it would required much more work than i want to do as it's hard for me to understand all that stuff libOGC does in it's time calculation routines. It seems to me as if there is no Decrementer callback included within libOGC or is it???
The third case would require checking the decrementer for it's current value against ZERO and IF IT IS within a range that would cause the next decrement to cause an exception, raise the decrementer value to something above the one which would fall at or below ZERO. This would also require to write some code and implement it into some LOOP which is being run through all the time while libOGC is running during your gameplay.
I think, i'm - at the moment - out of luck. This is even worse than what i thought of. As long as this isn't fixed, i'm not willing to release anything new as this would also frustrate all of you, playing my ports - and i want to do some good stuff. No worse and buggy sh*t...
Anyway... the decrementer crash (if exception-checking is activated for the decrementer vector value 0x0900), happens in BOTH cases (MWCC & GCC) at the very same state: inside libOGC's function "idle_func()" at reading the WHILE loop. This is even BEFORE we reach our main thread "MAIN()".
