Disassembler

[StingRay]

Originally Posted by copse

And just to be clear, can you describe a use case for the start/end offset for absolute address conversions?

It's more important for indirect address conversions [move.w #xx,x(ax)] but suppose something has been loaded to an absolute address, say $10000. Then it copies other areas to a different location, say $11000. It should be possible to set a start/end offset for the area that is copied to $11000 and NOT have the code at $10000 converted too.

And another for where resource doesn't handle absolute short addresses?

lea $1000.w,a0
moveq #0,d0
move.w d0,$1002.w

Once I set the origin to $1000 the move.w d0,$1002.w should be converted too but Resource just keeps it as $1002.w which is a bug IMHO.

[mark_k]

Originally Posted by StingRay

lea $1000.w,a0
moveq #0,d0
move.w d0,$1002.w

Once I set the origin to $1000 the move.w d0,$1002.w should be converted too but Resource just keeps it as $1002.w which is a bug IMHO.

Yep that's probably the most annoying bug/deficiency in ReSource. When you're disassembling absolute code (like many games), or code which uses absolute word addressing for low-memory variables (e.g. Emerald Mine, Macintosh programs) it's really annoying not having those references converted.

There are ways to work around the problem, but they aren't anywhere near as good as what ReSource should be doing itself. You have to tell ReSource to convert each individual reference manually.

For absolute code, build a binary image starting from address 0. Then put a label "0" at address 0. Then you can get ReSource to show e.g. move.w d0,($1002).w as move.w d0,(lbW001002-0).w
An option for things like Emerald Mine is to create custom symbol definitions for ReSource, then manually convert e.g. move.w d0,($1002).w to move.w d0,(SomeVariableName).w

[StingRay]

Originally Posted by mark_k

Yep that's probably the most annoying bug/deficiency in ReSource. When you're disassembling absolute code (like many games), or code which uses absolute word addressing for low-memory variables (e.g. Emerald Mine, Macintosh programs) it's really annoying not having those references converted.

It's indeed quite an annoying bug. I guess ReSource doesn't convert it because the code size will increase by 2 bytes for each converted instruction. However, there should at least be an option to enable this kind of conversions.

Originally Posted by mark_k

There are ways to work around the problem, but they aren't anywhere near as good as what ReSource should be doing itself.

Exactly!

Originally Posted by mark_k

For absolute code, build a binary image starting from address 0. Then put a label "0" at address 0. Then you can get ReSource to show e.g. move.w d0,($1002).w as move.w d0,(lbW001002-0).w

Quite an interesting workaround. Image starting at $0 makes it quite a bit harder to disassemble though since you have to be much more careful when deciding what's data and what's code.

Originally Posted by mark_k

An option for things like Emerald Mine is to create custom symbol definitions for ReSource, then manually convert e.g. move.w d0,($1002).w to move.w d0,(SomeVariableName).w

Yes, that works quite well and I've always been doing it like this. It's a lot of unnecessary extra work though.

[mark_k]

Originally Posted by StingRay

It's indeed quite an annoying bug. I guess ReSource doesn't convert it because the code size will increase by 2 bytes for each converted instruction. However, there should at least be an option to enable this kind of conversions.

Converting the instruction isn't needed. It's just that if the game has code like

jsr ($1234).l

ReSource can correctly create a lbC001234 label at address $1234. But if the game does

jsr ($1234).w

instead, ReSource won't create a label. The same applies to data references, e.g. I'd like move.l ($1234).w,d0 to be changed to move.l (lbL001234).w,d0.

Quite an interesting workaround. Image starting at $0 makes it quite a bit harder to disassemble though since you have to be much more careful when deciding what's data and what's code.

