is the music in Double Dash even effected by this patch?
I don't know if you are still around or not neXus, but do you have any idea at all how to fix the music looping issue with the AFC looping hack? It seems that other games besides Zelda Twilight Princess use AFC to loop music such as Super Mario Galaxy 2, with the current hack AFC music stops dead after a few minutes and doesn't loop.
It seems neXus either isn't around, or he is busy. I was hoping that I could provide him with necessary information so he could hopefully fix AFC looping. Several times I've gotten close, but never solved the problem, with the help of a coder I'm sure this issue can be nailed fairly quickly.
I wasn't in town last week. Besides, I read in forums very often so feel free to post any suggestions.
Though, I don't have any clue how to solve the looping problem. At least I know how to test if the problem still exists ^^
(07-28-2010, 06:13 AM)neXus Wrote: [ -> ]I wasn't in town last week. Besides, I read in forums very often so feel free to post any suggestions.
Though, I don't have any clue how to solve the looping problem. At least I know how to test if the problem still exists ^^
Nexus, i'm doing reverse engineering to the code, some lines of afc have not been implemented, but i need some help with accumulators. Could you give me a little hand with them?
(07-28-2010, 06:13 AM)neXus Wrote: [ -> ]I wasn't in town last week. Besides, I read in forums very often so feel free to post any suggestions.
Though, I don't have any clue how to solve the looping problem. At least I know how to test if the problem still exists ^^
Nice to see you around again, my apologies if I seemed rude in any way. I tried pm'ing ector for ideas but so far he hasn't responded.
I found out Super Mario Galaxy 2 uses AFC to loop music which of course doesn't work correctly yet, the first game might also use AFC to loop music but I'm not sure since I haven't tested the first game yet to determine if this is the issue, developers keep insisting that it uses the PCM16 format to loop music. I'm not saying they aren't correct, PCM16 might be used for some sounds and music while AFC handles the music and looping..
I've been playing around with your v3 patch, but with limited success. Music lasts longer in Super Mario Galaxy 2 but eventually stops looping. I was also able to get some AFC music in ZTP to last twice and thrice as long at the expense of that instrument/environment echoing issue in Windwaker resurfacing with my edits. It seems that at a certain point in the code AFC audio just halts, and I haven't been able to figure out why.
I was doing a bit of reading on the Googlecode regarding the Zelda Ucode, DSP_LLE and found some stuff that may be of interest:
Quote:
Theories, things to reverse engineer, and ways to do it¶
- Registers 8-11 - If you look into the documentation of other Macronix DSPs, they all have automatically looped indexing, that is, there's a base register, an index register, and a range register, specifying where the loop ends. When the index register is incremented past the range register, it gets reset to the base register automatically in hardware. I have a theory that R8-R11 have this job on the GC/Wii DSP. Needs to be tested.
- CLR15/SET15 - could these be the same as SET16/SET40 but for the "X-tra" 32-bit accumulators (so we'd call them SETX16/SETX32). This needs to be tested, and also whether or not SET16/SET40 have an effect on the extra accumulators.
- We should figure out whether it is possible that the Zelda illegal writes are because a loop relies on an exception happening when it starts writing to illegal memory... or is this the looped indexing?
- We can make our DSPCore library run on the Wii. This would have several advantages:
o We could expose the interface as a HTML form and let the user just type assembly into a box, and it would then run continuously on the Wii.
o We could also do things like running an emulated DSP in parallell with the real one, the exact same test DSP program on both (we do trust the small subset of instructions that is used to do the testing). Then we'll compare the results. This method could try massive numbers of input combinations really, really quickly. For example, it could be used to build large tables of M1 and M2 results after multiplications.
o TODO: Test if loading flags into SR with MRR is possible. Would be useful for figuring out 0xa100, if, as I believe, it really does some sort of conditional arithmetic.
- DSPSpy needs a lot of features:
o Tweak input registers on the fly
o Reset the whole thing so that the number of saved "frames" doesn't just keep growing indefinitely.
o Keyboard support, integrate the DSP assembler and disassembler.
- To test for exceptions in DSPSpy, we should do something like LRI r00, 2 in IRQ2 handler, and so on (or some other scratch register than r00). We should make the handlers as trivially short as possible otherwise (just RFI). This lets us see what exceptions gets called.
http://code.google.com/p/dolphin-emu/wiki/LLEInformationAndIdeas
Perhaps some of this can be applied to HLE as well?
(07-28-2010, 06:17 AM)Torin Wrote: [ -> ] (07-28-2010, 06:13 AM)neXus Wrote: [ -> ]I wasn't in town last week. Besides, I read in forums very often so feel free to post any suggestions.
Though, I don't have any clue how to solve the looping problem. At least I know how to test if the problem still exists ^^
Nexus, i'm doing reverse engineering to the code, some lines of afc have not been implemented, but i need some help with accumulators. Could you give me a little hand with them?
AFC needs a lot of work, the hack was a temporary solution, not sure if the developers didn't know how to implement proper AFC looping or just didn't feel like it at the time.
The hack would be sufficient if it were properly done and looped the music without stopping, it should be figured out what code for the AFC looping hack is causing problems and then go from there. It need more involved debugging that what us non-coders are able to to accomplish.
Good spot, Xtreme2damax. If what you have bolded is the cause, there is a tiny chance that my Rogue Leader patch will fix it. I have implemented memory exceptions correctly in the patch. I will be committing it in the next few days, provided that it passes testing with no problems. Fingers crossed.
We can only hope, I'd really give anything to see the music issue tackled but I have a feeling it may be the plugin/hack itself that isn't correctly looping the music. I've noticed that every time the music stops at the end of the soundtrack, when the music fades out and starts looping again. Something is not correctly resetting the loop or something and it just fades into silence. The weird thing is that it loops a few times and then goes silent, unsure of what could be causing that and I have no clue how to do advanced debugging to spot the issue in the code.
Hi everybody,
yesterday I did some testing of the SMG looping problem. I deactivated everything except of the PB.Format == 0x0010 (which calls RenderVoice_PCM16). So as expected the music stops after a certain time. So influences by other music or sound effects can be excluded.
Furthermore, I checked the variables and their content and didn't see any clues why the music breaks (sometimes it works, as I mentioned but I couldn't see any difference).
So, still I don't have any idea. So let's hope, mylek4 can solve all of our problems
greets,
neXus
Some debugging needs to be done and breakpoints need to be set to find out what line of code or code in general is causing the issue. I'd recommend to start debugging the Ucode_Zelda_Voice.cpp and then go from there. With a bit of debugging it should narrow down the problematic code, once that is identified the challenge will be implementing a better solution.
I was going to try debugging, but after speaking with skid I decided it's way above my head to attempt.
