Page 1 of 1

6502 disassemblers.

Posted: Mon Nov 22, 2004 1:34 pm
by koitsu
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?

Posted: Mon Nov 22, 2004 2:02 pm
by tepples
What essential feature do popular disassemblers lack?

Posted: Mon Nov 22, 2004 2:19 pm
by koitsu
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...

Posted: Mon Nov 22, 2004 2:45 pm
by Hyde
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#?

Re: 6502 disassemblers.

Posted: Mon Nov 22, 2004 3:25 pm
by doynax
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.

Posted: Mon Nov 22, 2004 5:04 pm
by tepples
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.

Posted: Tue Nov 23, 2004 9:23 am
by koitsu
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.

Posted: Tue Nov 23, 2004 11:21 am
by Disch
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

Posted: Tue Nov 23, 2004 2:11 pm
by Hyde
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.

Posted: Tue Nov 23, 2004 2:58 pm
by teaguecl
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>

Posted: Tue Nov 23, 2004 3:07 pm
by Hyde
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++.

Posted: Tue Nov 23, 2004 4:58 pm
by teaguecl
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:)