Extracting files from a kickstart rom

[Piru]

Is there any sort of command or program that can extract files or code from a kickstart rom?

No.

There is no generic solution to this problem (basically the problem is that relocs needs to be resolved properly, the code needs to be de-relocated. This is handwork).

Some tools might exist that extract single module (typically these tools have the specific relocs hardcoded).

[Piru]

@AF-Domains.net

What sort of coding or programming languages was the kickstart rom written in?

Assembler and C.

Since that might help.

No, it really doesn't.

[Piru]

@AF-Domains.net

I wrote such tool for BlizKick, too. It's called "romupdatesplit" and comes with full source code (well, it's AmigaE though... :-)) BlizKick.lha has the binary and source code included.

The usage is quite easy, for example:

Code: [Select]

romupdatesplit from "DEVS:AmigaOS ROM Update" to T:
This extracts the modules matching the current system.

To extract all modules, regardless of system type, use ALL/S.

[Piru]

@AF-Domains.net

Since it is next to impossible to extract files from the kickrom is it possible to disassemble a kickrom file?

Yes.

However, the problem remains the same: You need to decide whether values between 0x00f80000-0x00ffffff are pointers (reloc) or data. If you get even single item wrong, the reassembled module will misbehave (in some conditions).

[Piru]

@AF-Domains.net

Which are the best Assembly and C programming tools to use to disassemble the kick roms with?

The best tool for disassembling on Amiga is ReSource (by The Puzzle Factory, Inc.), a commercial tool dedicated for disassembly.

I have already downloaded several programs off aminet to attempt to look inside the kickrom file but it mostly comes out as total garbage, I assume that it probably has something to do with the C programming that the rom was also programmed in.

Not really. The problem is that there is no easy way determining which part of the binary is data and which is code. So these tools probably blindly disassemble everything as code, and that will never work.

Even with ReSource you still need to manually "guide" the program, adjust the code/data selection (and data type selection) if and when ReSource automagic disassembly gets it wrong.

This is only very very brief explanation, but I am sure this (and your troubles with initial attemps) give you an idea of the magnitude of the problems you're tacking with.

[Piru]

@seer

Ok, this is something I don't understand. I mean, something must read the ROM otherwise the Amiga doesn't work/boot.

True.

So, doesn't that mean you can make a tool that does almost the same ? Read the rom and extract the needed modules ?

No.



The problem is that the specific modules are absolutely relocated at link stage to fixed memory address, and there is no (easy) way to get the relocation information from the already absolute-address linked ROM.

The grabbed modules would only work when mapped exactly the addresses they were located originally. And if you think for a moment this means that the order of the modules can't be changed (some modules could be left out and holes filled with other things, though).

So the problem is that unless if the ripped modules are made 'relocatable' they cannot be 'moved' from their original address. This work of figuring out the 'relocs' for arbitrary ROM part is extremely hard. It certainly cannot be made 100% automatic (some tools can be made that figure out the obvious cases though, but still a lot of manual work is needed).

I hope this explanation helps and isn't too technical.

[Piru]

@seer

But I suppose it means that if you read the ROM and dump the info, the links inside the ROM are pointing to a certain "adress", so if you put the code at another adress it won't work anymore.

That's precisely what the problem is.

But then, if you know the correct location, and the intention is to "recreate" the ROM or in this case a merged 1.4 + 3.1 ROM couldn't you dump the files in RAM or disk, then "disasemble" it, and reprogram it a bit or put it back in another ROM and have the correct adresses again ?

The obvious problem here is that both roms use the *same* addresses, and thus the modules would overlap. It might be possible to find certain combinations that could be merged without overlap, but it's very unlikely you could find really useful combos, esp since traditionally the modules are linked in certain fixed order (that appears to be a side-effect from the link phase).

@AF-Domains.net

Would it be possible to copy both roms onto a flashrom and modify them from their instead of dumping them to disk?

Sure. But you still need to relocate the other image or they will overlap. And to do that you need to know exactly where to subtract the original address and add the new one (that's what re-relocation is basically: newptr = oldptr - oldbase + newbase).

I am creating a merged 1.4 and 3.1 rom to add some of the features that were in 1.4 but were never implemented into later versions of the kickstart and also to see if I can improve any part of both of the roms.

You still need to resolve all the relocs for the components you swap / merge.

[Piru]

since the kickstart rom wasn't included in the H/W of the A1000, there was a kickstart disk. Dunno til which version of the kickstart was released on disk, but surely the adressing on such a kickstart-on-disk is managed differently.

Nope. The image on disk is still absolutely linked, to address 0x00fc0000. Just like real 1.x Kickstart ROM.