DOS ain't dead

Hey everyone. I'm getting this error report in HXSTDERR.LOG when i try to run OGLTEST.EXE (under true MS-DOS 7.1):

dkrnl32: exception C0000005, flags=0 occured at BF:1684DB
ax=8190819 bx=1 cx=10000 dx=1400FF
si=8190819 di=190014 bp=12DD94 sp=12DC6C
exception caused by access to memory address 8190819
ip = Module 'vesa32.dll'+24DB
[eip] = F3 A4 8B C3 5B 5F 5E C9 C2 08 00 8B
[esp] = 00132044 0012E1F3 00004115 08180818 08180818 08180818
dkrnl32: fatal exit!

dkrnl32: exception C0000005, flags=0 occured at BF:168532
ax=8190819 bx=1 cx=10000 dx=148768
si=190014 di=8190819 bp=12DF34 sp=12DE08
exception caused by access to memory address 8190819
ip = Module 'vesa32.dll'+2532
[eip] = F3 A4 8B C3 5B 5F 5E C9 C2 04 00 8D
[esp] = 00132044 00400000 00010000 52A00004 00004B60 00000000
dkrnl32: fatal exit!

Video system is a m/b Intel 865G chipset.

Can anyone shed some light?

- Doug B.

> Hey everyone. I'm getting this error report in HXSTDERR.LOG when i try to
> run OGLTEST.EXE (under true MS-DOS 7.1):
>
> Video system is a m/b Intel 865G chipset.
>
> Can anyone shed some light?

Are you sure your card is VESA 2.0 compatible? What HX version are you using (2.16 or 2.17)?

> Are you sure your card is VESA 2.0 compatible? What HX version are you
> using (2.16 or 2.17)?

Intel 8xx and 9xx are VBE 3.0 capable (even with working refresh rate setting CRTC API), I have a testlog (my vesatest) from 865G and it worked. But I also met intel VGA with buggy BIOS (fixed in newer release).

---
DOS gives me freedom to unlimited HW access.

Thanks for your replies.

Rugxulo:

Yup, VESA VBE 3.0 in fact.

HX version is 2.17 (latest HXRT file is dated Jun-03-2010,
latest HXGUI file is dated Jan-26-2010).

RayeR:

Interesting about the buggy Intel BIOS. I suspected something
was up, as *every* VESA graphics mode is unusuable in a DOS box
or fullscreen in my Win98SE (images are completely "sliced up";
looks like some kind of pixel-offset error). Very frustrating.
But all VGA graphics modes <cough, cough> are fine in the Win DOS
box, and in pure DOS all graphics modes (VESA and VGA) seem fine.
I'd always thought it was a buggy Win driver (the latest from the
Intel site), but maybe it's the BIOS?

I installed the latest system BIOS update from the IBM site
(desktop ThinkCentre A50) a while back -- dunno if that updated
the video BIOS too. Do you know where i might find a newer i865G
BIOS? Or are they too system specific?

- Doug B.

P.S. Apologize to everyone for the somewhat off-topic Windows
comments.... Still, they were about DOS graphics.

>
> Can anyone shed some light?
>

the crash happens when saving/restoring VESA video state.

This may not work properly if there's a bug in the Video-BIOS.

You could try to set

save=0

in hxguihlp.ini - this avoids calling the BIOS functions.

---
MS-DOS forever!

Japheth -

All right -- that works! Thanks for the heads up.

So then, it seems that i do have a "buggy" video BIOS.

I checked around the Intel site (and did a brief web search) but couldn't find a video BIOS update for the 865G. (That doesn't mean i didn't miss it though!) I did find this note however:

"Video BIOS can only be updated through a system BIOS update."

here:

http://www.intel.com/support/graphics/sb/cs-022544.htm

As mentioned in my previous note, i have installed the latest IBM system BIOS update from their support site (dated 2008-Jan-21 -- i doubt they're interested in updating it further).

So can anybody steer me in a direction for a fix for my video BIOS? Or am i just stuck with it, as the Intel FAQ implies?

- Doug B.

> So then, it seems that i do have a "buggy" video BIOS.

It's likely - but not 100% safe to assume ( there may also be a bug in HX's vesa32.dll ).

> So can anybody steer me in a direction for a fix for my video BIOS? Or am
> i just stuck with it, as the Intel FAQ implies?

No. You can always "extend" - or "fix" - your Video BIOS by hooking Int 0x10.

The first thing what I'd do is to check if all values returned by Int 10h, ax=4F01h (get SuperVGA mode info) are reasonable.

