Hey, I have a VGA BIOS of my own. If I give you guys the source code,
to use in Plex, will it go under LGPL? I'd much rather put it under
GPL. It is approximately equivelent to that elpin BIOS, but it's written
to be compatible only with S/VGA architectures; elpin's probably
supports dual monitor support including EGA etc. like what most BIOSes
support. Mine doesn't support that shit because I don't have dual
monitors. Here's what I'm going to do: e-mail me if it is OK to have it
under GPL rather than LGPL. Will that require changing all of plex to
GPL? Is it OK with you guys? What I don't want, is I don't want
companies like VMWare to use my work. If someone wants to use my work,
I'd like it under GPL so that people can get the source code. It's
written in assembly language and is well commented and is 100%
compatible including 320x400-256 (which can be done via the BIOS if you
set a bit in low memory), and it has a VESA STUB (it appears to be
compatible with VESA 1.0 to programs that inquire, but for the modes it
supports, all it provides are the standard VGA modes.)
Please note that my e-mail has been on the frisk. I sent a message to
Kevin but the return address was [EMAIL PROTECTED] which does not work
any more. Actually this e-mail address, [EMAIL PROTECTED], just
started working again today. It should be fine now.
I've been using my BIOS with my S3 card (only the VGA features,
obviously) and with bochs, and it's all commented so you guys can tweak
with it and stuff. I couldn't find a VGA BIOS with source code anywhere
so I had to write my own. I found that bochs sped up development a great
deal.
After you guys figure out the GPL/LGPL thing we can add SVGA support
(VESA 2.0, and I'm thinking of writing an S3 emulator in C to use with
bochs). I compiled plex once, but I had to do it under Linux, and I had
the most difficult time. The configure script I got from CVS had char 13
and char 10 for each new line, and my version of Linux Mandrake 's make
script refused to accept those, so I had to write a program to turn
13,10 characters to just 13 (or was it just 10?) Then I could run make
no problem. When I got it to work, I was impressed that it worked, but I
wrote a program that did this (in "real" mode):
0100 mov cx,ffff
0103 nop
0104 loop 0103
and I found that it took several seconds, which was quite frightining. I
don't know the make script language and I don't know much UNIX (I only
guessed "chmod" when I couldn't run a script I d/l'd from CVS).
Here's what I do:
ere's what I've done: I create at time of program
execution a 32MB table. It's huge, but it's the fastest way I can
think of. By using assembly language I can take advantage of such
things as when the carry flag is set. Here's an example of what it
does: .main_loop:
mov ebx,ecx
.prefix_loop:
mov eax,[esi+ecx]
and eax,0x00ffffff
add ecx,[ebp+eax+_table1]
jc .special_handler
cmp ecx,edx
jnae .main_loop
.page_overflow:
.special_handler: Now _table1 is a 16MB table which specifies the length
of the
selected opcode if it can run natively, and the entire length is
known advance, based on the first three bytes. The only reason why
it would not be known in advance is if the CPU is running with an
operand size or address size of 16 bits, in which case special
handling is done (not shown in the above listing); or, if it is an
extended opcode (meaning it begins with 0x0f), AND it has a modr/m
which determines whether or not the length of the opcode is known
in advance from the first 3 bytes and can be run natively. In that
case, I just use _table2, which is the second half of the table.
Granted, this 32MB table scheme is HUGE, but it is lightining fast.
It is not practical to use DT for everything, and in any case, even
with DT, this approach would be the best possible (although, for
non-native code, rather than emulate on the spot, one would do a
DT-specific thing). If you want to know how I generate the table, I'd be
pleased to
show you. I made a file that is less than 150 lines that expands
into a several thousand line file that explains the entire x86
instruction set up to the Pentium excluding MMX and floating point.
MMX and Floating point can always run natively, but we need to know
the length of those instructions. Now in plex86 I went into dos' debug
and did this: -a
xxxx:0100 mov cx,ffff
xxxx:0103 nop
xxxx:0104 loop 103
xxxx:0106 ret
-g And was horrified to see that plex86 took nearly 5 seconds on my
p55c [pentium mmx; 166mhz piece o shit but it's all I can afford].
In VMWare, I was shocked to see that it was seemingly
instantaneous. Apparently VMWare put a breakpoint of somesort at
0106 and just let the code run natively. Does plex do that? I'd share
code with my own project but it's not far enough along to
be worth while, except, possibly, for that shorthand notation,
which makes it possible to work with a small number of lines, and
even memorize them (hehe, you can program directly in binary if you
memorize 150 lines or so, which is MUCH better than many thousands
of lines or so). one of my programs expands these lines into what you
find in the
secion of opcodes.lst which comes with ralf brown's interrupt list
that lists opcodes and their assembly language counterparts. Want to see
how I memorize how to encode modr/m's in 16 and 32 bit
addressing modes in binary? It's just a neat trick that is 100%
useless (and I don't use it with my programs except to create
another table, when running in 16-bit mode, to convert from the
32mb table to 16-bit addressing counterparts, since the lengths
stored in the table are all for 32-bit opcode sizes and addressing
modes; in the actual code I have to AND the length because the high
4 bits store such things as whether or not it is sensitive to
address size and 32-bit size; if it is, don't worry about it in 32-
bit mode [d=1] unless 6x was used; in 16-bit mode, only worry about
it if none was used; look in the tables to see how much to correct
by). Do you think that this table approach is faster? I've never
benchmarked it, because I'm assuming that it's faster regardless of
the fact that my processor only has a 512kb cache. I would also like to
make an S3 device, so that an S3 can be
emulated (and Windows can use its S3 drivers). ...PLEASE write
back........ Willow Schlanger
