-BOOTING

There are several ways to BOOT. 

MOTOROLA Boot-

The PROPER way, is to BOOT from a disk in the MOTOROLA format that is known by the firmware, using the firmware....MACsBUG/TenBUG/VMEBUG.  The Firmware will do the BOOT, by reading in the Initial Program Loader (IPL) and transfering control to it. The IPL then reads the OS and transfers control to it. 

For CPM, the IPL is the CPMLDR (in system track outside of filesystem)  

For Versados, the IPL is IPL.SY (in a contiguous file in the file system)

For Unix, the IPL is Unix loader (located between the SuperBlock and the Inode table)

( YOU SHOULD USE TENBUG, Boot->Defaults-> ROM file should be TENBUG22.mx)

To boot use TENBUG's BO or BH commands. 

 BO <disk>,<controller>,<string to be passed to the IPL.SY or UNIX LOADER>

IPL.SY's string defaults to 0.&.VERSADOS.SY..options are also allowed

Unix Loader's string defaults to stand.unix.. NO options allowed

CPMLDR does not use the string

If the Tenbug firmware is used, then you MUST NOT use the simulated BOOT via a menu item; and, none of the boot menu parameters are significant. The simulated boot will trash Tenbug scratch ram. Use simulated boot with the BSOD rom only. With TENBUG, Use the TENBUG BO or BH command to boot. Tenbug will load the IPL. If tenbug is used, you should get a tenbug prompt after the POR.(Tenbug 2.2 is recommended)

If the simulated boot is used, you MUST use BSOD rom; and, you must specify the menu item Boot Parameters( boot type, boot drive, boot parameters, and you must stop the emulator before booting)The emulator not BSOD will read IPL.SY (or unix loader, or cpmldr) into memory and set up registers to indicate that the IPL should use TENBUG IO routiines (implemented in BSOD) , then copy the command line to address $400, and the disk's configuration area to $500. WARNING - the simulated boot destroys the area of ram used by tenbug. Do NOT use simulated boot with tenbug.

The Dialog box for the simulated boot, has a dropdown list that contains several common boot command lines for Versados. 

WARNING - The simlated boot relies on the BSOD ROM. The Boot drive is set by BSOD after a POR. If you change the BOOT device, you MUST do a POR so that BSOD sets the Boot drive properly. The BSOD rom's disk IO routines, use the BOOT drive that is set when POR occurs. (note - the unix loader actually queries TENBUG for which drive was used..the BSOD supports such a query)

The menu item under BOOT type called MOTOROLA (disk) simulates a TENBUG firmware boot (needed, because the dummy BSOD ROM does not have Boot capability, that is, it does not read the IPL program into memory, so the emulator actually does the read of the IPL.SY program into memory). 

NOTE - The emulator MUST be stopped, to boot using the menu BOOT item. This is due to how the Microcode Engine works. The engine can not be stopped in non-event code (stopping requires a release to the OS).

CPM68k, Versados and UNIX SYSV all use the Motorola boot format. The SP is set to the value in the IPL.SY file's first 4 bytes. The PC is set to the value of the second 4 bytes in the IPL.SY file. 

