Auto-booting under Kickstart 1.2

[mark_k]

A few hard disk controllers for the Amiga were able to auto-boot even under Kickstart 1.2. If anyone has ROM dumps from one of those, I'd like to see them. For example:

Vortex Athlet and System 2000
Macrosystem Evolution 500 and Evolution 2000

I assume the ROM's diag routine (which gets copied to RAM and executed even under Kickstart 1.2) is how they manage to auto-boot with Kickstart 1.2. But what exactly would be diag routine need to do? Would it have to install a resident module which would be run later in the boot process?

[TjLaZer]

Never knew ANY would autoboot under KS 1.2! Thought that was the main reason everyone upgraded to KS 1.3

[Toni Wilen]

Looks like I can use this thread for KS 1.2 (and older) boot "documentation".

KS 1.2 autoboot description (Reverse-engineered Macrosystem evolution SCSI method) by Toni Wilen.

Expert/Guru level may be required to understand this completely.

Boot ROM at 0xF00000-0xF7FFFF region (Region that KS ROM scans for struct Residents)
Boot ROM has struct Resident gets called before KS ROM strap module (should have priority 0 or higher).

Resident code does following:

- Patch exec/DoIO()
- Patch exec/PutMsg()
- (Show custom boot screen)

DoIO() patch is used to create fake bootable disk in DF0:
It checks if DoIO is sent to trackdisk.device (check IORequest->Unit->Name == "trackdisk.device")
Patch code handles following IO commands (trackdisk.device won't see these)
- TD_MOTOR: simulate (return previous motor state).
- TD_CHANGESTATE: simulate disk inserted state.
- TD_CHANGENUM: simulate disk inserted state.
- TD_READ: return normal OFS boot block, then remove DoIO patch.
- If anything else: call original DoIO().

KS ROM boot strap module starts booting from non-existing floppy in DF0:.

PutMsg() patch is used to look out for DOS packets directed to floppy filesystem handler.
First it checks if Message is DOS packet:
- ln_Name must be non-zero.
- ln_Name must be long aligned (=pointer to DOS packet structure)
- Check if it is packet type 8 (ACTION LOCATE OBJECT).
- Anything else = call original PutMsg().

DOS packet was ACTION LOCATE OBJECT:
- Remove PutMsg() patch.
- Call disk detection/RDB parsing/add DOS device nodes routine. (Common routine that also all KS1.3+ Boot ROM drivers must have, normally called via autoconfig diag ROM)
- If no bootable partitions found: Call original PutMsg(). End.
- Allocate temporary big enough stack, call dos/DeviceProc("device name:") to force start filesystem handler process for this device. Deallocate temp stack. (Default stack is very small, too small for DOS BCPL routines, DOS LVO to BCPL call reserves 1500 bytes of stack for BCPL stack)
- Replace pr_FileSystemTask of process that called PutMsg() with process pointer that DeviceProc() returned.
- Call original PutMsg() but replace A0 (original message port) with DeviceProc() returned process->pr_MsgPort.

What happened?

DOS start routine (that sets default assigns, like SYS: and runs S/startup-sequence) was trying to find something (Called dos/Lock() = ACTION LOCATE OBJECT) from boot floppy. PutMsg() patch detected it, added all partitions, started boot partitions filesystem handler process and replaced default boot handler pointer (Was originally DF0: filesystem handler) with hard drive filesystem process, making it look like hard drive was the boot device.

It is a hack. But it is also very elegant hack, it does not poke or peek undocumented system structures.

What about KS 1.1 and older?
- DOS is BCPL only, it does not support non-BCPL file handlers. (dn_GlobalVec=-1 is not supported)
- expansion.library does not exist.
- 1.3 FastFileSystem calls exec/CopyMem. It does not exist.

What was needed to do to support KS 1.1 and older HD boot:

BCPL wrapper for WB 1.3 FastFileSystem and UAE directory harddrive filesystem handler.
Main difference between BCPL and non-BCPL filesystems:
- Must have correct BCPL segments or DOS will reject it.
- BCPL process code fetches DOS startup packet and passes it in D1 to filesystem but non-BCPL process needs to fetch the DOS startup packet. Solution was fortunately easy, just put the message back in original message port and jump to non-BCPL filesystem entry point.

Implement expansion/AddDosNode and expansion/MakeDosNode.

If 1.3 FastFilesystem: patch CopyMem() calls.

HD device dos node must have zero dn_GlobalVec and dn_SegList must point to filesystem's BCPL segment

OFS hardfile still needs one extra step: Need to find BCPL segment of ROM OFS (used by floppies). My solution was to FindTask("File System") which will return filesystem process for DF0: and then peek in pr_SegList to find OFS BCPL segment. This is not very elegant but OFS filesystem segment seems to be very well hidden in 1.1 and older.

It seems DOS at least since KS 0.7 (!) has supported external filesystems, harddrives etc.. Only missing part was official AmigaDOS support (Was "only" supported since KS 1.2). Internally Tripos BCPL DOS has apparently always supported them.

[Lonewolf10]

Wow, that's alot of neat information

Many thanks for sharing it Toni.

[ReadOnlyCat]

Originally Posted by Toni Wilen

KS ROM boot strap module starts booting from non-existing floppy in DF0:.

Wow, interesting.

If I understand correctly the Amiga initialization sequence, they have to stage their patch at multiple points because the initial autoconfig code runs before all necessary libraries are installed, so they cannot cleanly replace the boot device DF0: by another device at this stage because the OS has not setup everything yet?

This seems to be a nice hack overall but it would have crumbled if the low level sequence used to access the boot floppy changed for some reason since the DoIO() patch would not recognize the boot sequence anymore.

At that time this was unlikely since this would have required a KickStart ROM change but people switching Amigas could have been bitten by such an issue. This said, this sequence seems unlikely to change much over time so this probably was a mostly reasonable bet.

[Toni Wilen]

Originally Posted by ReadOnlyCat

If I understand correctly the Amiga initialization sequence, they have to stage their patch at multiple points because the initial autoconfig code runs before all necessary libraries are installed, so they cannot cleanly replace the boot device DF0: by another device at this stage because the OS has not setup everything yet?

No. It only patches exec.library and it "always" exists.

This seems to be a nice hack overall but it would have crumbled if the low level sequence used to access the boot floppy changed for some reason since the DoIO() patch would not recognize the boot sequence anymore.

It was only needed under KS 1.2 and it was already released (1.3 probably also existed when hack was being developed) = it was impossible for Commodore to break it with future KS versions because it didn't need to work with future versions

[a4k-oerx]

Thanks a lot for this very interesting documentation!