• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Free 68k (dis)assembler for Mac?

zuiko21

Well-known member
Is there such a thing? Searching these forums didn't show up anything valid, and the references I've found elsewhere didn't work -- I haven't been able to compile :(

Any app that works on a Mac (of whatever vintage, from SE/30 to iMac i5) is what I'm looking for... *nix and Win as a last resort only.

Thanks a lot in advance,

 

LOOM

Well-known member
I don't know, the webpage doesn't say..

You can send him an e-mail and see if you can buy it from him directly or donate some for it.

 
Last edited by a moderator:

zuiko21

Well-known member
Further digging into MacNosy's web reveals $225 :'(

On the other hand, IDA is very well regarded. There's a free for non-commercial use version available (5.0) which would suit perfectly my needs... but only runs under Windows :disapprove: That's sad because the most recent IDA (6.2) is available for OS X and Linux too -- its priced between $539 and $1059 8-o and there's an evaluation version... but among other limitations, only deals with x86 and ARM code xx(

Life is hard...

 

LOOM

Well-known member
Yeah, I edited that into my last post.. But I made a new reply instead:

The page says it's $225.00 USD for a single license, but the website haven't been updated for almost 10 years. I'm not sure if anyone is willing to pay $220 USD to a single user license for a 68k debugger.. It isn't really useful anymore for anyone else than us hobbyists..

Someone should e-mail him and ask if he want to release it as freeware or shareware for a "reduced" price..

 

Dennis Nedry

Well-known member
"Super ResEdit" has a built-in 68k disassembler almost identical to Resorcerer's. It only disassembles though. This is freeware as far as I'm aware and can be found easily with Google. I'm not sure how good of a disassembler it is though.

To use the disassembler on a dump of hex data, create a new 'cdev' resource (for example), open it with the option key held down and then paste in the hex. It will disassemble when opened normally. It won't let you edit in the disassembler though.

 

zuiko21

Well-known member
Busy days at work... but back to the hack scene! ;)

I'm aware of Super ResEdit dissasembling capability... but since my intention is to sneak a peek into Macintosh ROMs, I'm not sure about a few things:

1. How will ResEdit (and the resource system, in general) handle upon creating a code "resource" as large as a whole ROM?

2. I believe that CODE resources are usually relocatable: absolute addresses within the code start counting from zero, and the OS loader offsets them when the actual position is known in execution time -- most likely from an "attached" data structure. But ROM code is not relocatable in any way, how will such "distant" references show up?

3. To make things worse, ROM can actually be accessed from several addresses -- mirroring. That could add further confusion to the above!

Anyway, I've been trying the solution proposed by...

@ Gryphel: Thanks a lot! This could get the job done, at least for the disassembly part. It's always nice to get new software for the "classic" MacOS, and anyway Mini vMac works like a charm in my iMac core-i5. I'm using the Macintosh II version (26) with the original ROM from my IIx, and System 6.0.8 freshly installed on a 32M image. The only thing I can't get to work is the 256 colours mode... xx(

Anyway, it does work and thanks to the ExportFl/ImportFl utilities I can exchange information with ease. Now, I've got a question about the disassembler itself: I understand that the starting point of dissasembly has to be known, that's what the bin_map file is for, and it's likely to help with locating the original execution address -- don't know if it will support the aforementioned mirroring, though.

You supply some of this files (thanks again!) for disassembling specific ROMs, but I understand that the bin_map file for the Mac II ROM won't do for the IIx ROM, right? I tried using it but it seems the disassembly doesn't go too far :( Also checked FindCode, but really don't know how to use it efficiently.

Any clues about the bin_map file format?

Again, thanks a lot for all your ideas! :b&w:

 

MidnightCommando

Well-known member
TACK (The Amsterdam Compiler Kit) has an assembler for 68000, 68020, and 68040 - I see no reason why it couldn't be repurposed.

 

prattp

Member
The only thing I can't get to work is the 256 colours mode.
Oops. I missed seeing this reply before. Better very late than never?

The trick to get color to work in System 6 in the current state of Mini vMac Macintosh II emulation is to install 32-Bit QuickDraw (which is available from the System 6.0.8 installer).

I understand that the starting point of dissasembly has to be known, that's what the bin_map file is for, and it's likely to help with locating the original execution address -- don't know if it will support the aforementioned mirroring, though.
Macintosh 68k ROMs seem to contain mostly position independent code. My disassembler doesn't know where the ROM is in memory, and it mostly doesn't matter, with some exceptions that can be dealt with manually.

The bin_map file doesn't just say where the starting offset of the code is. Blocks of code and data are mixed throughout a ROM. The bin_map file says where these blocks are, and what areas aren't known yet.

You supply some of this files (thanks again!) for disassembling specific > ROMs, but I understand that the bin_map file for the Mac II ROM won't do > for the IIx ROM, right?
The Mac IIx ROM seems to be very similar to the Mac II. It differs only by a few patches until it gets to the floppy disk driver, in the resources in ROM section, three fourths of the way to the end. So format files I supply for the Mac II would be a good starting point.

I tried using it but it seems the disassembly doesn't go too far
This should have worked. Did you copy the Mac IIx ROM image into the FDMacII disk image, and rename it to "bin"?

Any clues about the bin_map file format?
Each line of the bin_map file contains a starting address and a type (both in hexadecimal). The type in the final line must be 0. The meaning of other types are:

1 - Unexplored

2 - Code

3 - Data

4 - Unknown opcode

 

powermax

Well-known member
but since my intention is to sneak a peek into Macintosh ROMs
If you're going to gather some knowledge about a specific ROM or ROMs, the question is if the static analysis (i.e. disassembly/hex dump) would be the right tool for the job. You can surely run a disassembler over your ROM dumps. The problem is that the most disassemblers are just dumb tools (the older the worse) - you'll get a lot of night-impossible-to-understand garbage out of them for a couple of reasons, among them:

  • disassemblers cannot fully automatically distinguish between data and code (and Mac ROMs mix them a lot!). This problem has been proven unsolvable, see this discussion on the Halting problem. That's why all modern disassemblers implement various pattern matching based heuristics to identify code and offer interactive features as a last resort so humans can step in and guide the disassembler. IDA is a good example of such a tool.
  • ROM dumps don't contain any human-readable function and variable names. Memory-mapped hardware can vary greatly between machines. One ROM usually has support for a group of machines and contain a lot of machine-dependent code.
  • a whole bunch of old Mac hardware remains fully or partially undocumented.
I therefore recommend you to try some sort of dynamic analysis - that is, an interactive debugger with disassembling capability. Because you're targeting 68k ROMs, you can try out MAME/MESS emulator. It's capable of emulation practically every 68k Macintosh including its hardware. The best part - it contains an integrated low-level debugger so you can even set breakpoints in ROM (that's what you cannot do in a real Mac!!!), dump hardware's internal state etc.

You'll need a fast modern host computer (Linux, Mac or Windows) but that's the price for its almost luxurious RE features.

Just ping me if you need any additional information on MESS (what a stupid name :)) ) and its tools.

Cheers

Max

 
Last edited by a moderator:

Gryphel

Active member
I therefore recommend you to try some sort of dynamic analysis - that is, an interactive debugger with disassembling capability.
The debugging tools you describe in MAME/MESS sound pretty useful.

But the specific comment you are replying to is about a disassembler, FDisasm, that avoids the issues you describe, by allowing one to create format files to annotate the disassembly, and then distribute those format files. These files exist for ROMs of several early Macintosh models.

In the six years since that comment, FDisasm has improved a bit. It is now accurate enough that one can take its output for those specific ROMs and use the MPW assembler to get back the originals exactly.

I think for working on emulation, both static analysis and dynamic analysis are helpful.

 

powermax

Well-known member
FDisasm, that avoids the issues you describe, by allowing one to create format files to annotate the disassembly, and then distribute those format files. These files exist for ROMs of several early Macintosh models
Thank you for pointing me to FDisasm that I'm aware of. I personally never considered to give it a try because

  • I don't use Mini vMac emulator
  • I never seen any ROM formatting files for the ROMs of my interest (PowerMacintosh 6100 and newer)
  • MAME/MESS offered me anything I need in just one package. Moreover, MAME's source code is a superb and the most complete documentation on the proprietary Macintosh hardware ever available
I'm glad to hear that your disassembler offers some annotation functions one could find in only few advanced tools like IDA Pro. It looks like we need to consolidate our efforts on MacROM-related tools.

BTW, are you aware of the cdg5 ("countdown to G5") project started by a small team off the macos9lives forum? The goal of this project is to hack Mac OS 9 to run on unsupported Macintosh hardware (PowerMac with newer G4/G5 processors). These guys have created their own toolchain, vaguely similar to yours (Python-based disassembler/annotator + MPW for rebuilding the ROM). You can take a look at this repository.

both static analysis and dynamic analysis are helpful.
Sure! My preferred workflow is to use a debugger coupled with an annotated assembly. Some tricks like memory mirroring simply cannot be coped with by the static analysis alone...

 

Dog Cow

Well-known member
Is there such a thing? Searching these forums didn't show up anything valid, and the references I've found elsewhere didn't work -- I haven't been able to compile
I discovered a little application called DisAsm by Bob Arning, 1986, a little over a year ago. I can't remember where it came from, and I can't locate it within Mac GUI Vault, though it must have originated somewhere within there. It's probably on a BCS disk, or some other compilation disk. I've attached it to this post in MacBinary format.

Anyway, it's a pretty good disassembler, and I use it fairly often. It shows A-trap calls with their symbolic names

View attachment DisAsm.Bin

 
Last edited by a moderator:
Top