Disassembler

[Don_Adan]

Check this thread:
http://eab.abime.net/showthread.php?t=56426
no doc, but maybe useful for something.

[kamelito]

Originally Posted by copse

To make the frontend code more flexible and less Amiga/68k dependent, I wanted to start by adding support for other platforms that are also m68k-based. The easiest is of course the Atari ST, and the screenshot below is shows disassembly of a random PRG file.

Anyone got any handy links for other 68k executable file formats other than Amiga loadfiles and ST prgs? I've been struggling to find any for the Sharp X68000 platform.

First link is a developer (japan) the second link said that the SDK was released so it may be available somewhere. Kamelito http://minahito.wordpress.com/tag/x68k/ The X68000 OS Human68k, BIOS files, an SDK, and other applications were released on the @nifty Sharp Products Users' Forum (FSHARP) on April 1, 2000 with the consent of Sharp, Hudson, and the other contributing companies. The original forum is no longer on the Internet (it was a pay-access service anyway and never generally accessible). This means that X68000 OS and system emulation is 100% legal source http://fullmotionvideo.free.fr/phpBB...php?f=2&t=1036

[copse]

Originally Posted by Don_Adan

Check this thread:
http://eab.abime.net/showthread.php?t=56426
no doc, but maybe useful for something.

Yeah, I went looking for the mentioned disk images in order to get an executable with symbols. The source code for the mentioned tool was available, but there was so much guesswork in it and "what the heck? I have 100 bytes left" that I went looking for something more authoritative. In the end I stumbled across this public domain aout2hux program which takes two fixed address aout binaries and uses them to construct a relocatable h68k .x file. I can now disassemble .x files, but my disassembler chokes on instructions it cannot handle yet.

Take this line from Tunnels and Trolls:

0x6683A: 0xFF3C: 1111[111]100[111][100] cpSAVE 7, Imm

Imm is actually an invalid effective addressing mode for the cpSAVE instruction, so as I understand it should cause an F-Line thingy. I think Resource disassembles these sorts of invalid instructions as "fRestore ?????" or even sometimes "AFLINE something".

Anyone have any insight into the best way to handle these invalid instructions?

[copse]

Originally Posted by kamelito

First link is a developer (japan) the second link said that the SDK was released so it may be available somewhere.

Indeed. Somewhere there is useful information, but where? That's the problem. Realistically, even if this rumoured SDK release was locatable, unfortunately it would be in Japanese.

There's some translated documentation available here.

However at this point, as I mentioned in my other reply, I have loading of these files working. The only improvement I'd like to make is working out what the mystery data in the symbol table is.

[kamelito]

Originally Posted by copse

Indeed. Somewhere there is useful information, but where? That's the problem. Realistically, even if this rumoured SDK release was locatable, unfortunately it would be in Japanese.

There's some translated documentation available here.

However at this point, as I mentioned in my other reply, I have loading of these files working. The only improvement I'd like to make is working out what the mystery data in the symbol table is.

The japanese developer speak english so I guess he can help.
Two other site.
http://www.jcec.co.uk/x68kinfo.html
http://gamesx.com/wiki/doku.php?id=x68000:x68000

Kamelito

[copse]

Originally Posted by kamelito

The japanese developer speak english so I guess he can help.
Two other site.
http://www.jcec.co.uk/x68kinfo.html
http://gamesx.com/wiki/doku.php?id=x68000:x68000

Kamelito

The first link was really helpful. I went to try and download a file, to find that it was no longer at the given URL. But googling for that file led me here. It's still all Japanese with scatterings of English, but I've already learned some a little more.

[kamelito]

cool, are you aware of the tools x68k2amiga?
The author is a member of this forum.
http://franck.charlet.pagesperso-orange.fr/misc

Kamelito

[copse]

Originally Posted by kamelito

cool, are you aware of the tools x68k2amiga?
The author is a member of this forum.
http://franck.charlet.pagesperso-orange.fr/misc

Kamelito

Yes, it was the first thing I looked at, Don posted about the forum thread discussing that above. But as I said in reply to that, the source is has the odd comment like "hey woopsie, there's 100 bytes I don't know what to do with here". Now, I'm paraphrasing when I quote that text, but I wanted to work from something that was more authoritatively correct.

