Jump to content
IGNORED

DIS6502 - The Interactive 6502 Disassembler


JAC!

Recommended Posts

On 7/21/2023 at 8:37 PM, tschak909 said:

This does not play nice on HiDPI displays under Wine, at all. :(

 

Windows applications _ARE NOT_ supposed to _HARD CODE_ font metrics. sigh.

 

image.thumb.png.118fb51725dca7ffde1149f51b6b53d6.png

The program started in 1997 on Win XP with a fixed pixel layout for 640x320. In fact Windows Forms force you to use pixels until today. With DIS6502 3.6, I've implemented an own layout manager which can handle different screen sizes and font sizes. Note that all you see are self-implemented non-standard controls. You can use "Double Font Height" from the "View" menu already. More scaling options are planned. But since this is a pixel exact fixed size font, only integer multiples make sense/will look OK.

 

Double Font Height:

image.thumb.png.a434e8049d2131da4b81af4f2335a1bc.png

  • Like 3
Link to comment
Share on other sites

1 hour ago, JAC! said:

The program started in 1997 on Win XP with a fixed pixel layout for 640x320. In fact Windows Forms force you to use pixels until today. With DIS6502 3.6, I've implemented an own layout manager which can handle different screen sizes and font sizes. Note that all you see are self-implemented non-standard controls. You can use "Double Font Height" from the "View" menu already. More scaling options are planned. But since this is a pixel exact fixed size font, only integer multiples make sense/will look OK.

 

Double Font Height:

image.thumb.png.a434e8049d2131da4b81af4f2335a1bc.png

About double height...

 

image.thumb.png.dac21d5e23cf66cf85e7585ac214f2d8.png

-Thom

Link to comment
Share on other sites

On 7/24/2023 at 3:00 AM, tschak909 said:

About double height...

 

-Thom

The correct font is used, by it is not correctly scaled. This is a bug in the CreateFont() handling of Wine. It works correctly on real Windows.

The long-term solution would be using the TTF fonts that are part of https://github.com/wudsn/wudsn-ide/tree/main/com.wudsn.ide.base/fonts. But this will require switching the whole project to Unicode support, which means a major rework. Nevertheless, it would make sense. Filed as https://sourceforge.net/p/dis6502/bugs/33/ for tracking.

  • Like 2
Link to comment
Share on other sites

  • 3 months later...
On 4/12/2023 at 1:36 AM, Alfred said:

How do you disassemble a large ROM file ? I tried RAW but it doesn't work, and other modes complain about missing segments. Is there a way to disassemble a plain ROM that has no binary header ?

Which size does the ROM have? RAW files can be added as RAW with up to 64k. The current DIS6502 can also read ROM images of 4/8/16k and 8/16k CAR files. You'd have to split larger files into banks and add them separately. And of course, cross-references between the banks will be hard to map. Nevertheless, I like the idea and registered it as https://sourceforge.net/p/dis6502/feature-requests/71/ -  Support adding banked .car files. 

 

    // Get file size.
    auto bytesRemaining = fileSize;

    if ((bytesRemaining == SIZE_8K_CAR) || (bytesRemaining == SIZE_16K_CAR)) {
        byte carHeader[CAR_HEADER_SIZE];
        inputStream.Read(carHeader, CAR_HEADER_SIZE);

        if (memcmp(carHeader, "CART", 4) != 0) {
            throw IOException("Invalid stream header. Stream is not a CART stream");
        }
        bytesRemaining -= CAR_HEADER_SIZE;
    }


    // Read only 4K, 8K and 16K cartriges.
    switch (bytesRemaining) {
    case SIZE_4K:
        wBegin = BASE_4K;
        wEnd = END_4K;
        break;
    case SIZE_8K:
        wBegin = BASE_8K;
        wEnd = END_8K;
        break;
    case SIZE_16K:
        wBegin = BASE_16K;
        wEnd = END_16K;
        break;

 

  • Like 1
Link to comment
Share on other sites

  • 3 months later...
On 5/6/2023 at 2:31 AM, Irgendwer said:

* when going for single file output without any includes the result is garbage. Is this a known issue (or a problem while I'm testing under Linux with "wine")?

Bugfix version https://sourceforge.net/projects/dis6502/files/dis6502/3.6.1/ released

No new features

Fixed bugs:
- Saving listings without includes now generates correct output (bug #32)
- Block numbers in SDX blocks are now output in hexadecimal if that option is active in the profile

 

This is a "by-product" of my 4.0 developments, where I try to track down the reported issue. I keep the 3.6 version in a state where I can compile and use it for reference.
I also found and fixed a bug in version 4.0 that prevented the correct usage of the scroll bar in the disassembly window.

 

Note: Microsoft Defender incorrectly complains about the version. I've submitted https://www.microsoft.com/en-us/wdsi/submission/feb36ac1-91b6-449d-888d-c6f912fb3447 for that.

 

  • Like 1
  • Thanks 3
Link to comment
Share on other sites

  • 2 months later...

Update: The daily build of the 4.x version has been updated to be a 64-bit executable.

 

This allows it to be run (again) under Wine on macOS (where 32-bit executables are now disabled in recent versions).

 

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

  • 4 weeks later...

Update: The daily build of the 4.x version has been updated to be a Unicode application.
 

As it turned out, being a 64-bit application does not work without also changing almost all strings to wstring (wide string).
This also required the last "byte vs. char vs. wchar_t" uncertainties to be analyzed and adapted.

Which means I had to touch almost every line in every source file.
But in the end, it is again less code than before and more readable.
Yet I may have missed someplace, so keep your eyes open for incorrect texts or messages.

For compatibility, the listing's output is still ASCII only. The option to use UTF8 or similar is a future idea, but for now, I see no use case.
The XML files containing the profiles, etc., are now assumed to be UTF8 encoded.


The version also finally contains a fix for the bi-directional selection between the dump and the listing.
I've been hunting this for quite a while, and I'm really happy this is now working (even though I still don't understand the call sequence in this case 100%).
If you select bytes in the dump, the listing is positioned to the right line.
If you mark lines in the listing, the selection in the dump is adapted.

 

The thing that does not yet work properly is the dialog to edit the equates.
That's the next thing I look after; now that the core disassembly appears to work.

image.thumb.png.f62201a0477935a3a6ebd3fb1fdbbb19.png

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Question to the Users

 

I have been thinking for quite some time about how equate editing should look in the future.

In version V3.6, there is a major difference between System Equates and User Equates.
System equates are stored in files and support comments, constant definitions, and separate name definitions for read- and write access (especially relevant for hardware registers).

Opposed that user equates can only be simple address equates defined via this dialog, the distinction between read and write is not possible.

image.png.e3c3ecfcfba8d8601d20615b35bae58a.png

 

Originally, my idea for version 4.X was to extend the dialog to become a "vi-like" line editor where you select a line from the list, edit it, including the additional data (e.g., comments), and push it back.

Upon closer examination, I discovered that the current approach, while functional, can be quite cumbersome.
Particularly when dealing with many labels due to the lack of structure.

 

Therefore, my idea is to discard whole line-based editing and make the dialog a full multi-line text field editor where you can edit the content directly in the form used by today's system equate files.
The dialog might later even become a non-modal dialog that remains open while you are working in the main window.


image.thumb.png.f9a39b53ddaa4ea93ffdba3d9d57eada.png

  • Like 1
Link to comment
Share on other sites

I also like the idea of a full editor for user labels. I take it there will be some validation of the text when one clicks OK.

One idea - would you consider reviewing the order of the menu items on the Open file and Add file menus? I would say these are not ordered from the most used to the least used.

 

 

Link to comment
Share on other sites

Posted (edited)

Thank you for all your hard work on this great tool! I'm glad to hear there is possibility of a version 4 down the line.

 

I have a suggestion/request, assuming you keep the current V3.6 'Edit User Label' facility - I'd appreciate a confirmation dialog that interrupts the operation if an entry submission is about to reassign an existing label.

 

-=P=-

Edited by -=Psycho=-
Link to comment
Share on other sites

  • 2 weeks later...
On 6/4/2024 at 5:15 PM, baktra said:

I take it there will be some validation of the text when one clicks OK.

One idea - would you consider reviewing the order of the menu items on the Open file and Add file menus? I would say these are not ordered from the most used to the least used.

1) Yes, input will be validated, of course. Lines will be parsed as they are when they are read from the system equates file.

2) The order is alphabetic by intention; every other sequence would be guessing. "Most used" really depends on what you typically work on and it can be any of them. 
image.thumb.png.844198e6c315704acfc29034cc6a460b.png

  • Thanks 1
Link to comment
Share on other sites

On 2/26/2019 at 3:55 AM, Dropcheck said:

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 2 kB · 224 downloads

It is partly by design because the lookup for being referenced does not distinguish the type of the equate definition (#/</>/=) nor the access type of access (immediate,

read, write) when the address is accessed. Therefore, if the address "$02" is accessed, implicitly also, the constant "#$02" is accessed.
In the 4.x version I am working on adding this missing distinction.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...