DIS6502 - The Interactive 6502 Disassembler

[+JAC!]

DIS6502 is an interactive 6502 disassembler. It can disassemble handle plain binary files and support specific executable files of Atari 8-bit, C64 and Oric computers. This support also includes the labels and handling of the operating system vectors to make the disassembly better. It can output the assembly listing in different configurable formats and comes with preset profiles for popular assemblers like ASMED, CA64, LADS, MAC65, and MADS.

There are currently two versions available:

• Latest 3.0 beta build: https://www.wudsn.com/productions/windows/dis6502/dis6502.zipwith resizable window and many new features
• Old but stable version 2.2 from 2006: https://sourceforge.net/projects/dis6502/files/latest/download

Version 3.0 uses a new workspace format. You can open old workspaces in older formats but only save in the new format. Therefore you should make a backup of your old workspace, before using the new version. Version 3.0 is not yet officially released, but you are strongly encouraged to use it and send feedback.

[marcokitt2000]

Hello Peter,

 

Thanks for the info and the update i will check soon the new build.

 

 

Gr.

Marco

[+JAC!]

Finally nailed down the bug that prevented usage under Windows XP.

Who would have thought that basic C functions like _stat are broken there...
https://stackoverflow.com/questions/32452777/visual-c-2015-express-stat-not-working-on-windows-xp

 

The daily download is updated.

[tebe]

[+JAC!]

Oh and I think I never mentioned these two new features:

 

Unreferenced system labels are greyed out in the disassembly. And by default they are omitted in the exported listed. This can be controlled by a profile settings.

 

And you can set a prefix for the labels belonging to a segment. This is esp. useful is you have for example a pre-load/intro that loads to the same address space as the main part.

 

[Tezz]

Hi Peter,

 

I used your latest update this week, it's great to see the improvements. DIS6502 is something I use often so it's much appreciated. The only thing I've noticed so far during disassembly is that the "select sprites" was ghosted in the menu, I could still press F4 to access it but the scroll bars for the start address and sprite width were not responsive.

[ascrnet]

Hi Jac!

 

thanks for updating this program, but in win10 when copying the bytes of the segment area I closed the application alone

regards

[snicklin]

Hi Jac!

 

Could you take a look at this:

 

 

The window title thing is a minor one.

 

The code output comes out different on 3.0 to 2.2. Perhaps you have improved something, but this seems like an odd ROM anyway. I am attaching the ROM file that I have used.

 

Soccer.rom

 

{ EDIT: Please note that I dragged soccer.rom onto both windows so its type was automatically deduced }

Edited February 3, 2019 by snicklin

[+JAC!]

Thanks for the feedback. I will look after each topic.

@Tezz: I have never seen/used the Sprite function before myself. I see I have to rework the complete menu enabling. The scrollbars in 2.2 require clicking in on the bar here (not on the arrow). Looks the same in 3.0. Can you check of the arrow have words at all before?

@ascrnet: Reproduced, exception due to bug in my code

[+JAC!]

Update:

- Fixed menu items enabling in dump context menu

- Fixed horizontal scroll bar dragging in sprite selection (was already a bug in V2.2)

- Fixed copy/cut/paste in the dump / context menu

- Computer system type and (if available) path to the current workspace is now displayed in the application title bar
- Improved part window header texts to be more consistent ("No segments loaded/No segment selected")

- First version of displaying the current dump selection range in the dump title, if range selection is active. Currently only works when selecting from the disassembly.

 

 

The segments list does not display the original file after loading a workspace name because I want to change the handling of that later. Having a single file name for the workspace makes no sense because you can add/remove segments from anywhere. Therefore segments will get a comment attribute and that will contain the filename of the original file they came from as documentation.

 

Now I'll check out snicklin's example.
EDIT: Fixed, also found that. Size of ROMs is now computed correctly when they are added

[Tezz]

Hi Peter,

 

sorry, it was actually the graphics mode pull down menu that was not functioning within "select sprites", the scroll bars were still functioning the same as the old version. It will be another welcome fix for the scroll bar dragging however

[+JAC!]

Update: Sprite selection dialog/control.
- Fixed selection of graphics mode in Sprite selection dialog/control.

- Changed default of the dialog to ANTIC MODE $F/Graphics 8 and default width to 40 bytes.
- The dialog now keeps select mode and width as long as the program runs.

[Alfred]

v2.2 won't load a 64K binary, as in the BB216 eprom. Set as segment $0000-$FFFF DIS says more than 256 segments. As a Raw file, trying to load the rom version (no header), it gives a "can't allocate memory" error.

[Alfred]

v2.2 won't load a 64K binary, as in the BB216 eprom. Set as segment $0000-$FFFF DIS says more than 256 segments. As a Raw file, trying to load the rom version (no header), it gives a "can't allocate memory" error.

 

The 3.0 beta just crashes if you try to open a 64K binary., but it will load it as a raw file.

[+JAC!]

The code currently assumes that (header+segment length <=$ffff) as it stores the segment length in a 16 bit word and uses $FFFF as indicator for "no segment selected".
I plan to change this over time (see screen shot), but it affects many parts in the code and does not yet work reliably

For the time being, it should be OK if you split the 64k into 2x32 segments and add them.

[ascrnet]

Hi JAC!

 

I found another bug, when searching in the hexadecimal editor (control + f) it does not look for anything when searching by hex for example C921

regards

[Dropcheck]

Hi Peter,

 

I have occasionally used this program over the years and I'm happy to see new updates.

 

