ParadigmShifter wrote: ↑Sun Jan 14, 2024 9:59 am
First check whether H'L' has that value or not on return to basic, if it does then the proposed fix will not work. Basic should not modify it at any time (I think) so it should still have same value on return.
After returning to BASIC, HL = $5C3B and HL' = $0038. So not the desired value; so this does seem to be the problem.
(The return value in BC doesn't matter as it is unused by the BASIC.)
I tried as suggested setting a breakpoint at $23DA or at $34BB. In both cases, the breakpoint is hit immediately when I call the routine (RANDOMIZE USR 60312), before the gameplay actually starts. Not sure what that does for me...
Even if I could catch it on the way out, I don't suppose that knowing I was back in BASIC would tell me anything about the last RET that I came from. Seems I need some kind of trace facility?
Next I'll try AndyC's suggestion of a "wrapper" routine. The site asm80.com seems to be a handy quick one for compiling a few instructions to bytes.
AndyC wrote: ↑Sun Jan 14, 2024 10:36 am
You probably only need find about 9 bytes somewhere:
[... wrapper code ...]
And then just call that in place of whatever the original USR was doing.
1 CLEAR 27135: LOAD "RFC" CODE 27136,38400
2 REM poke wrapper into level 27 map, just for testing
3 RESTORE: FOR n=0 TO 8: READ a: POKE 30208+1024*27+n,a: NEXT n: DATA 205,152,235,217,33,88,39,217,201
4 RANDOMIZE USR 30208+1024*27
When run, it produces some lines and gibberish text on the screen, and stops with "K Invalid colour". Have I made a mistake?
As was previously said, this works okay in 48k mode. If this was the issue it would return 'B: Integer Out Of Range' there too. I don't know what the problem is but I don't think this is the underlying cause.
The RANDOMIZE USR call to 60312 was writing the current stack pointer (SP) into the 128K BASIC system variables which was causing the previous problems. My original fix was to hot wire a fixed correct value for SP but I've now changed this to write SP to a safe area of memory (the routine that detects the Currah speech which is now disabled) and then restores this value back when the game returns control back to BASIC at 60116 - so the correct stack pointer is used rather than a constant. Debugging the crash, the issue was that the stack was off by 2 bytes which meant the code at 60116 was returning to the wrong code in the BASIC ROM which caused the 'B: Integer Out Of Range'. This seems to fix the issue for me.
bob_fossil wrote: ↑Sat Jan 20, 2024 10:50 pm
@equinox, can you try applying the following POKES to my previously modified RFC code block? [...]
The RANDOMIZE USR call to 60312 was writing the current stack pointer (SP) into the 128K BASIC system variables which was causing the previous problems. My original fix was to hot wire a fixed correct value for SP but I've now changed this to write SP to a safe area of memory (the routine that detects the Currah speech which is now disabled) and then restores this value back when the game returns control back to BASIC at 60116 - so the correct stack pointer is used rather than a constant. Debugging the crash, the issue was that the stack was off by 2 bytes which meant the code at 60116 was returning to the wrong code in the BASIC ROM which caused the 'B: Integer Out Of Range'. This seems to fix the issue for me.
Oooohhhh yeah! Looking good. I did the same statements as before, and this time no problems, just "0 OK" (or as I am henceforth calling it, "Yoko Ono").
This should work when loaded from 128k now. The original loader was one large CODE block loaded from 16384 which stomped over the printer buffer which 128 BASIC uses for paging. I've also applied my patch for the sound effects.
P.S. I have found another issue with this 128 fix — though it doesn't matter for the purposes of my modded version, because I won't be using the demo playback routine.
The title screen calls a routine at 60458, which waits for a keypress, and if no key is pressed, eventually goes into "attract mode", where it plays one of several pre-recorded gameplay demos. The 128 fixed version still does this correctly in 48k mode, but in 128k mode it does something rather strange: the player in the demo does not move, and is instead under the control of you, the human player. So it sort of starts a (semi-) game instead of playing back the demo.
equinox wrote: ↑Sat Feb 10, 2024 10:09 pm
P.S. I have found another issue with this 128 fix — though it doesn't matter for the purposes of my modded version, because I won't be using the demo playback routine.
The title screen calls a routine at 60458, which waits for a keypress, and if no key is pressed, eventually goes into "attract mode", where it plays one of several pre-recorded gameplay demos. The 128 fixed version still does this correctly in 48k mode, but in 128k mode it does something rather strange: the player in the demo does not move, and is instead under the control of you, the human player. So it sort of starts a (semi-) game instead of playing back the demo.
The demo state appears to be stored at 23434. When the menu times out and starts the demo mode, it sets this address to 255. At some point 128 BASIC stomps over this, as again this address is in the 128 BASIC system variables area. The game code checks whether this value is 255 to see if it needs to do the demo code - which it isn't so it thinks it's playing a real game. I've moved the demo state address into the unused block for the Currah speech detection which seems to fix the problem.
