Below is a list of answered questions regarding Kickstart ROMs (in no particular order), as answered by Jeff Weeks, Ville Jouppi and Mike Innes.
What is the internal structure of a ReKick/ReCode ROM image? What encryption is used for ReKick images? How do these images differ from standard EPROM images?
Header = 108 bytes of text
"AMIGA ROM Operating System and Libraries:
Copyright © 1985-1992 Commodore-Amiga, Inc. All Rights Reserved."
Then 512KB of "encrypted" ROM image, which is a simple XOR using $DEADFEED as the key
Finally, more text at the end:
"AMIGA ROM Operating System and Libraries:
Copyright © 1985-1992 Commodore-Amiga, Inc. All Rights Reserved."
"Beta
Release! Do not distribute!"
They are different from a real ROM image (apart from the obvious change of base
address from $f80000 to $200000)
Exec and Expansion had minor changes, the
rest of the modules are identical.
IIRC, the ROM name was changed to "Beta ROM", and expansion had some code to patch in the already existing expansion board list instead of trying to create it again, and also to remove the memory used by the ROM image from the memory list.
What is the meaning of the term "Kickety-Split" (referred to by KickInfo)?
It's an 8 byte "ROM header" found in the middle of some 512KB ROMs, essentially splitting the ROM into 2*256KB ROMs
1111 (ROM ID) 4EF9 00F8 0002 (JMP $F80002 = jump to real ROM init)
As to why they added it, the only possiblese I can see for this is if some old game is trying to reset the Amiga and assumes it has a 256KB ROM and calls $FC0002 instead of $F80002.
What is the significance of the Ident field reported by KickInfo?
That's the first 2 bytes of the ROM, used as a chip identifier. Since the 68k bootstraps by setting its PC register to the address stored at address 4, the first 4 bytes are "free", and normally have 2 bytes of ROM ID followed by JMP <coldstart address>.
Several IDs are used to specify what type of ROM it is:
There might be other values such as a 256KB Rekick or 1MB or 2MB ROMs. Looking at the 68k, only the low nibble of each byte is used. This is the same loading scheme used by expansion ROMs such a the A2091.
What exactly does the following block of code do (presented in hex)?
4C DF 41 01 4E F9 00 20 0B 50 48 E7 80 82 2C 78 00 04 08 2E 00 00 01 29 67 E6 20 6F 00 0E 30 10 02 40 FF C0 0C 40 40 C0 66 D6 00 10 00 02 08 2E 00 01 01 29 67 10 4E 7B 88 02 4E 7A 00 02 08 C0 00 02 4E 7B 00 02 4C DF 41 01 4E 73
That's the new privilege trap code installed by the decigel patch.
It checks
for a MOVE SR,<ea> instruction and changes it to a MOVE CCR,<ea> instruction
(and flushes instruction cache on 020+ too).
See attached disassembly, I also added the comments from the source on aminet (http://aminet.net/package/util/boot/Decigel)
Also note that Bryce Nesbitt's comments state that "This code is not expected to
function on the 68040."
I've noticed this patch code is never immediately
after the last module in ROM, which suggests to me it wasn't included as part of
the build process, but added later.
No idea if this was an "official" mod by the developers though, it would be
silly for a developer ROM to use code known to be a problem with an 040.
It
would also be trivial to add this patch to exec if they really wanted to make it
part of their build process.
; "Decigel" patch as found in Kickstart ROMs.
; Patches a "MOVE SR,<ea>" to "MOVE CCR,<ea>" due to the former being a priviledged instruction on 68010+ CPUs.
; Exec is also patched in ROM to point the priviledge trap to "NewHandler" here.
CallOrgHandler:
MOVEM.L (A7)+,D0/A0/A6 ;00: 4cdf4101
JMP $00f80c18 ;04: 4ef900f80c18 To previous handler... (exit)
NewHandler:
MOVEM.L D0/A0/A6,-(A7) ;0a: 48e78082
MOVEA.L ABSEXECBASE.W,A6 ;0e: 2c780004
BTST #0,(297,A6) ;12: 082e00000129
BEQ.S CallOrgHandler ;18: 67e6 Not 68010+, so call original handler.
MOVEA.L (14,A7),A0 ;1a: 206f000e
MOVE.W (A0),D0 ;1e: 3010 Examine opcode
ANDI.W #$ffc0,D0 ;20: 0240ffc0 Mask out EA field
CMPI.W #$40c0,D0 ;24: 0c4040c0
BNE.S CallOrgHandler ;28: 66d6 If not "MOVE SR,<ea>", call original handler
ORI.B #$02,(A0) ;2a: 00100002 Convert to MOVE CCR,<ea>
BTST #1,(297,A6) ;2e: 082e00010129
BEQ.S .no_cache ;34: 6710 If not 68020+ then there's no instruction cache to clear.
MOVEC A0,CAAR ;36: 4e7b8802
MOVEC CACR,D0 ;3a: 4e7a0002
BSET #2,D0 ;3e: 08c00002 Set "Clear entry in instruction cache"
MOVEC D0,CACR ;42: 4e7b0002
.no_cache
MOVEM.L (A7)+,D0/A0/A6 ;46: 4cdf4101
RTE ;4a: 4e73
Was Kickstart 1.0 ever made available in PAL form?
No.
What internal version were the A3000 softkick 1.4 boot ROMs?
Seems it is based on 36.16, but if you take a look, it has a second, newer copy of exec.library towards the end where it really boots from. This probably saves time, the superkick loading modules are right after it. I haven't done a disassembly though.
Were there any byte-level differences between the A3000 SuperKickstart 2.04 image and the physical ROM image?
No, the difference is that bonus code is added at the end.
Did an A3000 SuperKickstart 3.1 (40.068) ROM image exist? If so, were there any byte-level differences between it and the physical ROM image?
Educated guess: it probably did exist. All the 3.1 SuperKickstart disks I've seen floating around had the final version of the 2.04 bonus code tacked on the end.
What are the exact dependencies that the Amiga 3000 Kickstart ROMs have on a MMU or other A3000-specific hardware?
I know it uses 68030-specific MMU commands and I'm guessing it accesses the SCSI controller quite directly, but as before, I haven't disassembled it.
Did more than one version of Amiga 3000 SuperKickstart 1.3 Bonus code exist?
Yes, three versions:
Were any softkick tools available from Commodore other than KickIt?
Yes. Maprom, mmukick, ReKick (same name as a tool by Thomas Kessler). Also Dave Haynie's SetCPU can do ROM remapping via the MMU, but according to the documentation it was his personal project.