It's because the different regions of the game have differing memory offsets. They all have (mostly) the same instructions, just in different memory sections, so the only thing to do is search for the same instructions as the JP DW3 in the other versions. You can use no$psx to do this.
The adress I uploaded is the one that DW2003 has the same instructions in, and the one
@mrjaredbeta uploaded does the same, but for the NTSC-U release.
The reason you had lag and other issues with the Parasite Eve 2 adress is because that one hit a specific instruction lots of times, flushing caché for every time it was called upon. The times it crashed was because the adress wasn't even used when loading new data.
The DW2003 adress must be hit much less often, and used in loading, thus working fine.
Seeing that the DW2003 config and the DW3 config both worked for the game shows that there's tolerance in a difference between adresses of at least 0x3F0.
That means that specific address in PS1’s virtual memory is hit, and then the emulator does a cache clear (and event test in this case). I think it is really lucky that this works! Probably is not the best address to use, but if it works, it works.
@Webardo Very good description, I couldn’t have said it any better. The only thing is there is not necessarily a tolerance per se, but the game probably just hits that instruction in the function elsewhere. If the address was even +4 bytes, the game might not hit it as it would be in the game’s next function. So it really depends on where it hits. You can always breakpoint the offset in no$psx and see if it is hit, I am guessing it does so for Bugs Bunny.
Ah yes, I think I know the method
, in this case I used BizHawk or Cheat Engine, I was mistaken thinking that the memory addresses were already easily described in the internal list haha, I'm an innocent boy haha
Thank you for your detailed explanation <3
===========================================
Guess you reverse-jinxed it? That one adress gets hit
only once when loading a new scenario. I'm astonished at this.
Thanks
@The_Ho, you found a pretty clean fix!
It'd be amazing if he had it working with FMVs, but the most likely answer is that he has a modified game file. Check
this out.
Firstly I would like to thank you because you and
@mrjaredbeta saved me the adventure of reducing yet another huge amount of bits, which I was about to give up on.
I'll report in detail and I think we can find a solution for Destruction Derby or Star Wars with the same method, but it was quite boring for me to do this, it took about 3 hours or more.
I remembered that I once tested BB LiT with SLPS02480 and the game started with good speed but it crashed at several points or had severe slowdowns when the effects appeared on the screen.
When comparing with
@Webardo's CONFIg Cruzada I saw that there weren't many similarities as to why the game works with SLPS02480 and the first thing that came to mind was the memory address 0x11, so I left all the other commands aside and just applied 0x11 and yes it was him.
However, it worked very poorly, so I saw that 0x11 of the European PE2, despite being slower, was still stable, without crashes.
It was then that my suffering began, I decided to open the calculator in programmer mode and reduce the value 80023395 bit by bit (I made the decision to reduce it because the 0x11 in the JP version was superior and had less stability).
I reduced the decimal value between 100 and 200, finding several similar behaviors and sometimes with some improvement, until I reached "80020DC9" and the game seemed to work normally, but I found it very close to 0x11 from Digimon 2003 and decided to test that to my surprise it worked perfectly, so I preferred to report the ones from Digimon than 80020DC9 which is a less safe custom (???) perhaps.
What do I mean by DD2 or StarWars, that we can try in isolation to test in an "intuitive" way all the 0x11s from other games and observe if any cause any strange reactions, if so that means it can have some effect on and using a check of the memory instructions could shorten the path to finding a CONFIg for these that are unplayable...
What does POPs 3.02 have or do that makes DD2 work?, has anyone managed to observe this?
