Forums

There's no guarantee that palette entry 16 has any contrast with sprites, in particular if it's black then since most sprites have a black border, the contrast is lost. My particular case is the in game sprites in Micro Machines.

Hi guys,

an update of Emulicious has been released!
The changes are:

Some bugs have been fixed and some inconsistencies have been removed.
Performance has been improved
An option to enable scanlines has been added
Sub-line selection in the debugger has been enabled
The disassembler has been made more stable to significantly reduce the number of crashes and freezes caused by it
The reference hierarchy has been improved and now also supports jump tables, pointer tables and RAM addresses

Users of Emulicious can get the update via the update system.
Others can grab their copy from http://www.emulicious.net

Could you make an archive of old versions available?

Bock wrote

Could you make an archive of old versions available?

Hi Bock,

I don't own many (if any) old versions of Emulicious. Is there any particular need for an archive? Did anything become worse? If so, I will need help from others to build the archive.

Bock, I sent you a link via private message with all the archived versions I could find.

Not sure which ones would be best to add to the site. I'll leave that up to you guys.

Is this a bug when i trying to open a rom file using open dialog to navigate to desktop (of Windows 10)? It shows a nice animated blue ring but nothing in this folder but there is at least one .sms file.

Hi Calindro;

Something I just noticed -- the bytes following a conditional jump (e.g. `jp z`) should also be disassembled, Emulicious does not disassemble these unless they're executed. Disassembling the bytes following conditional jumps automatically would greatly reduce the amount of play you need to coax out all the code.

Secondly it would be helpful if the disassembly would mark data regions that have never been read. This would make it easier to spot unused code/data, and to be more aware of portions of code you haven't got the emulator to execute yet.

Hi Kroc,

Kroc wrote

Something I just noticed -- the bytes following a conditional jump (e.g. `jp z`) should also be disassembled, Emulicious does not disassemble these unless they're executed.

This is not true. If it doesn't get disassembled then it's for another reason. Can you point me to where it happens? Then I can tell you more. :)

Kroc wrote

Disassembling the bytes following conditional jumps automatically would greatly reduce the amount of play you need to coax out all the code.

You can also right-click the byte and click "Set Code" to turn it into code without the need to run it. But maybe we can already figure out why it's not getting disassembled in the first place. :)

Kroc wrote

Secondly it would be helpful if the disassembly would mark data regions that have never been read. This would make it easier to spot unused code/data, and to be more aware of portions of code you haven't got the emulator to execute yet.

The disassembler doesn't know what data is read so it also can't tell what data is not being read. You can use the Coverage recorder to see which data is being touched and which isn't.

Calindro wrote

Can you point me to where it happens? Then I can tell you more. :)

Metal Gear Solid for Gameboy Color:
(kind of annoying that you can't select multiple lines in the debugger)

_LABEL_150_:
   di
   ld sp, $CFFF
   cp $11
   jr nz, +
; Data from 158 to 16D (22 bytes)
.db $FA $43 $01 $FE $C0 $20 $0F $3E $01 $EA $07 $CF $3E $80 $EA $08
.db $CF $CD $A3 $06 $18 $09

You can clearly see there's code here that's not being disassembled. Thanks for looking into this.

Kroc wrote

Calindro wrote

Can you point me to where it happens? Then I can tell you more. :)

