Base ABOUT file for the osimplay code directory for the Ha3sm project and
offshoots.

My Ha3sm is not portable. 300 bajillion machines is fine. You want it for
the SPARC? Cool. Knock yourself out. I don't think I've ever seen a SPARC.

I do try to avoid 386 quirky code, however. I only use 2-register memory
addressing when I have to, for example. Like in the NMI reflex, IFF it comes
up.

It looks like Ha3sm will allow using BIOS drivers. What that is good for
is probably stuff you're only interested in in-passing. I'm personally not
going to be concerned with HD performance any time soon. The BIOS keyboard
driver, however, is unacceptable to me. YMMV. The key is to allow
something to work poorly if it doesn't degrade anything else that is
definitely not to be degraded. For me that's NMI, keyboard, VGA.


~~

On 386 alone, you're looking at several distinct global machine modes. The
PE bit is the big bifurcation, and next is the D bit of the active CS
segment.  Those two bits give four categories of effective machine, with
any possibility of using 16 or 32 bit code and allowing or not allowing
changes to segment descriptors. Thus the directory arrangement. PE is more
fundamental than Dbit, but the sources seem to make more sense with
16/32/global as the base split.

This directory is the trunk of the 386+ code tree, the only such tree of
Ha3sm at this writing. Stuff that isn't mode-specific is here. Stuff that
is use32 but doesn't care if it's PE0 or PE1 is in 32, and similar for
use16. Reflexes are PE-specific. Regular routines are usually specifically
use16 or use32. ./global is data, macros, mode-neutral code, and 32PE1
code for other modes, in some cases.

None of these modes implies particular segment settings as to limit, base
and granularity. 3 are supersets of or similar to documented modes; real
mode, use16 pmode, and use32 pmode. Use16 pmode is usually described as
pertaining to 286 gates, but any of this stuff can be set piecemeal. INTeL
does not discuss use32-PE=0, Forreal Mode. Contrarily, 386 V86 mode is
separate and outside from the four settings I use, being tightly linked to
special interrupt and task circumstances, and I'm hoping to avoid the
provided task-switch mechanisms.

8086 20-bit "segments" are not to be thought of as an alternate mode to
286+ descriptored segments. The descriptors are still in force when PE=0.
PE=0 means you can't change them. The 8086 segments are superficial to the
protection segments. Thus I distinguish 8086 shift-add "segments" from the
big dogs by refering to them as schmegments. A schmegmented interrupt
vector is a vexor.

The most pernicious annoyance of these various modes is the interrupt
issues. The four basic mode categories, PE=0&Dbit=0, PE=0&Dbit=1,
PE=1&Dbit=0, and PE=1&Dbit=1, all need thier own reflex (interrupt handler
bottom-end) code, and thier own IDTs. This is because dismiss (IRET) is
sesitive to Dbit, but not PE, as far as its stack pull (pop) behavior, so
the inner cases (in a binary listing) of PE=0&Dbit=1 and PE=1&Dbit=0 need
thier dismisses otheroperandsize'd, and that basically means four sets of
event handlers. Reflexes (bottom-ends) are no place for PE-conditional
interupt return types. We thus have 32-bit, 32-bit-small-dismiss, 16-bit
and 16bit-big-dismiss for any reflexes that may occur in the the
particular modes.

The default init mode will be use32, probably PE=1. Lessened-mode IDTs can
be BUILT in the top mode. I'm not trying to support the 8086. In fact, as
I think about it, I may not implement changing a reflex, i.e. installing
an interrupt vector transiently, in any but pmode. Hmmmm, sounds like a
mercy.

One can mix vectors and vexors in one IDT. The really important event
numbers conflict though at 4 OR 8 bytes. setIDT (load IDT register, i.e.
set new IDT) is 11 clocks; time well spent. That's an incredible
state-change for 11 clocks. That's an advantage of the fundament control
structures of the 386 (GDT, IDT, TSS...) being outside the CPU. You can
switch spinal columns in 11 clocks, which the machine-provided TSS
mechanisms take advantage of vis-a-vis tasks.

....................

You can't far xfer to a use-other with PE=0.  Thus the four basic modeoids
of the 386 have state-change constraints. CWR mode to Forreal Mode is
always 3 hops either way. I feel like diagramming them...

			 _______________
			|    WAKE-UP	|
			|canonical rmode|
			|  PE=0 use16   |
			|_______________|
			    A	     |set PE to 1
			    |	     |
		 set PE to 0|	     |
			 ___|________V__       
			|     Veal	|
			|     Mode	|
			|   PE=1 use16  |
			|_______________|
			    A	    |far xfer
			    |	    | to use32 CS
		far xfer to |	    |
		    use16 CS|	    | 
			 ___|_______V___ 
			|   Protected	|
			|      Mode	|
			|   PE=1 use32  |
			|_______________|
			    A	     |set PE to 1
			    |	     |
		 set PE to 0|	     |
			 ___|________V__
			|  Forreal Mode |
			|      Mode	|
			|   PE=0 use32	|
			|_______________|


Interesting. Forreal Mode is the furthest from Wake-up, and you can only
get to Forreal Mode from pmode. Forreal Mode is like a back room off of
pmode. You can interrupt between pmode and Veal Mode. Conversely, events
in rmode or Forreal Mode (PE=0) have to be handled in the mode they occur
in.

The above diagram does not account for different segment limits and bases
than those in effect in WakeUp Rmode. This chart also does not account for
V86 Mode, which basically requires 386 task-switch constructs. The above
modes and transitions do NOT need a TSS, or paging. I suspect V86 could
run off Veal Mode OR pmode.