I have however used x68k2amiga to compare my disassembly results to those of Resource

[kamelito]

any chance that your disassembler be available on other platform than windows?
OSX?
Kamelito

[copse]

Originally Posted by kamelito

any chance that your disassembler be available on other platform than windows?
OSX?
Kamelito

At the moment it is cross-platform, but I can't guarantee it will stay that way.

When I've added editing type actions like adding comments, renaming labels and the basic stuff Resource does, I'm considering a release. It will likely be under the GPLv3 for a start and if it isn't cross platform, maybe someone will make a OSX UI.

[AnimaInCorpore]

Hello guys,

I just stumbled upon this forum and I think this could be interesting for you as well: http://www.atari-forum.com/viewtopic.php?f=68&t=24111

Cheers
Sascha

[AnimaInCorpore]

Originally Posted by copse

I can now disassemble .x files, but my disassembler chokes on instructions it cannot handle yet.

Take this line from Tunnels and Trolls:

0x6683A: 0xFF3C: 1111[111]100[111][100] cpSAVE 7, Imm

Imm is actually an invalid effective addressing mode for the cpSAVE instruction, so as I understand it should cause an F-Line thingy. I think Resource disassembles these sorts of invalid instructions as "fRestore ?????" or even sometimes "AFLINE something".

Anyone have any insight into the best way to handle these invalid instructions?

Line-F calls are Human68k DOS calls. You can read more about those DOS calls here: http://datacrystal.romhacking.net/wiki/X68kOSCALL

Cheers
Sascha

[copse]

Originally Posted by AnimaInCorpore

Line-F calls are Human68k DOS calls. You can read more about those DOS calls here: http://datacrystal.romhacking.net/wiki/X68kOSCALL

Cheers
Sascha

Thanks. I'll note that down for when I am at the point where I want to automatically comment OS calls for different platforms. For now, I'm just curious about F-line instructions in general.

[matthey]

Originally Posted by copse

Take this line from Tunnels and Trolls:

0x6683A: 0xFF3C: 1111[111]100[111][100] cpSAVE 7, Imm

Imm is actually an invalid effective addressing mode for the cpSAVE instruction, so as I understand it should cause an F-Line thingy. I think Resource disassembles these sorts of invalid instructions as "fRestore ?????" or even sometimes "AFLINE something".

Anyone have any insight into the best way to handle these invalid instructions?

Unrecognized instructions that are not relocations should generate a dc.size like this:

dc.w $ff3c

This will reassemble correctly and can be viewed by a 68k assembly programmer as being f-line if it's determined to be code. If you add x68000 function calls later, this will probably change to being some kind of an OS function name but would probably require an external include/macro file to translate it to what I have above. A dc.w is self contained and easier for an assembler but a function name would be easier for a programmer.

[copse]

Originally Posted by matthey

Unrecognized instructions that are not relocations should generate a dc.size like this:

dc.w $ff3c

This will reassemble correctly and can be viewed by a 68k assembly programmer as being f-line if it's determined to be code. If you add x68000 function calls later, this will probably change to being some kind of an OS function name but would probably require an external include/macro file to translate it to what I have above. A dc.w is self contained and easier for an assembler but a function name would be easier for a programmer.

Exactly the advice I was looking for

[Codetapper]

Combine the two! Make it output:

dc.w $ff3c ;cpSAVE 7,Imm

[copse]

A little more work.

• I've rewritten the UI to use QT, which is a lot more flexible than the old toolkit I was using. This was very quick and easy, given all the documentation and examples available for the both QT and the PySide Python bindings.
• Work can be saved and loaded again later.
• Labels can be renamed.
• F-line instructions are generally properly disassembled now.

By no means is it ready for use, but it's a good start.



Latest source code is pushed to github. It should just work as long as you have Python 2.7 and PySide for Python 2.7 installed.

[prowler]

I'm very pleased to see that this project is going ahead... I'm following this (as far as I can ) with great interest.

Thanks again for your work on this, copse!

[BippyM]

Any chance of a compiled version??

[copse]

Originally Posted by bippym

Any chance of a compiled version??

That's an ambigious question. It could mean rewritten to a language where it gets compiled into a binary, like C or C++. It could mean with respect to Python, where I would for all relevant platforms package it up as a standalone installer which people could install and run from without caring it was Python.

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