S.O.S: C64 Dungeon Event Jump Table - Help

Darendor · Post by **Darendor** » Tue Jun 01, 2010 10:19 pm

I've managed to figure out a way to relocate the C64 game's jump table location, but I'm encountering errors.

I need you, ZeroZero, and/or anyone else to help me out.

I've been moving the table and code from $1B15 in memory to $4162. As far as I have been able to tell, that area is untouched by the game engine.

Code: Select all

4162 AE E0 E0  LDX $E0E0
4165 06 F0     ASL $F0
4167 08        PHP
4168 BD 75 41  LDA $4175,X
416B 20 B9 78  JSR $78B9
416E 18        CLC
416F 60        RTS
4170 A0 01     LDA #$01
4172 4C F0 19  JSR $19F0

4175 00    BRK

4176 1B    
4177 0C
4178 0D 0E 0B
417B 00
417C 0F
417D 10 1C
417F 1D 1E 11
4182 12
4183 14
4184 13
4185 1F
4186 20 21 22
4189 23
418A 24 25
418C 15 26
418E 27
418F 28
4190 29 2A
4192 2B
4193 2C 2D 2E
4196 2F
4197 16 18
4199 17
419A 30 31
419C 32
419D 33
419F 19 35 36
41A2 38
41A3 39 3A 3B
41A6 3C
41A7 3D 3E 3F
41AA 40
41AB 41 42
41AD 43
41AE 44

BUT...

The game crashes after "S"tart game is selected - the border flashes orange, it says "Insert the DUNGEON disk, check the drive, and press a key."...

The calls to the jump table are:
0884 JMP $1B15
5C78 JSR $1B15

So, I'm at a loss as to why the table relocation is not working.

The machine code register thingy at time of crash:

Code: Select all

PC    AC XR YR SP 00 01 FL  NV-BDICZ
7A21  00 3A 30 F7 2F 36 23  00100011

I am so close to being able to make it so we can add new events to the existing code.

Darendor · Post by **Darendor** » Tue Jun 01, 2010 10:23 pm

Oh, and yes, I did change the calls to the new code thusly:

Code: Select all

 0884 JMP $4162
5C78 JSR $4162

ZeroZero · Post by **ZeroZero** » Tue Jun 01, 2010 10:44 pm

I cannot see what you did by the info you gave, but it was not a wise idea to relocate code that you do not know of from where all it is referenced

Darendor · Post by **Darendor** » Wed Jun 02, 2010 5:05 pm

ZeroZero wrote:I cannot see what you did by the info you gave, but it was not a wise idea to relocate code that you do not know of from where all it is referenced

Oh please, I did a memory dump from when the game loads the Adventurer's Guild and picked an area that had nothing but "00".

I'ma e-mail you my findings in detail.

ZeroZero · Post by **ZeroZero** » Wed Jun 02, 2010 10:56 pm

This is not a wise idea, because:

unless you have decompiled the whole program, you do not know,
if and when that place of memory is used, and if even only
temporarely.

Also, you won't know then, from what all places (even on later
loaded events) that memory is referenced. Also, they can reference
not only to the start address but anywhere in between.

This all are reasons not to touch the program until you have understood
fully, how each and every byte in it works.

I don't, so I recommend not to try this.

Darendor · Post by **Darendor** » Thu Jun 03, 2010 1:40 am

You really don't wanna help me, do you?

ZeroZero · Post by **ZeroZero** » Fri Jun 04, 2010 1:45 pm

I simply CAN'T help you here, for the reasons I gave above and for what we talked in MSN

Darendor · Post by **Darendor** » Fri Jun 04, 2010 11:31 pm

Alright, time to compose a memory map of the areas the BT engine uses up to see if I can find some way to relocate this goddamned table successfully.

Anyone at all care to assist me?

Twoflower · Post by **Twoflower** » Wed Aug 04, 2010 10:21 pm

Concerning the jumptable and free space in memory:

The different modules occupy different amount of space at different places and at different times. There is no way you can tell whether or not the memory is getting overwritten at one or another point in the game unless you set a breakpoint in Vice and play through the game. Or simply write a text in that memory and see if it goes unaltered - but you can't even be sure then. The zeroes may or may not have a purpose.

What you need to work with if you intend to do this is the constant - things you know aren't touched or moved. The locations of the loader will f.ex never be touched or moved since the game will need it at all times. The party-data is another of those things which never will change. My best bet of free space is the end of the graphics-buffer - i'm pretty sure that BT1 don't have animations which fills it up completely.

Why do you need to move the table? What will you achieve/win by doing it?

Darendor · Post by **Darendor** » Tue Aug 31, 2010 12:51 pm

Twoflower wrote:Concerning the jumptable and free space in memory:

The different modules occupy different amount of space at different places and at different times. There is no way you can tell whether or not the memory is getting overwritten at one or another point in the game unless you set a breakpoint in Vice and play through the game. Or simply write a text in that memory and see if it goes unaltered - but you can't even be sure then. The zeroes may or may not have a purpose.

What you need to work with if you intend to do this is the constant - things you know aren't touched or moved. The locations of the loader will f.ex never be touched or moved since the game will need it at all times. The party-data is another of those things which never will change. My best bet of free space is the end of the graphics-buffer - i'm pretty sure that BT1 don't have animations which fills it up completely.

Why do you need to move the table? What will you achieve/win by doing it?

My ambition is to make it so that people can code their own event files and to expand the jump table accordingly.

The existing table has no room for addition.