Ahhh. I wondered what those weird trampolines were for. Those were the things that initially made me think you had a lot of self-modifying code; I thought perhaps the jump targets were changed as the game ran. Then I thought maybe they were there because you had some shared code between the game and the editor, so they would jump to different places depending on which one was running. Then I thought perhaps they were a debugging aid, so you could perform vectoring at runtime by poking values into the jump targets. But no! Thank you, I should be able to cobble something together now.Rocketeer wrote: ↑Tue Mar 31, 2020 8:26 pmThe way I developed it was quite primitive since I didn't have a linker. A block of code is defined by a jump table of several JMPs into the actual routines themselves so I didn't have to keep changing addresses of those routines used in other assembler. In general the last JMP was the last routine hightest in memory so if you can find that and where it ends then the memory between that and the next set of JMPs should be free.
This is miserable news, though.
EDIT: all right, did a quick test using b-em's debugger and this looks promising:
Code: Select all
patch! use 16-byte free region at &1df0: lda #&ff sta &85 sta &86 jmp &2fab so ... ?&1df0 = &a9 ?&1df1 = &ff ?&1df2 = &85 ?&1df3 = &85 ?&1df4 = &85 ?&1df5 = &86 ?&1df6 = &4c ?&1df7 = &ab ?&1df8 = &2f then patch the jump target: ?&3034 = &f0 ?&3035 = &1d
EDIT2: here's the WFDIS file I used. Some of it is wrong but meh:
Just unzip it, then go here and upload it with the "select a file to disassemble" button. Warning: it may paralyse your browser for a while.