Obtaining RTB and PAT files for KS 37.350

[psxphill]

-Using MakeKick on my kick205.rom file (wich is KS 37.350) I got the corresponding kick205.rom.kick. Good!
 
-Now, using Kick2RTB on kick205.rom (the file kick205.rom.kick is automatically detected and used), I get the PAT file, but no RTB.
 
It has to be 37.350, so... how can I get the RTB file for this KS?
Thanks!

Makekick doesn't do what you want, it creates a kick/kshd file from a rom and rtb/pat. Kick2RTB extracts the rtb/pat from the kick/kshd file.
 
From skick346.lha skick.doc
 
8. File structures
==================
8.1 .RTB file
.RTB file consists of two parts. The first part contains all the relocation
offsets compressed by my own simple algorithm. It is created with a special
program called RTG (relocation table generator) from specially pre-processed
kickstart image. How to get this image, it is my magic and I'll never tell
anybody about it. One note only: generation of 39.046 .RTB took 1 1/2 hours.
(Manual work, + about 10 mins my 7MHz '010 CPU time). Second part contains BCPL
relocation table and it is required for 1.3 ROM only. It was created manually,
analysing dos.library, which is written in BCPL in 1.3. .RTB file is not easy
to create. I don't recommend anybody to try it *without* very good knowledge of
assembly language and machine code (not the same). N.B. Auxiliary tools to do
such work took 1 month to develop.
8.2 .PAT file
Patch file has a very simple structure. It contains pairs of longs. Every pair
represents an offset from kickstart beginning (first long) and the value to
patch (the second one). Bytes and words cannot be patched individually, every
patch must be coded as a long, even with 3 bytes identical with original. When
a longer patch is to be coded, it must be coded as a sequence of these simple
patches. This stupid mechanism will be improved in next release. There is no
order specified, because every patch has its own, fully coded offset. It allows
simple addition of new patches to the existing file. Patch file must be ended
with two longs of zeros.
From revision 3.12, there may be also relocative patches coded. They
differ from a standard patch by the most significant bit of offset, which is set
to 1. In this case, current loading address is added to the patch value before
storing it. This feature is needed for 39.110 patch. For example, to code JMP
start+$7F900 patch to the address start+$100, where start is the current loa-
ding address, use the sequence 000000fe XXXX4ef9 80000102 0007f900, where XXXX
is original contents of ROM at address start+$fe.
N.B. To create patch file, I'm using this algorithm:
1) First, I patch new values directly into the kickstart with a debugger.
2) I load another copy of kickstart into memory (my 6Megs allow this)
3) I write simple program to generate the patch file directly with debugger's
assembler (I'm using Mon 1.55 by Timo Rossi, which seems to be the most
powerful PD debugger known to me). This program is so simple so I never save
it.
4) I save (with the debugger) the table to the disk.

I don't know if anyone ever took over creating rtb/pat files, but it's not something you can do with the tools you have. Otherwise, why would they bother to include the files at all?

[psxphill]

@psxphill: Ok, even if I accept there's no PAT/RTB for KS 37.350 and the available tools won't let me create my own RTB for it, there's still hope skick would allow me to softboot KS 37.350 without RTB, by using ADR parameter.
However, it's ignored, or so it seems.

No the ADR parameter is to tell it what location in RAM it should load the kickstart, it doesn't help in relocating it. You need the RTB/PAT files for 37.350 and AFAIK they don't exist.
 
Someone will have to create them by duplicating the skick authors method. You could try tracking him down, he did say that registered users would get new RTB/PAT files. If someone else had already figured out how to create RTB/PAT files then I'd have expected the ones for 37.350 to have turned up by now.

[psxphill]

Well, someone must have figured out how to create RTB files, because I believe the last version of SKick that the author worked on was 3.43. Assuming I'm not mis-remembering things, the versions since then have just been to add more RTB and PAT files.
 
One more idea: Since 2.04 and 2.05 are so similar, can you rename the RTB from 2.04 and see it it works?

You could ask Jean-François Fabre where he got the files. My guess was that Pavel Troller produced them for registered users, as he said that new files would be sent to them first, and someone leaked them.
 
2.04 and 2.05 aren't going to be similar enough.

[psxphill]

Pavel Troller is a nice guy! He answered my email but he's retired from Amiga. He also told me his Amiga wouldn't boot anymore. So I guess I'm pretty limited to:
 
-Forcing SKICK to boot 2.05 without an RTB. Almost there! In FS-UAE, I can do "skick kick205.rom FORCE" and it boots to a guru. Then if I soft-reset the Amiga it boots to the softkicked KS... On the Minimig it won't softboot this way. I suspect it COULD work if I could set the KS loading address manually: isn't the ADR parameter for this? But it's ignored...
 
-Using a different softkicking solution that can softboot 2.05. I don't know any. Any ideas?

I'm not sure how FS-UAE is working, it sounds like the rom area isn't write protected. So it's loading the kickstart image over the top of the existing one, like if you selected it that rom file in the configuration. If you load it to another address then it will fail because it's compiled to only load to one address (the RTB file is needed to relocate it to another address).
 
Can't you just select the kickstart 2.05 in the minimig configuration?

[psxphill]

I just need a way to softkick into a 2.x version with A600-compatible scsi.device...

I'm pretty sure there isn't a way to do it without manually creating the RTB file. You could start with kickstart 2.05/3.1 selected in the minimig and softkick 1.3 for games that need it.