Skip to content

04-boot-chain.md

Latest commit

 

History

History
172 lines (135 loc) · 6.13 KB

04-boot-chain.md

File metadata and controls

172 lines (135 loc) · 6.13 KB
Raw

04 — The boot chain, and every script on the disc

There are five scripts. All five are printed here in full, because together they are 908 bytes and they are the most informative bytes on the master — the Gunship lesson that pirates.demo was the single most useful file on that disc applies again.

s/Startup-Sequence — 103 bytes

.bra {
.ket }
failat 21
c:Setpatch >nil:
assign t: ram:
assign env: ram:
s:T17Menu
Execute ram:T17.bat

Eight lines and the whole architecture is in the last two.

  • .bra { / .ket } redefines the AmigaDOS Execute substitution brackets from < > to { }. That only matters if something later substitutes — and something does.
  • failat 21 raises the failure threshold so a WARN does not abort the boot.
  • c:Setpatch >nil: — the 40.16 SetPatch runs, silently, and its output is discarded.
  • assign t: ram: and assign env: ram: give the OS its scratch and environment directories in RAM. AmigaDOS is alive throughout. Nothing on this disc kills the OS.
  • s:T17Menu runs the front-end as a program.
  • Execute ram:T17.bat runs a script that does not exist on the disc.

So the menu's job is not to launch a game. Its job is to write a script: T17Menu puts the user's choice into ram:T17.bat and exits, and the startup-sequence then executes whatever it wrote. The dispatch from menu to game is a generated shell script, not an exec or a chain-load.

That is why the .bra/.ket redefinition is there: the generated batch file is run through Execute, and moving the substitution brackets off < and > keeps Execute from trying to interpret the redirection characters the generated lines contain.

ram:T17.bat is never on the master, so its content has to be read out of T17Menu — and it is there, as the literal text the menu assembles. See below.

/SuperFrog/SuperFrog — 275 bytes

cd0:c/Assign >NIL: SYS: CD0:  add
cd0:c/Assign >NIL: C:   CD0:C add
cd0:c/Assign >NIL: S:   CD0:S add

Stack 8192
cd0:c/Assign SDDISK1: SFData
SFIntro
SuperFrogCD

cd0:c/Assign >NIL: SYS: CD0:  remove
cd0:c/Assign >NIL: C:   CD0:C remove
cd0:c/Assign >NIL: S:   CD0:S remove

Assign SDDISK1: SFData is the whole floppy-to-CD bridge. The game engine asks for SDDISK1:L1BM; this line makes SDDISK1: mean /SuperFrog/SFData. See 10-floppy-ancestry.md for what the engine asks for when SDDISK1: is not the name it uses.

Note the symmetry: three add assigns before, three remove after. The script cleans up after itself so control can return to the menu.

SFIntro then SuperFrogCD — two separate programs, the intro run to completion before the game starts.

/Pool/Arcade Pool — 250 bytes

cd0:c/Assign >NIL: SYS: CD0:  add
cd0:c/Assign >NIL: C:   CD0:C add
cd0:c/Assign >NIL: S:   CD0:S add

Stack 8192
cd0:c/Assign b: ""
Pool

cd0:c/Assign >NIL: SYS: CD0:  remove
cd0:c/Assign >NIL: C:   CD0:C remove
cd0:c/Assign >NIL: S:   CD0:S remove

Same skeleton. The one line that is not shared is cd0:c/Assign b: "" — an assign of the name B: to the empty string, which in AmigaDOS removes an assign of that name. So the Arcade Pool launcher defensively clears a B: assign that this disc never creates.

Pool is the only binary on the disc that opens trackdisk.device (08-audio.md lists the device opens). A demo that clears a B: assign and opens the floppy controller is a demo built from a floppy release with the floppy plumbing left in.

/SuperStardust/Super Stardust — 272 bytes

cd0:c/Assign >NIL: SYS: CD0:  add
cd0:c/Assign >NIL: C:   CD0:C add
cd0:c/Assign >NIL: S:   CD0:S add

Stack 8192
cd0:c/LoadView
MAINDEMO2
TUNNELDEMO
MAINDEMO1

cd0:c/Assign >NIL: SYS: CD0:  remove
cd0:c/Assign >NIL: C:   CD0:C remove
cd0:c/Assign >NIL: S:   CD0:S remove

Two things worth having.

  • cd0:c/LoadView with no argument — the 144-byte Commodore command that resets the view to nothing. It is on the disc solely for this line. The Super Stardust demos take the display over completely, so the launcher blanks the Intuition view first; the other two games do not need it.
  • MAINDEMO2, TUNNELDEMO, MAINDEMO1 — three programs, in that order, and the second build runs first. MAINDEMO1 and MAINDEMO2 are near-identical builds differing in one immediate constant (06-executables.md); the running order is 2, tunnel, 1.

/SuperFrog/Manual — 8 bytes

ManMenu\n

The entire file. A one-line script whose only job is to run ManMenu, given a Manual.info icon so it appears in the Workbench drawer. Eight bytes, and it is a real dispatch step, not padding — the Gunship rule that a tiny file is a test rather than noise applies to eight bytes as well as to one.

What the menu writes

T17Menu (125,368 bytes) is a hunk file with 1,452 bytes of CODE and 123,620 bytes of DATA — 98.8 % data. Its 55 relocations all fall in hunk offsets 0x2C–0x566, i.e. inside those 1,452 bytes of code. Whatever draws the menu is in the data hunk as artwork and the code is a thin driver.

The strings it assembles are readable in it, including the assign line the Superfrog launcher needs:

Assign SDDISK1: SFData

so the launcher scripts on the disc and the lines the menu can generate into ram:T17.bat overlap. ManMenu carries the identical $VER: string — T17MENU 39.1 Kenny G (23.07.94) — so the manual browser is the same program under a different name, built from the same source on the same day.

What is not in the boot chain

  • No SetPatch failure handling beyond failat 21.
  • No noopenwb and no reboot: the chain ends by executing a generated script, not by resetting.
  • No IconX invocation in any script, although c/IconX ships — it is there because the four .info project icons are IconX tool icons, so the games can also be started by double-clicking from Workbench rather than through the menu. That is consistent with Disk.info being present and with each game having its own drawer icon.
  • No CD-ROM access of any kind in the scripts beyond the CD0: assigns: nothing opens cd.device, nothing reads a TOC, nothing touches Akiko.