WFDis - 6502/65C02 interactive disassembler

[White Flame]

[I've mentioned this project a few times on this board, but I might as well give it its own thread.]

WFDis is an interactive disassembler, with the front-end written in JavaScript, for portability and to give it a nice presentation. There is a much more powerful back-end in development, but the front-end is reasonable enough to use on its own.

It now supports 4 variants of the 6502, including the 65C02. The new 65C02 support is largely untested, as I don't really work with that chip, but I've had requests for supporting it and it should bring more of an audience to trying it out, especially from this board.

Saving/loading the current state of the disassembly to browser localStorage, as well as downloading/resuming from local files is supported. Full export to .asm files is not yet there, but is forthcoming.

It is slanted towards the Commodore 64, allowing viewing graphics for characters & sprites right in the disassembly, BASIC line analysis, and has common ROM labels pre-installed when loading C64-specific file formats. However, general 6502 code should pose no issue, and it can load raw .bin/.rom binary files without any C64 specifics involved.

More docs are available in the "Help" tab in the upper right of the page.

There's still a lot to do in the front-end, but it is usable as is. Any feature requests, bug reports, and generally using it is certainly welcome. Some features won't be a part of the standalone JavaScript version, but take enough analysis oomph to be on the full server version only. This does assume a modern HTML5/ES6 browser, with no concessions for older systems. There's a section in the Help docs listing known issues that will be updated.

Thanks!

[BigDumbDinosaur]

White Flame wrote:

WFDis is an interactive disassembler, with the front-end written in JavaScript, for portability and to give it a nice presentation. There is a much more powerful back-end in development, but the front-end is reasonable enough to use on its own.

Interesting, but I find the disassembly tough to read with all that pastel-like color.

[BigEd]

The help menu suggests that 'm' will toggle multicolour mode, BDD.

Whiteflame, I think maybe you are assuming Commodore-style binaries where the first two bytes are a load address? Would be nice to be able to toggle that, and supply a load address manually for Acorn-style binaries, or ROM dumps.

I loaded TUBE from this site
http://mdfs.net/Software/Tube/BBC/
and all I'm getting is a hex dump - can I force a disassembly?

[White Flame]

BDD: Would you prefer straight monochrome, or that the colors were simply closer in color/intensity but still distinguished?

BigEd: Multicolor mode swaps the display of graphics data between hires and wide-pixel multicolor; that was working, but is now on the bug list. I've changed some internal representations and event models, and there were a few casualties. When you switch bytes to a char/sprite display, it's only hi-res 1bpp for now.

The help page lists the file formats. If the file extension is .rom or .bin, then it asks you for a load address and loads the entire binary at that address. When loading like this, the only start addresses automatically disassembled are from the top $fffx vectors, if the image reaches there. Commodore-style .prg is the default if there's no recognized filename extension. While I do like the idea of "just does the right thing", I am considering having the user explicitly specify how the file is loaded every time.

To start a disassembly trace otherwise, select the byte at an entry address and hit Shift-a.

[BigEd]

Thanks! That's working much better, with the file renamed to have an extension, and using shift-A

I notice that 'u' will delete a line - is that a bug?

[White Flame]

Yeah. I thought I had that all fixed... It works to convert asm code back to unknown bytes, but on a row that's already just unknown hex bytes I duplicated that bug.

If you select the range surrounding those lines, and hit 'c' and 'u' to convert to chars and back to unknown, it forces those lines to be refreshed and displays properly again. Shift + cursor keys selects spans of bytes.

EDIT: should be fixed now.

[BigDumbDinosaur]

White Flame wrote:

BDD: Would you prefer straight monochrome, or that the colors were simply closer in color/intensity but still distinguished?

I'd prefer monochrome—black on white. I don't see any value in color in this sort of application. If color is going to be used, high contrast colors would work best, for me at least.

[BigDumbDinosaur]

BigEd wrote:

The help menu suggests that 'm' will toggle multicolour mode, BDD.

I couldn't get that to work.

Quote:

Whiteflame, I think maybe you are assuming Commodore-style binaries where the first two bytes are a load address? Would be nice to be able to toggle that, and supply a load address manually for Acorn-style binaries, or ROM dumps.

Interesting things happen when the disassembler encounters an unknown opcode. Just for grins, I tried loading in a 65C816 binary which starts off thusly:

Code: Select all

;================================================================================
;
;hrst: HARD SYSTEM RESET & POST
;
hrst     sei                   ;no IRQs during 1st stage POST
         sec                   ;select emulation mode to...
         xce                   ;default the MPU
         stz hmubas+hmumcfg    ;select default memory map
         clc
         xce                   ;select & stay in native mode

The first and second instructions disassembled as expected, and then disassembly stopped when the first XCE instruction was encountered—naturally, the disassembler wouldn't recognize that instruction but if running in 65C02 mode, ought to see it as a NOP. Also, the "memory dump" started jumping around once XCE was encountered, with parts of it vanishing. I had the disassembler set to 65C02 mode, which means it should recognize the STZ instruction as valid.

[White Flame]

Can you attach a binary? I don't have any 65c02 code of my own to test, and things that would trigger NOPs would be useful. However, the 65c02's "undefined" NOPs still can have addressing modes, so it might not disassemble as a 1-byte instruction. I don't have full information on that yet, which is the reason some of those are still un-disassembled. If you have tables which show the addressing mode of the NOPs, that'd be well appreciated. The closest I got was a document saying that the address modes are "as the opcode bits would imply", but as there's some weirdnesses across .X vs .Y indexing, I don't feel I have enough information to truly disassemble it yet.

The unknown hex dumps render at a lower priority than the disassembled lines, because they need to be manually flowed. They should all fill in last, after all other tracing is done. That avoids a lot of unnecessary work compared to reflowing them every time an instruction is disassembled.

HTML allows switching out alternate style sheets, which I can use to create a choice for high-contrast color scheme, so that shouldn't be a biggie. I tend to prefer strong visual distinction between code/comments/data, known labels vs unknown addresses, and the like.

[BigDumbDinosaur]

White Flame wrote:

Can you attach a binary?

Please see attached. The load address is $00C000, but the code in question begins at $00E000.

[nyef]

White Flame wrote:

However, the 65c02's "undefined" NOPs still can have addressing modes, so it might not disassemble as a 1-byte instruction. I don't have full information on that yet, which is the reason some of those are still un-disassembled. If you have tables which show the addressing mode of the NOPs, that'd be well appreciated.

You might find this, by forum member Dr Jefyll, to be of interest: http://laughtonelectronics.com/Arcana/K ... pping.html

[BigEd]

I'd be happy to see a monochrome mode too, possibly using bold or italic to distinguish datatypes. I'm no fan of low-contrast!

How about showing byte values as ASCII (or PETSCII) - perhaps in comments?
41,42,43 ; 'A', 'B', 'C'
or
41,42,43 ; "ABC"

[BigDumbDinosaur]

BigEd wrote:

How about showing byte values as ASCII (or PETSCII) - perhaps in comments?
41,42,43 ; 'A', 'B', 'C'
or
41,42,43 ; "ABC"

In other words, similar to what one would see when dumping memory in a machine language monitor.

Monitor Memory Dump

[White Flame]

nyef wrote:

You might find this, by forum member Dr Jefyll, to be of interest: http://laughtonelectronics.com/Arcana/K ... pping.html

Thank you!

However, in implementing this, there's still a missing hole: In the 65SC02, are the addressing mode & timings for $x7 and $xF the same as the bit operations of the full 65C02, or are they 1-byte, 1-cycle NOPs? I suspect the latter, as a description here says that "undocumented" NOPs of the xxxxxx11 variety are 1 byte, 1 cycle, but that's after describing the bit ops, so I'm not sure what coverage that statement has.

(Also, is my selection of "65C02" and "65C02 + bit ops" a good way to label it, or would "65C02" (with bit ops) and "65SC02" (without) be better? I don't know whether "65C02" on its own implies having RMB/SMB/BBx in most people's minds.)

Regarding the hex dump showing characters, I had been mulling what format to display such characters. As this version is C64 oriented, there's screen codes & PETSCII codes which are different, and then of course ASCII. Many games have their own byte ranges for characters in their custom fonts & tilesets, so it's not necessarily a global setting either, but specific to each range of addresses. I'll certainly have some options for this later, as I agree that's an expected part of hex dumps, but I have some more pondering to do on it.

[BigEd]

However you name them, I think it will be useful to distinguish the early Rockwell C02 parts (as used in some Acorn micros) and the more recent WDC C02 parts (which we can buy today)

Edit: fair enough, the display of strings is not completely straightforward! But I imagine you will find a solution. (perhaps a four way toggle? If you add in some directives for the four cases, that could also be a state-rotating button, perhaps: hex, ascii, petscii, screen.)