-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase read delay cycles for Kingdom Hearts II #248
Conversation
The initial version of KH2 has some timing issues with disc reads which leads to a game lockup when entering the gummi ship menu. A patch applied by the ee_core exists since quite some time, but probably because of improvements to the rest of the project, the original delay cycles count is no longer sufficient to prevent the game from locking up. Some bisection has shown that increasing the value from 0x100000 to 0x110000 is sufficient. For reference, a value 0x10c000 already fails to work. Also note that there are multiple critical transitions the game does. One is the obvious transition from the overworld map to the gummi menu. Another one is the transition from the gummi stage back to the gummi menu. E.g. with a value of 0x10c000 the former one works, but the latter fails. All tests were done using SMB mode and the SLUS_210.05 release. It seems plausible that the other language release suffer from the same issues, so apply the new value to all of them.
@tobiasjakobi, this changes affects only the game Kingdom Hearts II or can it affect other games? Best regards. |
Due to how the ee_core patch system works, this can only affect the corresponding game IDs. I'm not sure if I understand your question? |
@tobiasjakobi, i mean, the changed delay cycles it is specificic only for the Kingdom Hearts II, And also, this is only tested loaded with SMB, but could it break the game when it Best regards. |
Well, you should see for yourself, apply_patches() @ ee_core/src/patches:880, you only enter the switch statement if the game ID and the game mode matches. Since game mode is ALL_MODE it also affects HDD and USB mode. |
@tobiasjakobi, thank you very much for your detailed explanation and for your work, Best regards. |
The initial version of KH2 has some timing issues with disc reads which leads to a game lockup when entering the gummi ship menu. A patch applied by the ee_core exists since quite some time, but probably because of improvements to the rest of the project, the original delay cycles count is no longer sufficient to prevent the game from locking up. Some bisection has shown that increasing the value from 0x100000 to 0x110000 is sufficient. For reference, a value 0x10c000 already fails to work. Also note that there are multiple critical transitions the game does. One is the obvious transition from the overworld map to the gummi menu. Another one is the transition from the gummi stage back to the gummi menu. E.g. with a value of 0x10c000 the former one works, but the latter fails. All tests were done using SMB mode and the SLUS_210.05 release. It seems plausible that the other language release suffer from the same issues, so apply the new value to all of them.
The initial version of KH2 has some timing issues with disc reads which leads to a game lockup when entering the gummi ship menu. A patch applied by the ee_core exists since quite some time, but probably because of improvements to the rest of the project, the original delay cycles count is no longer sufficient to prevent the game from locking up. Some bisection has shown that increasing the value from 0x100000 to 0x110000 is sufficient. For reference, a value 0x10c000 already fails to work. Also note that there are multiple critical transitions the game does. One is the obvious transition from the overworld map to the gummi menu. Another one is the transition from the gummi stage back to the gummi menu. E.g. with a value of 0x10c000 the former one works, but the latter fails. All tests were done using SMB mode and the SLUS_210.05 release. It seems plausible that the other language release suffer from the same issues, so apply the new value to all of them.
The initial version of KH2 has some timing issues with disc reads which leads to a game lockup when entering the gummi ship menu. A patch applied by the ee_core exists since quite some time, but probably because of improvements to the rest of the project, the original delay cycles count is no longer sufficient to prevent the game from locking up. Some bisection has shown that increasing the value from 0x100000 to 0x110000 is sufficient. For reference, a value 0x10c000 already fails to work. Also note that there are multiple critical transitions the game does. One is the obvious transition from the overworld map to the gummi menu. Another one is the transition from the gummi stage back to the gummi menu. E.g. with a value of 0x10c000 the former one works, but the latter fails. All tests were done using SMB mode and the SLUS_210.05 release. It seems plausible that the other language release suffer from the same issues, so apply the new value to all of them.
The initial version of KH2 has some timing issues with disc reads which leads to a game lockup when entering the gummi ship menu. A patch applied by the ee_core exists since quite some time, but probably because of improvements to the rest of the project, the original delay cycles count is no longer sufficient to prevent the game from locking up. Some bisection has shown that increasing the value from 0x100000 to 0x110000 is sufficient. For reference, a value 0x10c000 already fails to work. Also note that there are multiple critical transitions the game does. One is the obvious transition from the overworld map to the gummi menu. Another one is the transition from the gummi stage back to the gummi menu. E.g. with a value of 0x10c000 the former one works, but the latter fails. All tests were done using SMB mode and the SLUS_210.05 release. It seems plausible that the other language release suffer from the same issues, so apply the new value to all of them.
The initial version of KH2 has some timing issues with disc reads
which leads to a game lockup when entering the gummi ship menu.
A patch applied by the ee_core exists since quite some time, but
probably because of improvements to the rest of the project, the
original delay cycles count is no longer sufficient to prevent
the game from locking up.
Some bisection has shown that increasing the value from 0x100000
to 0x110000 is sufficient. For reference, a value 0x10c000 already
fails to work.
Also note that there are multiple critical transitions the game does.
One is the obvious transition from the overworld map to the gummi
menu. Another one is the transition from the gummi stage back to the
gummi menu. E.g. with a value of 0x10c000 the former one works, but
the latter fails.
All tests were done using SMB mode and the SLUS_210.05 release. It
seems plausible that the other language release suffer from the same
issues, so apply the new value to all of them.
Pull Request checklist
Note: these are not necessarily requirements
Pull Request description