• Keine Ergebnisse gefunden

4.2.3.2.3 After Running SBIOSTESTER

Im Dokument 910-335-1594 (Seite 122-126)

Make sure to return to caller Dying on this machine is simple

IV. 4.2.3.2.3 After Running SBIOSTESTER

If SBIOSTESTER runs through to completion, and if it displays no error messages, you may attempt to bootstrap your System with some degree of confidence.

Otherwise, debug your SBIOS and try again. Do not attempt to boot your System if you know there are bugs in your SBIOS.

116

IV.4.3 Bootstrapping

IV.4.3.1 Loading a Bootstrap

If the SBIOS is not already in memory, it must be loaded (see the preceding section). The bootstrap must then be loaded into memory at either

aooo

hex or

0000 hex, depending on the machine's memory configuration (see Section IV.4.1).

The bootstrap is recorded on the first 256 bytes of Track 0 of each Bootstrapping disk. Any available method may be used to load this code into the appropriate memory space. Possible methods include using a manufacturer-supplied operating system or a small assembly language program that calls the already-resident SBIOS to read the code. An example of such a program for each type of CPU is provided in Chapter V.

IV.4.3.2 Executing a Bootstrap

Each bootstrap requires that the parameters described in Section IV.4.2.3.1 be on the top of the processor stack (the number of disk dri ves to test must be zero).

Once the configuration parameters are on the stack, and the SBIOS and bootstrap are in memory, the bootstrap is ready to execute. This is done by executing a jump instruction to the beginning of the bootstrap code (i.e., either

aooo

hex or

0000 hex).

The bootstrapping process may take as long as two or three minutes. This is only for the time being; Section IV.4.4 explains how to write a faster bootstrap.

Note: On

zao/aoao

Systems, the 'number of dri ves to test' parameter must equal

o

only if the supplied bootstrap is used: with a user-written bootstrap, it must not be pushed. On 6502 Systems, it should equal O.

IV.4.3.3 Checking the System

Once the System appears to have bootstrapped, there are a few simple tests that help verify the interaction between the SBIOS and the p-System.

If the System has booted correctly, the console should display a welcome message, followed by the System version number, and the date on which the Bootstrap disk was created. After that, the outer System promptline should appear (see the Users' Manua!).

I f these messages do not appear, the bootstrap has not worked. First check the values that are on the stack before the bootstrap is run. If these appear to be correct, the bootstrap code may not have functioned. If the bootstrap appears to be correct, then the SBIOS routines that handle either disk reads or console output

Installation Guide Full Adaptable System

may be at fault.

Once the System appears to have booted, the next test is to type 'F'. This should call the Filer. Several sectors will be read off the System disk, and another promptline will appear. If these actions do not occur, the SBIOS disk read routines or console

I/o

routines may not work.

The final quick test is to type '0' while in the Filer. When prompted, type the Gurrent date (e.g., l2-JAN-79) followed by <return>. Finally, type '0' again. If the correct' date (that is, the one you just typed) is not displayed, the disk write routines may be wrong.

I V.4.3.4 Accessing Other System Programs

The sale purpose of the Bootstrapping disk is to aid in the development of bootstraps. There is no need for most System programs in this process. Hence, they are provided on the System disk rather than on the Bootstrapping disk.

The System disk as shipped contains three disk images, and may be unpacked as described in Section 1.4. The first disk image, SYSTEMl, contains a p-System that may be booted once a working bootstrap and Interpreter are transferred to it.

The other two disk images contain other System programs (Appendix C contains a full catalog).

Bootstraps may be transferred using the utility BOOTER (see Section 1l.3).

Interpreters may be transferred as any normal file, by using the Filer's T(ransfer command. Once it has a bootstrap, Interpreter, and Operating System, SYSTEMI may be booted like the Bootstrap disk.

For any disk to be booted, it must contain a bootstrap, SYSTEM.INTERP, SYSTEM.PASCAL, SYSTEM.SYNT AX (if you· intend to' compile programs);

SYSTEM.MISCINFO (if you intend to use the Screen Oriented Editor), and SYSTEM.LIBRARY

Cif

you intend to use Long Integers or code that you yourself have placed in the Library).

In order to use anpssembler, its name must be SYSTEM.ASSMBLER (no 'E').

Assemblers qre shipped with the name of the processor they generate code for, so it is necessary to enter the Filer and use the C(hange command to name the desired assembler SYSTEM.ASSMBLER. Any assembler information files (e.g., Z80.0PCOOES) must reside on the same disk as SYSTEM.ASSMBLER.

118

IV.4.3.5 Writing a Bootstrap

Chapter II discusses bootstraps in some detail. This section is only meant to provide some reminders about the same topics.

The Adaptable System comes with primary, secondary, and tertiary bootstraps.

They are located on each Bootstrapping disk as diagrammed in Figure 4 (Section II.3). The primary bootstrap that is supplied must be loaded by a bootstrap loader which you yourself supply; at some point in your use of the System you will almost certainly want to replace it with a simpler bootstrap (a "cold boot").

Section IV.4.1.2 describes how to do this.

Until you write your own primary bootstrap, you must load the supplied primary bootstrap wi th a bootstrap loader: this can be either a small program that you write yourself, or some other operating system that you are already using.

The supplied primary bootstrap must be loaded into either 8000H or OOOOH, depending on your memory configuration, as described in Section IV.4.1. The processor's stack must also be loaded with parameters, as described in Section IV.3.2.3.1; the number of drives to test must be O.

Once the primary bootstrap is loaded and the parameters are on the stack, execute the bootstrap by doing a JUMP to its location (either 8000H or OOOOH). Do not call the bootstrap as you would a subroutine.

The supplied primary bootstrap will load the SBIOS and the secondary bootstrap, push some parameters on the stack, and initiate the secondary bootstrap. If you have prepared things correctly, within a short time you should have a running p-System.

Installation Guide Full . Adaptable System

IV.4.4 Improvements

When the p-System is first booted with a minimal SBIOS and the primary bootstrap supplied on the Bootstrapping disk, it does not have the speed or the extended I/O capabilities of a fully-implemented System. This section describes the improvements that can be made to your System, once you have jumped the

This section discusses changing disk recording formats and writing a simpler bootstrap. Both of these improvements are relatively simple, and can substantially improve the speed of your System.

Im Dokument 910-335-1594 (Seite 122-126)