Metal Gear Solid for Gameboy Color:
(kind of annoying that you can't select multiple lines in the debugger)

_LABEL_150_:
   di
   ld sp, $CFFF
   cp $11
   jr nz, +
; Data from 158 to 16D (22 bytes)
.db $FA $43 $01 $FE $C0 $20 $0F $3E $01 $EA $07 $CF $3E $80 $EA $08
.db $CF $CD $A3 $06 $18 $09

You can clearly see there's code here that's not being disassembled. Thanks for looking into this.

Open the Disassembler Settings and enable "Allow calls to unknown RAM".

That did it, but why was that?

Kroc wrote

That did it, but why was that?

When this option is disabled and there is a branch to unknown RAM (the disassembler doesn't know what's in RAM at that place as it reaches the branching point) the disassembler assumes the branch to be invalid.

This option is meant to be a hint from the user about the ROM being examined. If you know that a ROM does definitely not run code from RAM then you can disable the option. Otherwise you can enable it.

Most SMS games don't run code from RAM or if they do it's easy to track because they just copy a block from ROM to RAM via LDIR. So it is safer to have this option disabled. But from what I've seen in GBC games so far it seems like it's fairly common for them to run code in RAM.
On the other hand the GB disassembler is still very untested so it is very likely to be immature.

Are you saying that that portion of ROM is being copied to RAM causing the misinterpretation as data?

If not, it still seems like a bug since bytes following a conditional jump should _always_ be disassembled.

IMO execution should always take priority over reads, so once a ROM location has been executed, all reads do not revert the disassembly (reading of executable code could be tracked separately)

I of course don't understand how this works under the hood and what's possible with disassembly.

Calindro wrote

But from what I've seen in GBC games so far it seems like it's fairly common for them to run code in RAM.

The Gameboy has DMA transfers which typically require code to be running from RAM.

BTW, could you pre-define the known gameboy addresses in the disassembly? -- e.g. $FFFF is the interrupt mode address.

Author	Message
Maxim Site Admin Joined: 19 Oct 1999 Posts: 14939 Location: London	Posted: Sat Jun 27, 2015 7:18 am
	There's no guarantee that palette entry 16 has any contrast with sprites, in particular if it's black then since most sprites have a black border, the contrast is lost. My particular case is the in game sprites in Micro Machines.

Calindro Joined: 14 Apr 2013 Posts: 637	Posted: Thu Dec 03, 2015 9:05 pm
Calindro Joined: 14 Apr 2013 Posts: 637	Hi guys, an update of Emulicious has been released! The changes are: Some bugs have been fixed and some inconsistencies have been removed. Performance has been improved An option to enable scanlines has been added Sub-line selection in the debugger has been enabled The disassembler has been made more stable to significantly reduce the number of crashes and freezes caused by it The reference hierarchy has been improved and now also supports jump tables, pointer tables and RAM addresses Users of Emulicious can get the update via the update system. Others can grab their copy from http://www.emulicious.net

Bock Site Admin Joined: 08 Jul 2001 Posts: 8702 Location: Paris, France	Posted: Thu Dec 03, 2015 9:33 pm
	Could you make an archive of old versions available?

Calindro Joined: 14 Apr 2013 Posts: 637	Posted: Sun Dec 06, 2015 1:04 pm
Calindro Joined: 14 Apr 2013 Posts: 637	Bock wrote Could you make an archive of old versions available? Hi Bock, I don't own many (if any) old versions of Emulicious. Is there any particular need for an archive? Did anything become worse? If so, I will need help from others to build the archive.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Wed Dec 23, 2015 11:31 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Bock, I sent you a link via private message with all the archived versions I could find. Not sure which ones would be best to add to the site. I'll leave that up to you guys.

dark Joined: 09 Jan 2012 Posts: 73 Location: Germany	Posted: Sat Jan 30, 2016 4:09 pm
dark Joined: 09 Jan 2012 Posts: 73 Location: Germany	Is this a bug when i trying to open a rom file using open dialog to navigate to desktop (of Windows 10)? It shows a nice animated blue ring but nothing in this folder but there is at least one .sms file.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Thu Jun 23, 2016 4:37 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Hi Calindro; Something I just noticed -- the bytes following a conditional jump (e.g. `jp z`) should also be disassembled, Emulicious does not disassemble these unless they're executed. Disassembling the bytes following conditional jumps automatically would greatly reduce the amount of play you need to coax out all the code. Secondly it would be helpful if the disassembly would mark data regions that have never been read. This would make it easier to spot unused code/data, and to be more aware of portions of code you haven't got the emulator to execute yet.

Calindro Joined: 14 Apr 2013 Posts: 637	Posted: Thu Jun 23, 2016 8:13 pm
Calindro Joined: 14 Apr 2013 Posts: 637	Hi Kroc, Kroc wrote Something I just noticed -- the bytes following a conditional jump (e.g. `jp z`) should also be disassembled, Emulicious does not disassemble these unless they're executed. This is not true. If it doesn't get disassembled then it's for another reason. Can you point me to where it happens? Then I can tell you more. :) Kroc wrote Disassembling the bytes following conditional jumps automatically would greatly reduce the amount of play you need to coax out all the code. You can also right-click the byte and click "Set Code" to turn it into code without the need to run it. But maybe we can already figure out why it's not getting disassembled in the first place. :) Kroc wrote Secondly it would be helpful if the disassembly would mark data regions that have never been read. This would make it easier to spot unused code/data, and to be more aware of portions of code you haven't got the emulator to execute yet. The disassembler doesn't know what data is read so it also can't tell what data is not being read. You can use the Coverage recorder to see which data is being touched and which isn't.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Thu Jun 23, 2016 9:27 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Calindro wrote Can you point me to where it happens? Then I can tell you more. :) Metal Gear Solid for Gameboy Color: (kind of annoying that you can't select multiple lines in the debugger) _LABEL_150_: di ld sp, $CFFF cp $11 jr nz, + ; Data from 158 to 16D (22 bytes) .db $FA $43 $01 $FE $C0 $20 $0F $3E $01 $EA $07 $CF $3E $80 $EA $08 .db $CF $CD $A3 $06 $18 $09 You can clearly see there's code here that's not being disassembled. Thanks for looking into this.

Calindro Joined: 14 Apr 2013 Posts: 637	Posted: Thu Jun 23, 2016 10:20 pm
Calindro Joined: 14 Apr 2013 Posts: 637	Kroc wrote Calindro wrote Can you point me to where it happens? Then I can tell you more. :) Metal Gear Solid for Gameboy Color: (kind of annoying that you can't select multiple lines in the debugger) _LABEL_150_: di ld sp, $CFFF cp $11 jr nz, + ; Data from 158 to 16D (22 bytes) .db $FA $43 $01 $FE $C0 $20 $0F $3E $01 $EA $07 $CF $3E $80 $EA $08 .db $CF $CD $A3 $06 $18 $09 You can clearly see there's code here that's not being disassembled. Thanks for looking into this. Open the Disassembler Settings and enable "Allow calls to unknown RAM".

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Thu Jun 23, 2016 10:35 pm
Kroc Joined: 08 Dec 2013 Posts: 200	That did it, but why was that?

Calindro Joined: 14 Apr 2013 Posts: 637	Posted: Thu Jun 23, 2016 10:47 pm
Calindro Joined: 14 Apr 2013 Posts: 637	Kroc wrote That did it, but why was that? When this option is disabled and there is a branch to unknown RAM (the disassembler doesn't know what's in RAM at that place as it reaches the branching point) the disassembler assumes the branch to be invalid. This option is meant to be a hint from the user about the ROM being examined. If you know that a ROM does definitely not run code from RAM then you can disable the option. Otherwise you can enable it. Most SMS games don't run code from RAM or if they do it's easy to track because they just copy a block from ROM to RAM via LDIR. So it is safer to have this option disabled. But from what I've seen in GBC games so far it seems like it's fairly common for them to run code in RAM. On the other hand the GB disassembler is still very untested so it is very likely to be immature.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Jun 24, 2016 8:10 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Are you saying that that portion of ROM is being copied to RAM causing the misinterpretation as data? If not, it still seems like a bug since bytes following a conditional jump should _always_ be disassembled. IMO execution should always take priority over reads, so once a ROM location has been executed, all reads do not revert the disassembly (reading of executable code could be tracked separately) I of course don't understand how this works under the hood and what's possible with disassembly. Calindro wrote But from what I've seen in GBC games so far it seems like it's fairly common for them to run code in RAM. The Gameboy has DMA transfers which typically require code to be running from RAM. BTW, could you pre-define the known gameboy addresses in the disassembly? -- e.g. $FFFF is the interrupt mode address.

Forums

View topic - Emulicious Major Update