Direction control

[David]

(It took me about 3.5 hours to find the hacks, test them, and write this post.)

Wow...

Yes, because I didn't have a disassembly of PoP2 1.1 yet (only PoP2 IR), so I had to start that first.

My other thing is, is there a way for me to learn what you did with this games ? (I wanna try to hack the controls of Karateka)
From the the looks of it, seems that I gonna need alot of Assembler Language ?
Could you give me some pointers ? Thanks a MILLION.

Yes, knowledge of assembly is needed to find these kinds of hacks.
You also need a good disassembler, or alternatively you can use an already existing disassembly of the game (if there is one).
(I have posted disassemblies of PoP1 and PoP2 IR in the forum.)

you know what David, forget about disabling the ALT & CTRL keys, I'll just re-configure or re-wire my cabinet controls to different keys.

So your cabinet does support that after all?

If you can give me some pointers on how (maybe it's hard for me) to hack game just for changing the key from their default values to something else (cause the game has FIXED keys), I'll give it a try.

It depends on the game. There is no universal method which works with every game.
You need to disassemble the game and find how it checks the keyboard.

[Thenasty]

Only I can re-wire the CTRL ALT keys.. The others keys must be left alone. Can't re-wire any others.

I re-wired those keys to ; ' [ ] and change the control on the 4 games that uses the CTRL-ALT keys.


It all done now and with this COVID-19, I have plenty of time enjoying the old game thanks to you.

Stay safe wherever you are David.


Thanks again,
Ed

[Norbert]

- A way to force the prince to auto-run right, with left/right arrows having no impact.

This is the easier of the two.
search: [...] change: [...]

If you still have some hexpert energy left...
Is there a(n easy - for you) way to completely get rid of the prince's recuperation delay after he gets hurt from falls?

[Edit:] Also, how to force auto-run to the left? (Keyboard hander only is fine.) In the file after numpad 6 I see the same two bytes, but changing those in the same manner crashes the game. Auto-run to the left is more useful for modders, because of the gate's position on the tile (*).

[David]

Is there a(n easy - for you) way to completely get rid of the prince's recuperation delay after he gets hurt from falls?

With this hack the game will use the soft landing animation for those landings which take 1 HP.

Code: Select all

seg005:017F C7 06 70 43 01 00          mov  is_guard_notice, 1
seg005:0185 C7 46 FE 14 00             mov  [bp+seq_id], 20 ; hard land ; <-- change 20 (0x14) = hard land to 17 (0x11) = soft land
seg005:018A EB 16                      jmp  short loc_5F82

Search: C7 46 FE 14 00 EB 16
Change: 14 to 11

Also, how to force auto-run to the left? (Keyboard hander only is fine.)

Code: Select all

seg000:152F                      loc_152F:
seg000:152F
seg000:152F 80 3E D7 28 00                  cmp  key_states_4B_left, 0
seg000:1534 75 07                           jnz  loc_153D ; <-- change to: jmp loc_153D
seg000:1536 80 3E D3 28 00                  cmp  key_states_47_home, 0
seg000:153B 74 07                           jz   loc_1544
seg000:153D
seg000:153D                      loc_153D:
seg000:153D C6 06 12 46 FF                  mov  control_x, 0FFh
seg000:1542 EB 13                           jmp  short loc_1557

Search: 80 3E D7 28 00 75 07
Change: 75 07 to EB 07

[David]

In the file after numpad 6 I see the same two bytes, but changing those in the same manner crashes the game.

For the record, here is that hack:

- A way to force the prince to auto-run right, with left/right arrows having no impact.

This is the easier of the two.
search: 80 3E D7 28 00 75 07
change: 75 07 to EB 1C
This changes the keyboard handler, so it won't work in joystick mode.

And here is what it changes:

Code: Select all

seg000:152F                      loc_152F:
seg000:152F
seg000:152F 80 3E D7 28 00                  cmp  key_states_4B_left, 0
seg000:1534 75 07                           jnz  loc_153D ; <-- change to jmp loc_1552
seg000:1536 80 3E D3 28 00                  cmp  key_states_47_home, 0
seg000:153B 74 07                           jz   loc_1544
seg000:153D
seg000:153D                      loc_153D:
seg000:153D C6 06 12 46 FF                  mov  control_x, 0FFh
seg000:1542 EB 13                           jmp  short loc_1557
seg000:1544
seg000:1544                      loc_1544:
seg000:1544 80 3E D9 28 00                  cmp  key_states_4D_right, 0
seg000:1549 75 07                           jnz  loc_1552
seg000:154B 80 3E D5 28 00                  cmp  key_states_49_pageup, 0
seg000:1550 74 05                           jz   loc_1557
seg000:1552
seg000:1552                      loc_1552:
seg000:1552 C6 06 12 46 01                  mov  control_x, 1
seg000:1557
seg000:1557                      loc_1557:

So why does EB 1C mean jmp loc_1552?
0x1C is a relative jump offset, counted from the byte after the jump instruction: 0x1536 + 0x1C = 0x1552.

If you write the same bytes at 0x1549, then it will jump to 0x154B + 0x1C = 0x1567.
That address is the second byte of this instruction:

Code: Select all

seg000:1566 24 03              and  al, 3

Jumping into the middle of instructions is generally a bad thing.
The CPU will see these instructions:

Code: Select all

.00001567: 03 28                             add       bp,[bx+si]
.00001569: 06                                push      es
.0000156A: C6 4C CB 55                       mov       [si-35],55
.0000156E: 8B EC                             mov       bp,sp

So the CPU will skip the return instruction (retf = CB, the mov "ate" it), and starts to execute the following procedure, which is copy_screen_rect().
At the end of copy_screen_rect() there is a "pop bp" instruction, because it has a stack frame (for local variables).

Code: Select all

seg000:15E3 8B E5                 mov   sp, bp
seg000:15E5 5D                    pop   bp
seg000:15E6 CA 04 00              retf  4

However, we have also skipped the "push bp" (55, also eaten by the mov) at the start of this procedure, so "pop bp" will pop not a pushed bp but the return address meant for the "retf" in read_keyb_control()!
Then the following "retf" will return to a "random" address read from whatever is on the top of the stack is at this point.
That's why it crashes.

[Norbert]

Thanks for these instructions.

[Norbert]

I've noticed that, as an auto-runner, the prince can no longer enter level exits.
I hope it's okay for me to ask if there's a solution for this.
Maybe auto-entering the level exits when merely passing by them, not requiring up arrow?

[David]

I've noticed that, as an auto-runner, the prince can no longer enter level exits.
I hope it's okay for me to ask if there's a solution for this.
Maybe auto-entering the level exits when merely passing by them, not requiring up arrow?

A workaround is to put a wall on the left side of the exit (if the prince is running to the left).
Then the wall stops the prince and you can enter the exit with the up arrow as usual.

I will see what I can do about auto-entering.

[Norbert]

A workaround is to put a wall on the left side of the exit (if the prince is running to the left).
Then the wall stops the prince and you can enter the exit with the up arrow as usual.

Ah, yes. This'll be just fine.