OK Kevin, here's what I recommend.
First we'll add VESA VBE 2.0 support via the BIOS. This will get SVGA
working under the QNX boot disk.
VES VBA 2.0 is _VERY_ easy to emulate. You just tell it which video
modes are available, and we'll support only a flat video mode. What if a
flat video mode (linear framebuffering) isn't requested? In that case,
we'll pretend to be supporting a banked video mode... to be compatible
with all programs we'll need to add bank support that uses 64KB segments
whose banks can be flipped.
Now I recommend that we _FIRST_ not emulate any chipset since we'll need
to have VESA support anyways and since the VESA support would just be
telling the chipset emulator what to do; initially let's skip chipset
emulation and directly hook the video interrupt.
This will involve changes to VGA.CC that will make it resemble GUI.CC.
Then, we will make a separate file, perhaps S3.CC which will resemble
BEOS.CC in that it talks to VGA.CC. BEOS.CC talks to GUI.CC, with GUI.CC
being generic and BEOS.CC specific. In a similiar way VGA.CC will be
generic and the chipset emulator will talk to it by translating
requests.
Now, eventually an SVGA BIOS like so: put a jump at C000:3 to C800:3 and
put the SVGA BIOS at C800:0. The SVGA BIOS' C000:3 will do a far CALL to
the target of the jump that was at the old C000:3. Thus calling C000:3
will first call the VGA BIOS' initializer and then continue executing at
the SVGA BIOS that will reside at C8000..CFFFF. Our SVGA BIOS will then
hook interrupt 10 after calling the old VGA initializer, but not INT 6D.
INT 6D is the same as INT 10 usually, but not for us: we'll make INT 10
go to _our_ handler which will generate INT 6D _only_ if the function is
not a VESA function.
The Elpin's VGA BIOS' INT 10 just generates INT 6D and then IRETs. It
hooks INT 6D too. For proof:
hook INT 6D in DOS and call INT 10. Look at how many "cycles" went by:
enough for only one instruction. Now return form the interrupt and look
at the number of cycles: enough for one instruction!
It doesn't matter if the INT 10 actually does INT 10h and IRET; it might
do a far CALL or something, but that's not important; what's important
is:
that ALL VGA BIOSes have the same effect since IBM's VGA BIOS is. My S3
SVGA BIOS just makes INT 10 and INT 6D point to the same address.
But the point is, we can "chain" INT 10, passing it to INT 6D if AH is
not 4Fh and otherwise interpreting it.
The VMWare video BIOS, which was made by Phoenix and works with plex86
and bochs, appears to provide VESA support by writing to AH I/O port if
AH is not a standard VGA function.
I think the port they used is 4321h or 1234h or something like that...
maybe it was 0ABCDh but something weird.
The point is, they didn't actually make an SVGA BIOS extension to the
BIOS they had. They didn't have source code for the VGA BIOS, just like
we don't (I suspect). THey probably just asked Phoenix to add that OUT
instruction or OUTS instruction with CX=1 or whatever.
Then they probably just made ther I/O emulator recognize the port and
then interpret things.
That's what we should do, at least at first. Instead of using an I/O
port we have to do the dirty trick of making a little mini-BIOS at
C800:0 like I mentioned above, since I don't think we want to say to
Elpin Systems, "ummm, can you add an OUT instruction please if it's an
invalid function number so we can see if AH is 4Fh or something?"
Instead we'll just hook it as I mentioned above.
Now the VESA VBE emulator will talk directly to VGA.CC. If chipset
emulation is added, that chipset emulation will carry out commands by
talking to VGA.CC too. Eventually, we could make the mini-SVGA BIOS
actually program the chipset, but, like VMWare's engineers, I think it's
not worth the trouble. But the point is we're leaving open that
possibilitiy.
Thus here's what we'll basically do: make up the GUI.CC in the
GUI.CC--BEOS.CC pair, and test it not by making a
VGA.CC--FAKE_CHIPSET_THAT_WE_MADE_UP.CC, but by directly interacting
with VGA.CC from our mini SVGA BIOS.
Here's what the QNX bootdisk does according to the documentation that
they include on the 1.44MB challenge thing: rather than try to fit lots
of chipset drivers, they set the video mode during bootup to a linear
framebuffer mode (a mode where the entire screen works like mode 13h
320x200-256 colors; only there might be 2,3, or 4 bytes per pixel; for 3
bytes, it's one byte for red, one for green and one for blue, for each
pixel; for 4 bytes its the same thing but the last byte is not used but
can be used for a 'channel' (have a DVD decoder writing to it, maybe
hardware blitting, or maybe fading; who the hell knows what that byte is
used for) and for the 2 byte mode, there's 5 bits for red and 5 bits for
blue and, since the eye can see more ranges of green than any other
color since it's the color the sun outputs the most of and hence we
evolved that way [on the spectrum, red and blue are on opposite sides of
green]... anyways there are usually 6 bits for green but sometimes there
are 5 bits and one bit is left unused).
Now the reason why VESA 2.0 support is easy to do is because you _TELL_
the program which video modes you support by telling it the resolution
each mode you support has as well as the color depth (bytes per pixel)
and the format (which bets store red? where's green? etc.)
Thus we'll initially support ONLY the get video mode, set video mode,
get VBE version, and the get video mode info functions.
I suspect QNX uses the BIOS during boot for only those things; it's most
likely.
Now VESA VBE 2.0 is interesting in that there are functions to get a
pointer to code in the VGA BIOS that can be called from 32-bit protected
mode that changes the bank, and that changes the start of video memory
(e.g. page).
I don't know if those are necessary for QNX. But if they are then our
32-bit code would just load the registers to correspond to the
corresponding INT 10 function and then trap to the VGA.CC emulation code
the way the INT 10 handler would, maybe via port like 1234h but I'd
rather do it via HLT or something; make the HLT handler check the
_physical_ location of CS:EIP and if it's between C8000..CFFFF then call
the VGA.CC interpreter which will look at AH and if it's 4Fh, interpret
it.
Basically, this is going to be a piece of cake to get most programs
working. If you insist on 100% VESA VBE compatibility then I'm going to
say, that you are crazy. Because the plex86 pic etc. aren't 100%
compatible. They're just compatible enough to run most programs
(including OSes) and we _ADD_ functionality as we discover a program
that tries to use it. Thus the pic needs to support polling mode, and we
won't at first support non-linear frame buffer modes, etc., and at
_FIRST_ we won't even emulate a chipset.
Kevin Lawton wrote:
>
> Debian User wrote:
> >
> > Hey...
> > Plex86 has been awsome at helping me develop my OS, but unfortunatly, besides
> > the physical memory access bug I sent a fix for, I have no idea how to fix
> > the following problem:
> > After sending all the required parameters to the hard disk controller, I send
> > the 0x20 (read multiple sectors with retries) command to the controller, and
> > wait for an interrupt. Under vmware, as well as in a real system, the IRQ
> > arrives and the data is read from the data I/O port of the controller.
> > In plex86, no IRQ arrives.
> >
> > Any idea why an IRQ wouldn't arrive?
> >
> > When replying, please include [EMAIL PROTECTED]
>
> This sector - is it C/H/S = {0,0,0}? I just scanned the hard drive
> code quickly and see there is an abort for that sector for some
> WinNT case, with no interrupt. Just a thought...
>
> Also, if you have a GRUB loadable ELF file or whatever, put it somewhere
> and post a URL so I can try it.
>
> -Kevin
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Kevin Lawton [EMAIL PROTECTED]
> MandrakeSoft, Inc. Plex86 developer
> http://www.linux-mandrake.com/ http://www.plex86.org/
