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.

Rev 444 and the beginnings of Beta 3

Rev 444 was just regression fixes and a bit of code clean-up from some of my prior commits. Now, I'm on to the major recode for Beta 3. I've changed the way I'm going about it from my prior post here. I've decided instead of working in reverse removing parts of DX64 and working backwards, I will start from scratch, import code as needed, and work forward. This way I can ensure all the code gets looked at and I would've basically been doing this after I finished with the code disassembly.

I've talked with Strmnnrmn about how I plan to do the ME move to get a normally serialized process working asynchronously. Right now in DX64 it goes:
1.Dynarec
2.CPU Execution
3.Graphics
4.Audio (Although in Async this is basically bypassed on the SC.)

Which is basically serialized access to the individual components. To make this a truly multi-processing app. When the move is done it will go:

First Two Frames:
SC                      | ME
1. Dynarec (Frame 1)    |
3. Dynarec (Frame 2)    | 2. CPU Execution (Frame 1)
4.2 Graphics (Frame 1)  | 4.1 CPU Execution (Frame 2)
4.3 Audio (Frame 1)     |

Subsequently: (Frame X = Current Frame, X-1 = Last frame)
SC                      | ME
1. Dynarec (Frame X)    | 0. (Finishing execution of X-1)
2.2 Graphics (Frame X-1)| 2.1 CPU Execution (Frame X)
2.3 Audio (Frame X-1)   |

This will mean at any given time DX64 will be working on two frames at once. I want the Dynarec, CPU Execution and Audio to all individually be able to be moved between the SC and the ME through build flags as needed for debugging purposes. Graphics will always be on the SC as the ME has no GE access. (The only exception there might be some math heavy tasks like clipping, but without a VFPU I think this should stay where it's at.)

What all this means is I will basically be recoding everything from scratch and looking at all of the code for optimization and memory usage as I go. This includes uCodes, graphics, audio, the combiner, RSP emulation, etc... I literally mean every line of code. I got the go ahead from Strmnnrmn to do this, but I'm not going to be committing the changes as I go as not to break the SVN. I will also be looking at the new GUI and preparing for it as well as all the other plans I had listed for Beta 3. Next time I post, I will update my progress on all of this and list any issues I'm running in to.

Rev 435 and upcoming...

Well lately I've been trying to track down why when a specific "bug" happens we get about a 46% increase in speed on Mario 64. In the process of trying to track it down. I noticed a few things that either got reverted in 432 and shouldn't have and 1 more small speed-up I noticed where logic on a function could be improved. The speed-up seems to be fully dynarec related, but will take more time to track down. Next I plan to see what part of the 432 changes caused Paper Mario to start freezing so much. Stability (or consistency ) of games the play is definitely needed before we can proceed to move the CPU to the ME. I added back the reverted code and another speed up or two for 435. I also added an advanced options menu as a secondary menu to the ROM options. These are all the extra items that can be enabled in the roms.ini file. Most of them cause breaks in many titles which is why they are on the advanced options, but you can try them out to see if they help the speed or graphics in other titles besides the ones they are specifically written for. Enjoy


P.S. Sorry this post is late, but the Rev has been posted for a few days.

Rev 424

Well I've just commited and posted Rev 424. Here's the changelog:
[+]Renenable SIMULATE_DOUBLE w/Mario Party hack
[+]Reduce resource usage of Double Display w/o breaking roms
[+]Removed need for extra sceGuSync for FPS Display
[+]Switched from string compare to flags for hacks
[+]Added hack flags to Roms.ini and as menu options Debug mode
[~]Added files the Vis C++ project to reflect Changes in Microcode Structure
[!]Fixed 007 Broken on Rev 423
[+]Reduced extra rendering steps on non-rendered frames with FS enabled
Note: Approx 10% Speed-up, some games that need DoubleDisplay to function correctly have issues under FS (Ex:Automobili only work properly under odd FS)

A total of 16 files were changed. As promised most of the speed we lost between 300 and 423 should be back now and hopefully without side effects. All you GoldenEye fans should note the GoldenEye sky uCode has been disabled until after the release of Napalm's source code or I find a way to fix it myself, but at least it's playable again after Salvy broke it. The speed increases will be more noticable in some games vs others. Next I'll be back to working on the CPU to ME move. Also don't forget to overwrite the roms.ini when you upgrade as new stuff has been added to it for per game hacks.

Headed in the right direction...

Well, I had a voice chat with one of our currently inactive devs who got the ME idea going first(Howard0su). He liked my plan of attack and my general idea to get it going. I also found out using the method he used, he did meet with limited success. I think by going about it using my method, it should end up more stable and work better in the long run which is what I'm aiming for. Tomorrow after I take care of a few things, I'm going to start the disassembly part of my work. I'm hoping this will also give me a better understanding of the code overall as well. I also heard about some new work being done with the ME concerning signaling which hopefully we can benefit from in order to have less overhead.

Restarting DaedalusX64

That's right I'm restarting DaedalusX64 practically from scratch. I've already announced it to the devs and my reasoning behind it.

In preparation to move the CPU(R4300i) to the ME(Media Engine) I noticed we lack encapsulation of CPU. Howard was trying to accomplish it but was unable to finish it. So, due to this I'm going to be semi-restarting DaedalusX64 from scratch in order to encapsulate each component to be handled by a central thread management function. It would be like a PC emulator having separate (CPU w/Dynarec), GPU, SPU, and Input plug-ins and the "main app" only handling the I/O between them instead of the CPU built in to the emulator. In our case the "main app"(AKA the thread handler), the GPU, and input will run on the SP, and the CPU on the ME. The SPU will be able to run asynchronously on either. (So it's portable to where we need it.) By having each item fully encapsulated we should be able to debug CPU/Async Sound issues by bringing it back to the SP with a simple #define flag since they will be fully encapsulated and not dependent on other functions to operate. This will allow DaedalusX64 to be truly multi-threaded.