(note- the IPL.SY file does not need to be in the disk's file system. For Versados the IPL.SY file IS an actual file in the file system (file type is Contiguous). For CPM 68k, the IPL.SY(cpmldr.sys) file is placed in the system tracks. The CPMLDR.SYS file contains the disk's MAGIC and the IPL.SY file(which is the CPM loader). It appears that UNIX uses a BOOT LOADER that is not in the file system(located between the superblock and teh Inode table). The UNIX loader uses the firmware's IO to read UNIX (in the file system) into memory. And unix uses the firmware IO to mount root.

NOTE - once the simulated BOOT (or tenbug) has loaded IPL.SY (or equivalent), then IPL does the rest of the BOOT. IPL.SY uses the IO methods specified by the registers(as set by the simulated boot code or by TENBUG) The BSOD supports those IO methods. IPL calls the IO routines in BSOD or TENBUG to do the actual I/O. SO, the BSOD implements those TENBUG functions needed for IPL.SY to complete the BOOT.

The MOTOROLA Boot method sets up registers as follows

'    ENTRY  SR = $2700
'           PC = FROM LOCATION 4
'           A0 = CHANNEL ADDRESS
'           A2 = POINTER TO CONFIGURATION DATA WITHIN DEBUGGER
'           A3 = DEBUGGERS' INTERNAL DISK READ ROUTINE ADDRESS (NON TRAP #15)
'           A4 = DEBUGGER ENTRY POINT
'           A5 = BEGINNING OF COMMAND LINE - FILE NAME
'                     (FOLLOWING BO 0,0,)
'           A6 = END OF COMMAND LINE
'           D0 = DEVICE NUMBER (LOW ORDER BYTE)
'           D1 = CONTROLLER NUMBER (LOW ORDER BYTE)
'           D2 = CONFIGURATION CODE (BYTE 5 VALUE)
'           D3 = FLAG FOR IPL FROM DEBUGGER:  CODE 'ME4U' TELLS IPL IT IS
'                OK TO USE THE DEBUGGERS' INTERNAL DISK READ ROUTINE.
'           D4 = FLAG(s) for IPL if we have new bug interface (AUG 84)
'                   D4 = 'IPLx' where x = bits 7654 3210
'                   Bits         Status
'                    0           Firmware supports TRAP #15 calls I/O
'                    1           Firmware is to do disk I/O for IPL
'                                  (Old 'ME4U' in D3)
'                    2           Firmware supports an alternate TRAP #15 I/O
'                                protocol
'                    3           Firmware supports TRAP #15 disk I/O
'                    4-7         Reserved
'     EXIT:    SR = $2700

Here's the Actual Code used to set up the registers for simulated booting.

        gCpuD(0) = gBootDrive
        gCpuD(1) = 0 ' IPC
        gCpuD(2) = DskAttrWord ' Disk configuration code $48 HD, $AC floppy ????
        gCpuD(3) = &H4D453455 ' ME4U = Use Macbugs Disk I/O
        Select Case gBugType
            Case 0 'tenbug
                gCpuD(4) = &H49504C03 ' IPL + 03 (x x x x T15Disk AltT15io UseBug T15io)
            Case 1 'vmebug
                gCpuD(4) = &H49504C0C ' IPL + 0C (x x x x T15Disk AltT15io UseBug T15io)
        End Select
        gCpuA(0) = &HF1C0D1 ' address of RWIN
        gCpuA(1) = AddressToLoadAt ' address of program just loaded
        For i = 0 To 255
            MemW &H500 + i, True, CnfgArea(i), True
        Next i
        gCpuA(2) = &H500 ' address of disk configuration area
        gCpuA(3) = &HF00020 ' address of macsbug disk read routine
        gCpuA(4) = &HF00040 ' Address of macsbug entry point
        gCpuA(5) = &H400 ' Start of text after second comma  BO 0,0,text;HL=$0000
        If Len(gBootString) > 0 And Len(gBootString) < 128 Then
            For i = 0 To Len(gBootString) - 1
                MemW &H400 + i, True, Asc(Mid(gBootString, i + 1, 1)), True
            Next i
        Else
            i = 0
        End If
        gCpuA(6) = &H400 + i ' End of Text +1
        
        MC68010.SR = &H2700
        gCpuA(7) = SP
        gCpuPC = PC

Simple Boot-

SIMPLE Boot uses the same parameters (except the Disk specification) as specified in the Get/Put Boot dialog box. SIMPLE boot will load LSN-Blocks (256 bytes) of the Selected BOOT DISK into memory at Load Address, and load the PC with Alternate Boot PC and load the SP with Alternate Boot SP. 

The Alternate boot PC and alternate boot SP, will be used for boot methods that do not inherently set them. Alternate PC and SP can be set by menu item Boot->Get/Put Boot.

Boot S-REC-

Boot SREC will allow two S-rec files to be loaded. The SP will be set to the Alternate boot SP, and the PC set to the "last loaded" S7, S8 or S9 S-record. Some programs that create Srec files do not place the proper PC value in the S7, S8 or S9 record, so an option exists to allow you to either use the Srec PC or the Alternate boot PC. This is usefull to boot the first generation CPM system. You could boot two srec files, one with a custom BIOS and another with the CPM 68k CPM15000.SR (or CPM400.SR) file.  The CPM1500/400.SR files do NOT have a valid start address in the S7, S8 or S9 records. Several freeware assemblers also do not put a valid start address into the Srec file. The two SREC files are specified by using the boot->defaults menu. Other files are requested on-demand. 

Boot CPM Command File-

Boot CPM Command file alows you to load any CPM command file (.68k or .SYS). The Sp is set to the Alternate boot SP and the PC is set to the starting address of the Command file. CPM.SYS can be booted directly using this method. 

Other boot methods-

Boot Versados Load Module allows a Versados .LO file to be booted. the SP is set to the alterante boot SP and the PC is set to the Entry Point of the Load Module.

Boot Versados IPL (Initial Program Load Module) allows you to boot IPL.SY or Versados.SY directly. (or any Load module that meets the IPL requirements) The SP is set to the value of the first four bytes in the IPL's first Memory Image Block (MIB) and the PC to the second four bytes. (note- typically, the PC in the MIB is the same as the Entry pointer address, contrary to what the manuals say)

NOTE -  it is best to NOT LOAD or BOOT to an area where the emulator is currently excuting instructions. A reset or Power on Reset will cause execution in the ROM. But, it is still possible to crash the ROM during BOOT by trashing the stack. 

It is best to boot using the firmware ROM BO command. To boot using TENBUG, first select which IO port is the console. Tenbug uses the first port that it sees a character from..note that 2.2 requires a Cntrl-C to select port, but 2.1 ..any character will do.

HOW the VME10 Normally boots.

TenBUG, the VME10 firmware, does a real system boot. TenBug reads the first sector to determine the MAGIC and to acquire boot parameters for the IPL.SY program and the location of the disk configuration area for the media in the drive. TenBUG, then, reads the Configuration area and configures the Disk Controller for the type of media in the drive. TenBug, then, reads the IPL.SY program into memory. The IPL.SY file is nothing more than a set of contiguous 256 byte blocks, somewhere on the drive. There is a pointer to the IPL.SY file in the VID. IPL.SY can be a contiguous file in the disk's file system, or it can be in a reserved area of the disk. Versados uses a contiguous file, in the Versados file systrem. CPM uses the reserved tracks at the begining of the disk, before the file system. 


          Side 0     Side 1
        |----------|----------|
 Cyl 0  | V0  C0   | V1  C159 |   V0/C0, is always FM (16x128 byte SPT)
        |----------|----------|
 Cyl 1  | V2  C1   | V3  C158 |   For Versados and Unix V1-V159 are MFM 16x256 byte SPT
        |----------|----------|
 Cyl 2  | V4  C2   | V5  C157 |   For CPM 68k C1-C159 are MFM 8x512 byte SPT
        |----------|----------|
        | .......  | ........ |  
        |----------|----------|
 Cyl 78 | V156 C78 | V157 C81 |
        |----------|----------|
 Cyl 79 | V158 C79 | V159 C80 |
        |----------|----------|

CPM reserves 3 tracks, C0, C159, and C1, for the IPL.SY (CPMLDR.SYS) program. Notice that, for CPM, TenBug sees the disk as having the IPL.SY program in V1,and V2 (32 256 byte Blocks); with V0 reserved for the VOLID and the CONFIG area. TenBUG and Versados, see V0 as having the first 8 LSNs(0-7,256 byte blocks) with LSN 8 starting in the first sector of V1. The remaining V1-V159, each have 16 LSNs(256 byte blocks). However, the RWIN disk controller sees things differently. The RWIN sees the LSNs according to the configuration parameters in the Command Block. To access V0, LSNs are calculated as though the entire disk has 16 128 byte sectors per track. To access V1-V159, the LSNs are calculated as though the entire disk has 16 256 byte sectors per track. 

So, to the RWIN, LSN 16 is the first 256 byte Block in V1; while to Versados, LSN 8 is the first 256 byte Block on V1. The Versados driver adjusts for this discrepency. Versados sees the disk as continuous with LSN 7 next to LSN 8, whereas, the RWIN can not access LSN 8-15, since they do not exist. Another way to say it, is, the RWIN's LSN 16 is Versados's LSN 8. TenBUG uses the Versados way of numbering Blocks. 

CPM numbers thing totally different. Whereas VersaDOS sees tracks alternating from side to side, CPM sees tracks as going "out" one side; and, then "in" on the other. The CPM driver for the RWIN makes the appropriate adjustment for this. 

For VersaDOS, Tenbug, the Versados IPL.SY, see the disk as a contiguous set of 256 byte blocks, numbered from 0 to n-1, where n is the number of 256 byte blocks on the drive, known as LSNs. 

For CPM, Tenbug sees the disk just as it did with Versados. The IPL.SY program is replaced with the CPMLDR. Since the CPMLDR has the same RWIN driver as the CPM.SYS, CPMLDR sees the disk just as CPM does.

Notice, that for CPM, the Data tracks are 2 - 158, with C0, C1 and C159 reseved for the system. C0 is V0. C1 is V2. And C159 is V1. So, there's really 3 system tracks. C0 and C2 are reseved by the DPB Offset, while C159 is reserved by making the number of data tracks one less than the max. 

Get/Put BOOT- 

Normally, you would use a utility that is part of the SYSTEM that you are running to Initialize and place the boot loader on a disk. For CPM that is a program called PUTBOOT. PUTBOOT will write the OS's Boot loader and the info required for the Firmware (TENBUG) to perform a BOOT. For Versados the program is called INIT. INIT is used to prepare a disk for use, and to place the Boot loader (IPL.SY) onto the DISK. INIT is noramlly used to format the disk also, but for the VME10 Emulator, there's no need to format a disk. The disk images made by the emulator are preformatted and perfect.

The Emulator also has a Get/Put BOOT feature. It is more or less, just a Read and Write of the Disk. So, if there's no bootable disk for your system, the emulator's Get/Put BOOT can be used to place the proper info to boot on the disk image. 

USE the Get/Put BOOT feature with EXTREME CAUTION.

The Get/Put BOOT feature always treats the disk as a Versados Disk. It sees the disk as a sequence of 256 byte Logical Sectors. This is OK for Versados disks, but notice that CPM disks use different numbering for sectors and tracks. But also notice that the boot info for CPM is placed exactly as it would be for Versados, so that the Firmware can boot it as though it was a Versados disk. So it is reasonable to use the Get/Put BOOT feature to place the boot loader and other required information for booting a system onto a disk image. 

