Tuesday, June 30, 2009
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.
Monday, June 29, 2009
Day 2
Well as far as I can tell I've removed all non-PSP related code. Including endian and W32 related stuff. Next is the disassembly of the individual parts. First the Sound, then Graphics, finally Controls/SaveTypes. Then I'm going to debug a few nagging menu issues(Namely the alphabetization issues). Afterward, I'll begin the process of writing the new thread management code for Daedalus. Then after that is done and I have the ability to run the CPU on either the ME or SP, I will bring back the Controls/SaveTypes first(And work to get as many games as possible booting while the CPU is on the ME or SP). Next will be graphics then I can begin running performance numbers(after writing my new profiling code to better work with the new system). I hope to be at this point in a few weeks to a month, but it might be longer. I have a few things coming up next month and one in particular that will take me away from DX64 for a week. On top of that as I bring each section back in I'll be looking at the bugs in each and doing what I can to clean up, comment, and optimize the code, so in the end this part may take a while, but I'll keep you informed here.
Sunday, June 28, 2009
Getting Started
Today I decied to get started on the tear down and rebuild of this project. The first thing I did was remove all traces of XBOX and OSX support. Next will be Big Endian support the DAEDALUS_xxx platform and then I will back up the project at that point before I removed the W32 support. Why? Just to make it easier to reimplement it once I'm done with all my work recoding specifically for the PSP. I still want to support windows for debugging, but not until I'm finished on the PSP side. In this next stage all Defines will be looked at. When I'm done the code will be pure PSP homebrew. Then I will start taking apart and separating out each piece in order to rebuild it from the ground up. It's easier to get it working with one part at time then to try to do it all at once. It is a slow but very methodical route I'm taking so that each piece gets looked at worked on and improved in the process. I personally know nothing about programming for the XBOX, OSX, or Strmnnrmn's unnamed system, but W32 and the PSP I can handle. I'm only working with the PSP part first as this will be the primary platform with the others as more of an afterthought to give devs/users more options to work with down the road. Will this possibly be put on platforms other than W32 and the PSP in the future... maybe but I'm not the one that's going to do it. Well it's back to the code for me now.
Friday, June 26, 2009
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.
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.
Subscribe to:
Posts (Atom)
