|
DataMuseum.dkPresents historical artifacts from the history of: CP/M |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CP/M Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 41600 (0xa280)
Types: RcTekst
Names: »99110093.WP«
└─⟦7fab0c8ae⟧ Bits:30005866/disk3.imd Dokumenter i RcTekst format (RCSL 99-1-*)
└─⟦this⟧ »99110093.WP«
╱04002d4e0c0006000000000301473100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆b3┆RC39 Monitor┆05┆Page ┆0b┆↲
┆a1┆↲
↲
┆a1┆1. INTRODUCTION.↲
↲
↲
The RC39 Monitor is a program for a processor of the Intel iAPX 286 ↓
family intended to run on a system which includes at least the ↓
following com┄ponents:↲
↲
↲
╞ - iAPX 286 microprocessor,↲
╞ - some PROM to hold the Monitor program,↲
╞ - some RAM to hold the Monitor variables,↲
╞ - a disk (winchester and/or floppy) controller and drive(s),↲
╞ - a USART supporting a V.24 serial communications interface.↲
↲
↲
Several versions of the RC39 Monitor will exist for systems which ↓
differ with respect to the specific type of disk controller, USART or ↓
other hardware components.↲
↲
↲
An ┆a1┆operator console┆e1┆ for the RC39 Monitor is a tty-compatible terminal ↓
attached via the V.24 interface.↲
↲
↲
The following facilities are provided by the RC39 Monitor:↲
↲
↲
╞ - ┆84┆a Debug Monitor, running in the Protected Virtual Address Mode ↓
┆19┆┆86┆┄┄only, integrated with both the power-on selftest programs and the ↓
┆19┆┆86┆┄┄XENIX Version 3.2 Operating System. In the latter case the ↓
┆19┆┆86┆┄┄Monitor acts as a KERNEL Debugger which communicates with an ↓
┆19┆┆86┆┄┄operator by means of the operator console,↲
↲
↲
╞ - ┆84┆a disk boot loader which can load a file, in Microsoft x.out ↓
┆19┆┆86┆┄┄SMALL model format, from the bootstrap track of a disk ↓
┆19┆┆86┆┄┄(winchester or floppy) into RAM.↲
↲
↲
┆8c┆┆83┆┆ec┆↓
A unified command interface allows all functions of the Debug Monitor ↓
to be activated from the operator console. In typical applications, the ↓
Debug Monitor is integrated with hardware selftest programs, so that it ↓
will be possible to enter the Debug Monitor from the selftest and to ↓
return also.↲
↲
↲
The primary use of the RC39 Monitor lies in the area of testing and ↓
debugging low-level programs. The Debug Monitor will, however, also be ↓
used in production systems, where only the bootloader will be commonly ↓
used, but where the other features will also be available for special ↓
tests and diagnostics.↲
↲
↲
When the system is powered on or reset the Debug Monitor will test ↓
whether or not an operator console is present by inspecting V.24 status ↓
signals. If the status signal indicate console present the Debug ↓
Monitor will prompt the operator for a command, otherwise it will ↓
execute a load-and-go command using the default disk medium. Thus the ↓
bootloader will work, also when no operator console is present.↲
↲
↲
In the operator console dialogue 7-bit ASCII-code is used. The high ↓
order bit of characters transmitted to the console is 0, and the high ↓
order bit of received characters is ignored.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆2. THE DEBUG MONITOR.↲
↲
↲
The Debug Monitor allows execution and monitoring of a program loaded ↓
into RAM. The program being monitored is called the ┆a1┆target program┆e1┆ to ↓
distinguish it from the RC39 Monitor itself. The only restrictions to ↓
the target program is that it must not overwrite the RAM reserved for ↓
the Debug Monitor.↲
↲
↲
The Debug Monitor has two modes: ┆a1┆command mode┆e1┆ and ┆a1┆target mode┆e1┆. The ↓
Debug Monitor is in command mode when a command is being typed in or ↓
executed (this includes loading). The Debug Monitor is in target mode ↓
when a target program is exe┄cuting. A transition from command mode to ↓
target mode occurs when control of the processor is transferred to the ↓
target program as a result of a go command ( G(C)(sel:offset)(; ↓
sel:offset) ) or load-and-go command ( L(W/F)G ).↲
↲
↲
While in command mode the Debug Monitor keeps external interrupts ↓
disabled in order to exclude the execution of any part of a loaded ↓
target program. Thus the contents of RAM will change only under command ↓
control.↲
↲
↲
When the system is powered on or reset the Debug Monitor will enter ↓
command mode, possibly after execution of a hardware selftest program.↲
↲
↲
A transition from target mode to command mode, i.e. an activation of ↓
the Debug Monitor, takes place in the following situations:↲
↲
↲
1.╞ ┆84┆┆84┆A breakpoint trap is encountered during the execution of a target ↓
┆19┆┆84┆┄┄program.↲
↲
↲
┆8c┆┆83┆┆bc┆↓
2. ┆84┆A single step trap is encountered during the execution of a target ↓
┆19┆┆84┆┄┄program.↲
↲
↲
3.╞ ┆84┆An INT3 instruction is executed by a target program.↲
↲
↲
All these traps generates a TASK SWITCH into the Debug Monitor. The ↓
Debug Monitor will be able to change the target program context ↓
(registers and variables) by backtracking to the suspended target Task ↓
State Segment (TSS) and even further.↲
↲
↲
Up to eight breakpoints can be set in the user program by means of the ↓
set breakpoint command ( B(bp_no sel:offset) ). A breakpoint must be ↓
located at the first byte of an instruction. Break┄points work ↓
transparently, i.e. following a break execution of the program may be ↓
resumed simply by giving a go command. Once set, a breakpoint remains ↓
until redefined by a new set breakpoint command or explicitly deleted ↓
by either the clear breakpoint command ( C(bp_no) ) or the go and clear ↓
all breackpoints command ( GC (sel:offset)(; sel:offset) ).↲
↲
↲
The Task State Segment (TSS or Context) of the target program may be ↓
modified by an ( R(reg-spec)) command. When the transition from command ↓
to user mode is made ( G(C) (sel:offset)(; sel:offset) ) the processor ↓
registers are updated from the modified TSS.↲
↲
↲
In addition to breakpoint handling the Debug Monitor can be used to ↓
inspect and modify RAM, Protection Tables, Segment Descriptors, System ↓
Descriptors and to read to or write from specified I/O ports. For ↓
details, see the next chapter.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆2.1 iAPX 286 Protection Mechanisms.↲
↲
↲
The basic entity in an iAPX 286 system is the ┆a1┆Segment┆e1┆. A segment is ↓
a contigous part of virtual memory used to hold either CODE (TEXT) or ↓
DATA. Segments are of variable size, ranging from as small as a single ↓
byte to as large as 64 K byte. Allthough the iAPX 286 processor ↓
supports a virtual address range of 1 Giga byte and a physical address ↓
range of 16 Mega byte, only 4 segment may be addressed at the same ↓
time. The CS register is used to address the current CODE (TEXT) ↓
segment, and DS, SS and ES may be used to address various types of ↓
DATA. The segment is accessed indirecly through a ┆a1┆Segment Descriptor┆e1┆ ↓
which reside in a specific ┆a1┆Segment Descriptor Table┆e1┆. Two kinds of ↓
segment descriptor tables exists, the Global Descriptor Table (GDT) ↓
used to hold segment descriptors shared by several users and the Local ↓
Descriptor Table (LDT) used to hold user specific segment descriptors. ↓
A segment descriptor is 8 byte long as shown below.↲
↲
↲
╞ ╞ --------------------------------↲
╞ +7╞ ! reserved ! +6↲
╞ +5 !P!DPL!1!TYPE!A! BASE A23-A16 ! +4↲
╞ +3 ! BASE A15-A0╞ ! +2↲
╞ +1 ! LIMIT 15-0╞ ! 0↲
╞ ╞ --------------------------------↲
↲
↲
╞ ╞ ┆a1┆┆e1┆┆a1┆Segment Descriptor.↲
↲
↲
The first word of the descriptor is used to hold the size of the ↓
segment and if the program makes access to CODE or DATA outside the ↓
segment limit a trap is generated into the operating system. Byte 2-4 ↓
is used to hold the physical memory base address of the segment. Byte 5 ↓
is the ┆a1┆Access Right Byte┆e1┆. The P bit indicates whether the segment is ↓
present in physical memory or not. The DPL is a two bit wide field ↓
giving the ┆a1┆Descriptor Privelege Level┆e1┆. Privilege levels are used to ↓
seperate high quality and very thrusted CODE such as the operating ↓
┆8c┆┆83┆┆c8┆↓
system kernel from code generated by stupid (sorry) application ↓
programmers. In XENIX Version 3.2 only two of the four available ↓
privilege levels are used, the operating system executes at privilege ↓
level 0 (SYSTEM) and applications execute a level 3 (USER). The 3 bit ↓
wide TYPE field gives the segment access rights. For CODE segments the ↓
possibily of Execute Only, Execute and Read, Read Only or Conforming ↓
(Execute at caller privilege level) exists. For DATA segments the ↓
expand direction may be either expand up (like CODE segments) or expand ↓
down. A DATA segment may also be either Read Only or both Read and ↓
Write. The A bit is set whenever a segment is referenced. A segment ↓
descriptor is addressed by an index. Bit 2 of the index, the ┆a1┆Table ↓
┆19┆┄┄┆84┆Indicator┆e1┆, tells whether the descriptor is in the GDT or the LDT table. ↓
Bit 0 and bit 1 of the index gives the ┆a1┆Requested Privelege Level┆e1┆ (the ↓
level upon which the caller is executing). Whenever a descriptor is ↓
accessed extensive access checks such as Privilege Level Check, Access ↓
Right Check and Segment Present Check is made by the iAPX 286 ↓
processor. If access is granted the A bit is set and processing ↓
continues otherwise a trap into the operating system is generated.↲
↲
↲
┆a1┆2.2 Alias Descriptors.↲
↲
↲
In order to be able to access the also protected protection tables GDT, ↓
LDT and IDT as data segments the Debug Monitor as well as the XENIX ↓
operating system needs to use an alias descriptor. An alias descriptor ↓
for the GDT table for instance is a Segment Descriptor that addresses ↓
the GDT table as a DATA segment. Several conventions for the layout of ↓
the LDT and GDT tables exists. The first entry of the protection tables ↓
are never used, it is filled with zeroes. The second entry of the GDT ↓
or LDT table is an alias descriptor for the table itself (R/W DATA). ↓
This means that if the Debug Monitor wants to access the GDT or the LDT ↓
table it may use the alias descriptor allready present. The third entry ↓
in the GDT table is an alias to access the IDT table as a R/W DATA ↓
segment.↲
↲
↲
┆8c┆┆83┆┆bc┆↓
HINT! If you want to change the protection tables from the Debug ↓
Monitor (no commands exists for that) then you should use the alias ↓
descriptors allready there.↲
↲
↲
┆a1┆2.3 Monitor Exception Handling.↲
↲
↲
When CPU control switches from target mode to command mode the Debug ↓
Monitor saves the 17 lowest target interrupt vectors, and loads 17 ↓
Debug Monitor vectors. These vectors are used to catch exceptions and ↓
protection violations that might happen in command mode (it is for ↓
instance possible to change the limit or access rights of the Debug ↓
Monitor itself). The protection violations and instruction exceptions ↓
will cause the Debug Monitor to write a message to the console and then ↓
execute a HALT instruction. The only way to get out of these exceptions ↓
is to hardware reset the CPU.↲
↲
↲
┆a1┆Vector type Error Text ↲
↲
0 Interrupt 0 at 'CS:IP' Divide By Zero↲
╞ ╞ HALTED - Hardware RESET required↲
↲
2╞ ╞ Interrupt 2 at 'CS:IP' NMI↲
╞ ╞ HALTED - Hardware RESET required↲
↲
4╞ ╞ Interrupt 4 at 'CS:IP' Overflow↲
╞ ╞ HALTED - Hardware RESET required↲
↲
5╞ ╞ Interrupt 5 at 'CS:IP' Bounds Check↲
╞ ╞ HALTED - Hardware RESET required↲
↲
6╞ ╞ Interrupt 6 at 'CS:IP' Undefined Operation↲
╞ ╞ HALTED - Hardware RESET required↲
↲
7╞ ╞ Interrupt 7 at 'CS:IP' Device Not Available↲
╞ ╞ HALTED - Hardware RESET required↲
↲
┆8c┆┆83┆┆d4┆↓
8╞ ╞ Interrupt 8 at 'CS:IP' Double Fault↲
╞ ╞ HALTED - Hardware RESET required↲
↲
9╞ ╞ Interrupt 9 at 'CS:IP' Math Address Error↲
╞ ╞ HALTED - Hardware RESET required↲
↲
10╞ ╞ Interrupt 10 at 'CS:IP' Invalid Task State Segment↲
- ECODE = XXXX↲
╞ ╞ HALTED - Hardware RESET required↲
↲
11╞ ╞ Interrupt 11 at 'CS:IP' Not Present - ECODE = XXXX↲
╞ ╞ HALTED - Hardware RESET required↲
↲
12╞ ╞ Interrupt 12 at 'CS:IP' Stack Protection↲
╞ ╞ - ECODE = XXXX↲
╞ ╞ HALTED - Hardware RESET required↲
↲
13╞ ╞ Interrupt 13 at 'CS:IP' General Protection↲
╞ ╞ - ECODE = XXXX↲
╞ ╞ HALTED - Hardware RESET required↲
↲
14╞ ╞ Interrupt 14 at 'CS:IP'↲
╞ ╞ HALTED - Hardware RESET required↲
↲
15╞ ╞ Interrupt 15 at 'CS:IP'↲
╞ ╞ HALTED - Hardware RESET required↲
↲
16╞ ╞ Interrupt 16 at 'CS:IP' Math Error↲
╞ ╞ HALTED - Hardware RESET required↲
↲
↲
The term 'CS:IP' refers to the logical location in the program, where ↓
the exception came. The errorcode pushed onto the stack by some ↓
exceptions (ECODE) may be hard to decode, and no attempt to document ↓
them in this manual will be done. Consult INTEL manuals for further ↓
description of the exceptions and their errorcodes.↲
↲
↲
┆8c┆┆83┆┆c8┆↓
Prior to the exit to target mode the target vectors are naturally ↓
restored.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3. MONITOR COMMANDS.↲
↲
↲
When the Monitor enters command mode or completes execution of a ↓
command without entering target mode, i.e. whenever it becomes ready ↓
for a new command, it outputs a '. ' (period and space) as a prompt. A ↓
command can then be typed as a sequence of characters terminated by CR, ↓
',' (comma), or '^' (upward arrow head or circumflex =5E┆82┆Hex┆81┆). It is ↓
possible to edit the command line using backspace or del (rubout) to ↓
erase faulty characters one at a time. No distinction is made between ↓
upper and lower case letters in the command input.↲
↲
↲
Before details of the individual commands are given, the vocabulary of ↓
the command syntax definitions is explained:↲
↲
↲
╞ - Capital letters must be typed as shown (or in lower case).↲
↲
↲
╞ - Parentheses delimit optional parameters and should not be typed.↲
↲
↲
╞ - ┆84┆Slashes separate alternative forms of a parameter and should not ↓
┆19┆┆86┆┄┄be typed.↲
↲
↲
╞ - "bp-no" stands for a breakpoint number in the range 0-7.↲
↲
↲
╞ - ┆84┆"addr type" stands for a memory address specified as either ↓
┆19┆┆86┆┄┄"sel:offset" or as "physadr".↲
↲
↲
- ┆84┆"sel:offset" stands for a memory address specified as ↓
┆19┆┆86┆┄┄selector:offset or just offset, where segment and offset can each ↓
┆19┆┆86┆┄┄be given as a hexadecimal number with up to 4 digits or as the ↓
┆19┆┆86┆┄┄name of one of the registers in the context. In the latter case ↓
┆8c┆┆83┆┆c8┆↓
┆19┆┆86┆┄┄the value of the indicated register variable is used. When only ↓
┆19┆┆86┆┄┄offset is specified the value of CS is used as default for ↓
┆19┆┆86┆┄┄selector. An address speci┄fication may also be left out ↓
┆19┆┆86┆┄┄completely, in which case CS:IP is used as default. When both ↓
┆19┆┆86┆┄┄selector and offset are specified the separating ':' (colon) must ↓
┆19┆┆86┆┄┄be typed.↲
↲
↲
- ┆84┆"physadr" is a 6 digit long hexadecimal physical memory address.↲
↲
↲
╞ - ┆84┆"count" stands for an unsigned decimal number to be used as a ↓
┆19┆┆86┆┄┄repetition counter.↲
↲
↲
╞ - ┆84┆"port_adr" stands for the address of an I/O port.↲
↲
↲
- ┆84┆"value" stands for a byte or word value to be written to a ↓
┆19┆┆86┆┄┄register, memory location, or output port. Both may be given as a ↓
┆19┆┆86┆┄┄hexadecimal number with up to 4 digits (2 if byte). Register ↓
┆19┆┆86┆┄┄names may also be used as for addresses.↲
↲
↲
- ┆84┆"reg_spec" stands for one of the iAPX 286 internal registers CS, ↓
┆19┆┆86┆┄┄DS, SS, ES, AX, BX, CX, DX, SP, BP, SI, DI, IP or FL (flags).↲
↲
╞ - ┆84┆"string" stands for any string of graphic characters not ↓
┆19┆┆86┆┄┄including ',' or '^'.↲
↲
↲
Command names are typed as single letters, in some cases preceded by an ↓
optional count indicating the command should be repeated the specified ↓
number of times, and usually followed by other parameters. In several ↓
cases a command may be continued or repeated if a ',' or '^' is typed ↓
instead of a command in response to the next prompt.↲
↲
↲
┆8c┆┆83┆┆c8┆↓
In the remainder of this chapter the individual commands are described. ↓
In the command syntax definitions the elements of each command are ↓
separated by blanks for readability. Such blanks are not necessary in ↓
actual command input. In the EXAMPLES shown below all Debug Monitor ↓
output is shown in ┆b0┆bold┆f0┆ and comments is preceded with a % character.↲
↲
┆a1┆↲
┆a1┆3.1 Help Command.↲
↲
↲
Command Syntax: ┆b0┆(H/?).↲
↲
↲
The help command displays a menu of available commands like this.↲
↲
↲
┆b0┆********************************************************************↲
┆b0┆*╞ ╞ RC 39 MONITOR MENU╞ ╞ - PAGE 1 *↲
┆b0┆********************************************************************↲
┆b0┆Command╞ ╞ ╞ Action↲
↲
┆b0┆(<delete>/<back space>)╞ ╞ Erase last character↲
┆b0┆(H/?)╞ ╞ ╞ Request this menu↲
┆b0┆*╞ ╞ ╞ ╞ Hardware Reset Command↲
┆b0┆G (C) (sel:offset) (; sel:offset)╞ GO FROM user addr. TO user addr.↲
┆a1┆┆e1┆┆b0┆(count) N (sel:offset) (; sel:offset) STEP FROM user addr TO user addr.↲
┆b0┆B (bp_no sel:offset)╞ ╞ Set breakpoint in user code↲
┆b0┆C (bp_no)╞ ╞ ╞ Reset one or all breakpoints↲
┆b0┆R (reg_spec)╞ ╞ ╞ Display all/Change one register↲
┆b0┆RMSW╞ ╞ ╞ Dispaly Machine Status Word↲
┆b0┆(count) M (W/X/P)(addr type)(=value) Display/Update/Disassemble Memory↲
┆b0┆(count) M (W/X) P (physadr)(=value) P means Physical 6 digit hex addr.↲
┆b0┆(count) M (W/X) (sel:offset)(=value) Address given as Selector:Offset↲
┆b0┆I (W) port_adr╞ ╞ Input from byte or Word port↲
┆b0┆O (W) port_adr=value╞ ╞ Output value to byte or Word port↲
┆b0┆L (W/F) (G) (:string)╞ ╞ Load from disc↲
↲
┆b0┆,╞ ╞ ╞ ╞ Request more menu↲
↲
↲
┆8c┆┆83┆┆e0┆↓
If a comma is entered the rest of the menu is displayed.↲
↲
↲
┆b0┆********************************************************************↲
┆b0┆*╞ ╞ RC 39 MONITOR MENU╞ ╞ - PAGE 2 *↲
┆b0┆********************************************************************↲
┆b0┆Command╞ ╞ ╞ Action↲
↲
┆b0┆(count) XLDT (ldt_index) (,)╞ Examine USER LDT↲
┆b0┆(count) XGDT (gdt_index) (,)╞ Examine GDT↲
┆b0┆(count) XIDT (idt_index) (,)╞ Examine IDT↲
┆b0┆(count) XDT (gdt_index) (,) Examine any LDT↲
┆b0┆XTSS (gdt_index) (,)╞ ╞ Examine TSS↲
┆b0┆,╞ ╞ ╞ ╞ Request more menu↲
↲
↲
┆a1┆3.2 Programmable Hardware Reset Command.↲
↲
↲
Command Syntax: ┆b0┆*.↲
↲
↲
This command is only available on the RC Manufactured CPU 610, not the ↓
Intel Manufactured CPU 691 iAPX 286 board. This command executes a ↓
hardware reset on the Multibus.↲
↲
↲
┆a1┆3.3 Set Breakpoint Command.↲
↲
↲
Command Syntax: ┆b0┆B (bp-no sel:offset).↲
↲
↲
Without parameters this command causes all currently set breakpoints ↓
to be displayed. With parameters, a B command sets the breakpoint with ↓
the specified number at the specified address. If this breakpoint was ↓
previously set the old setting is deleted.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
EXAMPLE.↲
↲
↲
┆b0┆. B╞ ╞ ╞ ╞ ┆f0┆% display active breakpoints.↲
┆b0┆Breakpoint 0 at 0160:664A substitute B8↲
┆b0┆Breakpoint 4 at 0168:001B substitute EA↲
┆b0┆Breakpoint 7 at 0168:1AAB substitute B8↲
┆b0┆.↲
↲
or↲
↲
↲
┆b0┆. B 6 11AB┆f0┆╞ ╞ ╞ % set breakpoint no. 6 at CS:11AB↲
↲
↲
If no selector is given CS is used.↲
↲
↲
┆a1┆3.4 Clear Breakpoint Command.↲
↲
↲
Command Syntax:┆b0┆ C (bp-no).↲
↲
↲
┆a1┆┆e1┆If a parameter is present the breakpoint with the specified number is ↓
deleted, otherwise all currently set breakpoints are deleted.↲
↲
↲
┆a1┆3.5 Single Step Through Target Code Command.↲
↲
↲
Command Syntax: ┆b0┆(count) N (sel:offset) (;sel:offset) (,).↲
↲
↲
This command single steps through target code from start address to end ↓
address. It may be wise to use a count if the end address is never ↓
reached. Breakpoint also terminates the single stepping. Before every ↓
step the instruction to be executed is disassembled and after each ↓
single step the registers are displayed.↲
↲
↲
┆8c┆┆83┆┆ec┆↓
EXAMPLE.↲
↲
↲
┆b0┆. 4N┆f0┆╞ ╞ ╞ % execute 4 Single Steps↲
↲
↲
╱04002d4e0c00060000000003014e3100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
╱04002d4e0c0006000000000301473100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
↓
┆b0┆0168:664A C746FC0000╞ MOV WORD PTRÆBP+FCÅ,0000H↲
┆b0┆ IP FL AX CX DX BX SP BP SI DI ES CS SS DS ABELGSI↲
┆b0┆6647 0312 0000 0120 00DC 0010 03C8 03D4 0004 097A 0008 0168 0188 0158 +---+-+↲
↲
┆b0┆0168:664F 8B46FC╞ MOV AX,WORD PTRÆBP+FCÅ↲
┆b0┆ IP FL AX CX DX BX SP BP SI DI ES CS SS DS ABELGSI↲
┆b0┆6652 0312 0000 0120 00DC 0010 03C8 03D4 0004 097A 0008 0168 0188 0158 +---+-+↲
↲
┆b0┆0168:6652 6BC016╞ IMUL AX,AX,0016H↲
┆b0┆ IP FL AX CX DX BX SP BP SI DI ES CS SS DS ABELGSI↲
┆b0┆6655 0356 0000 0120 00DC 0010 03C8 03D4 0004 097A 0008 0168 0188 0158 --+---+↲
↲
┆b0┆0168:6655 8BF8╞ MOV DI,AX↲
┆b0┆ IP FL AX CX DX BX SP BP SI DI ES CS SS DS ABELGSI↲
┆b0┆6657 0356 0000 0120 00DC 0010 03C8 03D4 0004 0000 0008 0168 0188 0158 --+---+↲
╱04002d4e0c0006000000000301463100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
╱04002d4e0c00060000000003014e3100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
↓
↲
┆b0┆┆b0┆.↲
The command may be repeated with comma.↲
↲
↲
┆a1┆3.6 Go to (Exit to) Target Code Command.↲
↲
↲
Command Syntax = ┆b0┆G (C) (sel:offset) (;sel:offset).↲
↲
↲
This command exits to target code. If C is specified all breakpoints ↓
are deleted. If no start address is given the current CS:IP is used. ↓
If an end address is given a breakpoint (no. 0) is set at that ↓
address. NOTE that you should always reserve breakpoint 0 for the G ↓
command.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
EXAMPLE.↲
↲
↲
┆b0┆. G ;665E┆f0┆╞ ╞ ╞ % CS is default↲
↲
↲
┆b0┆Breakpoint no. 0 at 0168:665E┆f0┆↲
┆b0┆. ↲
↲
↲
┆a1┆3.7 Display Target Registers.↲
↲
↲
Command Syntax: ┆b0┆R (reg-spec).↲
┆a1┆↲
↲
┆a1┆┆e1┆The R command is used to display and modify the values of the register ↓
variables in the target context. If the register specification is left ↓
out the values of all the registers are displayed. If a register is ↓
specified the value of that register is displayed followed by '-'. A ↓
new value for that register may now be entered, followed by CR. If no ↓
value is specified the old value (the one displayed) is kept.↲
↲
↲
EXAMPLE.↲
↲
↲
┆b0┆. R┆f0┆╞ ╞ ╞ ╞ % display all registers↲
╱04002d4e0c00060000000003014e3100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
╱04002d4e0c0006000000000301463100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
↓
↲
IP FL AX CX DX BX SP BP SI DI ES CS SS DS ABELGSI↲
┆b0┆665E 0286 0000 0120 00DC 0010 03C8 03D4 0004 8D18 0008 0168 0188 0158 +--+-++↲
╱04002d4e0c0006000000000301463100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
╱04002d4e0c00060000000003014e3100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
↓
↲
↲
┆b0┆. RAX┆f0┆╞ ╞ ╞ % change register AX↲
┆b0┆AX=0000-┆f0┆┆b0┆1234┆f0┆╞ ╞ ╞ % user types 1234↲
┆b0┆. RAX↲
┆b0┆AX=1234-┆f0┆╞ ╞ ╞ % user types <cr>↲
┆b0┆.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.8 Display Machine Status Word.↲
↲
↲
Command Syntax: ┆b0┆RMSW.↲
↲
↲
This command displays the Machine Status Word.↲
↲
↲
EXAMPLE.↲
↲
↲
┆b0┆RMSW↲
┆b0┆MSW = FFFD↲
┆b0┆. ↲
↲
↲
┆a1┆3.9 Display/Change/Disassemble Memory.↲
↲
↲
Command Syntax: ┆b0┆(count) M(W/X/P) (addr type)(=value) (,) (^).↲
↲
↲
The M command is used to inspect and/or modify the contents of ↓
specified memory locations. It operates in three different ways, ↓
depending on the presence of the count and value specifications. In all ↓
cases the oper┄ation is performed on consecutive locations, beginning at ↓
the specified address. If X is specified memory is inspected in units ↓
of (variable length) processor instructions, i.e. a disassembler is ↓
invoked. If W is specified the unit to be inspected/modified is a word, ↓
otherwise a byte. If P is specified a maximum 6 digit long hexadecimal ↓
address must be given, otherwise a logical selector:offset address is ↓
expected.↲
↲
↲
If a value is specified, in which case the '=' (equal sign) must be ↓
typed, it is assigned to as many consecutive units (bytes or words) of ↓
memory as specified by the count, 1 if the count is omitted.↲
↲
↲
┆8c┆┆83┆┆e0┆↓
If no value is specified, but a count is, or if X is specified, the ↓
command is a pure display command. 16 bytes/8 words/1 instruction are ↓
displayed per line in hexadecimal/mnemonic. The number of units to be ↓
displayed is specified by the count. If, in this case, a ',' is entered ↓
in response to the following command prompt the same number of ↓
bytes/words/instructions is again displayed from subsequent memory ↓
locations. This exercise may be repeated indefinitely.↲
↲
↲
If no value, no count, and no X is specified, the command works as ↓
follows: The specified address and the current contents of the memory ↓
unit (byte or word) at that location are displayed, followed by '-'. A ↓
new value to be entered into that location may now be entered, followed ↓
by ',', '^', or CR. If no value is specified the old value (the one ↓
displayed) is kept. If CR is entered the command terminates; if ',' or ↓
'^' is input the address is incremented/decremented by 1 (byte) or 2 ↓
(word) and the operation repeated.↲
↲
↲
If a logical address is given (selector:offset), and an attempt to ↓
display/substitute/disassemble memory outside the descriptor limit is ↓
made then a message is written to the console.↲
↲
↲
┆b0┆Selector limit exceeded↲
↲
↲
NOTE that if a physical address is supplied then there is no ↓
restrictions to the address except it must be in the 16 M byte memory ↓
space.↲
↲
↲
NOTE also that the Debug Monitor always writes bytes to memory, even ↓
if word is specified. Word commands is divided into two successive ↓
byte operations.↲
↲
↲
EXAMPLE.↲
↲
↲
┆8c┆┆83┆┆e0┆↓
┆b0┆. 4MX┆f0┆ ╞ ╞ ╞ % CS:IP is default↲
↲
┆b0┆0168:665E 6BC00A ╞ IMUL AX,AX,000AH╞ ; I=+10↲
┆b0┆0168:6661 8BF0╞ MOV SI,AX↲
┆b0┆0168:6663 81C66E25╞ ADD SI,256E╞ ; I=+9582↲
┆b0┆0168:6667 688200╞ PUSH 130↲
↲
┆b0┆. 20 M DS:0┆f0┆╞ ╞ ╞ % display bytewise, (.) means non↲
╱04002d4e0c00060000000003014e3100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
╱04002d4e0c0006000000000301463100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
↓
╞ ╞ ╞ ╞ % ascii character↲
┆b0┆0158:06F0 1E 61 60 01 E6 21 60 01 7C 4D 68 01 21 41 68 01 .a'..!'.øMh.!Ah.↲
┆b0┆0158:0700 7C 6D 68 01╞ ╞ ╞ ╞ ømh.↲
╱04002d4e0c0006000000000301463100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
╱04002d4e0c00060000000003014e3100000000000000000000000000000000000000000000000000050f19232d3741464b555f69737d87ff04╱
↓
↲
┆b0┆.┆f0┆↲
↲
┆b0┆. 10 MW DS:6F0┆f0┆╞ ╞ % display wordwise↲
↲
┆b0┆0158:06F0 611E 0160 21E6 0160 4D7C 0168 4121 0168↲
┆b0┆0158:0700 6D7C 0168↲
↲
┆b0┆. 10 MWP FFF5┆f0┆╞ ╞ ╞ % display physical memory↲
↲
┆b0┆00FFF5 0000 0000 0000 0000 0000 0000 0000 0000↲
┆b0┆010005 0000 0000↲
↲
┆b0┆. MWP FFF5┆f0┆╞ ╞ ╞ % substitute physical memory↲
↲
┆b0┆00FFF5 0000-1234,┆f0┆╞ ╞ % user types 1234 and (,)↲
┆b0┆00FFF7 0000-5678,┆f0┆╞ ╞ % user types 5678 and (,)↲
┆b0┆00FFF9 0000-^┆f0┆╞ ╞ % user types ^↲
┆b0┆00FFF7 5678-^┆f0┆╞ ╞ % user types ^↲
┆b0┆00FFF5 1234-╞ ┆f0┆╞ ╞ % user types <cr>↲
↲
┆b0┆. ↲
↲
↲
┆b0┆100 MW DS:1000 = 1234┆f0┆╞ ╞ % block assignment↲
↲
↲
┆8c┆┆83┆┆c8┆↓
┆a1┆3.10 Input from Port.↲
↲
↲
Command Syntax: ┆e1┆┆b0┆(count) I (W) port (,).↲
↲
↲
A number of bytes or, if W is specified, words, are read from the ↓
specified input port and displayed. The number of input operations is ↓
specified by count. Default is 1. Repetition can be requested (',').↲
↲
↲
EXAMPLE.↲
↲
↲
┆b0┆. IDE┆f0┆╞ ╞ ╞ % input from byte port↲
┆b0┆68↲
┆b0┆┆b0┆. IWDE┆f0┆╞ ╞ ╞ % input from word port↲
┆b0┆E868↲
┆b0┆. ,┆f0┆╞ ╞ ╞ ╞ % repeat↲
┆b0┆E868↲
↲
↲
┆a1┆3.11 Output to Port.↲
↲
↲
Command┆e1┆ Syntax: ┆b0┆O (W) port = value.↲
↲
↲
The specified value is written to the specified output port as a byte ↓
or, if W is specified, as a word.↲
↲
↲
EXAMPLE.↲
↲
↲
┆b0┆. ODE=12┆f0┆╞ ╞ ╞ % output to byte port↲
↲
┆b0┆. OWDE=1234┆f0┆╞ ╞ ╞ % output to word port↲
↲
↲
┆8c┆┆83┆┆e0┆↓
┆a1┆3.12 Load (boot) from disc.↲
↲
↲
Command Syntax:┆e1┆ ┆b0┆L (W/F) (G) (: string).↲
↲
↲
The L command starts the disk bootloader. If G is speci┄fied and if the ↓
loading is succesfull then the Debug Monitor makes a Task State Segment ↓
for the target code and starts execution.↲
↲
↲
If the G is omitted, or if an exception occur the Debug Monitor remains ↓
in command mode.↲
↲
↲
The first parameter specifies the type of disk:↲
W Winchester disk↲
F Floppy disk↲
↲
↲
If a string parameter is present it is forced to lower case letters and ↓
stored in the bootname string area terminated with CR.↲
↲
↲
┆a1┆EXAMPLE.↲
↲
↲
┆b0┆. LG┆f0┆╞ ╞ ╞ % load and Go command↲
┆b0┆Stage 1 Boot OK↲
↲
┆b0┆ ╞ ╞ Microsoft XENIX 3.2 ┆f0┆(and so on)↲
↲
↲
See chapter 4 for further boot information.↲
↲
┆a1┆↲
┆a1┆3.13 Examine Global Descriptor Table (GDT).↲
↲
↲
┆8c┆┆83┆┆d4┆↓
Command Syntax: ┆b0┆(count) XGDT (gdt_index) (,).↲
↲
↲
This command is used to display the content of the Global Descriptor ↓
Table (GDT). The content of the GDT table is ┆a1┆Segment Descriptors┆e1┆ and ↓
┆a1┆System Descriptors┆e1┆.↓
↲
↲
Also if the GDT index is outside the GDT limit another error message is ↓
written.↲
↲
↲
┆b0┆exception - table limit exceeded↲
↲
↲
EXAMPLE.↲
↲
↲
┆b0┆. 4 XGDT┆f0┆╞ ╞ ╞ % display first 4 GDT entries↲
↲
┆b0┆0000 : NULL DESCRIPTOR↲
╞ ╞ ╞ ╞ % Note that entry 0008 is the GDT↲
╞ ╞ ╞ ╞ % alias descriptor↲
┆b0┆0008 : LIMIT = 027F - BASE = 00297A - ACCESS = 93↲
┆b0┆╞ DSEG, Present, DPL=0, Expand Up, Read/Write, Accessed↲
↲
┆b0┆╞ ╞ ╞ ╞ ┆b0┆┆f0┆% Note that entry 10 is the IDT↲
╞ ╞ ╞ ╞ % alias descriptor↲
┆b0┆0010 : LIMIT = 07FF - BASE = 0030D8 - ACCESS = 93↲
┆b0┆╞ DSEG, Present, DPL=0, Expand Up, Read/Write, Accessed↲
↲
┆b0┆0018 : LIMIT = 0200 - BASE = 000000 - ACCESS = 93↲
┆b0┆╞ DSEG, Present, DPL=0, Expand Up, Read/Write, Ignored↲
↲
↲
┆b0┆. XGDT 28╞ ╞ ╞ ┆f0┆% example TASK GATE↲
↲
┆b0┆0028 : SSEL = 0040↲
┆8c┆┆83┆┆c8┆↓
┆b0┆ TASK GATE, Present, DPL=0↲
↲
↲
┆b0┆. XGDT 30┆f0┆╞ ╞ ╞ % example Task State Segment↲
↲
┆b0┆0030 : LIMIT = 002C - BASE = 001008 - ACCESS = 81↲
┆b0┆ AVAILABLE TSS, Present, DPL=0↲
↲
↲
┆b0┆. XGDT 108┆f0┆╞ ╞ ╞ % example LDT descriptor↲
↲
┆b0┆0108 : LIMIT = 0838 - BASE = 001008 - ACCESS = 82↲
┆b0┆ LDT DESCRIPTOR, Present, DPL=0↲
↲
↲
┆b0┆. XGDT 138┆f0┆╞ ╞ ╞ % example CODE (TEXT) segment desc.↲
↲
┆b0┆0138 : LIMIT = 7FFF - BASE = FF8000 - ACCESS = 9B↲
┆b0┆ ESEG, Present, DPL=0, Execute/Read, Not Conforming↲
↲
↲
┆b0┆. XGDT 1D0┆f0┆╞ ╞ ╞ % example CALL GATE↲
↲
┆b0┆01D0 : WCNT = 1 - SSEL = 0160 - SOFF = 4559↲
┆b0┆ CALL GATE, Present, DPL=3↲
↲
↲
┆a1┆3.14 Examine Target Local Descriptor Table (LDT).↲
↲
↲
Command Syntax: ┆b0┆(count) XLDT (ldt_index) (,).↲
↲
↲
This command is used to display the content of the presently active LDT ↓
descriptor table. The content of the LDT table is ┆a1┆Segment Descriptors┆e1┆ ↓
and ┆a1┆System Descriptors┆e1┆. If neither CS, DS, SS or ES references a LDT ↓
table a message is written to the console.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
┆b0┆exception - USER has no LDT↲
↲
↲
Also if the LDT index is outside the LDT limit another error message is ↓
written.↲
↲
↲
┆b0┆exception - table limit exceeded↲
↲
↲
EXAMPLE.↓
↲
↲
┆b0┆. 4XLDT┆f0┆╞ ╞ ╞ % display 4 LDT entries↲
↲
┆b0┆0004 : NULL DESCRIPTOR↲
↲
┆b0┆000C : LIMIT = 0838 - BASE = 000350 - ACCESS = 92↲
┆b0┆ DSEG, Present, DPL=0, Expand Up, Read Write, Ignored↲
↲
┆b0┆0014 : LIMIT = 7FFF - BASE = FF8000 - ACCESS = 9B↲
┆b0┆ ESEG, Present, DPL=0, Execute/Read, Not Conforming↲
↲
┆b0┆001C : LIMIT = FFFF - BASE = 000000 - ACCESS = 93↲
┆b0┆ DSEG, Present, DPL=0, Expand Up, Read/Write, Accessed↲
↲
↲
┆a1┆3.15 Examine Interrupt Descriptor Table (IDT).↲
↲
┆82┆↲
Command Syntax: ┆b0┆(count) XIDT (idt_index) (,).↲
↲
↲
This command is used to display the content of the Interrupt Descriptor ↓
Table. The content of the IDT table may be either ┆a1┆TASK Gates┆e1┆, ┆a1┆Interrupt ↓
┆19┆┄┄┆84┆Gates┆e1┆, ┆a1┆Interrupt Traps┆e1┆ or ┆a1┆NULL Descriptors.↲
↲
↲
┆8c┆┆83┆┆c8┆↓
If IDT index is outside the IDT limit another error message is written.↲
↲
↲
┆b0┆exception - table limit exceeded↲
↲
↲
EXAMPLE.↲
↲
↲
┆b0┆. 4 XIDT┆f0┆╞ ╞ ╞ % display 4 IDT entries↲
↲
┆b0┆0000 : SSEL = 0160 - SOFF = 44AE↲
┆b0┆ TRAP GATE, Present, DPL=0↲
↲
┆b0┆0008 : SSEL = 0160 - SOFF = 44B2↲
┆b0┆ TRAP GATE, Present, DPL=0↲
↲
┆b0┆0010 : SSEL = 0160 - SOFF = 44BF↲
┆b0┆ TRAP GATE, Present, DPL=0↲
↲
┆b0┆0018 : SSEL = 0160 - SOFF = 44C8↲
┆b0┆ TRAP GATE, Present, DPL=0↲
↲
↲
┆b0┆. XIDT 200┆f0┆╞ ╞ ╞ % example Interrupt Gate↲
↲
┆b0┆0200 : SSEL = 0160 - SOFF = 4576↲
┆b0┆ INTERRUPT GATE, Present, DPL=0↲
↲
↲
┆a1┆3.16 Examine any LDT Table.↲
↲
↲
Command Syntax: ┆b0┆(count) XDT (gdt_index) (,).↲
↲
↲
This command is used to display the content of any memory resident LDT ↓
table. This command is typically used to display the content of ↓
┆8c┆┆83┆┆c8┆↓
inactive LDT tables whereas the XLDT command displays the content of ↓
the currently active LDT table. The gdt_index must be an LDT descriptor ↓
in the GDT.↲
↲
↲
If the LDT descriptor indicates segment not present in physical memory ↓
a message is written to the console.↲
↲
↲
┆b0┆exception - LDT segment NOT present↲
↲
↲
Also if the GDT index does'nt point to a LDT descriptor another ↓
message is generated.↲
↲
↲
┆b0┆exception - entry is NOT an LDT descriptor↲
↲
↲
Also if the GDT index is outside the GDT limit another error message is ↓
written.↲
↲
↲
┆b0┆exception - table limit exceeded↲
↲
↲
EXAMPLE.↲
↲
↲
This command will produce a listing similar to the XLDT command. There ↓
is a known bug in this command in release 3.2 of the Debug Monitor. ↓
This bug will be corrected in further releases.↲
↲
↲
┆a1┆3.17 Examine TASK State Segment (TSS).↲
↲
↲
Command Syntax: ┆b0┆XTSS (gdt_index) (,).↲
↲
↲
┆8c┆┆83┆┆e0┆↓
This command is used to display the content of a Task State Segment ↓
(TSS). A TSS is a special segment (44 bytes long) used to hold all the ↓
iAPX 286 variables that changes during a TASK SWITCH. The gdt_index ↓
must be TSS descriptor (TSS descriptors must always be available and ↓
for that reason they must be in the GDT table). If a (,) is entered ↓
the command is repeated with the next GDT selector.↲
↲
↲
If the GDT index does'nt point to a TSS descriptor an error message is ↓
written.↲
↲
↲
┆b0┆exception - entry is NOT a TSS descriptor↲
↲
↲
Also if the GDT index is outside the GDT limit another error message is ↓
written.↲
↲
↲
┆b0┆exception - table limit exceeded↲
↲
↲
EXAMPLE.↲
↲
↲
┆b0┆. XTSS 190┆f0┆╞ ╞ ╞ % examine XENIX 3.2 TSS (Only One)↲
↲
┆b0┆ Link SP-0 SS-0 SP-1 SS-1 SP-2 SS-2 IP-r FL-r AX-r CX-r↲
┆b0┆0190 : 0000 0400 0188 0000 0000 0000 0000 0000 0000 0000 0000↲
┆b0┆ DX-r BX-r SP-r BP-r SI-r DI-r ES-s CS-s SS-s DS-s LDT-s↲
┆b0┆╞ 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 01C8↲
↲
↲
The snapshot above was taken before the XENIX TASK was running, just ↓
after bootload was finished.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆a1┆4. LOAD (BOOT) FROM DISC.↲
↲
↲
The Debug Monitor is carefully integrated with the built in selftest ↓
in the products where it is used. The selftest is for instance ↓
responsible for the initialization of all peripheral devices and also ↓
for switching the iAPX 286 CPU and the SBC board itself into the ↓
Protected Virtuel Address Mode (PVAM) of operation┆b0┆. ┆f0┆Before the ↓
┆19┆┄┆81┆┄termination of the selftest a Multibus configuration is made and all ↓
┆19┆┄┆81┆┄"test-slaves" are sent to their bootload phase. Allthough it is ↓
┆19┆┄┆81┆┄possible to stop the selftest prior to its natural termination and ↓
┆19┆┄┆81┆┄then execute a boot (load from disc) command, it is not wise to do so ↓
┆19┆┄┆81┆┄because the XENIX operating system uses the Multibus Configuration ↓
┆19┆┄┆81┆┄schedule to determine which boards need bootloading and the "test-↓
┆19┆┄┆81┆┄slaves" will be waiting for their go to boot command as well.↲
┆81┆↲
↲
If no console is present on the iAPX 286 CPU board then the bootload ↓
from winchester disc is started by default, otherwise the result of ↓
the configuration is written to the screen and the Debug Monitor is ↓
entered. The console output might look like this.↲
↲
↲
┆b0┆Multibus Configuration:↲
┆b0┆======================================================================↲
┆b0┆┆b0┆MB entry - MB address - Card State - Card ID - MB RAM size - error no.↲
┆b0┆======================================================================↲
┆b0┆00000 000000╞ master╞ CPU 610 02048 00000↲
┆b0┆┆b0┆00001 9E0000╞ ready╞ ITC 602 00064 00000↲
┆b0┆00002 8E0000 ready╞ COM 601 00064 00000↲
┆b0┆00003 800000 ready ETC 611 00512 00000↲
↲
┆b0┆<00001> Sent to bootload↲
┆b0┆<00002> Sent to bootload↲
┆b0┆<00003> Sent to bootload↲
↲
┆b0┆RC 39 Monitor release 2.0↲
┆b0┆.↲
↲
↲
┆8c┆┆83┆┆e0┆↓
It is now necessary to enter a boot command to get XENIX up and ↓
running. If the bootload is made from floppy it is normally necessary ↓
to enter the file name "xenix.fd" (LFG:xenix.fd). If the booload goes ↓
from winchester it is enough to enter (LG) and the default kernel ↓
"/xenix" is loaded.↲
↲
↲
The bootload is seperated into two stages. The first stage loads the ↓
bootstrap track from either winchester or floppy into memory, builds a ↓
Task State Segment from the loaded image, and starts execution. The ↓
format of both the floppy and the winchester disc is 1024 ↓
bytes/sector. The floppy disc has 8 sectors/track and the winchester ↓
has 9 sectors/track.↲
↲
↲
If the first stage is unable to read from floppy or winchester disc an ↓
error message is written to the console.↲
↲
↲
┆b0┆SCSI disc read error↲
↲
↲
If the reading went succesfull but the format was not as expected ↓
another message is written. The loaded code must be in MICROSOFT x.out ↓
SMALL model format. ↲
↲
↲
┆b0┆x.out Format error↲
↲
↲
If neither SCSI error nor format error is detected an OK message is ↓
written to the console.↲
↲
↲
┆b0┆Stage 1 Boot OK.↲
↲
↲
┆8c┆┆83┆┆bc┆↓
The loaded program is not XENIX, but the second stage boot which ↓
"knows" about the XENIX file structure, and is able to load and ↓
start the execution of the XENIX Kernel, which must be in MICROSOFT ↓
x.out MIDDLE model format. When the Kernel is loaded succesfully and ↓
started a message is written to the console.↲
↲
↲
╞ ╞ ┆f0┆┆b0┆Microsoft XENIX 3.2 ┆f0┆(and so on)↲
↲
↲
A number of exceptions may arise during the second stage boot. The ↓
exceptions are listed below. After an exception the loader returns to ↓
the Debug Monitor if possible. Experience has shown that not all ↓
exceptions are restartable, but a hardware reset must be supplied.↲
↲
↲
All exceptions are numbered and they will all produce the same type of ↓
output.↲
↲
↲
┆b0┆Stage 2 Boot EXCEPTION no: nn↲
↲
↲
nn↲
↲
↲
2. header error (x.out format error)↲
↲
3. bad magic number (x.out format error)↲
↲
4. bad word ordering (x.out format error) ↓
↲
5. bad target cpu (x.out format error)↲
↲
6. bad runtime environment (x.out format error)↲
↲
7. extended header read error (x.out format error)↲
↲
┆8c┆┆83┆┆c8┆↓
8. can't boot unsegmented x.out files (x.out format error)↲
↲
9. zero segments (x.out format error)↲
↲
32. means file not found↲
↲
100. 5 retries was made by the disc driver, but still no data.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆5. RAM RESERVATION.↲
↲
↲
┆a1┆┆e1┆This version of the Debug Monitor is currently running on two iAPX 286 ↓
CPU's, the CPU 610 and the CPU 691. On both CPU's the lowest 8 K byte ↓
of RAM is reserved for the Debug Monitor.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆6. RELATED DOCUMENTS.↲
↲
↲
RC 39 Selftest Concept, User's Manual RCSL. 99110092↲
↲
ITC 602 hardware selftest, User's Manual RCSL. 99110095↲
↲
F641 COM 601 hardware selftest, User's Manual RCSL. 99110097↲
↲
RC 3902 (CPU 691) hardware selftest, User's Manual RCSL. 99110094↲
↲
RC 3902 (CPU 610) hardware selftest, User's Manual RCSL. 99119134 ↲
↲
↲
RC 39 Monitor 8086 version, Reference Manual RCSL. 99110134↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆Appendix A.↲
↲
↲
In order to integrate the Debug Monitor with XENIX 3.2 a number of GDT ↓
selectors (40) is reserved for the Debug Monitor. This gives the ↓
following GDT table layout.↲
↲
↲
╞ ╞ ╞ -----------------↲
╞ ╞ 0000╞ ! ! NULL DESCRIPTOR↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 0008╞ ! GDT ALIAS !↲
╞ ╞ ╞ !----------------!↲
╞ 0010╞ ! IDT ALIAS !↲
╞ ╞ ╞ !----------------!-----------------------↲
╞ ╞ ╞ !╞ ! 40 Debug Monitor GDT↲
╞ ╞ ╞ !╞ ! entries↲
╞ ╞ ╞ !╞ !↲
╞ ╞ ╞ ╞ ↲
╞ ╞ ╞ ╞ ↲
╞ ╞ ╞ ! !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 0110 ! CONFIG DESC. ! Descriptor for the Mul-↲
╞ ╞ ╞ !----------------! tibus Configuration Table↲
╞ ╞ 0118 ! INT 1 TASK GATE! Task Gate to simulate↲
!----------------! Single Step interrupt↲
╞ ╞ 0120 ! INT 3 TASK GATE! Task Gate to simulate↲
╞ ╞ ╞ !----------------! Breakpoint OR INT 3 int.↲
╞ ╞ ╞ ! not used !↲
╞ ╞ ╞ ! !↲
!----------------!------------------------↲
↲
↲
╞ ╞ ╞ ┆b0┆┆f0┆┆a1┆┆f0┆┆e2┆┆e1┆ ┆a1┆GDT Layout.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ 0158 ! KERNEL DATA ! XENIX 3.2 selectors↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 0160╞ ! KERNEL CODE 1 !↲
╞ ╞ !----------------!↲
╞ 0168╞ ! KERNEL CODE 2 !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 0170 ╞ ! KERNEL CODE 3 ! not used in XENIX 3.2↲
╞ ╞ ╞ !----------------!↲
╞ 0178╞ ! KERNEL CODE 4 ! not used in XENIX 3.2↲
╞ ╞ ╞ !----------------!↲
╞ 0180╞ ! KERNEL CODE 5 ! not used in XENIX 3.2↲
╞ ╞ ╞ !----------------!↲
╞ 0188╞ ! KERNEL STACK !↲
╞ ╞ ╞ !----------------!↲
╞ 0190╞ ! XENIX TSS ! XENIX 3.2 is only one iAPX↲
╞ ╞ ╞ !----------------! 286 Task.↲
╞ 0198╞ ! TSS ALIAS !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01A0╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01A8╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01B0╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01B8╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01C0╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01C8╞ ! USER LDT ! XENIX 3.2 USER LDT↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01D0╞ ! SYS CALL GATE !↲
╞ ╞ ╞ !----------------!↲
↲
↲
╞ ╞ ┆a1┆GDT Layout Continued.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ 01D8╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01E0╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01E8╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01F0╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 01F8╞ ! KERNEL WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ 0200╞ ! MAP WORK !↲
╞ ╞ ╞ !----------------!↲
╞ ╞ ╞ ! 10 Dynamically !↲
╞ ╞ ╞ ! Allocated !↲
╞ ╞ ╞ ! entries !↲
╞ ╞ ╞ !╞ !↲
╞ ╞ 027F╞ !----------------!↲
↲
↲
╞ ╞ ┆a1┆┆e1┆ ┆a1┆GDT Layout Continued.↲
↲
↲
The Debug Monitor is integrated with XENIX 3.2 in a way so that it ↓
works as a KERNEL Debugger. This means that all interrupt 1 or ↓
interrupt 3 that occur in SYSTEM-mode (privilege level 0) are directed ↓
to the Debug Monitor and all USER-mode interrupt of the same type are ↓
handled by the XENIX Kernel itself. This strategy preserves the ↓
functionality of the XENIX USER-mode debugger, ADB.↲
════════════════════════════════════════════════════════════════════════
↓
!↲
╞ !↲
INT 1 or INT 3 -----------------------> mch.s↲
! !↲
!----! ╞ oemsup.s↲
╞ ! !╞ ╞ ╞ !↲
!╞ ! SYSTEM-mode -------- USER-mode↲
╞ !╞ !╞ !╞ ╞ !↲
╞ !╞ ! DEBUG MONITOR╞ ╞ mch.s↲
╞ !╞ !╞ !╞ ╞ !↲
╞ !╞ !-----------!╞ ╞ !↲
╞ !╞ ╞ ╞ ╞ ! XENIX Handles TRAP↲
!↲
↲
↲
┆a1┆XENIX 3.2 Interrupt 1 or 3 Handling.↲
↲
↲
The figure above explains what happens in the XENIX 3.2 Kernel when an ↓
interrupt 1 or 3 occur. The interrupt gate in the IDT points to a TRAP ↓
handler in a file called mch.s . This TRAP handler passes control to a ↓
program in a file called oemsup.s . This program finds out whether the ↓
interrupt occured in SYSTEM-mode or not. If true a call to the Debug ↓
Monitor through one of the GDT gates index 118 or 120 hex. is made. ↓
The Debug Monitor compensates for the additional processing since the ↓
TRAP occured and returns direct to the point where the exception came ↓
from. In USER-mode the program in oemsup.s returns transparently to ↓
mch.s and the operating system handles the TRAP.↲
↲
↲
To get into the monitor from the Kernel a routine called "rcmonitor" ↓
is included in the module called "oemsup.s". This routine simply ↓
executes an INT 3 instruction into the Debug Monitor. After one single ↓
step (N command) your back into the suspended program.↲
↓
↓
↓
↓
┆b0┆↓
┆1a┆┆1a┆╞ ╞ !----------------!↲
╞ 0180╞ ! KERNEL CODE 5 ! not used in XE