---
MS-DOS forever!

Yes, the VGA BIOS is integrated in system BIOS image. It is possible to disassemble one BIOS image (doesn't matter for what specific model but must be for 865G) with latest VGA BIOS and then inject this particular VGA BIOS image to another BIOS image. But I can do it only on standard Award and AMI BIOS. If is this your case send it to me. E.g. Intel, Asus, HP, Dell use some custom crap and there are no available tools for easy manipulation.

---
DOS gives me freedom to unlimited HW access.

Japheth -

Thanks for the feedback.

> You can always "extend" - or "fix" - your Video BIOS by hooking
> Int 0x10.
>
> The first thing what I'd do is to check if all values returned
> by Int 10h, ax=4F01h (get SuperVGA mode info) are reasonable.

Hah -- you know not what you ask! I have to say that i'm
mostly what you would call an "end user", and although i am
somewhat experienced with 16-bit assembler, i'm not what you
would call an expert with video-hardware gutz. But i can get
around BIOS I/O interrupts ok, and i have used VESA 4Fxxh calls,
so i'll see what i can do.

I do know what 4F01h does though -- you set up a data buffer,
feed the call a video-mode number, and it returns data about that
mode in the buffer. Now, me determining if the data is
*reasonable*, well, that's a whole 'nuther story....

And... i'm not sure i have enough knowledge/skill to re-write a
video-BIOS routine....

RayeR -

> then inject this particular VGA BIOS image to another BIOS
> image. But I can do it only on standard Award and AMI BIOS. If
> is this your case send it to me.

Wow, thanks for that very generous offer. (That's what i love
about this community and forum!)

Unfortunately, it's a Phoenix BIOS for an IBM machine. From the
bootup banners:

Phoenix FirstBios(tm) Desktop Pro Version 2.0 for IBM ThinkCentre.
Copyright 1985-2005 Phoenix Technologies Ltd.
(C) Copyright Lenovo Corporation 2005
(C) Copyright IBM Corporation 1981-2005
Portions copyright 1998-1999 Intel Corporation

Despite the copyright dates above, the actual BIOS is dated
2008-Jan-21, the latest (last?) offered at the IBM/Lenovo support
site.

- Doug B.

> Unfortunately, it's a Phoenix BIOS for an IBM machine. From the
> bootup banners:

Sorry I can't help you with phoenix BIOS. I have 845G VGA BIOS version:
Intel(r)845G/845GL/845GE/845GV PCI Accelerated SVGA BIOS
Build Number: 3205 PC Dev 01/05/2004 16:03:22
If you search the similar string at C000:0000-FFFF you will see if you have older or newer VGA BIOS but anyway I don't have any tools for phoenix...

---
DOS gives me freedom to unlimited HW access.

> I do know what 4F01h does though -- you set up a data buffer,
> feed the call a video-mode number, and it returns data about that
> mode in the buffer. Now, me determining if the data is
> *reasonable*, well, that's a whole 'nuther story....

I know what VESA32 does, so I might be able to help.

I guess you're calling ogltest from a text mode. OTOH, the crash dump tells me that VESA32 erroneously thinks it has access to the frame buffer.

So the test is to call vesa int 10h, ax=4F01h, current mode is TEXT (video mode 3) and then see if

- the call succeeds
- field MemoryModel (offset 1Bh in structure below) is zero.


SVGAINFO struct
ModeAttributes dw ?             ;+00
WinAAttributes db ?             ;+02
WinBAttributes db ?             ;+03
WinGranularity dw ?             ;+04
WinSize        dw ?             ;+06
WinASegment    dw ?             ;+08
WinBSegment    dw ?             ;+0A
WinFuncPtr     dd ?             ;+0C
BytesPerScanLine dw ?   ;+10
;---------------------- rest is optional info (since Version 1.2)
XResolution    dw ?             ;+12
YResolution    dw ?             ;+14
XCharSize      db ?             ;+16
YCharSize      db ?             ;+17
NumberOfPlanes db ?             ;+18
BitsPerPixel   db ?             ;+19
NumberOfBanks  db ?             ;+1A
MemoryModel    db ?             ;+1B
BankSize       db ?             ;+1C
NumberOfImagePages db ?
Reserved       db ?
RedMaskSize        db ?
RedFieldPosition   db ?
GreenMaskSize      db ?
GreenFieldPosition db ?
BlueMaskSize       db ?
BlueFieldPosition  db ?
RsvdMaskSize       db ?
RsvdFieldPosition  db ?
DirectColorModeInfo db ?
PhysBasePtr        dd ?         ;since Version 2.0
OffScreenMemOffset dd ?
OffScreenMemSize   dw ?
Reserved2          db 206 dup (?)
SVGAINFO ends


I also added a missing check in VESA32. When trying to save the vesa state, it always assumed that int 10h, ax=4f01h succeeded (it perhaps might fail for standard VGA text modes on your system).

EDIT: I uploaded a new HXRT217.zip which contains the modified VESA32.DLL.

---
MS-DOS forever!

RayeR -

> Sorry I can't help you with phoenix BIOS.

Yeh i understand. I appreciate the offer anyway.

> If you search the similar string at C000:0000-FFFF you will see if you have
> older or newer VGA BIOS

I have a binary copy of the video BIOS that Win98SE saved to my C:\ directory (VIDEOROM.BIN). I scanned it for text, and these were the human-comprehensible strings i found:

-----
IBM VGA Compatible BIOS.
PCIR

For Evaluation Use Only.

$VBT Springdale-G d
BIOS_DATA_BLOCK v
3327Intel(r)865G PCI Accelerated SVGA BIOS
Build Number: 3327 PC Dev 04/12/2004 17:02:31
DECOMPILATION OR DISASSEMBLY PROHIBITED
Copyright (C) 2000-2003 Intel Corp. All Rights Reserved.

CH-7009-A
CH-7009-B
NA-2501

Use the force luke

Intel(r)865G Graphics Chip Accelerated VGA BIOS
Intel Corporation
Intel(r)865G Graphics Controller
Hardware Version 0.0

Total time for VGA POST:
Seconds
0.000
Total time for VGA initialization < 10 MilliSeconds

$VBT Springdale-G d
BIOS_DATA_BL
-----

Note the curious reference to Luke S. and "the force". Does the spirit of ol' Ben permeate Intel? (They failed to capitalize the name though!)

Anyway, if it's of any interest to you, i can forward the binary file.

- Doug B.

> 3327Intel(r)865G PCI Accelerated SVGA BIOS
> Build Number: 3327 PC Dev 04/12/2004 17:02:31

So your vbios is newer build...

> Use the force luke
> Note the curious reference to Luke S. and "the force". Does
> the spirit of ol' Ben permeate Intel? (They failed to capitalize the name
> though!)

