Forums

So I am currently working on a full disassemble of Castle of Illusion for SMS. Not sure if this is useful to anyone, I am mostly doing it for fun and to learn more about programming for the system. I will github it as soon as its cleaned up a bit.
I use a combination of vim, wla-dx and emulicious.

I currently have a few questions pertaining to wla-dx.

I'm not sure if this makes sense but i wonder whether it is possible to control the scope of defines. I try to define as much as possible of the constants used and have a separate .asm file for global constants, while putting local constants at the top of their respective subroutines. Since their scope is still global, their names can become quite long and convoluted to not overlap. I find the use of the @ prefix for labels useful for the same reason, but could not find anything similar for .defines. I provide an example below of how the disassembly can look like.

Another question is whether it is possible to have a routine define once and the code copied to different locations at compile time. The reason is that the game has a bunch of identical functions copied to different banks and its tedious to keep track of them whenever I relabel something.

Lastly, I had trouble with the .smsheader function. The recompiled rom is identical except for the two checksum bytes, which seems weird to me. This is my current code:

.smsheader
productcode $53, $70, 0
version 0
regioncode 4
reservedspace $ff, $ff
romsize 0
.endsms

Any help is appreciated!

Example code from project:

WormHandler: ;$39BDD
; Handles worm enemies (sitting on leaves) in stage 1.

.define WormAnimationFrames $03
.define WormAnimationSpeed $10
.define WormLeafYOffset $F000
.define WormDieVelocity $FC00
.define WormDieAcceleration $0080

ld a, (ix + Object_State)
ld hl, @StateJumpTable
jp ParseJumpTable ;why not rst?

@StateJumpTable:
.dw @SpawnObject
.dw @LivingState ;worm stays attached to leaf by borrowing its position
.dw @DyingState ;when killed

@SpawnObject:
inc (ix + Object_State)
ld a, WormAnimationFrames
ld b, WormAnimationSpeed
ld hl, WormGfxPointers
jp SetObjectAnimated

@LivingState:
push ix
pop hl
ld de, $000A ;offset for worm position and velocity
add hl, de
ld d, h
ld e, l
dec h ;corresponding leaf object in RAM
ld bc, $000A ;copy position + speed from leaf to worm
ldir
call GetObjectYPosition
ld de, WormLeafYOffset
add hl, de
call SetObjectYPosition
ld a, (ix + Object_XScreen)
bit 7, a
jr z, @CheckCollision
neg
@CheckCollision:
cp $02
ret nc
call EnemyMickeyCollision
jr c, @KillObject
call ThrowBlockCollision
ret nc
@KillObject:
call KillEnemyScore10
inc (ix + Object_State)
ld hl, WormGfxPointers + 16
call SetObjectStatic
call ResetObjectXVelocity
ld hl, WormDieVelocity
jp SetObjectYVelocity

@DyingState:
call DestroyOffscreenObject ;delete dead worm when left screen
ld de, WormDieAcceleration
jp AccelerateObjectY

I think defines take file scope. Going multi-file can be helpful sometimes.

Was the computed checksum correct?

Maxim wrote

I think defines take file scope. Going multi-file can be helpful sometimes.

Was the computed checksum correct?

Yeah, splitting into multiple files probably helps a bit, thanks!

Oh, you mean that the original checksum might be incorrect? But the game would not boot then, right?

Maxim wrote

I think defines take file scope. Going multi-file can be helpful sometimes.

Was the computed checksum correct?

Ville Helin provides wla dx asm files with constants for Game Boy that can be included into your code so defines cannot have file scope.

People usually use

.undefine

to avoid name clashes and achieve some kind of scoping. But with that, you need to manually clean up all the defines that you want to have scoped.

JonteP wrote

Oh, you mean that the original checksum might be incorrect? But the game would not boot then, right?

I think he's asking if the checksum that WLA DX put there is correct.

Including files is like including headers in C. Separating defines by files is like compiling multiple files in C - the linker joins the parts together later.

