WIPL and LOAD - Nakazoto/CenturionComputer GitHub Wiki

WIPL (Warrex Initial Program Loader)

The Warrex Initial Program Loader is the first starting off point for getting further into the system and executing some genuine Centurion software. It is important to note that the WIPL requires the MUX card to be in an uninterrupted card chain from CPU6, because it relies on daisy chain interrupts. We're still working on fully disassembling the code to figure out exactly what is what.

WIPL Usage

To use the WIPL, the name of the program is typed in and then the WIPL will search for the program on the disk. Here is a list of programs that we currently know (but have yet to successfully execute).

Name Program Notes
@OSN Centurion Operating System This will search for the OS on the Hawk drive and execute it if found
?MOST Memory Self Test We currently believe this is a more fully fledged memory test
?TOS Test Operating System This is similar to TOS on the DIAG Board, but includes more features
?DISK Hawk Drive and Disk Test Currently unsure as to what exactly this tests
DDUMP Disk Dump Disk image copy that dumps one platter to another for backups

The Code

This code was pulled directly off the platter using a special dump program. This is particularly important because the code does appear to have some parts that are self-modifying, but this code should be pre-modifications. The binary file is available here

LOAD

Also known as LOS (Load OS?)

LOAD is a second stage bootstrap. On the disk platters we have dumped, WIPL has been configured to automatically boot into LOAD root directory if a file named @LOAD can be found in the root directory.

@LOAD can be used in two ways. As a more advanced WIPL, or as a bootstrap loader for the final operating system.

As a more advanced WIPL

When sense switch #2 is set, LOAD act as a more advanced WIPL showing the exact same NAME= CODE= DISK= prompt, and is able to boot standalone executables.

But it gains little bit of extra functionality over WIPL.

  • LOAD supports subdirectories. Entering NAME=?.?TMOS should launch executable ?TMOS from the ? directory.
    The fullstop is used as a directory separator
  • WIPL only has drivers for the disk it's installed on. Load as drivers for other types of DISK, so you could use a hawk WIPL+LOAD to a file from a finch drive, or a floppy.
  • It prints a version string before the prompt, for example: LOS 7.1 - E
  • If you give it a configuration dataset, it will correctly bootstrap and load OPSYS as below.

It does have one limitation compared to the WIPL version we have. Our WIPL relocates a stub upto the top of memory, and can load executables into any addresses upto 0xeee3. LOAD itself takes advantage of this and places code as high as 0xe969. But LOAD can only load executable into the lower 32KB of memory. Hence LOAD is unable to load itself or another version of LOAD.

It is possible that previous versions of WIPL, before LOAD was introduced, shared this maximum address limitation.

Before transferring execution to a binary, LOAD removes any interrupt handlers it installed; disables interrupts; resets DMA and MUX; and restores the A register to the original value from when WIPL transferred execution to LOAD. Z is not restored.

As a bootstrap

When Sense #2 is off, LOAD is configured to automatically load @OSN from the root. OSN might be a standalone binary (file type of 4), in which case LOAD boots it as above. But in a correctly configured OS, OSN will be a configuration file containing stored configuration for devices.

When acting as a bootstrap, the LOAD version appears to be somewhat coupled to the version of OPSYS it's booting. The configuration format is different for both versions of LOAD we have, and LOAD has knowledge of many OPSYS data structures compiled in (though it's not clear how much these change)

LOAD is responsible for configuring all of OPSYS's "comrg" (Common Region?) variables at 0x100 to ~0x160, along with the various data structures which they point to, such as the physical unit block table (describing devices), memory map tables and task infomation blocks. Some of the the comrg values hardcoded in LOAD, or based on the amount of ram, while others are read from the OSN Configuration Data Set.

This section of code hasn't been fulled REed, but

OSN can specify:

  • Lines of text to echo to CRT0 before starting the load
  • pre-loaded task infomation blocks aka "tib"
  • "physical unit block" aka "pub" structs for Disks, CRTs, Printers and even Print Spoolers (which are virtual devices)
  • SPEC, which appear to be additional driver object files.

While LOAD is responsible for creating the pubs for all the devices, it does not initialise any devices, and in theory OPSYS shouldn't try to initialise devices before the are accessed, except for CRT0, the boot disk and SPECs.

Structure

LOAD a type 4 file in the standard centurion binary format. It loads a few KB of data to low mem, and then fills most of the 0x8000 to 0xefff range.

LOAD requires a minimum of 64 KB of memory to even load (60KB is not enough, it uses page tables to break the 60KB boundary), and probably requires more to actually boot an OPSYS.

LOAD comes with an integrated version of OPSYS + drivers, that comes pre-configured with a single CRT device, all possible disks, and a single task. LOAD initialises this OPSYS (even sets up the clock interrupt handler), and uses it's syscall interface for all IO.

In one of our LOAD versions, OPSYS appears to be somewhat complete, with a bunch of syscalls, code and strings which are never used. The later version stripped it down, but it still seems to have unused code and strings, including handlers for some of the deleted syscalls.

Versions

We have found two versions of @LOAD so far. Version 6.05-B and Version 7.1-E

Version 6.05-B

Was found on the first removable hawk platter we dumped.
This platter didn't have a proper directory structure, it appeared to a backup disk with tar style archive format. There were two archives, a complete BACKUP03 and a partially overwritten BACKUP02. @LOAD was found in BACKUP02, and was the only file of interest on the platter.

  • Based on an OPSYS claiming to be DOS 6.4-D
  • Has drivers for CRT, Hawk, Floppies and Phoenix.
  • Most syscalls in OPSYS are intact.
    Missing syscalls
    • 0x3e/62: @rs cpl record skip
    • 0x40/64: @tioc tape io
    • 0x51/88: @bug
    • 0x61/97: @ccc security code check
  • OSN file type is 1, should have SYSTEM at offset 2.
  • Hardcoded load path for OPSYS kernel is @SYS.OSN
  • Includes an integrated debugger appended to the end
    You can break on entry by setting Sense #3. You can break at any point by pressing CRTL+B (not 100% sure about this)

We don't have any support files to go with this.

Binary can be downloaded here
There is a WIP disassembly here

Version 7.1-E

Found on the second removable hawk platter we dumped.

  • Based on an OPSYS claiming to be DOS 7.1-A
  • Has drivers for CRT, Hawk, Floppies and Phoenix, Finch and an unknown disk type named WCN
  • To fit the extra drivers, most unnecessary syscalls have been striped out. The OPSYS section is 4KB smaller.
  • OSN file type is 3.
  • Hardcoded load paths for OPSYS kernel are @SYS.OSEG0 and @SYS.OSEG1
  • Appears to be more optimised for size, potentially compiler improvements?
  • No integrated debugger, but enough spare memory for one to be added.

We appear to have a complete operating system to go along with this LOAD

Binary can be downloaded here
There is a WIP disassembly here