Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Disassembly and WLA-DX

Reply to topic
Author Message
  • Joined: 27 Nov 2014
  • Posts: 21
Reply with quote
Disassembly and WLA-DX
Post Posted: Fri Sep 25, 2020 12:24 pm
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
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13389
  • Location: London
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Joined: 27 Nov 2014
  • Posts: 21
Reply with quote
Post Posted: Fri Sep 25, 2020 1:29 pm
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?
  View user's profile Send private message
  • Joined: 14 Apr 2013
  • Posts: 538
Reply with quote
Post Posted: Fri Sep 25, 2020 1:47 pm
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.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13389
  • Location: London
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Joined: 27 Nov 2014
  • Posts: 21
Reply with quote
Post Posted: Fri Sep 25, 2020 2:22 pm
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.
  View user's profile Send private message
  • Joined: 14 Apr 2013
  • Posts: 538
Reply with quote
Post Posted: Fri Sep 25, 2020 2:34 pm
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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2775
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 27 Nov 2014
  • Posts: 21
Reply with quote
Post Posted: Fri Sep 25, 2020 2:58 pm
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!
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!