This is going to take me a while to set up and I will continue working on non-ME related performance and bugs in the mean time, but this is my planned direction for DX64. Also in doing this I will be dropping OSX/Win32(I will restore this later for debugging on the PC)/XBOX support and this will become a PSP only version(temporarily until W32 is restored). However fixes and improvements we make will still be easily portable back to the original project(Strmnnrmn's -N64 branch). As I do this I will be rewriting several parts on this app to ensure that we are getting the most out of it. We've lost some decent speed somewhere along the way. Some titles in interpreter mode have seen over 20% drop in speed. This should also simplify the source code and have our processing going closer to the original N64 in the way it operates. I will also be commenting the source to make it easier for future developers to work on.

My first step is to learn about the ME and it's limitations. I have some ME test code I've been playing with and know some of the limitations of the ME now. Once the ME has been called:

1. CPU speed can't be changed we'll be stuck at 333Mhz (Not a problem)
2. Standby mode will not work. Not sure if this is a limitation of the current PSP SDK libraries or a Hardware limitation. So, no standby mode for us with the CPU on the ME since it will be called with every ROM. This limitation may only be temporary, but I have no clue. If it's permanent sorry to those that like to use standby.

First I will be rebuilding the main app. Now this part will be platform specific and be written for only the PSP to begin with. This means the DaedalusPSP project will still exist and the whole app won't become one project. The DaedalusW32 will be recreated later. This main app's purpose is only to set-up the environment variables, the user interface for ROM/Option Selection, and detection of system capabilities (AKA Phat/Slim/3K). I plan to look at the current GUI bugs at this time as well. Once a ROM is selected and "Start Emulation" is clicked, this is where things will be different. The system will then create the primary thread manager/memory manager first and then create the individual threads for each component as needed on the proper CPU based on code flags. Then the thread manager will act as the I/O interface between the individual parts so they can all be running asynchronously. This is what Howard was trying to accomplish, but I'm not sure it's possible under the current code. Once I have all the different threads running on the SP then I will push the CPU to the ME with the encapsulation already in place at that point I can set-up whether or not to use the ME as a flag so we can still debug CPU/Audio issues by using or not using the ME in Debug Mode as needed.

I also plan to rework the batch test and profiling code to help us further and last but not least add a wolf fence technique to the memory management to prevent leaks. As I work I will be bringing each piece back in slowly in small parts. Grazz will be helping with this and debugging the individual parts as we go to get rid of as many of the current bugs as possible. This is all going to be done on a private SVN for the time being with small fixes being back ported to the current code for testing. This process will overall take several months. Afterward, we will be posting the Beta 3 Preview in the Testers Section for final debugging. Then it will be finalized, committed and published as Beta 3.

The end result as compared to current Revs...
In Release Mode DX64 should be much faster and more stable. However the Debug version may be slightly slower when ME CPU processing is off than currently. This will be due to the thread manager overhead.

This is what's currently happening and my current plans. 99% of my other work on the project has been put on hold, but I think this is definitely worth while to pursue.