6502 disassemblers.

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

6502 disassemblers.

Post by koitsu » Mon Nov 22, 2004 1:34 pm

Is it just me or do all of the present-day 6502 disassemblers blow goats? Hell, even the one I wrote back in the 90s in Pascal blows goats.

What gives?

tepples
Posts: 21802
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Nov 22, 2004 2:02 pm

What essential feature do popular disassemblers lack?

User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu » Mon Nov 22, 2004 2:19 pm

Most I've found suffer from the following idiocies:

* Expect specific binary sizes (i.e. 32K or 16K)
* Expect NES images (i.e. full game images with iNES header)
* Do not allow you to specify a src address offset (i.e. $E000 vs. the usual $8000 or $C000)
* Cannot disassemble to code that is easily re-assembled (i.e. without address labels / opcodes+operand bytes)
* Do not support lowercase mneumonics (i.e. all opcodes in uppercase)
* Do no form of proper code tracing (NESRev does this by implementing a small emulator-like pre-pass which generates pretty clean code)
* For those which insert inline comments for NES PPU registers / etc., do not allow you to disable this behaviour
* Do not include binaries for *IX platforms (or do not include source); I consider this a minor issue, though

If you look at all of the 6502 disassemblers out there, you won't find any which encompass all of the above -- or even HALF of the above.

Pretty amazing, if you ask me. I always have such a hard time understanding why video game consoles **never** have decent public tools for them. In the case of the NES, tools today are (generally) in the same condition they were 10 years ago. There are some CHR-oriented tools which finally came out that suffice (YYChr, for example), but for code work, nothing has changed.

In this case, I'm starting to wonder if some of the Atari 2600 6502 disassemblers would suffice instead...

Hyde
Posts: 101
Joined: Mon Sep 27, 2004 11:51 pm

Post by Hyde » Mon Nov 22, 2004 2:45 pm

Which reminds me to release mine some time soon... The only reason I have not released it yet is because I keep coming up with new ideas for it... If I do release it, however, would a lot of people have problems with it because it's coded in C#?

doynax
Posts: 162
Joined: Mon Nov 22, 2004 3:24 pm
Location: Sweden
Contact:

Re: 6502 disassemblers.

Post by doynax » Mon Nov 22, 2004 3:25 pm

Yay, my first post =)

IDA (the interactive dissassembler) supports just about everything on that list except for the Unix support. Some of it's features, like the scripting language or graphing functions, are simply mind blowing compared to anything I've ever used.

Unfortunatley it's far from free and the interface can be a bit awkward.

tepples
Posts: 21802
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Nov 22, 2004 5:04 pm

koitsu wrote:Most I've found suffer from the following idiocies:

[...]
* Cannot disassemble to code that is easily re-assembled (i.e. without address labels / opcodes+operand bytes)
* Do not support lowercase mneumonics (i.e. all opcodes in uppercase)
Is what you sed important? (pun intended) Besides, if you change something that inserts or removes one or more bytes, the code may not reassemble into something that still runs, as it's not always possible to determine what is part of an address without solving the Halting Problem.
* Do no form of proper code tracing (NESRev does this by implementing a small emulator-like pre-pass which generates pretty clean code)
And when it gets to code loaded into RAM, now you're trying to solve the Halting Problem. Besides, how can even a tracing disassembler expect to trace across banks for a given unknown mapper? Or should a tracing emulator for a given platform be expected to know about all memory management and I/O layouts for all platforms and peripherals that use a given instruction set architecture? In that case, it'd probably be best to couple the tracing disassembler to the CPU core of a full-scale emulator in order to reliably mark addresses as code or data.
* Do not include binaries for *IX platforms (or do not include source); I consider this a minor issue, though
Not everybody has access to a *IX system to test on, as many people don't know how to shrink their NTFS hard drives to open up some space to install *IX.
I always have such a hard time understanding why video game consoles **never** have decent public tools for them.
Is it because Nintendo puts all the good tools under non-disclosure agreements or threatens to sue the maintainers that don't give in?

It appears YY-Chr is not free software either, nor is it well documented in the English language. I'm still stuck with TED, which I wrote as a free and cross-platform alternative to Tile Layer Pro.

User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu » Tue Nov 23, 2004 9:23 am

Hyde wrote:Which reminds me to release mine some time soon... The only reason I have not released it yet is because I keep coming up with new ideas for it... If I do release it, however, would a lot of people have problems with it because it's coded in C#?
Absolutely not. C# is just fine; if it has .NET reliance, IMHO, that's fine too. Java, on the other hand... well... I won't get into that. :)

Finish it up and put it somewhere. I'll give it a few test runs if you'd like.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Tue Nov 23, 2004 11:21 am

koitsu wrote:Absolutely not. C# is just fine; if it has .NET reliance, IMHO, that's fine too. Java, on the other hand... well... I won't get into that. :)
Ironically... I feel just the opposite. Java is fine, C# is what's "ew". XD

Hyde
Posts: 101
Joined: Mon Sep 27, 2004 11:51 pm

Post by Hyde » Tue Nov 23, 2004 2:11 pm

koitsu wrote: Finish it up and put it somewhere. I'll give it a few test runs if you'd like.
It's up on my website. Go to the Games Sources section to get the disassembler and go the aNESe page to get the emulator, which can be used to generate files containing label info (files are named as "Addresses.log"). The disassembler should be able to handle a lot of the Mapper 0, 3 games without the help of aNESe, but if you'd like to disassemble a different game (1, 7) you gotta use the data retrieved by the emulator.

User avatar
teaguecl
Posts: 210
Joined: Thu Oct 21, 2004 4:02 pm
Location: San Diego

Post by teaguecl » Tue Nov 23, 2004 2:58 pm

Not trying to hijack this tread, but I'm with Disch on this one, Java over C# any day. People should develop on whatever platform they want, with whatever langauge they want. But they should consider the hoops they will make their end users jump through to use their product before they choose. Personally, running anything on C# would require a significant amount of effort for me, as I refuse to run Microsoft based systems. C# on linux isn't exactly perfect, but is workable. But if someone wants to release something on C# they should consider users like me (and I know there aren't that many) as a non-viable market for their product.
</rant>

Hyde
Posts: 101
Joined: Mon Sep 27, 2004 11:51 pm

Post by Hyde » Tue Nov 23, 2004 3:07 pm

Here we go again :D . The only reason I coded my app in C# was because I hadn't done anything in C# before, and this seemed like a good opportunity to exploit the language and its advantages. I think it's an interesting language, but I'm not going to write any other applications in it mostly because everything done in C++ is just a lot more portable and faster. What do I think about Java? It's nothing but a castrated C++.

User avatar
teaguecl
Posts: 210
Joined: Thu Oct 21, 2004 4:02 pm
Location: San Diego

Post by teaguecl » Tue Nov 23, 2004 4:58 pm

After re-reading my earlier post, it's a little more confrontational than I meant it to be, sorry about that. I didn't mean to criticize anyones choice of language, just to point out how that choice can affect the applications usefulness to different end users. I'm a little touchy on this subject. Don't even get me started on UNIF:)

Post Reply