DIS6502 - The Interactive 6502 Disassembler

[ascrnet]

7 hours ago, ebiguy said:

Thank you very much for your feedback.

I fixed this issue.

You can download the version 3.1 at the same location.

Thanks to you for solving it so quickly, but I found something else that I use a lot that doesn't work in the new version, which is to search in Hex (CONTROL+F)

 

Greetings

[ebiguy]

1 hour ago, ascrnet said:

I found something else that I use a lot that doesn't work in the new version, which is to search in Hex (CONTROL+F)

Again, thank you for finding this issue.

The bug is when you include a byte with Hex value greater that $80.

We need more users like you!

The bug is fixed in a new version.

You can get the version 3.2 at the usual location.

https://sourceforge.net/projects/dis6502/files/latest/download

[ascrnet]

2 hours ago, ebiguy said:

Again, thank you for finding this issue.

The bug is when you include a byte with Hex value greater that $80.

We need more users like you!

The bug is fixed in a new version.

You can get the version 3.2 at the usual location.

https://sourceforge.net/projects/dis6502/files/latest/download

quite the opposite thanks to you. The search is already working but the vertical scroll of the light blue area where I found the bytes does not move

Greetings

[ebiguy]

18 hours ago, ascrnet said:

The search is already working but the vertical scroll of the light blue area where I found the bytes does not move

OK, I fixed it in version 3.3 available with the same usual link.

[marcokitt2000]

On 5/16/2020 at 11:53 PM, ascrnet said:

Hi ebiguy and JAC!,

 

thanks for the new version, but I miss clicking on the position and it shows where it is as version 2.2

Greetings

 

Hello Eric,

Check first 1 2 3 image bne reference is  SxxxLxxx label rename to lxxx and the reference is working. allso the image 4 manual renamed than working, this must be a error in the old 3.0 and the equ when i do ghostbusters 02e2 e3 initad is show and 02e0 e1 runad is greyed.

And a other error when i save wrk and start dis6502 and load wrk than some of SxxxLxxxx of some comeback must be renamed again.

What i do i save allso the equ and load it after wrk load and than is ok.

Why i do ghostbusters late 1990 91 i had some tool from a atari friend dissassembler ( not the mosfilm) i dont no if it was basic or machine code.

But i had dissassembled and than used mac65 to compile it was working only the header with logo was bad. I hope wit this to do it ok now see how ghostbusters little by little works.

 

 

Gr.

Marco (sorry for my bad English)

[ascrnet]

5 hours ago, ebiguy said:

OK, I fixed it in version 3.3 available with the same usual link.

thanks now if the search works perfectly, another thing that I miss is the list of defined memory areas of the program L0082-LFFFF I don't know if it is because of what marcokitt2000 mentions by the tags "SxxxLxxx"

Greetings

 

[ebiguy]

13 hours ago, marcokitt2000 said:

Check first 1 2 3 image bne reference is  SxxxLxxx label rename to lxxx

I think your problem is related to the migration from a previous 3.0beta version to this version.

Some of the 3.0beta where using the SnnnLxxxx labels but Peter does not like these long labels so, in the official version 3.x, I use short labels (Lxxxx) for Atari binaries and long labels (SnnnLxxxx) for SDX binaries.

In my opinion, long labels should always be used because some segments may have overlapping addresses and having long labels is mandatory to have an accurate disassembly in such a situation.

Anyway, your workspace has still some long labels but, once loaded, the DIS6502 applies the new rules and it produces this usage of mixed label types.

I can have a look if you upload your .wrk and also the file (xex or whatever).

But I guess that I won't be able to do something about the compatibility with these workspace files created during the 3.0beta period.

 

11 hours ago, ascrnet said:

I miss is the list of defined memory areas of the program L0082-LFFFF I don't know if it is because of what marcokitt2000 mentions by the tags "SxxxLxxx"

Well, no, the issue with SnnnLxxxx is not related to your issue.

Dealing with labels in DIS6502 is a quite complex topic and, in this version I removed the generation of labels if they are not part of the disassembly.

If an instruction is referencing an address inside the disassembled segments (like a BNE L3452), then a label is generated.

If an instruction is referencing an address outside the disassembled segments, then no label is generated. A constant is used in the instruction. And this is a difference with old version 2.2.

In version 2.2, in such a case, labels were created and defined in the Code equates section. Now, there is no Code equates section.

At first, I thought that having all these code equates was noisy.

But I understand with all your previous messages that it is a bad change because without labels, you can not look at the reference panel to see the instructions using this label.

I will try to re-introduce these code equates but this time, it will take more time to do it so don't expect a version 3.4 in the evening...

Edited May 19, 2020 by ebiguy

[marcokitt2000]

 

8 hours ago, ebiguy said:

I think your problem is related to the migration from a previous 3.0beta version to this version.

Some of the 3.0beta where using the SnnnLxxxx labels but Peter does not like these long labels so, in the official version 3.x, I use short labels (Lxxxx) for Atari binaries and long labels (SnnnLxxxx) for SDX binaries.

