Thread
Free 68k (dis)assembler for Mac?
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,
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,
I found that, but... is that free?
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.
You can send him an e-mail and see if you can buy it from him directly or donate some for it.
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...
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...
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..
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..
Oooh. Nice work!
"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.
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.
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:
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:
TACK (The Amsterdam Compiler Kit) has an assembler for 68000, 68020, and 68040 - I see no reason why it couldn't be repurposed.
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).
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.
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.
This should have worked. Did you copy the Mac IIx ROM image into the FDMacII disk image, and rename it to "bin"?
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
Does it disassemble a binary into LISP code?