Hehe, I found this message in 845G vbios too, I noticed it on my web when modified bios for this nice mobo http://www.rayer.ic.cz/hardware/azxab100.htm
I guess it was written by some vbios developer in despair of debugging

EDIT by rr: fixed URL

---
DOS gives me freedom to unlimited HW access.

Japheth -

> I know what VESA32 does, so I might be able to help.

You da man!

> I guess you're calling ogltest from a text mode.

Yes. I never thought to call it from a graphics mode!

> OTOH, the crash dump tells me that VESA32 erroneously thinks it
> has access to the frame buffer.

Now that's interesting. I'm successfully using your VESAMTRR...
here are results from VSPEED (benchmark included with John
Hinkley's FASTVID):

VESA mode 0101h reports LFB address: F0000000
VESA mode 4101h reports LFB address: F0000000
PCI config10 reports possible LFB address: F0000000
PCI config14 reports possible LFB address: E8000000

VSPEED will use VESA mode 4101h and F0000000h as the LFB address.

32-bit protected-mode video benchmark version 1.10. (640x480x8bit)

Default:

Copy DRAM to banked VGA: 50.14 million bytes per second
Copy DRAM to linear framebuffer: 53.08 million bytes per second

After VESAMTRR:

Copy DRAM to banked VGA: 50.14 million bytes per second
Copy DRAM to linear framebuffer: 79.99 million bytes per second

That's about a 50% increase for LFB Write Combining (i'm assuming
that's what the second measurement means) and no improvement for
Banked VGA. (This is in a P4, 2.8ghz, i865G system.)

> So the test is to call vesa int 10h, ax=4F01h, current mode is
> TEXT (video mode 3) and then see if
>
> - the call succeeds

Ok, i did a "quickie" with DEBUG, assembling some code then using
P command to proceed thru it and looking at the registers.
Setting CX = 3 (video mode 3), after calling Int 10h, AX returned
014Fh. According to RB's interrupt list, the function is
supported (AL = 4Fh), but it failed (AH = 01h). So there you
have it! (Just to double check, i did the same but with CX =
0101h -- a standard VESA mode -- and the call succeeded: AX =
004Fh.)

> - field MemoryModel (offset 1Bh in structure below) is zero.

I guess no sense in doing this, as the call failed.

> SVGAINFO struct
> ...
> SVGAINFO ends

Thanks -- this will be helpful in future projects!

> I also added a missing check in VESA32. When trying to save the
> vesa state, it always assumed that int 10h, ax=4f01h succeeded
> (it perhaps might fail for standard VGA text modes on your
> system).

Looks like a definite possibility. So i wonder if it's universal
VESA behavior or just my BIOS? I have some other systems i can
also test it on.

> EDIT: I uploaded a new HXRT217.zip which contains the modified
> VESA32.DLL.

Downloaded it... and OGLTEST now works ok with SAVE=1 in
HXGUIHLP.INI file.

> MS-DOS forever!

YES!!!

- Doug B.

> Ok, i did a "quickie" with DEBUG, assembling some code then using
> P command to proceed thru it and looking at the registers.
> Setting CX = 3 (video mode 3), after calling Int 10h, AX returned
> 014Fh. According to RB's interrupt list, the function is
> supported (AL = 4Fh), but it failed (AH = 01h). So there you
> have it! (Just to double check, i did the same but with CX =
> 0101h -- a standard VESA mode -- and the call succeeded: AX =
> 004Fh.)

Interesting. It's still a bit "unusual" that the program fails, because VESA32 clears the buffer at ES:DI with zeros before its int 10h, ax=4F01h call. This means, although your VESA-BIOS returns with an error code, it modifies the buffer content!?

---
MS-DOS forever!

> Interesting. It's still a bit "unusual" that the program fails, because
> VESA32 clears the buffer at ES:DI with zeros before its int 10h, ax=4F01h
> call. This means, although your VESA-BIOS returns with an error code, it
> modifies the buffer content!?

So it would be interesting how vbios modified it...

---
DOS gives me freedom to unlimited HW access.

> Interesting. It's still a bit "unusual" that the program fails, because
> VESA32 clears the buffer at ES:DI with zeros before its int 10h, ax=4F01h
> call. This means, although your VESA-BIOS returns with an error code, it
> modifies the buffer content!?

No -- calling with VGA video mode 3, "supported but failed" is
returned (AX = 014Fh) and the ES:DI buffer is *not* touched! (I
set the buffer up with 256 bytes of character "x" just to be
sure.)

As a check, calling with VESA mode 101h, "supported and
succeeded" is returned (AX = 004Fh) and the ES:DI buffer *is*
modified.

Later tonite, i will check these same functions on other systems
that have an Intel 845 chipset, an NVidia GeForce4 M440 card, a
NeoMagic MagicMedia 256AV chipset, and an ancient VESA 1.1 Cirrus
Logic GD5446 chipset... just to see what they do!

- Doug B.

> No -- calling with VGA video mode 3, "supported but failed" is
> returned (AX = 014Fh) and the ES:DI buffer is *not* touched! (I
> set the buffer up with 256 bytes of character "x" just to be
> sure.)

Ok, mystery solved. VESA32 cleared the buffer located in real-mode, but didn't copy the contents back to protected-mode if the call failed.

---
MS-DOS forever!

> > No -- calling with VGA video mode 3, "supported but failed" is
> > returned (AX = 014Fh) and the ES:DI buffer is *not* touched! (I
> > set the buffer up with 256 bytes of character "x" just to be
> > sure.)
>
> Ok, mystery solved.

Cool that the mystery is solved, but now i'm a bit confused.
(This is where my lack of video-hardware and programming
knowledge shows up!)

> VESA32 cleared the buffer located in real-mode,

Ok, maybe i'm misunderstanding, but my code *was* all real mode
(16-bit)... and the interrupt did *not* clear the buffer -- the
call failed and it didn't change the buffer at all! I set the
buffer up with 256 bytes of "x" characters, ran the VESA BIOS
4F01h Int 10h call, and then looked at the buffer -- no change,
still 256 bytes of "x" characters.

Here's my "quickie" code (DEBUG script):

a 0100
MOV     DI, 0110        ;es:di -> data buffer
MOV     CX, 0003        ;vga text video mode < change to 0101h for VESA mode
MOV     AX, 4F01        ;VESA Get Mode Info
INT     10              ;BIOS Video
INT     20              ;DOS Terminate
;space to align data buffer to next paragraph (for viewing convenience):
DB      "___"
;data buffer (256 bytes):
DB      "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
DB      "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
DB      "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
DB      "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

rcx 0110
w
q

I loaded the .COM file into DEBUG, then used P and D commands to
see what happens. The data buffer was unchanged with VGA mode 3
but *was* modified (as expected) when i called with VESA mode
101h.

> but didn't copy the contents back to protected-mode if the call
> failed.

I'm pretty-much duh! about protected mode programming. (I do
know -- in general -- what p/m is though! )

