Late reply, but did you omit some isyncs and this caused the hang?
As an fyi isync does the following...
1. Waits for all currently executing instructions to complete
2. Purges all instructions that are sitting in the instruction queue
3. Refetches instructions into the instruction queue.
This may not make sense unless you know how the instruction pipeline works and what it "looks" like via some sort of diagram (chapter 6 of Broadway Manual provides such a diagram)
Because isync does a purge then refetch, you can use isync to enforce instruction context synchronization. This means if you change/alter the privilege or other attributes of how Instructions get executed, you can enforce this change immediately and in program order with isync. Without isync, these changes wont be immediate and won't be in order since Broadway executes instructions out of order.
For modifying IBATs, you want these changes immediately or else you can cause a fault.
If you are in Real Mode, and you've changed your IBATs to use mem80 (Virtual Address), then jump to Virtual Mode w/o isync, its a high chance the instructions in the program (that sit in Virtual addresses), were already fetched with the property/context of Real Mode. Now when said instructions get executed, BOOM an exception occurs.
Placing an isync after modifying the IBATs before going to Virtual Mode will purge those faulty instructions and refetch them with the proper context
My Cache tutorial explains how isync can be used to prevent bugs within Self Modifying Code - https://mariokartwii.com/showthread.php?...27#pid9227
As an fyi isync does the following...
1. Waits for all currently executing instructions to complete
2. Purges all instructions that are sitting in the instruction queue
3. Refetches instructions into the instruction queue.
This may not make sense unless you know how the instruction pipeline works and what it "looks" like via some sort of diagram (chapter 6 of Broadway Manual provides such a diagram)
Because isync does a purge then refetch, you can use isync to enforce instruction context synchronization. This means if you change/alter the privilege or other attributes of how Instructions get executed, you can enforce this change immediately and in program order with isync. Without isync, these changes wont be immediate and won't be in order since Broadway executes instructions out of order.
For modifying IBATs, you want these changes immediately or else you can cause a fault.
If you are in Real Mode, and you've changed your IBATs to use mem80 (Virtual Address), then jump to Virtual Mode w/o isync, its a high chance the instructions in the program (that sit in Virtual addresses), were already fetched with the property/context of Real Mode. Now when said instructions get executed, BOOM an exception occurs.
Placing an isync after modifying the IBATs before going to Virtual Mode will purge those faulty instructions and refetch them with the proper context
My Cache tutorial explains how isync can be used to prevent bugs within Self Modifying Code - https://mariokartwii.com/showthread.php?...27#pid9227