Gameboy 3 Bytes instructions

[OdnetninI]

For example gameboy games have their start point at 0x0100, normaly with a NOP and J instructions, but medusa says:
0xCE
0x50
0x01

Medusa doesn't translate it.

[wisk]

Hi Odnetninl,

I just tried to disassemble LoZ (sha1: fa38601c371ca327166bf52be194697) with qMedusa and I failed to reproduce your issue (disassembly looks good, at least for this part):

00:0100  ;; File disassembled with Medusa 0.4.4 (debug) Jul  1 2015 - 22:55:13
00:0100  ;; website: https://github.com/wisk/medusa 
00:0100  ;; SHA1: fa38601c371ca327166bf52be194697
00:0100  
00:0100  
00:0100  ; xref: 00:7e49, 00:45ef
00:0100  start:
00:0100      nop             
00:0101  
00:0101  ; xref: 00:461f, 00:4619, 00:4615, 00:4610, 00:460a, 00:4606, 00:4600, 00:45fc, 00:45f9, 00:45f6, 00:45f2, 00:45ec
00:0101  lbl_00_0101:
00:0101      jp               lbl_00_0150 

Could you bring me more information about your issue? (tool used, version and branch of medusa compiled, hash of the ROM, etc)

Thank you. :)

[OdnetninI]

Hi,
I used, Pokemon Red (E), Spanish Version of Pokemon Red, (sha1: fc17c5b94d551b1b9854ccd1c493f)

00:00ff
00:00ff ; xref: 00:4fe7
00:00ff lbl_00_00ff:
00:00ff nop
00:0100 ;; File disassembled with Medusa 0.4.4 (release) Jul 6 2015 - 09:08:19
00:0100 ;; website: https://github.com/wisk/medusa
00:0100 ;; SHA1: fc17c5b94d551b1b9854ccd1c493f
00:0100
00:0100
00:0100 ; xref: 00:53f6, 00:432a, 00:4fbb
00:0100 start:
00:0100 nop
00:0101 db 0xC3
00:0102
00:0102 ; xref: 00:5e8c, 00:2f7f
00:0102 lbl_00_0102:
00:0102 ld d, b
00:0103
00:0103 ; xref: 00:5ea8, 00:5e9f
00:0103 lbl_00_0103:
00:0103 ld bc, dat_00_edce
00:0106 ld h, byte [hl]
00:0107 ld h, byte [hl]
00:0108 call z, lbl_00_000d

I'm using the last version of dev branch.

[wisk]

Hi OdnetninI,

Thanks for this info, I guess instruction at 00:0102 is badly disassembled because instruction at 00:5e8c or 00:2f7f uses the constant 0x0102. It's hard to tell the difference between literal values and addresses, especially on this kind of architecture (i.e. 16-bit addressing mode).
Since I can't "retrieve" this ROM and I'm unable to reproduce this bug, do you mind giving me both instruction at 00:5e8c and 00:2f7f? It could help to understand the root cause.

[OdnetninI]

I can give you the rom: http://gameboyonline.es/roms/rojo.gb

[wisk]

Thanks for the link. :)
As I though, both instruction 00:2f7f (ld bc, lbl_00_0102) and 00:5e8c (ld bc, lbl_00_0102) uses address 00:0102.
It happens because the vertical blank handler 00:0040 is disassembled before the entry point (00:0100), and since it stumbles across instructions which reference the address 00:0102, but the entry point is not yet disassembled, medusa wrongly believes it's safe to associate 00:0102 as data (so it creates xref/label). When it disassembles the entry point, the first instruction (nop) is correctly disassembled (00:0100), however, it refuses to disassemble the next one (jmp) because there's a xref/label in the middle of the instruction.
A quick and dirty workaround for this issue would be to force the entry point to be disassembled first. The problem is, Label are stored in boost::bimap. This container doesn't preserve the order of element.

I'll try to find something better, but don't hesitate to share if you have an idea. :)