Actually, it's okay to post here about development questions. Discussion promotes discovery. Even what may seem to be a non-relevant post may help me or someone else down the road. I will delete or move off-topic posts at my discretion however.

So, is your current priority :

1) fixing of the async bug and
2) getting rid of the unnecessary work when sound is disabled ?

Yup. I can fix the Async bug already, but I'm working on a bit of a hybrid method so that Sync/Async work identical and can be used in all titles that currently support sound. (Async will still be faster, just no Async Bug and Sync will work with titles like Turok.)

Awesome as always. BTW, now that Hackerslim is back, is our animated eboot with sound in consideration of being implemented? If not thats ok too. 2nd btw, how easy/hard is it for you to implement multi language support?

Keep up the good work!

Well multi-language support is easy/difficult depending on the languages to be supported (some are multi-byte and have more the 256 total characters).

The PC version has multi-language support and I could implement it to DX64, but not sure it supports multi-byte characters. I'll have to do a bit of research on this and see what I can do.

KK. Though my C/C++ skills sucks and are quite hard to improve, I can still translate English to Norwegian perfectly.
Are ÆØÅ multibyte characters?

I hope you can get the Async bug fixed asap and release a rev. That is MY hopes.

can you do a plan work like do in daedalux64 on ps3 ??

All this request for DaedalusX64 on other consoles. Please guys, one little turd-let at a time.

im sorry for my bad english,i meant say plan work daedalux64 for psp,pc and ps3, en el tema de -daedalusx64 on ps3- kreationz habia mostrado su plan de trabajo de los proximos meses,eso es lo que me gustaria ver de nuevo ^^.

kreationz:
Yes, the dynarec would need to be rewritten. I personally plan to work on a PS3 port. However, I want want to:
A)Finish my merge work (about 230 Revs to go)
B)Take care of the "Async Bug" (for a nice speed-up)
C)Move the CPU to the ME (Another nice speed-up)
D)Fix Stability issues (I'm working with buggy code for the merge, but is needed for Daedalus to be multi-platform)
E)Bring the PC version up to speed (Add full plug-in and SaveState support)

This means that there is several months of work for me to do (A=2-3 weeks, B=at least a few days, C=??? but likely a couple weeks, D+E=like another month or two). Overall at least 3-4 months. I wouldn't expect any progress on the PS3 until about April or later. Unless another dev comes along that want to work on it.

on update of your plan code work kreationz? ^^ with all respect.

kreation perdona si es molesta mi pregunta pero admiro mucho tu trabajo y de todo el equipo.

3/12/11 - @All - My plans haven't changed, only timeframes have which keeping slipping by as time always does. Life in general and especially work have brought my time for DX64 down to pretty much zero for the next few days at least. (Should be back to code and the following around Wednesday.)
I have finished my merge work up to Rev 638 (last rev prior to B3's release). I just haven't committed it yet as I want to go over a few pieces of it. After that I want to bring it up to B3 publicly. I will be merging changes in the Dev branch since then to prevent future conflict issues porivately. That will be committed as the code goes public. This will allow me to work with Dev branch level code while I work on the Async, ME move, DKR, etc... related items and commit them to the dev branch as they are finished.

In the past week I have done some testing, and have also provided a second source of info to the other devs on the T1 issue(I'm not working on it but got info from another PSP dev). We have now one or two possible solutions for this, but it's up to the other devs who takes on the task. I have too much planned for myself already in order to think about it right now.

3/14/11 - Life Update: Work has slowed down a bit... busy today with only a little time but should have more time tomorrow. So I'll be back to code a day earlier than expected
Code Update: Today, I'm going to make sure my -N64 merge still compiles through 636 and then see if I can't throw a quick audio fix for the PC branch in. I'll finish it, test, and commit it tomorrow. After that, I'll update my SDK and the changes through B3 should be fairly straight forward. Once I get though B3, I'll post a release for the PC side of things consisting of Daedalus(using B3 code)+R91 1964Video/Rice (Most recent Binary release). Then it will be on to everything described in my last post.

3/18/11 - Yesterday, I managed to get the merge through R638 (last one prior to B3) committed to the -N64 side, but with bugs. Today, I'll be working on the bugs. The audio bug has to do with OSHLE calling the PSP Audio plugin code that was added after the 432 time frame.(Thx Salvy ). It's not a major issue. For the time being until I have a proper fix, I will disable the part causing the issue on the PC build. The other two (SS and the Plugin Asserts) should be fairly straight forward to fix.

Update: Apparently OSHLE wasn't the entire problem and it may be related to the SaveState(which is due to the abstraction of hardware from the CPU in prep for the move) issue as well. I have already added code to allow OSHLE to be turned on/off with a ROM reload. On that note, the reason OSHLE can only be turned on/off with a reload is because it actually patches the fragments (the code you get when the dynarec is done recompiling it) and there is no way to unpatch them afterward.

3/19/11 - Current the Audio is being reported as disabled. ProcessAList(process the audio list) is being called and the plugin is reporting enabled properly(gAudioPluginEnabled = True) , but even forcing it to "Enabled" there is still no sound. This means it's not a core issue but in the way the audio processing was changed. I'll have to move on to the next step in the process to see where it's being incompatible with the PC. I've also decided before a public release to work some on the Debug console on the PC side of things. As it stands closing the console closes the emulator, turning it off via the options causes a crash. Neither of these should be the case for a public release. The debug console itself should be part of the Advanced/Debug options and be able to be turned on/off at will.