I really like the feature of graying out of unused equates. It does seem to do it with most equates on the binary file I'm testing with, but all the IO EQUATES and the DISPLAY LIST EQUATES are still showing although they are not referenced in the binary file. Is this by design or possibly a bug?

 

The file is loaded as a raw file at $800.

6500-1dump.rom

[+JAC!]

Thanks everybody for your feedback. I've added all points to the todo list.

Regarding the equates: Current value equates are added unconditionally, only address equates are omitted.

Eric implemented this, so I'll have to see if it can be improved,

 

; OS EQUATES
; ----------
;
; Syntax:
; Use '=' for addresses
; and '<' for read addresses (ex: KBCODE)
; and '>' for write addresses (ex: STIMER)
; and '#' for values
;
; IO EQUATES
;
ICHID # $00
ICDNO # $01
ICCOM # $02
ICSTA # $03
ICBAL # $04
ICBAH # $05
ICPTL # $06
ICPTH # $07
ICBLL # $08
ICBLH # $09
ICAX1 # $0A
ICAX2 # $0B
ICAX3 # $0C
ICAX4 # $0D
ICAX5 # $0E
ICAX6 # $0F
;
; DISPLAY LIST EQUATES
;
ADLI # $80
AVB # $40
ALMS # $40
AVSCR # $20
AHSCR # $10
AJMP # $01
AEMPTY1 # $00
AEMPTY2 # $10
AEMPTY3 # $20
AEMPTY4 # $30
AEMPTY5 # $40
AEMPTY6 # $50
AEMPTY7 # $60
AEMPTY8 # $70
;
; OS VARIABLES FOR XL/XE
;
; PAGE 0
;
NGFLAG = $01

[Alfred]

Graphic screen chars like horizontal bar, or the corner characters for example, cannot be displayed as string values. It still just shows them as .bytes. Is that by design ?

[Alfred]

It also seems to have a problem now recognizing the end of the file. The one I'm looking at, the last segment is the $02E0-1 run vector. After that it loops back and shows the segments from the beginning again. I only twigged because I realized I was seeing the same text strings.

[+JAC!]

Graphic screen chars like horizontal bar, or the corner characters for example, cannot be displayed as string values. It still just shows them as .bytes. Is that by design ?

 

That is the default, because the listing will otherwise contain characters you cannot handle with a PC/ASCII editor.

You can uncheck the "Display Non-ASCIII Characters As Bytes" setting in the profile. The only EOL/$9B, the quote defined in the profile and $00 are represented as bytes.

 

 

It also seems to have a problem now recognizing the end of the file. The one I'm looking at, the last segment is the $02E0-1 run vector. After that it loops back and shows the segments from the beginning again. I only twigged because I realized I was seeing the same text strings.

 

I think I've fixed that already in my local build and I don't see that effect. But because of a larger refactoring I cannot currently upload it. Please check again with the next build.

 

As for the other remarks above, they're on the list and not forgotten.

[Alfred]

Couple of other things about the current version. The two windows are now disconnected, which manifests in two ways. If the executable is a single large segment, for example say $3000-$9FFF, when you click on any instruction in the right window, the left window always jumps to the top. If the file is multiple segments, and the instruction you click in the right window is not in the left window segment, then the left window does nothing at all. It no longer jumps to the proper segment. The jumping to the top is really annoying, as is the constantly having to scroll the window back down.

 

A feature request: Can you make the characters larger, like say twice their size ? I run 1920x1080 on dual 27" LCD panels, and even with DIS6502 expanded to full screen, it's very hard to read the hex digits of the left window from where I sit, about 40 inches from the monitors.

[+JAC!]

Couple of other things about the current version. The two windows are now disconnected, which manifests in two ways. If the executable is a single large segment, for example say $3000-$9FFF, when you click on any instruction in the right window, the left window always jumps to the top. If the file is multiple segments, and the instruction you click in the right window is not in the left window segment, then the left window does nothing at all. It no longer jumps to the proper segment. The jumping to the top is really annoying, as is the constantly having to scroll the window back down.

 

A feature request: Can you make the characters larger, like say twice their size ? I run 1920x1080 on dual 27" LCD panels, and even with DIS6502 expanded to full screen, it's very hard to read the hex digits of the left window from where I sit, about 40 inches from the monitors.

 

>If the executable is a single large segment, for example say $3000-$9FFF, when you click on any instruction in the right window, the left window always jumps to the top.

With "Left" you mean the hex dump? Will check that.

 

>A feature request: Can you make the characters larger, like say twice their size ? I run 1920x1080 on dual 27" LCD panels, and even with DIS6502 expanded to full screen, it's very hard to read the hex digits of the left window from where I sit, about 40 inches from the monitors.

The option to double the character height is in the menu.

[Alfred]

 

>If the executable is a single large segment, for example say $3000-$9FFF, when you click on any instruction in the right window, the left window always jumps to the top.

With "Left" you mean the hex dump? Will check that.

 

>A feature request: Can you make the characters larger, like say twice their size ? I run 1920x1080 on dual 27" LCD panels, and even with DIS6502 expanded to full screen, it's very hard to read the hex digits of the left window from where I sit, about 40 inches from the monitors.

The option to double the character height is in the menu.

 

So it is, that's much better. Yes, I mean the hex window jumps to the top of the segment when you click a line in the disassembly window.

[Alfred]

Oh yes, another bug. If you save the workspace and then say "New Workspace" it always asks if you want to save. If there was no changes, it shouldn't ask, imo.