1

I'm trying to crack an old commodore game called "Katz und maus". I already realized the infinite lives, rewrite scores and I'm halfway on implementing the level jump. I think sprite collision will be the key to finish the level jump.

The problem is I could not find any part in the code which might responsible for sprite/character collision.

I tried to find it with an action replay emulator: no results.

In MC monitor I searched D01E and D01F but all the matches caused because of opcodes:

H 0000 FFFF 1E D0

H 0000 FFFF 1F D0

I also tried to look for LDA $D01E and LDA $D01F, but no results:

H 0000 FFFF AD 1E D0

H 0000 FFFF AD 1F D0

What else can I check? Thanks!

Cactus
  • 27,075
  • 9
  • 69
  • 149
Paxi
  • 111
  • 11
  • 3
    Hmm, I wonder if this is on topic here or better on [Retrocomputing](https://retrocomputing.stackexchange.com/). – Nick Westgate Aug 08 '19 at 07:08
  • 1
    If collisions result in variable changing, like health, lives, points, try searching for one of those variables,then search for code that reference one of those variables. This could be an issue if addresses to such variables are computed. – rcgldr Aug 08 '19 at 07:41
  • 3
    @NickWestgate: or maybe on https://reverseengineering.stackexchange.com/, but yeah retrocomputing might be a better bet for hacking old games on old processors like 6502. – Peter Cordes Aug 08 '19 at 09:03
  • @PeterCordes, yes, I think the platform knowledge is key, and is concentrated in Retrocomputing. I can debug a modern kernel or crack/hack an Apple II game, but I couldn't answer this C64 question without a lot of research. – Nick Westgate Aug 08 '19 at 09:42
  • 4
    @NickWestgate It's on-topic here because it's about programming. Whether the question is on-topic on another site is irrelevant. There's no rule here requiring questions to be about sufficiently modern technology nor are reverse engineering questions off-topic – Ross Ridge Aug 08 '19 at 16:34
  • 2
    Are you running it in an emulator? If yes, try breaking on reads from the VIC2 collision registers (`break load $d01e $d01f` in Vice's console for example) – Cactus Aug 10 '19 at 13:42
  • Yes, I'm trying to run it on vice and ccs64 too. I tried your suggestion but unfortunately it did not help. I also tried to look for lines which stores the base address as @JeremyP recommended, but I found only some code which runs every time (so not triggered by any event) which is the following: `LDA $D010 AND #$01 CMP #$01 BEQ $A2BA LDA $8996 SEC ...` I think they did not use hardware collision because it would recognized by the action replay cartridge emulator. Maybe they used software collision? – Paxi Aug 10 '19 at 17:33
  • "Shapes which appear to be sprites may actually be user defined characters, or the programmer may be using coordinate information rather than the VIC system to detect collisions. " - Found on [link](https://rr.pokefinder.org/wiki/Action_Replay_MK6_Manual_Project64.txt) . I assume the coordinate info is the case. – Paxi Aug 11 '19 at 09:57

1 Answers1

3

Were I writing a game that used the VIC2 heavily (I suppose all games do), I would consider storing the base address of the VIC2 somewhere and then accessing the registers in it using indexed addressing. So you could look for any code that stores the base address (or any address in the VIC2 range) at a location. Any such code would first have to do LDA #$D0 at some point (or LDX or LDY).

Another thing to check is whether your program messes with the interrupt routines. The VIC2 can be programmed to raise an interrupt when it detects a sprite collision.

JeremyP
  • 84,577
  • 15
  • 123
  • 161