Anyway, as promised in a note above, i did finally test some
other video hardware with the above code, using video mode 3.
Interesting and inconsistent results:

  CHIPSET/CARD                  VBE  RETRN  DESC  ES:DI BUFF
  ----------------------------  ---  -----  ----  -----------
  Intel 865G                    3.0  014Fh  fail  unchanged
  Intel 845G                    3.0  014Fh  fail  unchanged
  NVidia GeForce4 MX440 (NV18)  3.0  004Fh  succ  data filled
  NeoMagic MagicGraph 256AV     2.0  014Fh  fail  unchanged
  Cirrus Logic GD-5436/46       1.2  014Fh  fail  0-filled

As a double-check, they all worked properly when called with VESA
video mode 101h (returned 004Fh in AX and modified the ES:DI
buffer). "Unchanged" means that after the Int 10h, the ES:DI
buffer contained the exact-same 256 bytes of "x" characters that
it was setup with. "0-filled" means that all 256 "x" bytes in
the buffer were replaced with ASCII-0 bytes. "Data filled" means
that the buffer was filled with what appeared to be VESA data
(but i didn't examine it closely).

Just to add some confusion!

- Doug B.

I'll describe what Japheth meant if you allow.

> > VESA32 cleared the buffer located in real-mode,
>
> Ok, maybe i'm misunderstanding, but my code *was* all real mode
> (16-bit)... and the interrupt did *not* clear the buffer -- the
> call failed and it didn't change the buffer at all! I set the
> buffer up with 256 bytes of "x" characters, ran the VESA BIOS
> 4F01h Int 10h call, and then looked at the buffer -- no change,
> still 256 bytes of "x" characters.
>
> ...
>
> > but didn't copy the contents back to protected-mode if the call
> > failed.
>
> I'm pretty-much duh! about protected mode programming. (I do
> know -- in general -- what p/m is though! )

