Disassembler

[copse]

Has anyone disassembled Resource?

I was thinking that a feature I would like would be to load in my "in-progress" .RS files some of which I've slowly been working away on for 10 years or so. If I could do that, then these could be continued in PeaSource.

But first I would need to know the .RS file format, and the easiest way to do so, would be for someone who had disassembled it to document the file format.

[copse]

New update, there is now support for location relative labels. In this case, you can see what I guess is very proactive X68000 self-modifying code. Source code in same location.

[lucadip]

Originally Posted by copse

I would prefer to spend my time on fleshing out the disassembler at this point, rather than that sort of (potentially prolonged and painful) side project. It is not likely that I would consider making a compiled version (whatever that means), until the disassembler is "ready to use".

Right! Keep up the great work!

[Wepl]

Originally Posted by copse

Has anyone disassembled Resource?

I was thinking that a feature I would like would be to load in my "in-progress" .RS files some of which I've slowly been working away on for 10 years or so. If I could do that, then these could be continued in PeaSource.

But first I would need to know the .RS file format, and the easiest way to do so, would be for someone who had disassembled it to document the file format.

I have a disassembled ReSource which assembles into an indentical binary. But not with optimization enabled, because ReSource contains some constructs which ReSource doesn't support, e.g. unsigned relative references. Some years ago I had the plan to fix some bugs and to remove the cmp2 instructions if a 68060 is present. But due the lot of work required I stopped working on this. Instead I patched the binary to enlarge some windows.
I also tried to get the source but it seems the original author hasn't the latest source and won't give it and the copyright holder has died.

[copse]

Originally Posted by Wepl

I have a disassembled ReSource which assembles into an indentical binary. But not with optimization enabled, because ReSource contains some constructs which ReSource doesn't support, e.g. unsigned relative references. Some years ago I had the plan to fix some bugs and to remove the cmp2 instructions if a 68060 is present. But due the lot of work required I stopped working on this. Instead I patched the binary to enlarge some windows.
I also tried to get the source but it seems the original author hasn't the latest source and won't give it and the copyright holder has died.

Can you put the source somewhere so I can try and go over it?

What are the most important features of Resource, that you would use in a replacement? I tend to just add/rename labels, comment, change the odd data type, apply symbols from the symbol library and repeat until I have something that I understand. But it would be good to get some idea of what others would use.

[Wepl]

Originally Posted by copse

Can you put the source somewhere so I can try and go over it?

send me pm with your email address...

Originally Posted by copse

What are the most important features of Resource, that you would use in a replacement? I tend to just add/rename labels, comment, change the odd data type, apply symbols from the symbol library and repeat until I have something that I understand. But it would be good to get some idea of what others would use.

in the last years I only used it to understand and to comment code. this requires not all functions.
sometimes I also used it to create a modifyable source, this will require many of the resource features.
key features for me would be:
- interactive
- 100% reliable save/load of work
- binary files, specify origin
- intelligent disassembling and data/code detection
of course lowercase opcodes and new motorola syntax

[spud]

Hi, nice project. I tried this disassembler on the game I'm developing only to get error

hunkfile.py: _process_file: Unexpected leading segment type: 3F1 (HUNK_DEBUG)

I'm not clued up on hunks, really, frankly it's a miracle stuff I program on the Amiga work at all sometimes, so I'm not sure what this means.

Is this useful feedback to you?

[StingRay]

That most probably means that hunks that contain debug info are not supported yet.

[copse]

Originally Posted by spud

Hi, nice project. I tried this disassembler on the game I'm developing only to get error

hunkfile.py: _process_file: Unexpected leading segment type: 3F1 (HUNK_DEBUG)

I'm not clued up on hunks, really, frankly it's a miracle stuff I program on the Amiga work at all sometimes, so I'm not sure what this means.

Is this useful feedback to you?

It reminds me that not all of my hunk support is enabled yet. It's written and tested, but I left it out in order to just get the basics working. I currently only support code, data, bss and relocation hunks.

If you compile your project without debug information, it should disassemble fine.

Thanks for trying :-)

[spud]

