Ha3sm Implementation on x86 PC
It's looking like Torvalds was right. I did some "save the BIOS" hacks,
some rather unprecedented, but I can't say they were worth it. I don't
even like the BIOS keyboard service.
July 2003
I still want to provide a pmode interface to the BIOS though.
legmeg
The legacy megabyte. Closely related to Legba, which is West-African I
believe for "The Devil" or "Pure Evil". The PC AT BIOS knows stuff about
the mobo I don't want to figure out. And I don't have an o-scope. Mobo
people know thier FDC and so on, and the BIOS is the standardness of it.
Thus there seems to be some value in preserving access to the AT BIOS.
Thus the legacy of the PC will not be obliterated in Ha3sm quite like it
is in e.g. Linux. The legmeg is the low meg of address-space in a PC that
used to be an AT. That will be molested, but will remain largely an AT.
The AT interrupt vectors will be shuffled a bit, but some will still call
the AT BIOS.
An example; Lets say we want to use the AT BIOS int 0x13 read floppy
command, command 2. I'm talking about after the system is up, not the boot
load.
"Yeah but it's slow." Is it? Real mode is as fast as pmode. Smaller
operands too. BIOS runs out of ROM, which is slow. Is it
position-independant code? We might move it to RAM. Pfeh. Anyway,
"Yeah but it's limited to the low meg." Yes it is (and vm86 is worse).
How fast can a Pentium move a sector memory-to-memory? We can get the
sector as an AT and move it as a Pentium. That's a hit that is easily
ignorable for the floppy, keyboard, VGA, serial, most parallel stuff, and
what else? Probably EIDE too. Ethernet (RBIL). All of a very useable
machine. The Multics/UNIX lesson is... Implementability is good. Also, the
move is only necessarily a hit for guests. 0wner can use the results where
they arrive. Ha3sm emphasizes performance for 0wner.
So I want to use it. That AT service will not be at 0x13, but will still
exist somewhere in the 16 bit intvec table based at hardware address 0.
The system gets said request.
if guest
perms check, else done
(perms good, or not guest)
The system goes rmode
The system calls the BIOS call
The system resumes pmode
if necessary,
the system moves the results to the requesting guest
done
"Yeah but BIOS is stupid. You don't want it the way it gives it to you."
Alas, that does appear to be the case with the keyboard, as one example. I
want up&down and chording and so on. The VGA gtty is dumb too, but
adequate, as such things go.
Guests can't be allowed to call the BIOS. Perhaps the INTCALLER stuff
(see Janet_Reno q.v.) needs to be reworked to one pmode submission (INT,
trap).
An area where Linux strains a bit without the AT BIOS is in VGA
configuration stuff. With a bit of nostalgia we keep all that at runtime.
x86 IO ports
Hopefully guests won't need direct access to the x86's speshul IO address
space. That affords some hiding. Ha3sm may also find a way to hide that so
that in Ha3sm/H3sm it looks memory-mapped, but I haven't fried that
particular fish quite yet. Ideally Ha3sm source will compemble or Ha3sm
"include" on any CPU in the range of suitable machines, and be a
systems-capable portable assembler in a unix shell script.
floppy
Just for nostalgia, I want a mode where the floppy spins continuously.
WHO stops the floppy motor with that funny lag?
After that long blurb about using the BIOS, another annoyance is that the
stock BIOS format floppy command doesn't have an FM encoding option. My
numbers say there's a humorously large wad of free space on a 1.44 floppy,
and FM is more robust probably than MFM. It would be cute to have one's
said numbers were wrong. Duh.
own floppy low-level format, a "Ha3sm Format Floppy", and to be able to
claim that it's extra robust. So format looks like it's going to be
hand-rolled.
segments
The 386 provides a lot of task-switching stuff. It's all based on paging,
and I think it implicitly buys into virtual memory on mass store. I do not
buy into that. Thus I will attempt to use a segmented protection scheme.
This may have latency benefits, and perhaps total throughput benefits as
well. The provided page-based task-switch is a monster. Like 300 clocks.
Other machines don't have 386-style segments. They'll have to fake it.
No rythm
The PC is clocks-challenged. Clocks/timers are REAL handy, even if I
wasn't a musician. The PC solders the GATE pins of the extra clocks in the
PITs to Vcc. How impersonal. There are some process-switch semantics that
are going to suffer because of that. Hopefully that is stuff that stays
hidden from the Ha3sm machine model as a portability layer.
not_a_PC-ism
so what's crucial, and what the whole industry always watches, is how do
you violate de-facto standards and not kill yourself. How can Ha3sm not be
Wintendo, and not even Linux, and be viable?
more
As to extending what one can assume, I'm looking for slight variances
with big payoffs. A chording keyboard. A more robust floppy format, one
opcode bit off from the stock BIOS format command. AEOI mode for the
PICs. Level-triggered interrupts are looking good. A compembler in the
kernel. Thus the 386 is hidden. Stuff like that. IWTBTW stuff. Stuff
where there are valid hardware assumptions that haven't back-ported to the
AT BIOS.
less
Much less risky is NOT using things, IF you can still do what you want. I
can do what I want thusly: No paging. No FAT. No files. No TSS. No TLB.
TR I don't know yet. No floats in the kernel. No sector size assumptions.
Not even for a boot floppy. Hide x86 IO.