Hi Fhub,


You can put the good byte for a good checksum at the end of the patch.
However, a curious programmer (Fh..) could be astonished by a byte never adressed by the patch.

So I prefer to use a dummy short instruction (yes, with 2 clocks CPU lost) with the good byte as immediate value.
The BF is a "branch never", as BT is a branch always, without testing any code condition.
So 41 50 is a 2 clocks cpu lost instruction who only make PC = PC+2, and 50 is the byte for a good checksum.

You can make a best performance patch with :

66D0: 7F52 7260 bclr #6, @h'ff52
66D4: 7F52 7270 bclr #7, @h'ff52
66D8: 5A00 5062 jmp h'5062
66DC: 91 ; (41+50)

Cordialy,

Mychess

Yes, I'm a VERY curious programmer!
Ok, now I understand that this jump is never done.
But what is an instruction BF good for, when it actually never does anything?

The 2 clocks CPU lost is of course no problem, because I think this bugfix code is only executed when the user changes the level (to or away from a Fun level).

__________________
Meine Webseite: https://fhub.jimdofree.com/

And from your "66DC: 91 ; (41+50)" I guess the program uses only a 1-byte checksum, correct?
Then why not just change the checksum byte instead of adding such a dummy byte?

__________________
Meine Webseite: https://fhub.jimdofree.com/

Yes, only a one byte checksum.
However, the checksum is not stored, it should be 00, so I add a byte to obtain 00.

Another solution would be to delete the checksum call from the rom, but I'm follower of "Entia non sunt multiplicanda praeter necessitatem", or principle of parsimony.


Cordialy,

Mychess

Well, a 1-byte checksum is a quite simple method - how does the program react when it detects a wrong checksum?
I remember such a situation for any other ROM that I've patched, and it actually returned an error message (I've just skipped this error routine).

__________________
Meine Webseite: https://fhub.jimdofree.com/

A continuous error message (E: ron) with beep.
However, "enter" bypass the message and the computer is ready.