The VESA32 program apparently sets up a buffer in some memory accessible in real (or if applicable V86-)mode first. It initializes this buffer properly in some way. It makes its call to that video BIOS interface. Now the protected mode part of VESA32 has its own memory allocated for the buffer, which it uses to process the results. However, this "protected mode buffer" isn't initialized specifically - after all, after the call the content of the "real mode buffer" is copied into the protected mode buffer. The real mode buffer had been initialized before the call, so in the end, the protected mode buffer should either contain whatever results the call wrote to the buffer, or it should contain the initialization content ('x' characters or NULs or whatever). Right?

Wrong. As Japheth said, the code was accidentally written so that it would only copy the buffer's contents from the real mode buffer to the protected mode buffer in case the call indicated success. If the call indicated failure, the protected mode buffer would never be initialized. VESA32's processing of the buffer contents would therefore read this uninitialized buffer.

> Cool that the mystery is solved, but now i'm a bit confused.
> (This is where my lack of video-hardware and programming
> knowledge shows up!)
>
> > VESA32 cleared the buffer located in real-mode,
>
> Ok, maybe i'm misunderstanding, but my code *was* all real mode
> (16-bit)... and the interrupt did *not* clear the buffer -- the
> call failed and it didn't change the buffer at all! I set the
> buffer up with 256 bytes of "x" characters, ran the VESA BIOS
> 4F01h Int 10h call, and then looked at the buffer -- no change,
> still 256 bytes of "x" characters.

Sorry for my very sloppy usage of terminology! cm described what I "meant" already, but I want to add that my fragment "copy the contents back to protected-mode" is absolute nonsense if taken literally. In fact, with "protected-mode" I meant "extended memory used in protected-mode", and "real-mode" is to be translated to "conventional memory used in real-mode".

>
> CHIPSET/CARD                  VBE  RETRN  DESC  ES:DI BUFF
> ----------------------------  ---  -----  ----  -----------
> Intel 865G                    3.0  014Fh  fail  unchanged
> Intel 845G                    3.0  014Fh  fail  unchanged
> NVidia GeForce4 MX440 (NV18)  3.0  004Fh  succ  data filled
> NeoMagic MagicGraph 256AV     2.0  014Fh  fail  unchanged
> Cirrus Logic GD-5436/46       1.2  014Fh  fail  0-filled
>

Thanks! Very unsurprisingly I tested the VESA stuff on a NVidia machine. I guess I should change this habit.

---
MS-DOS forever!