More build option groundwork
This commit is contained in:
Jeff Parsons
parent
e4cee436cc
commit
7913ef2a0a
7 changed files with 111 additions and 35 deletions
|
|
@ -1 +1 @@
|
|||
<div id="{{ include.id }}"></div>
|
||||
<div class="pcbuild" id="{{ include.id }}"></div>
|
||||
|
|
|
|||
|
|
@ -142,10 +142,10 @@ FOOTBALL Design Document
|
|||
---
|
||||
|
||||
The following text is from an email titled "3xBox Design Document" sent to the
|
||||
*football* alias on Saturday, February 28, 1987, at 5:02pm.
|
||||
|
||||
### Overview
|
||||
Microsoft *football* alias on Saturday, February 28, 1987, at 5:02pm.
|
||||
|
||||
Overview
|
||||
--------
|
||||
The goal for this research project was to demonstrate the feasability of
|
||||
supporting multiple virtual DOS 3.x machines on a 286DOS-based kernel running
|
||||
on an 386 personal computer. Each "3xBox" would have its own virtual screen,
|
||||
|
|
@ -174,8 +174,8 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
|
||||
Unless stated otherwise, most of the concepts extant in 286DOS apply to 386DOS.
|
||||
|
||||
### V86 Mode and the 386
|
||||
|
||||
V86 Mode and the 386
|
||||
----------------------
|
||||
The 386 CPU has three distinct execution modes: REAL, PROT, and V86. REAL
|
||||
and PROT modes are largely compatible with the corresponding modes of an 286.
|
||||
V86 modes is exactly the same as RING 3 PROT mode, with the following
|
||||
|
|
@ -203,8 +203,8 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
sensitive.
|
||||
This allows the OS to simulate the Interrupt Flag, if desired.
|
||||
|
||||
### V86 IRETD Frame
|
||||
|
||||
V86 IRETD Frame
|
||||
---------------
|
||||
When any interrupt, trap, exception, or fault occurs in V86 mode, the CPU
|
||||
switches to PROT mode and switches to the TSS Ring 0 Stack and builds the
|
||||
following stack frame:
|
||||
|
|
@ -219,8 +219,8 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
(0) (old CS)
|
||||
(old EIP) <- (SS:SP)
|
||||
|
||||
### CPU Mode Determination
|
||||
|
||||
CPU Mode Determination
|
||||
----------------------
|
||||
A new implementation of the WHATMODE macro was written in order to distinguish
|
||||
between the three CPU modes: REAL, PROT, and V86. REAL mode is indicated by
|
||||
a 0 PE bit in CR0 (a.k.a. MSW on a 286). If the PE bit is 1, then the mode
|
||||
|
|
@ -230,8 +230,8 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
be changed. So, we change IOPL and then check to see if it changed. If so,
|
||||
PROT mode, else V86 mode.
|
||||
|
||||
### CPU Mode Switching
|
||||
|
||||
CPU Mode Switching
|
||||
------------------
|
||||
The 286DOS kernel relies extensively on switching inbetween REAL and PROT.
|
||||
This functionality is provided by the RealMode and ProtMode routines.
|
||||
In 386DOS, RealMode is no longer needed. As soon as we switch to PROT mode
|
||||
|
|
@ -256,28 +256,28 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
the caller. NOTE: V86 Services is also used for completing the 386 LOADALL
|
||||
used by PhysToVirt to map "high" memory in "REAL" mode.
|
||||
|
||||
### Stack Switching
|
||||
|
||||
Stack Switching
|
||||
---------------
|
||||
In order to maintain the 286DOS mode switch and stack switch semantics
|
||||
when V86 mode is used, we have a new stack (the V86 Stack) in the 3xBox PTDA.
|
||||
|
||||
### 286DOS Modes and Stacks
|
||||
|
||||
286DOS Modes and Stacks
|
||||
-----------------------
|
||||
The RealMode and ProtMode procedures in 286DOS are the only ways to switch
|
||||
the CPU execution mode. These routines both maintain SS:SP, allowing
|
||||
RealMode and ProtMode to be reentrant. The TSS Ring 0 stack is always the
|
||||
current TCB stack in the current PTDA. The only other stacks in the system
|
||||
are the Interrupt Stack and user stack(s).
|
||||
|
||||
### 386DOS Modes and Stacks
|
||||
|
||||
386DOS Modes and Stacks
|
||||
-----------------------
|
||||
In 386DOS, any interrupt or exception while in V86 mode causes a switch to
|
||||
PROT mode and the TSS Ring 0 Stack. So we have a new way to mode switch with
|
||||
an incompatible stack semantic. We had to fix this mode switch to make it
|
||||
compatible with 286DOS.
|
||||
|
||||
### Observation
|
||||
|
||||
Observation
|
||||
-----------
|
||||
In V86 mode, the current stack must not be the TSS Ring 0 Stack. The CPU
|
||||
only leaves V86 mode via an interrupt/exception, which causes a stack switch
|
||||
to the TSS Ring 0 Stack. If the current stack was the same as the TSS Ring 0
|
||||
|
|
@ -285,8 +285,8 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
the PTDA. Since we run on this stack in V86 mode, we need a new Ring 0 stack
|
||||
when a 3xBox is running.
|
||||
|
||||
### Approach
|
||||
|
||||
Approach
|
||||
--------
|
||||
1) When a PMBox is running, the TSS Ring 0 Stack is a PTDA TCB stack.
|
||||
+ This is consistent with the 286DOS model.
|
||||
|
||||
|
|
@ -298,8 +298,8 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
+ Otherwise, copy the V86 IRETD frame to the previous stack and
|
||||
switch back to the previous stack.
|
||||
|
||||
### Details
|
||||
|
||||
Details
|
||||
-------
|
||||
1) Leaving V86 mode
|
||||
a. V86ToProt (analog of ProtMode)
|
||||
+ Issue special V86ToProt software interrupt. If the interrupt
|
||||
|
|
@ -341,8 +341,8 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
+ Execute 386 LOADALL with VM bit set in EFLAGS image in loadall
|
||||
buffer.
|
||||
|
||||
### Interrupt Management
|
||||
|
||||
Interrupt Management
|
||||
--------------------
|
||||
All software interrupts, hardware interrupts, and CPU traps and exceptions
|
||||
are vectored through a common IDT, regardless of whether the CPU is in PROT
|
||||
or V86 mode.
|
||||
|
|
@ -352,8 +352,8 @@ The following text is from an email titled "3xBox Design Document" sent to the
|
|||
keyboard and mouse (since those are implicitly for the foreground box),
|
||||
can be given to background 3xBoxes.
|
||||
|
||||
### Passing Hardware Interrupts to the Foreground 3xBox
|
||||
|
||||
Passing Hardware Interrupts to the Foreground 3xBox
|
||||
---------------------------------------------------
|
||||
In the interrupt manager:
|
||||
|
||||
IF a 3xBox is foreground -AND-
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
|
|
@ -1134,7 +1134,7 @@ MarkOut.prototype.convertMDMachineLinks = function(sBlock)
|
|||
reIncludes.lastIndex = 0; // reset lastIndex, since we just modified the string that reIncludes is iterating over
|
||||
}
|
||||
|
||||
sBlock = sBlock.replace(/\{%\s*include\s+build\.html\s+id=(["'])(.*?)\1\s*%}/g, '<div id=$1$2$1></div>');
|
||||
sBlock = sBlock.replace(/\{%\s*include\s+build\.html\s+id=(["'])(.*?)\1\s*%}/g, '<div class="pcbuild" id=$1$2$1></div>');
|
||||
|
||||
/*
|
||||
* Start looking for Markdown-style machine links now...
|
||||
|
|
|
|||
|
|
@ -36,6 +36,76 @@
|
|||
* This file provides all the UI options for building a functional PCjs PC.
|
||||
*/
|
||||
|
||||
var typeAddress = {
|
||||
type: "address"
|
||||
};
|
||||
|
||||
var typeBoolean = {
|
||||
type: "boolean"
|
||||
};
|
||||
|
||||
var typeNumber = {
|
||||
type: "number"
|
||||
};
|
||||
|
||||
var typePath = {
|
||||
type: "string"
|
||||
};
|
||||
|
||||
var typeString = {
|
||||
type: "string"
|
||||
};
|
||||
|
||||
var machineTypes = {
|
||||
'5150': "IBM PC (Model 5150)",
|
||||
'5160': "IBM PC XT (Model 5160)",
|
||||
'5170': "IBM PC AT (Model 5170)",
|
||||
'deskpro386': "COMPAQ DeskPro 386"
|
||||
};
|
||||
|
||||
var aMachineElements = {
|
||||
'machine': {
|
||||
choices: machineTypes
|
||||
},
|
||||
'name': {
|
||||
desc: "Machine Description"
|
||||
},
|
||||
'computer': {
|
||||
desc: "General Computer Features",
|
||||
'buswidth': {
|
||||
type: typeNumber,
|
||||
values: [20, 24, 32]
|
||||
},
|
||||
'resume': {
|
||||
type: typeNumber,
|
||||
value: [0, 1, 2],
|
||||
descs: ["Resume Disabled", "Resume Enabled", "Resume with Prompt"]
|
||||
}
|
||||
},
|
||||
'ram': {
|
||||
desc: "Read-Write Memory (Conventional or Extended)",
|
||||
'addr': {
|
||||
type: typeAddress
|
||||
},
|
||||
'size': {
|
||||
type: typeNumber
|
||||
}
|
||||
},
|
||||
'rom': {
|
||||
desc: "Read-Only Memory",
|
||||
'addr': {
|
||||
type: typeAddress
|
||||
},
|
||||
'size': {
|
||||
type: typeNumber
|
||||
},
|
||||
'file': {
|
||||
type: typePath
|
||||
}
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
/**
|
||||
* buildPC(idElement)
|
||||
*
|
||||
|
|
|
|||
|
|
@ -104,14 +104,20 @@ if (NODE) {
|
|||
*
|
||||
* The parmsMachine object, if provided, may contain any of:
|
||||
*
|
||||
* url: the location of the machine XML file
|
||||
*
|
||||
* autoMount: if set, this should override any 'autoMount' property in the FDC's
|
||||
* parmsFDC object.
|
||||
*
|
||||
* autoPower: if set, this should override any 'autoPower' property in the Computer's
|
||||
* parmsComputer object.
|
||||
*
|
||||
* messages: if set, this should override any 'messages' property in the Debugger's
|
||||
* parmsDbg object.
|
||||
*
|
||||
* state: if set, this should override any 'state' property in the Computer's
|
||||
* parmsComputer object.
|
||||
*
|
||||
* url: the location of the machine XML file
|
||||
*
|
||||
* If a predefined state is supplied AND it's successfully loaded, then resume behavior
|
||||
* defaults to '1' (ie, resume enabled without prompting).
|
||||
*
|
||||
|
|
|
|||
Loading…
Reference in a new issue