In my opinion, long labels should always be used because some segments may have overlapping addresses and having long labels is mandatory to have an accurate disassembly in such a situation.

Anyway, your workspace has still some long labels but, once loaded, the DIS6502 applies the new rules and it produces this usage of mixed label types.

I can have a look if you upload your .wrk and also the file (xex or whatever).

But I guess that I won't be able to do something about the compatibility with these workspace files created during the 3.0beta period.

 

Well, no, the issue with SnnnLxxxx is not related to your issue.

Dealing with labels in DIS6502 is a quite complex topic and, in this version I removed the generation of labels if they are not part of the disassembly.

If an instruction is referencing an address inside the disassembled segments (like a BNE L3452), then a label is generated.

If an instruction is referencing an address outside the disassembled segments, then no label is generated. A constant is used in the instruction. And this is a difference with old version 2.2.

In version 2.2, in such a case, labels were created and defined in the Code equates section. Now, there is no Code equates section.

At first, I thought that having all these code equates was noisy.

But I understand with all your previous messages that it is a bad change because without labels, you can not look at the reference panel to see the instructions using this label.

I will try to re-introduce these code equates but this time, it will take more time to do it so don't expect a version 3.4 in the evening...

 

Hello Eric,

 

I will sent you later my ghostbusters.wrk and my users equ when i save wrk i save first equ.

Load wrk than users equ.

I was started with dis6502 3.3 latest build.

 

Gr. Marco

 

 

 

wrk and the equ and floppy 6a atr first game is ghostbusters.

 

 

gr.

ghostbusters.equ ghostbusters.wrk floppy 6A.ATR

Edited May 19, 2020 by marcokitt2000

[ascrnet]

6 hours ago, ebiguy said:

Well, no, the issue with SnnnLxxxx is not related to your issue.

Dealing with labels in DIS6502 is a quite complex topic and, in this version I removed the generation of labels if they are not part of the disassembly.

If an instruction is referencing an address inside the disassembled segments (like a BNE L3452), then a label is generated.

If an instruction is referencing an address outside the disassembled segments, then no label is generated. A constant is used in the instruction. And this is a difference with old version 2.2.

In version 2.2, in such a case, labels were created and defined in the Code equates section. Now, there is no Code equates section.

At first, I thought that having all these code equates was noisy.

But I understand with all your previous messages that it is a bad change because without labels, you can not look at the reference panel to see the instructions using this label.

I will try to re-introduce these code equates but this time, it will take more time to do it so don't expect a version 3.4 in the evening...

No problem can be expected, this reference is useful, it would be good if the ones between L0082 and LFFFF appear.

I think it would be nice to be able to select the type of binary if it is traditional or SDX, for example I am testing with the Tiger Attack game and those S000L2F12 labels appear I do not make much sense to it.

Greetings

[marcokitt2000]

Hello Eric,

 

I found a other problem when i load my ghostbusters.wrk and than users equ , than i use F4 select sprite 1st time work than 2nd time not i must press esc key to work on dis6502 but when select again still not working must restart all so when i do another program etc.

 

 

 

gr. marco

Edited May 21, 2020 by marcokitt2000

[ebiguy]

Dear users,

 

On 5/18/2020 at 11:32 PM, marcokitt2000 said:

And a other error when i save wrk and start dis6502 and load wrk than some of SxxxLxxxx of some comeback must be renamed again

 

On 5/19/2020 at 1:39 AM, ascrnet said:

another thing that I miss is the list of defined memory areas of the program L0082-LFFFF

 

I fixed the issues with the labels.

@marcokitt2000, now you can reload your workspace and the labels should be fine without renaming them.

 

On 5/19/2020 at 7:10 PM, ascrnet said:

it would be good if the ones between L0082 and LFFFF appear.

Now DIS6502 generates equates even for addresses outside segments (like the old v2.2).

 

Here is the readme file from the v3.4 which is available at the usual location:

https://sourceforge.net/projects/dis6502/files/latest/download

 

New features:
- Equates are now created for all addresses pointing outside segments

 

Fixed bugs:
- when disassembling an Atari binary file (not SDX), some long labels (SnnnLxxxx) are wrongly generated
- page 7 system labels are used only when disassembling an SDX binary
- the Sprite Search dialog box can not be displayed 2 times

Edited May 22, 2020 by ebiguy

[marcokitt2000]

Hello Eric,

 

 

So thats fast i will check it some minutes.

 

Thnxxxxx

 

 

Test so far good.

 

I have some questions about the profiles (prf) i mean asmed.prf etc etc etc.

when i start dis6502 and open the profile these are different to lads,mac65,asmed,ca65 what is the original defaults i save it.

For wich asmbler is it to use?

 

 

 

1st time startup defaults.prf

Edited May 22, 2020 by marcokitt2000

[+skr]

Is this 32-Bit software? Because it doesn´t run with Wine64 on OS X Catalina, which only runs 64-Bit applications. Any chance to make it 64-Bit?

[ebiguy]

1 hour ago, marcokitt2000 said:

For wich asmbler is it to use?

