Re: [9fans] hardware acceleration

["Russ Cox" <rsc@plan9.bell-labs.com>]

	because frankly, the install process is baroque.

Besides the VESA problems (which I really would like
to see done, but I've a thesis to write and currently
don't even have a working Plan 9 terminal) what else
could be improved?  I'm always interested in ways to
make it better.  The hardware detection aspect
is admittedly not as good as it could be, but that's
a problem permeating the system rather than a shortcoming
of the install process.  Are there other inadequacies
that stand out?

	How about writing it to drive off the serial port, and bypassing the
	screen altogether for some level of bootstrap?

Others have done this (in text mode, which amounts to the
same thing).  The problem is that it's not a particularly
usable system -- without rio, there's no functional equivalent
of job control or even an interrupt key, so the result is a
bit tough to use.  But if you want to do it, the diffs
are in the archives.

I started to write a reply to the VESA discussion earlier
this evening, in which I complained that VBE < 3.0 (by far
the common case) needs a real-mode call to jumpstart it,
and that would mean passing the info about graphics mode
through the boot loaders.  There's no room for font data
and graphics code in ld.com, and I'd rather keep it out of
9load too.  While writing this it occurred to me that we
can probably defer the switch from text to graphics mode,
so I canned the reply.

Then again, if you want VBE 1.2, you need to do the graphics
switch right away, and all the problems come back.  I did
a google search for XFree86 startup dumps and found that
there were a huge number of VBE 1.2 (non-VBE 2.0) cards still
out there, so it seems reasonable to want to support them.

An approach that works even for VBE 1.2 is to
simulate the BIOS code rather than run it directly.  The
Alpha PC does this in firmware, I'm told.  I wrote
a 3000-line real mode x86 emulator that seems to do a decent job,
and it keeps the x86 creepiness contained.  The only
problem is that the mode switch on my particular card
makes some INT 15 calls to grub around PCI space, and
simulating those in turn requires turning off interrupts,
which I'd rather not do from user space.  Answering the
INT15 calls directly is probably enough to get the mode
switches working, but I haven't gotten back to it.

g% 8.out
>> info
signature: VESA
version: 2.0
oem string: Diamond Mutlimedia. Savage4		[sic -rsc]
capabilities: 8-bit-dac
video modes:
	0109 010a 012e 010e 010f 0131 0133 0134 0141
	0143 0144 0151 0153 0154 0100 011d 011e 0101
	0111 0112 0171 0173 0174 017c 017e 017f 0102
	0103 0114 0115 0104 0105 0117 0118 0161 0163
	0164 0106 0107 011a 011b 0120 0122 0124 0191
	0193 0194 01a1 01a3 01a4 0136 0138 0139
total memory: 16777216
oem software rev: 1.1
vendor name: Diamond Multimedia Inc.
product name: Stealth III Savage4
product rev: Rev C
>> modeinfo 0x0139
mode attributes: supported color graphics linear
bytes per scan line: 7680
resolution: 1920x1440
charsize: 8x16
1 planes, 32 bpp, 1 banks @ 0 kb each
memory model 6 (direct)
r8g8b8x8 r@16 g@8 b@0 x@24
directcolor:
physptr: 0xE0000000
g%

Russ