The original game may have used a different checksum range. Do any other header fields mismatch?

Sorry, I misunderstood then. No, just the two checksum bytes differ when comparing to the original rom in hexdiff.

I'm not sure about how to go about confirming the checksum, but I would assume that the calculation is correct. So a different checksum range sounds plausible, I guess.

JonteP wrote

Sorry, I misunderstood then. No, just the two checksum bytes differ when comparing to the original rom in hexdiff.

I'm not sure about how to go about confirming the checksum, but I would assume that the calculation is correct. So a different checksum range sounds plausible, I guess.

Different checksum range requires the romsize nybble to have a different value (That's why he asked if any other header bytes differ).

In the original game it's 0 (256 KB) and in yours it's 0 as well so the same range is summed for the checksum and thus the checksum should match.

Are you sure that it's the checksum that differs?

You can select a BIOS in Emulicious and test your reassembled ROM to see if the BIOS likes it.

JonteP wrote

Lastly, I had trouble with the .smsheader function. The recompiled rom is identical except for the two checksum bytes, which seems weird to me.

there was an issue in WLA-DX until a few days ago, fixed now. Try using latest version.

sverx wrote

JonteP wrote

Lastly, I had trouble with the .smsheader function. The recompiled rom is identical except for the two checksum bytes, which seems weird to me.

there was an issue in WLA-DX until a few days ago, fixed now. Try using latest version.

Yes, this fixed the issue for me, thank you!

Should have tried updating before posting here of course. Sorry for the false/late bug report!

Author	Message
JonteP Joined: 27 Nov 2014 Posts: 21	Disassembly and WLA-DX Posted: Fri Sep 25, 2020 12:24 pm
JonteP Joined: 27 Nov 2014 Posts: 21	So I am currently working on a full disassemble of Castle of Illusion for SMS. Not sure if this is useful to anyone, I am mostly doing it for fun and to learn more about programming for the system. I will github it as soon as its cleaned up a bit. I use a combination of vim, wla-dx and emulicious. I currently have a few questions pertaining to wla-dx. I'm not sure if this makes sense but i wonder whether it is possible to control the scope of defines. I try to define as much as possible of the constants used and have a separate .asm file for global constants, while putting local constants at the top of their respective subroutines. Since their scope is still global, their names can become quite long and convoluted to not overlap. I find the use of the @ prefix for labels useful for the same reason, but could not find anything similar for .defines. I provide an example below of how the disassembly can look like. Another question is whether it is possible to have a routine define once and the code copied to different locations at compile time. The reason is that the game has a bunch of identical functions copied to different banks and its tedious to keep track of them whenever I relabel something. Lastly, I had trouble with the .smsheader function. The recompiled rom is identical except for the two checksum bytes, which seems weird to me. This is my current code: .smsheader productcode $53, $70, 0 version 0 regioncode 4 reservedspace $ff, $ff romsize 0 .endsms Any help is appreciated! Example code from project: WormHandler: ;$39BDD ; Handles worm enemies (sitting on leaves) in stage 1. .define WormAnimationFrames $03 .define WormAnimationSpeed $10 .define WormLeafYOffset $F000 .define WormDieVelocity $FC00 .define WormDieAcceleration $0080 ld a, (ix + Object_State) ld hl, @StateJumpTable jp ParseJumpTable ;why not rst? @StateJumpTable: .dw @SpawnObject .dw @LivingState ;worm stays attached to leaf by borrowing its position .dw @DyingState ;when killed @SpawnObject: inc (ix + Object_State) ld a, WormAnimationFrames ld b, WormAnimationSpeed ld hl, WormGfxPointers jp SetObjectAnimated @LivingState: push ix pop hl ld de, $000A ;offset for worm position and velocity add hl, de ld d, h ld e, l dec h ;corresponding leaf object in RAM ld bc, $000A ;copy position + speed from leaf to worm ldir call GetObjectYPosition ld de, WormLeafYOffset add hl, de call SetObjectYPosition ld a, (ix + Object_XScreen) bit 7, a jr z, @CheckCollision neg @CheckCollision: cp $02 ret nc call EnemyMickeyCollision jr c, @KillObject call ThrowBlockCollision ret nc @KillObject: call KillEnemyScore10 inc (ix + Object_State) ld hl, WormGfxPointers + 16 call SetObjectStatic call ResetObjectXVelocity ld hl, WormDieVelocity jp SetObjectYVelocity @DyingState: call DestroyOffscreenObject ;delete dead worm when left screen ld de, WormDieAcceleration jp AccelerateObjectY

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Fri Sep 25, 2020 1:01 pm
	I think defines take file scope. Going multi-file can be helpful sometimes. Was the computed checksum correct?

JonteP Joined: 27 Nov 2014 Posts: 21	Posted: Fri Sep 25, 2020 1:29 pm
JonteP Joined: 27 Nov 2014 Posts: 21	Maxim wrote I think defines take file scope. Going multi-file can be helpful sometimes. Was the computed checksum correct? Yeah, splitting into multiple files probably helps a bit, thanks! Oh, you mean that the original checksum might be incorrect? But the game would not boot then, right?

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Fri Sep 25, 2020 1:47 pm
Calindro Joined: 14 Apr 2013 Posts: 624	Maxim wrote I think defines take file scope. Going multi-file can be helpful sometimes. Was the computed checksum correct? Ville Helin provides wla dx asm files with constants for Game Boy that can be included into your code so defines cannot have file scope. People usually use .undefine to avoid name clashes and achieve some kind of scoping. But with that, you need to manually clean up all the defines that you want to have scoped. JonteP wrote Oh, you mean that the original checksum might be incorrect? But the game would not boot then, right? I think he's asking if the checksum that WLA DX put there is correct.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Fri Sep 25, 2020 2:04 pm
	Including files is like including headers in C. Separating defines by files is like compiling multiple files in C - the linker joins the parts together later. The original game may have used a different checksum range. Do any other header fields mismatch?

JonteP Joined: 27 Nov 2014 Posts: 21	Posted: Fri Sep 25, 2020 2:22 pm
JonteP Joined: 27 Nov 2014 Posts: 21	Sorry, I misunderstood then. No, just the two checksum bytes differ when comparing to the original rom in hexdiff. I'm not sure about how to go about confirming the checksum, but I would assume that the calculation is correct. So a different checksum range sounds plausible, I guess.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Fri Sep 25, 2020 2:34 pm
Calindro Joined: 14 Apr 2013 Posts: 624	JonteP wrote Sorry, I misunderstood then. No, just the two checksum bytes differ when comparing to the original rom in hexdiff. I'm not sure about how to go about confirming the checksum, but I would assume that the calculation is correct. So a different checksum range sounds plausible, I guess. Different checksum range requires the romsize nybble to have a different value (That's why he asked if any other header bytes differ). In the original game it's 0 (256 KB) and in yours it's 0 as well so the same range is summed for the checksum and thus the checksum should match. Are you sure that it's the checksum that differs? You can select a BIOS in Emulicious and test your reassembled ROM to see if the BIOS likes it.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Sep 25, 2020 2:43 pm
	JonteP wrote Lastly, I had trouble with the .smsheader function. The recompiled rom is identical except for the two checksum bytes, which seems weird to me. there was an issue in WLA-DX until a few days ago, fixed now. Try using latest version.

JonteP Joined: 27 Nov 2014 Posts: 21	Posted: Fri Sep 25, 2020 2:58 pm
JonteP Joined: 27 Nov 2014 Posts: 21	sverx wrote JonteP wrote Lastly, I had trouble with the .smsheader function. The recompiled rom is identical except for the two checksum bytes, which seems weird to me. there was an issue in WLA-DX until a few days ago, fixed now. Try using latest version. Yes, this fixed the issue for me, thank you! Should have tried updating before posting here of course. Sorry for the false/late bug report!

Forums

View topic - Disassembly and WLA-DX