This is for MADS. The only cross assembler allowing you to build both an Atari executable and an SDX executable.

 

1 hour ago, skr said:

Any chance to make it 64-Bit?

There will be a 64bit version.

This will be the next major release prepared by Peter.

But there is no delivery date.

[marcokitt2000]

1 hour ago, ebiguy said:

This is for MADS. The only cross assembler allowing you to build both an Atari executable and an SDX executable.

 

There will be a 64bit version.

This will be the next major release prepared by Peter.

But there is no delivery date.

oke default is mads with sdx and when i load mads.prf from the dis6502/profiles is old one only for atari executable?

there is a difference see picture. 

 

[ascrnet]

thanks ebiguy for the new version 3.4?

 

now some details,

when converting bytes to screen there are double quotes at the beginning and single quotes at the end

 

Another one that I noticed when opening a file "ti.xex" and then another ".menu.xex" the program adds them. in the old version it deleted everything or is this a new functionality?

 

that for the moment

Greetings

 

[ebiguy]

9 hours ago, marcokitt2000 said:

default is mads with sdx and when i load mads.prf from the dis6502/profiles is old one only for atari executable?

I will change the profiles in the next release because:

1) all profiles are still in the old binary format instead of the XML format

2) there are some errors. There should be no difference between MADS.prf and the default configuration but I see with your screenshot that they differ.

 

8 hours ago, ascrnet said:

when converting bytes to screen there are double quotes at the beginning and single quotes at the end

Thank you for reporting this bug I did not notice.

I will wait for other changes to group the fixes in a next release.

 

8 hours ago, ascrnet said:

in the old version it deleted everything or is this a new functionality?

This is Peter's change.

Do you prefer the old 2.2 behaviour (replacing) or the new behaviour (adding)?

Edited May 23, 2020 by ebiguy

[marcokitt2000]

1 hour ago, ebiguy said:

I will change the profiles in the next release because:

1) all profiles are still in the old binary format instead of the XML format

2) there are some errors. There should be no difference between MADS.prf and the default configuration but I see with your screenshot that they differ.

 

Thank you for reporting this bug I did not notice.

I will wait for other changes to group the fixes in a next release.

 

The is Peter's change.

Do you prefer the old 2.2 behaviour (replacing) or the new behaviour (adding)?

Hello Eric,

 

Replacing and adding maybe a new option?

And when is segment merge come to work? I now Peter was still busy with it.

 

But thnxxx for your fast replay and make dis6502 better.

Have a nice atari day.

 

 

Gr. Marco

[+JAC!]

4 hours ago, marcokitt2000 said:

Replacing and adding maybe a new option?

 

Yes, there will be "Add File" in addition to "Open File".

[ascrnet]

8 hours ago, ebiguy said:

Thank you for reporting this bug I did not notice.

I will wait for other changes to group the fixes in a next release.

I totally agree, while I keep reviewing

 

3 hours ago, JAC! said:

Yes, there will be "Add File" in addition to "Open File".

Perfect, it is necessary to have both apart.?

 

Greetings

[marcokitt2000]

When start a new dis6502 800 for atari 8bit computer 5200 for the vgs and oric(other 8bit computer).

But on the sourceforce.net it says allso for commodore c64 are there more systems that wel be nice for other programmers.

 

Gr. Marco

[ebiguy]

55 minutes ago, marcokitt2000 said:

But on the sourceforce.net it says allso for commodore c64 are there more systems that wel be nice for other programmers

This was a bad description on the DIS6502 wiki. I changed it.

 

Maybe one day, @JAC! will add the support for C64...

But is it really useful as there is a chance that the C64 community already has all the tools needed to disassemble C64 binary files?

[+JAC!]

40 minutes ago, ebiguy said:

This was a bad description on the DIS6502 wiki. I changed it.

 

Maybe one day, @JAC! will add the support for C64...

But is it really useful as there is a chance that the C64 community already has all the tools needed to disassemble C64 binary files?

In fact you can use it for C64 and everything else with 6502 - and I've used V2.2. on C64 for the largest disassembly in my life ?.

C64 binaries are one block with word start address, that's it. And yes, planned for the next version.

[ascrnet]

I would like them to change the following when one saves the program in .asm "Files > Save Disassembly Files..."

 

icl 'D:menu.inc' by icl 'menu.inc'

asl A by asl @

lsr A by lsr @

 

In the next version if possible ?

 

Greetings

Edited May 23, 2020 by ascrnet
highlighting

[ebiguy]

2 hours ago, ascrnet said:

icl 'D:menu.inc' by icl 'menu.inc'

OK, will do.

 

2 hours ago, ascrnet said:

asl A by asl @

lsr A by lsr @

In the next version, I already changed the default value for option "Show 'A' in accumulator mode' to false.

And I also changed the MADS.prf profile.

So, by default or with MADS, the disassembly generates asl instead of asl A which is OK.

So I won't add an option to generate @ as it is the same without it (at least in a version 3.x).

 

Did you try to assemble a source generated by DIS6502?

Does it assemble without any modification?