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.