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.