When reversing, MD games, I see several things as far as label names and branches: Entire Subroutine Code (Text): ROM:000EBC30 ; =============== S U B R O U T I N E ======================================= ROM:000EBC30 ROM:000EBC30 ; TODO DOCUMENT THE RUNS / ET BETTER ROM:000EBC30 ; ROM:000EBC30 ; THERE ARE 2 POINTERS A1,A2 . ROM:000EBC30 ; ROM:000EBC30 ; A1 POINTS TO AN ARRAY IN ROM WITH THE PLANE MAPPING META DATA AND RUN LENGTH ROM:000EBC30 ; A2 POINTS TO AN ARRAY IN ROM WITH THE PLANE MAPPING ID DATA AND RUN LENGTH ROM:000EBC30 ; ROM:000EBC30 ; d1 holds the meta run length / counter number lengths left ROM:000EBC30 ; d2 holds the id run length / counter number lengths left ROM:000EBC30 ; ROM:000EBC30 ; There Are Two Types Of Runs: ROM:000EBC30 ; -1 runs same value ROM:000EBC30 ; -2 runs different values. maybe research the second one .its basically an array and not perhaps even a run as it is not saving space .... ROM:000EBC30 ; ROM:000EBC30 ; runs of different values star run length are stored in the Array a negative values ( not to say that every neg alue in array are these as IDK honetly ) .. they are sign extended as a word to FFXX and then the lower byte is negated to positive to make it a counter. so if it was originally 0xFE THEN FFFE sign extended as word , then negate the lower byte to 0x02 , we have as a word 0xFF02 ROM:000EBC30 ; ROM:000EBC30 ; There Are 2 data that has runs: ROM:000EBC30 ; ; 1 meta data ( priority / x/yflip / palette ) ROM:000EBC30 ; ; 2 tile id ROM:000EBC30 ; ROM:000EBC30 ; these two data are OR' together after shifting the meta data << 8 bits to the upper byte of the low order word of d0: ROM:000EBC30 ; ROM:000EBC30 ; MMMM MMMM IIII IIII ROM:000EBC30 ; ROM:000EBC30 ; M = meta ROM:000EBC30 ; I = ID ROM:000EBC30 ; ROM:000EBC30 ROM:000EBC30 sub_EBC30: ; CODE XREF: sub_E88A8+B6↑p ROM:000EBC30 ; sub_E88A8+102↑p ... ROM:000EBC30 swap d1 ; Swap bits around for plane X Address ROM:000EBC32 clr.w d1 ROM:000EBC34 swap d1 ROM:000EBC36 lsl.l #2,d1 ROM:000EBC38 lsr.w #2,d1 ROM:000EBC3A swap d1 ROM:000EBC3C bset #$1E,d1 ; VRAM write ROM:000EBC40 move.l d1,(VDP_CTRL).l ; Tell VDP control port were writing VRAM at Plane X address ROM:000EBC46 moveq #$FFFFFFFF,d1 ; runs metadata ROM:000EBC48 moveq #$FFFFFFFF,d2 ; runs tile-id ROM:000EBC4A subq.w #1,d0 ROM:000EBC4C ROM:000EBC4C loc_EBC4C: ; CODE XREF: sub_EBC30+64↓j ROM:000EBC4C swap d0 ROM:000EBC4E ROM:000EBC4E Check_If_Done_With_Meta_Run: ROM:000EBC4E tst.b d1 ROM:000EBC50 bpl.s Check_If_Done_With_ID_Run ; Are we done with the tile meta data run? ROM:000EBC50 ; if not branch ROM:000EBC50 ; if so continue ROM:000EBC52 ROM:000EBC52 Done_With_Meta_Run: ROM:000EBC52 move.b (a1)+,d1 ROM:000EBC54 ext.w d1 ROM:000EBC56 bpl.s Check_If_Done_With_ID_Run ; If d1 as a word is negative ( the upper byte of word is FF) then it is a run of meta of different values. Continue. ROM:000EBC56 ; If d1 is positve as word , it is a run of meta of same values. Branch. ROM:000EBC58 ROM:000EBC58 Tile_Meta_Run_Of_Different_Values: ; Negate original negative run value to positive so it is FFxx , where xx of lower byte is the run length. ROM:000EBC58 neg.b d1 ; We have FF in upper byte of word and a positive counter value in the lower byte ROM:000EBC58 ; .. bc duhh we need a positive run length ^.^ ROM:000EBC5A ROM:000EBC5A Check_If_Done_With_ID_Run: ; CODE XREF: sub_EBC30+20↑j ROM:000EBC5A ; sub_EBC30+26↑j ROM:000EBC5A tst.b d2 ROM:000EBC5C bpl.s Not_Done_ID_Run ; Are we done with the tile id data run? ROM:000EBC5C ; if not branch ROM:000EBC5C ; if so continue ROM:000EBC5E ROM:000EBC5E Done_With_ID_Run: ROM:000EBC5E move.b (a2)+,d2 ROM:000EBC60 ext.w d2 ROM:000EBC62 bpl.s Not_Done_ID_Run ; If d2 as a word is negative ( the upper byte of word is FF) then it is a run of ID of different values. Continue. ROM:000EBC62 ; If d2 is positve as word , it is a run of ID of same values. Branch. ROM:000EBC64 ROM:000EBC64 Tile_ID_Run_Of_Different_Values: ; Negate original negative run value to positive so it is FFxx , where xx of lower byte is the run length. ROM:000EBC64 neg.b d2 ; We have FF in upper byte of word and a positive counter value in the lower byte ROM:000EBC64 ; .. bc duhh we need a positive run length ^.^ ROM:000EBC66 ROM:000EBC66 Not_Done_ID_Run: ; CODE XREF: sub_EBC30+2C↑j ROM:000EBC66 ; sub_EBC30+32↑j ROM:000EBC66 tst.w d1 ROM:000EBC68 bmi.s Build_Tile_MetaData_Runs_Of_Same_Value ; is this runs of meta data of the same values? ROM:000EBC68 ; if so branch ROM:000EBC68 ; otherwise continue ROM:000EBC6A ROM:000EBC6A Build_Tile_MetaData_Runs_Of_Different_Values: ; get current meta data ( of different values ) incrment pointer to point to next meta data ( of diffrent values ) ROM:000EBC6A move.b (a1)+,d0 ROM:000EBC6C subq.b #1,d1 ; decrement run length countner for meta data ( Different Values ) ROM:000EBC6E bra.s Shift_MetaData_Upper_Byte_Of_Word ROM:000EBC70 ; --------------------------------------------------------------------------- ROM:000EBC70 ROM:000EBC70 Build_Tile_MetaData_Runs_Of_Same_Value: ; CODE XREF: sub_EBC30+38↑j ROM:000EBC70 move.b (a1),d0 ; get meta data of same value ROM:000EBC72 subq.b #1,d1 ; decrement run length countner for meta data ( Same Values ) ROM:000EBC74 bpl.s Shift_MetaData_Upper_Byte_Of_Word ; Are we not finished with this run of data with different values? ROM:000EBC74 ; if so branch ROM:000EBC74 ; otherwise continue ROM:000EBC76 ROM:000EBC76 Meta_Same_Value_Done_Point_To_Next_Run_Length: ; Meta Run of same value finished , incrment pointer to point to next run length ROM:000EBC76 addq.l #1,a1 ROM:000EBC78 ROM:000EBC78 Shift_MetaData_Upper_Byte_Of_Word: ; CODE XREF: sub_EBC30+3E↑j ROM:000EBC78 ; sub_EBC30+44↑j ROM:000EBC78 lsl.w #8,d0 ROM:000EBC7A tst.w d2 ROM:000EBC7C bmi.s Build_Tile_ID_Runs_Of_Same_Value ; is this runs of id data of the same values? ROM:000EBC7C ; if so branch ROM:000EBC7C ; otherwise continue ROM:000EBC7E ROM:000EBC7E Build_Tile_ID_Runs_Of_Different_Values: ROM:000EBC7E move.b (a2)+,d0 ROM:000EBC80 subq.b #1,d2 ROM:000EBC82 bra.s Map_Tile_To_Plane ; * ROM:000EBC84 ; --------------------------------------------------------------------------- ROM:000EBC84 ROM:000EBC84 Build_Tile_ID_Runs_Of_Same_Value: ; CODE XREF: sub_EBC30+4C↑j ROM:000EBC84 move.b (a2),d0 ROM:000EBC86 subq.b #1,d2 ROM:000EBC88 bpl.s Map_Tile_To_Plane ; * ROM:000EBC8A ROM:000EBC8A ID_Same_Value_Done_Point_To_Next_Run_Length: ; ID Run of same value finished , incrment pointer to point to next run length ROM:000EBC8A addq.l #1,a2 ROM:000EBC8C ROM:000EBC8C Map_Tile_To_Plane: ; CODE XREF: sub_EBC30+52↑j ROM:000EBC8C ; sub_EBC30+58↑j ROM:000EBC8C move.w d0,(VDP_DATA).l ; * ROM:000EBC92 swap d0 ; * ROM:000EBC94 dbf d0,loc_EBC4C ; * ROM:000EBC98 rts ROM:000EBC98 ; End of function sub_EBC30 In this code a few things are peculiar. In this code below if it results plus , we are are not done with the run and we branch ahead. The code it jumps to does other tasks. I named the label after the next task it does.. Check_If_Done_With_ID_Run .. But I could have named the label Not_Done_With_Meta_Run after the fact we are not done with the run. Code (Text): tst.b d1 bpl.s Check_If_Done_With_ID_Run ; Are we done with the tile meta data run? What do you all find the more proper mode of labeling such situational code? This point brings up the next thing that is peculiar and ties to the above... Look at the code below .... If it is plus here we branch to Check_If_Done_With_ID_Run. This code makes the function of the label Check_If_Done_With_ID_Run no longer so simple as before with a single condition branch. Where either it would branches to it or eventually flow to it. Now there are three ways it can get to it. Two branches on condition and one flow through. So labeling it Not_Done_With_Meta_Run is not a proper name, Which is why I named it Check_If_Done_With_ID_Run . Is this the proper way to deduce the correct name for the labels? Code (Text): ext.w d1 bpl.s Check_If_Done_With_ID_Run ; If d1 as a word is negative ( the upper byte of word is FF) then it is a run of meta of different values. Continue. ; If d1 is positve as word , it is a run of meta of same values. Branch. This game at least partially written in C and compiled. As a bonus question , considering C compilation, why would they have labels flow in such a way where the task of things isn't more black and white and straight forward that it always does this under this flow of code and always does that under this flow? Maybe the C if else / switch statements were more black and white? I assume it is to make the decompression code more tight?
