ROM format/structure question.

[Doobrey]

Does anyone know the what the last 16 bytes in the Amigas ROM is for?..
 I know 8 bytes before it is the checksum and the rom size,but I`ve drawn a blank on the last bit.

 All the 3.x ROMS I`ve seen have the same series of 16bit words at the end.
 0018,0019,001A,001B,001C,001D,001E,001F.

I just found it strange, since unused space is normally set to $FF..

[Piru]

IMO it's just some padding to avoid matching anything useful there (like empty space, which it is not).

Curiously, when two of the mathieeesingbas.library V40.4 LVOs were not linked properly, the values in the function offset table were 001A,001C... Almost the same pattern. Not quite though, if it was 001A, 001B I would have considered that pattern some linker padding.

[Castellen]

Check the Motorola 68000 datasheet to see if it does anything with the data at those addresses.
Could be something like reset vectors or interrupt vectors??

[Doobrey]

I don`t think they could be vectors, as some of them would result in the code starting at odd locations. (odd as in not even, not odd as in wierd !)

 I`m beginning to think they`re just leftovers from debugging.

[Piru]

680x0 reads two memory addresses at reset, 0 and 4. 0 contains the initial SSP and 4 contains the initial PC.

Anyway, Amiga ROM is made to appear at address 0 via ROM overlay bit in cia register at reset. That is the ROM appears at both 0x0 and 0xf80000 (for 256K roms, the 256K is mirrored twice to 0xf80000 and 0xfc0000).

The first longword is ROM id + jmp opcode, SSP will contain this (bogus) value initially (it's soon replaced by low chipmem address in the ROM code). The 2nd longword is ptr to ROM startup code (0xf80?? or 0xfc00??), and this is the address that will be executed. This code sets up some HW regs, turns off ROM overlay, initializes CPU regs, does initial system integrity checking, scans for onboard memory and begins executing resident modules.

The end of the ROM is not used for anything, except ROMSize and checksum. The other values seem to be some sort of padding, without any function.

[Doobrey]

Ta for the info Piru,
 I`d only just stopped playing around with hacking the ROM, zeroing that pattern made no difference to anything, so like you say, just junk..
 Oh well, back to messing around again..
I just made myself a new ROM image with Piru`s Exec44.1, removed carddisk.device,workbench and icon librarys, added some BlizKick modules and replaced bits with some of the OS3.9 modules.
 Now I`ve got 80Kb free space to play with.. :evilgrin:

[Sparky]

Doobrey wrote:
Ta for the info Piru,
 I`d only just stopped playing around with hacking the ROM, zeroing that pattern made no difference to anything, so like you say, just junk..
 Oh well, back to messing around again..
I just made myself a new ROM image with Piru`s Exec44.1, removed carddisk.device,workbench and icon librarys, added some BlizKick modules and replaced bits with some of the OS3.9 modules.
 Now I`ve got 80Kb free space to play with.. :evilgrin:

Now making your own ROM image would be a rather nice tutorial ...

[Doobrey]

Don`t worry Sparky, when I`m done it`ll be a simple point and click program that`ll do it for you.
 I suppose I`d better figure out what stuff you can add to what machine, and what stuff you can`t remove too !

 There`s even more stuff in the pipeline, but if I told you, I`d have to kill you  :quickdraw:

[Nickman]

Doobrey wrote:
Don`t worry Sparky, when I`m done it`ll be a simple point and click program that`ll do it for you.
 I suppose I`d better figure out what stuff you can add to what machine, and what stuff you can`t remove too !

 There`s even more stuff in the pipeline, but if I told you, I`d have to kill you  :quickdraw:

I'm realy looking forward to that

I'm also planning on makeing your kickrom flash thingy when your are done with it an posts some nice description :-D

[Doobrey]

Castellen wrote:
Check the Motorola 68000 datasheet to see if it does anything with the data at those addresses.
Could be something like reset vectors or interrupt vectors??

Bingo !
The CPU uses that data at the end of the ROM to map the hardware interrupt level to an autovector.
 Just stumbled upon this from the RKM Libs/Interrupts.. hey, it only took me 3 years to get back to this and follow Anthony's advice ! :lol:

The priority level of the new interrupt is used to index into the top seven words of the processor address space. The odd byte (a vector number) of the indexed word is fetched and then shifted left by two to create an offset into the processor's auto-vector interrupt table.The vector offsets used are in the range of $064 to $07C.

[Jeff]

@Doobrey

I'll join the list of people that can't wait:-D Thank you for what you have done so far!

Jeff

[Piru]

Heh indeed, didn't spot that before either. I can think of some clever applications for this stuff, say for example having interrupts relocated on 68000, much like with VBR on 68010. Obviously that'd require a custom ROM, but still... :-)

[alexh]

Doobrey we love you. (In a totally platonic, non sexual way).