Yeah, and then ReSource (from memory, it's been a while) thinks all small constants in the code are address references. So that can create more problems than it solves.

[StingRay]

Originally Posted by mark_k

Converting the instruction isn't needed.

What I meant is this:

move.w d0,$1002.w -> 2 bytes for the instruction, 2 bytes for the absolute short address

move.w d0,lBW1002 -> 2 bytes for the instruction, 4 bytes for the absolute address

Thus the code size changes (converted instruction is 2 bytes larger) and that's most probably the reason why ReSource doesn't convert things like that even if "specifiy origin" is used. But it's still a bug in my opinion.

[mark_k]

Why would ReSource need to convert instructions like that? It should be valid assembler source to keep the same addressing mode, i.e. move.w d0,(lbW001002).w.

But, I guess an option to display instructions which use absolute word addressing, without showing the (xxx).w could be useful if you want to re-assemble the program at a different address. So move.w d0,(lbW001002).w would be shown in the disassembly output as move.w d0,lbW001002 with that option. Then when you re-assemble the .asm file the assembler would generate absolute long addressing (6 bytes instruction + opcode) for that instruction.

[BippyM]

how do I run this? Python 2.7 and pyside installed

[StingRay]

Originally Posted by mark_k

Why would ReSource need to convert instructions like that? It should be valid assembler source to keep the same addressing mode, i.e. move.w d0,(lbW001002).w.

Well, depends on how you look at it. For me (label).w is invalid, since label is an absolute address and only if make the code run at the same address that it was loaded to it will work. And in that case you don't need any created labels at all since you can't change anything anyway. In any case, it is annoying that ReSource doesn't handle these cases properly.

Originally Posted by mark_k

But, I guess an option to display instructions which use absolute word addressing, without showing the (xxx).w could be useful if you want to re-assemble the program at a different address. So move.w d0,(lbW001002).w would be shown in the disassembly output as move.w d0,lbW001002 with that option. Then when you re-assemble the .asm file the assembler would generate absolute long addressing (6 bytes instruction + opcode) for that instruction.

That's exactly the same idea I had myself. Should be quite a good approach to handle this I think.

[copse]

Originally Posted by bippym

how do I run this? Python 2.7 and pyside installed

Download it from github. Enter the 'peasauce' directory. If you are on a unix-like platform, type 'run.sh'. If you are on Windows, type 'run.bat'. If you are on another one where neither of these are suitable, then view one of those and execuate the given python command line.

[BippyM]

ahh i had to change the location of Python in the batch file..

thanks

[copse]

Originally Posted by bippym

ahh i had to change the location of Python in the batch file..

thanks

Any feedback positive or negative is appreciated and may (or may not) affect the work I do before it hits "ready for usage by people who don't mind teething problems" or zeta testing as I call it.

[copse]

Finally got a little more time to fix bugs and implement the ASCII data block type, as seen in the screenshot below.

Source code and instructions on how to install it, available on github as usual. And please keep in mind it is moderately usable, but is not complete enough for use compared to Resource, yet.

[Hewitson]

run.sh is no good.

#!/bin/bash
/c/python27/python.exe python/qtui.py $@

Should be:

#!/bin/bash
python python/qtui.py $@

[copse]

Originally Posted by Hewitson

run.sh is no good.

Should be:

#!/bin/bash
python python/qtui.py $@

You're right, it should support other platforms, but not at the expense of it working for me - who uses this script to develop it further

I'll do some shell scripting revision, so I can work out how to get both working.

Thanks for the reminder.

[copse]

I've had this functionality in since the beginning, the ability to go to referring addresses to the current selected label. But without a UI to select when there are multiple options, and some hint about the difference between them, it wasn't much use.

It works as follows: Select the line with a label, hit CTRL+SHIFT+RIGHT and the shown window will pop up with the addresses and code lines that reference that label.

Source code and instructions on how to install it, available on github as usual. Nowhere near release yet, but project save file format has been solidified and will be kept backwards compatible from a few changes previous to this one.

[copse]

Note to self:

• Support loading files directly from ADF via pyadf and ADFlib.
• Support decompressing files by using Toni's uaexfd tool (Windows only).

[_ThEcRoW]

Interesting piece of software. i like definitely the x68000 part, as it is one of my favourite 16 bit machines. Is the code now in python?. I remember reading that it was java o earlier posts. By the way, good work, and will take a look when some free time appears.

[copse]

It was never written in Java, someone else had a Java disassembler. I wrote this in Python as a prototype.

There's no reason that the same core software can't support multiple architectures, whether m68k or x68k or arm and so forth.

This is also on hiatus. The code isn't terrible, but it became a little unmanageable to change, and for now I am focusing on other projects.

[copse]

I've been working on my disassembler project peasauce a little more lately. Some new features:

• Ability to search back and forwards with currently only case insensitive matching.
• Showing labels in data statements where the value was relocated, and the ability to follow these.

I am hoping to work on these features next:

• Detecting and automatically using jump tables to convert data blocks to code blocks.
• Some sort of symbol library where you can change a value to a symbol, like (_LVOCloseLibrary, a6) and so forth.
• Detect library calls and automatic application of symbols.

If anyone has any thoughts or ideas on any of these features, they'd be appreciated. Nothing too pie in the sky, as I'm trying to keep it simple to ensure I make progress. At the moment, the primary qualifier for features is so that after the initial load of a file, as much of the grunt work is done as possible.

[copse]

Alright, I've gotten the basics of "code analysis" working at a prototype level.

The first part where library calls are recognised, and then for each exec library open call the library name identified and converted to ASCII and renamed. The three library names in this Neuromancer executable that I use for testing, are all automatically renamed.

The next step is looking where the output register goes and then using that to classify non exec library calls. Then perhaps loading in fds and naming library function symbols, ..