| Posted By
icbrkr
on 2015-01-01
16:51:11
|  Finding packed starting addresses
I've been converting PAL games over to NTSC so that we North Americaners can use PAL games without converting our systems.
If the program isn't packed by Sledgehammer, Bit Packer, etc, is no big deal to convert. But I'm having trouble finding the entry point to the depacked program.
I know in my former life on the C64, my intros would drop down to low memory, depack into standard RAM locations, and then JMP to the starting address of the program.
Is there an easy way to look at a packed program to see where it's going to JMP to when it depacks?
|
|
Posted By
gerliczer
on 2015-01-02
01:50:03
| Re: Finding packed starting addresses
Unfortunately, there is no better way than tracing the depacker and finding the actual entry point. Sometimes packers do some sort of BASIC warm reset, so if you familiarise with the Commodore BASIC V3.5 startup procedure it might help identifying the entry point.
Edit:
Maybe it would be the best course of action if you write a depacker identifier and entry point finder tool. You know, like if we have in the memory at given location a signature byte sequence, than entry call must be at address $XXXX; if there is the expected content, you are ready, if not then you have an unidentified depacker. Although, I don't think this would be the bottleneck in your NSTC fixing efforts.
|
|
Posted By
icbrkr
on 2015-01-03
19:40:11
| Re: Finding packed starting addresses
I've been following it in YAPE's monitor, but it's not always obvious unfortunately. That, and it's time consuming.
Maybe you have a point on the second piece - I can try packing a couple programs that I know the starting address to and see where the packer puts its JMP code.
|
|
Posted By
gerliczer
on 2015-01-04
05:44:13
| Re: Finding packed starting addresses
I know it is time consuming, but I don't think finding the program start address will take the most time. Finding _all_ the relevant code sequences setting deliberately or inadvertently PAL display mode and fixing them, or even realising that there is not enough raster-time to run in NTSC and trying to speed up the code will take lots more effort and time in my view.
But if you need help, we (as in the forum visitors of Plus4world) may give you a hand (as our time permits) finding these addresses for the programs you try to fix.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
