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: