DIS6502 - The Interactive 6502 Disassembler

[+JAC!]

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.

 

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:

[tschak909]

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:

About double height...

 

-Thom

[+JAC!]

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.

[+JAC!]

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;

 

[+JAC!]

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.

 

[+JAC!]

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).

 

[marcokitt2000]

Thnxx Peter,

 

Keep the good work i am still busy in 3d printing world and klipper and marlin.....

 

 

Greeetings Marco

[+JAC!]

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.

[+JAC!]

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.

 

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.

[janzh]

Great Work! 👍🏻

I like the idea of a full text edit for user labels.

[baktra]

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.

 

 

[-=Psycho=-]

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 clobber a previously existing label which happens to be assigned the submitted address.

 

-=P=-