Thanks chaps, I switched off the debug symbols output in Devpac and it now disassembles fine.

[copse]

New update. Code available here as always.

The only functional change is that Amiga executable files should now disassemble fine, as I've added support for HUNK_NAME, HUNK_SYMBOL and HUNK_DEBUG. Any symbols should be used for labels in decompilation, the same as for GEMDOS PRG files and X68000 X files already do. Debug hunk contents are discarded, although adding the source code contained within them as comments should be an easy task to do later when comments are fully supported.

Otherwise most of the work in this, was spent writing UI code. There are now options presented when saving a new project, loading an existing project or creating a new project. There's so much more UI work to do but it's making an obvious difference so the distraction from writing more functional code isn't that discouraging.

The binary file loading doesn't work yet. Hooking it up so it works will probably be the next task.

[copse]

It is now possible to select a binary file, not have it recognised as a known file type, and then to specify load and entrypoint addresses, and then to have it disassembled.

Of course, this is a lot more complicated than it just being okay for it to work. There's the question of whether an instruction operand's value is just a value that happens to look like a known address - or if it is actually an address.

There is so many possible things that could be worked on, and so many things that could be done for each to do them properly! On the bright side, in addition to making binary file disassembling as correct and usable as possible, there are only two more things I need to do before I can start proclaiming this ready for use (for those okay with teething problems).

Here's what looks to be a trackloader:

[prowler]

Originally Posted by copse

It is now possible to select a binary file, not have it recognised as a known file type, and then to specify load and entrypoint addresses, and then to have it disassembled.

Of course, this is a lot more complicated than it just being okay for it to work. There's the question of whether an instruction operand's value is just a value that happens to look like a known address - or if it is actually an address.

There is so many possible things that could be worked on, and so many things that could be done for each to do them properly! On the bright side, in addition to making binary file disassembling as correct and usable as possible, there are only two more things I need to do before I can start proclaiming this ready for use (for those okay with teething problems).

This is marvellous, copse!

If you can pull this off, you will be my hero!

[StingRay]

Originally Posted by copse

It is now possible to select a binary file, not have it recognised as a known file type, and then to specify load and entrypoint addresses, and then to have it disassembled.

Nice but make sure that user input for this kind of stuff is possible. Since it is impossible to disassemble things like that correctly automatically for reasons you already mentioned.

Other than that what you've achieved so far looks quite promising, keep working on it!

[copse]

Originally Posted by StingRay

Nice but make sure that user input for this kind of stuff is possible. Since it is impossible to disassemble things like that correctly automatically for reasons you already mentioned.

Other than that what you've achieved so far looks quite promising, keep working on it!

The last two screenshots above, one for relocatable files, one for binaries, should show you what user input is currently possible. Is that what you mean?

[StingRay]

What I mean is that it should be possible to switch the data type (code/data etc.). It should also be possible to select start/end offset for the absolute address conversions. And, make sure you handle absolute short addresses properly as well, ReSource f.e. doesn't.

[copse]

Originally Posted by StingRay

What I mean is that it should be possible to switch the data type (code/data etc.). It should also be possible to select start/end offset for the absolute address conversions. And, make sure you handle absolute short addresses properly as well, ReSource f.e. doesn't.

It's possible to do the first thing already, except readable ascii data blocks aren't supported yet.

And just to be clear, can you describe a use case for the start/end offset for absolute address conversions? And another for where resource doesn't handle absolute short addresses?

[kamelito]

I remember back in the day trying to disassemble DPaint with Resource, it didn't work because DPaint was using Hunk Overlays, is it possible to support such format to disassemble program using them?
Kamelito

[copse]

Originally Posted by kamelito

I remember back in the day trying to disassemble DPaint with Resource, it didn't work because DPaint was using Hunk Overlays, is it possible to support such format to disassemble program using them?
Kamelito

At some point, but it would be way down the list of bonus features as it isn't something of interest to myself. Find someone to sponsor me doing it, and I'll have it done by the end of the week

[copse]

A bit more work on binary file processing. The two docked windows on the right try and list all the possible values that the programmer should verify to see if they need to be mapped to labels. May not be perfect, but it's a good start.