Update on the Async bug

Well, I've been really busy with life lately, but I recently had some time to get back to code. I've managed to make some progress on the Async bug and what seems to be getting skip are the Audio Interface Interrupts(AII). I can in a hacky way force this not to be skipped in Async mode or in Disabled. For Async, this means the Async bug never activates and this means we don't lose sound (I tested this in SM64 and SSB on the intro). For Disabled, this means games like Turok can boot completely without sound. Also when working with Turok, I discovered that the audio interrupt has to occur at the beginning of the frame rather than the end of it. I believe this is the proper for it to be done in order to reduce some of the popping as well. I be experimenting further with this tonight so that Sync, and Async are both using the same method. Upon a scene change (like when entering a level in SM64), the missing audio interrupt with the bug active is what causes it to freeze due to not updating the registers properly. It's creating a busy wait situation when it's not actually busy and getting stuck in a loop. I believe that all of this should yield multiple benefits in the form of better sound(with fewer delays in between sound processing cycles), faster speed (by only processing the AII we have to), and better compatibility (with more modes working with more titles and without the sound dropping).

Still busy with life, but...

    Life is still keeping me busy, but I have had time to do some testing related to the Async bug. From what I can tell it's a semaphore issue causing a race condition which is why there is the intermittent nature of the bug. Generally speaking because DX64 runs at less than 100% speed we just get choppy sound on sync but every now and again we do get burst of over 100%. Using the ME for sound the bursts of speed happening more often(even more often with frame skip.) Whenever the ME is busy and the rest of the emu completely finishes it job and then tries to give the ME more work to do it usually gets added to the back of the line and continues about it's business. Sometimes however, the line is full and there is no more room and the proper signal isn't being sent back to the CPU emulation that it can receive more data, this causes the CPU to not only stop not sending audio data, but also to completely skip other audio related checks as we (DAC Rate changed, etc..) Assuming this is correct, I'm working to force the situation then I'll know for sure. It's the bypassing of the audio interrupt checks and the processing done during those interrupts is where we get our speed boost from the bug from.

    Now the big question. Can we use this to our advantage? Yes, no and sometimes. If sound is off and we process the bare minimal checks to prevent lock-ups then, yes. If sound is on and we have to process all the checks then, no not without lock-ups. However, if the sound on and we don't need all the checks for the audio or don't need to check as often then, maybe. Now those are all big if's, but we may see an advantage without sound. I'm currently working on narrowing down first what is bypassed in the CPU (I already know part of it but it doesn't explain the amount of speed we are getting or the lock-ups.) Then seeing what if any of it we can do without or modify for our own purposes through code. (It wouldn't be true emulation, but HLE isn't true emulation to begin with.)

P.S. If this can provide a boost then it would function even after the CPU move. The only question is can it? and can it with audio?

Lack of recent progress and current news

    People have been asking for an update, so I thought I'd let everyone know what's going on. The past month and a half has been very busy for me. I'm now in college and working full time. I work 7 days a week 12 hours a day for up to two months straight then I get a week or two off. I was unemployed most of last year, so now I have a lot less time on my hands for code. My job does afford me some downtime most of which goes toward school. I'm currently pursuing a Associates of Applied Science in Computer Programming. I'm also looking at getting several IT certifications along the way to help keep my options open when I can finally make a career change. I do still have a decent amount of left over time most of which has been spent working on the forums and dealing with staff issues. The main changes I had planned there are done. (I got a staff hierarchy set up in order to reduce issues there and integrated the compatibility list with the site.)


    On the code side of things I've done some minor code clean-ups and I'm currently working on a few regressions. Along the way I've learned to better debug crashes which is a good thing. I also made my first attempt at moving code to the ME. I tried to move the "JPEG_Task" to the ME but this didn't go so well. So far it gets about half way through the code for it and crashes. Crashes on the ME are hard to debug, but this will be good practice for the CPU move. I've also started a full port of 1964Video(Rice 6.3.0r35) from the 1964 SVN which should kill 90% of the graphical errors and a few crashes from within the graphics plug-in. It will also increase the overall compatibility of the emulator as well. This will all take a while. The JPEG_Task isn't planned to be move and I'm only doing this as it much simpler than the CPU_Task and a good case for learning. As I stated I'm working on the regressions I introduced in Rev 432, this should only take a few days. Then I'll be back to debugging my JPEG related code and porting Rice.


    On a side note, both school and work are going well. Salvy has been adding a few bits of code related to uCodes and the blender lately and one of our forum members (Yamagushi)  has implemented a new GUI on Rev 463. I still have further plans for the GUI but his changes are a good starting point for my plans.