VESA under FLAT/UNREAL mode with PB 3.5

[Gunther]

After an interesting discussion here I've decided to post an example that uses the Linear Frame Buffer (bank switching is obsolete) inside the FLAT mode. All source is included. The example shows how one can establish and use the FLAT/UNREAL mode.

But the entire thing is tricky. The application will work fine under the direction of VirtualBox, DOSBox, VirtualPC, Bochs and the like. You can download VirtualBox here. For the DOS OS I would recommend FreeDOS. Here you'll find a step by step guidance to install FreeDOS with VirtualBox. It works fine and stable.

The application should run under plain DOS, too. But here starts the tricky part of the story. With my AMD Radeon HD 7570, the results are somewhat strange. It shows only a part of the Mandelbrot set in the lower third of the monitor. I think that has to do with the location of the LFB; it's physical address is at 3758096384, which is nearly the end of the address space. Japhet's DOS extender has had also problems with that high addresses on my machine; but that's fixed now. You can follow this discussion here. Anyway, I've an i5 laptop with a NVIDIA GeForce GT 630M here. The graphics adaptor provides only four 256 color modes:

101h      640x480
103h      800x600
105h      1024x768
17Dh      1366x768

All modes work fine with that card and the application is very fast. You should be aware that some ATI cards don't work well under plain DOS.

The application won't work under the DOS emulation of Windows, OS/2 or Linux (DOSEmu). That's the price to pay for the FLAT mode. The better approach is a 32 bit DPMI client which can map the LFB in it's address space. That will probably work with nearly all usual cards and monitors. But that'll take a little while, because a hard work week is ahead of me.

It would be nice to test the program with other hardware and post the results.

Gunther

[Antariy]

Hi Gunther, the program works fine under DOSBox 0.74 with every available display mode :t

[FORTRANS]

Hi,

   Tested on two machines.  One is the same as the other thread.
One is the same machine, but booted into DOS.  So the results
should be comparable to the results from your svga.exe.  There
were problems with some of the the images though.  Faster
performance noted.  Nice.

Regards,

Steve N.

Code Select Expand

Laptop 800 CS, MS-DOS 6.22.

The FLAT mode or UNREAL mode was established successful!
========================================================

Your program is now in fat city. It can use the entire memory
above 1 MB up to 4 GB directly.

But you've to pay a price for that: This application works only
under plain DOS with HIMEM.SYS installed, or inside a VM directed
by VMWare, VirtualBox, VirtualPC, Bochs and the like.

It won't work under the DOS emulation of Windows, OS/2 or DOSEmu.

Let's try now if we can establish a VESA mode and using the
Linear Frame Buffer above 1 MB. That'll speed up the things
in a dramatic way, because bank switching isn't necessary.

Please, press any key to continue ...

Current VESA configuration:
===========================

VESA BIOS 1.2
MagicGraph NM2070 40K SVGA BIOS
Installed Video Frame Buffer = 786432 Bytes = 768 KB = .75 MB

Please, press any key to continue ...

Overall VESA Modes available:
=============================

100           101           10D           10E           110
111           102           103

Please, press any key to continue ...

Possible 256 color VESA Modes:

Mode Nr.:   X resoltion    Y resolution     Number
100h        640            400              1
101h        640            480              2
103h        800            600              8

Please enter the appropriate number: 1

The VESA Mode number was: 100h
The resolution was:  640 x 400 Pixel

Linear Frame Buffer address: 3221225472

Elepsed Time: 2.854614 Seconds

(The image was rotated left ~10%.)

Possible 256 color VESA Modes:

Mode Nr.:   X resoltion    Y resolution     Number
100h        640            400              1
101h        640            480              2
103h        800            600              8

Please enter the appropriate number: 2

The VESA Mode number was: 101h
The resolution was:  640 x 480 Pixel

Linear Frame Buffer address: 3221225472

Elepsed Time: 2.689672 Seconds

(The image was rotated left ~10%.)

Possible 256 color VESA Modes:

Mode Nr.:   X resoltion    Y resolution     Number
100h        640            400              1
101h        640            480              2
103h        800            600              8

Please enter the appropriate number: 8

The VESA Mode number was: 103h
The resolution was:  800 x 600 Pixel

Linear Frame Buffer address: 3221225472

Elepsed Time: 3.569832 Seconds

(The image was rotated left ~30%.)

- - - - - - - - - - -
Desktop, MS-DOS 6.20, no TSR.

Current VESA configuration:
===========================

VESA BIOS 2.0
Matrox Graphics Inc.
Installed Video Frame Buffer = 33554432 Bytes = 32768 KB = 32 MB

Please, press any key to continue ...
Overall VESA Modes available:
=============================

100           101           102           103           110
111           112           113           114           115
10A

Please, press any key to continue ...
Possible 256 color VESA Modes:

Mode Nr.:   X resoltion    Y resolution     Number
100h        640            400              1
101h        640            480              2
103h        800            600              4

Please enter the appropriate number: 1

The VESA Mode number was: 100h
The resolution was:  640 x 400 Pixel

Linear Frame Buffer address: 3623878656

Elepsed Time: .1649342 Seconds

(The image looked normal.)

Possible 256 color VESA Modes:

Mode Nr.:   X resoltion    Y resolution     Number
100h        640            400              1
101h        640            480              2
103h        800            600              4

Please enter the appropriate number: 2

The VESA Mode number was: 101h
The resolution was:  640 x 480 Pixel

Linear Frame Buffer address: 3623878656

Elepsed Time: .1642036 Seconds

(The image looked normal.)

Possible 256 color VESA Modes:

Mode Nr.:   X resoltion    Y resolution     Number
100h        640            400              1
101h        640            480              2
103h        800            600              4

Please enter the appropriate number: 4

The VESA Mode number was: 103h
The resolution was:  800 x 600 Pixel

Linear Frame Buffer address: 3623878656

Elepsed Time: .3300137 Seconds

(The image was rotated left ~15%.)


[Gunther]

Hi Alex and Steve,

thank you for testing the software. That it'll work under DOSBox isn't surprising. But it's an emulated DOS with an emulated graphics adaptor.

Steve your results are a bit surprising, especially the image left rotation. What could be the reason?

Anyway, it's not the best solution. 32 bit DPMI is the way to go.

Gunther

[japheth]

I did run the sample under plain DOS ( MS-DOS 7.1 ), with a NViIDIA GeForce 8400GS and HimemX.exe.

Everything looks ok in all resolutions than can be displayed on my monitor ( 640x400 - 1280x1024 ).

[Gunther]

Andreas,

I did run the sample under plain DOS ( MS-DOS 7.1 ), with a NViIDIA GeForce 8400GS and HimemX.exe.

Everything looks ok in all resolutions than can be displayed on my monitor ( 640x400 - 1280x1024 ).

thank you for testing and posting the results. It seems that NViIDIA has better graphics adaptors. May be that I'll change the cards, because AMD/ATI makes some problems.

Gunther

[FORTRANS]

Steve your results are a bit surprising, especially the image left rotation. What could be the reason?

Hi Gunther,

   I don't know of a reason.  That was one of the reasons I tried
another machine.  The first line on the laptop is black for the first
part of the line.  It is as if the program skipped most of the top
line.

   The Matrox card does not preserve the register contents after
calling some interrupt calls.  That broke some of my software that
set AH outside a loop.  It used more stack space than I allocated
once.  (Testing someone else's soft ware looking for a failure mode.
Going from 100 bytes to 100H fixed it.)

   The laptop VESA video has some quirks.  But nothing that looks
like this.  The ones I have noted concern the palette and fonts.

Regards,

Steve N.

[sinsi]

Using VMware I get a mostly black screen with something in the lower 20%, is this right? Maybe GS isn't 0 when you write the pixel?
Also, VMware has lots of 256-colour modes, they scroll off the top of the screen.

A couple of things
- GDT length should be called "highest GDT address", so 15 is correct here
- no need for jumps (prefetch cache) since you aren't going to use 32-bit code (which would need a far jump to selector:offset anyway).

[Gunther]

Hi sinsi,

Using VMware I get a mostly black screen with something in the lower 20%, is this right? Maybe GS isn't 0 when you write the pixel?
Also, VMware has lots of 256-colour modes, they scroll off the top of the screen.

it's the same effect on my machine, but with plain DOS. VirtualBox and DOSBox are working right with no image errors. I don't know the reason.

A couple of things
- GDT length should be called "highest GDT address", so 15 is correct here
- no need for jumps (prefetch cache) since you aren't going to use 32-bit code (which would need a far jump to selector:offset anyway).

The jumps are only for security to make the prefetch queue invalid. 20 years ago I had a GPF with an 80386 without jumps. The jumps are the remainder of that time and don't make any harm, I think.

Gunther

[sinsi]

Booting from an MS-DOS disk just gives me a black screen, but I can escape back to the prompt as normal. Card is an NVidia GTX580.
You might have to setup a palette, some newer cards just blank the DAC -> 256 identical shades of black ::)

edit: on the laptop (intel graphics) it works normally.

[japheth]

- no need for jumps (prefetch cache) since you aren't going to use 32-bit code (which would need a far jump to selector:offset anyway).

The 80386 needs the jump, allegedly. And from my own experiences I'd say that the 80486 needs at least 1 instruction to be executed in PM before a segment register can successfully be initialized with a selector.

Although the sample runs fine for me in DOS there is an issue: the program activates unreal-mode and then optimistically assumes that "nobody" is going to change this until the program has terminated. However, there might be a device driver installed ( or even just a BIOS routine ) that temporary switches to protected-mode and thus deactivates unreal-mode while your program is still running.

I guess that's why MS Himem.sys ( which also uses unreal-mode for its block-move routine ) uses a different and very stable approach: it just installs a interrupt handler for INT 0Dh on the fly and then starts copying. If an "general protected exception" occurs ( exception 0Dh in real-mode! ), the interrupt handler gets control, checks if it's indeed an exception that caused INT 0Dh to be called and, if yes, activates unreal-mode and returns.

[Gunther]

Andreas,

Although the sample runs fine for me in DOS there is an issue: the program activates unreal-mode and then optimistically assumes that "nobody" is going to change this until the program has terminated. However, there might be a device driver installed ( or even just a BIOS routine ) that temporary switches to protected-mode and thus deactivates unreal-mode while your program is still running.

good point; that's a weakness of the application. But I'm writing now the DPMI version. So, I can't fix that at the moment. But your scenario isn't unrealistic.

Gunther

[Manos]

Does anybody know the source of VESA BitBlt function under FLAT/UNREAL mode ?

Manos.

[Gunther]

Hi Manos,

I haven't good news for you.

The purpose of the VESA BIOS Extension is to provide support for extended VGA environments. Thus, the underlying hardware architecture is assumed to be a VGA. Graphics software that drives a Super VGA board will perform its graphics output in generally the same way it drives a standard VGA, i.e. writing directly to a VGA style frame buffer, manipulating graphics controller registers, directly programming the palette, etc. No significant graphics processing will be done in hardware. For this reason, the VESA BIOS Extension does not provide any graphics output functions, such as BitBlt, line or circle drawing, etc.

Or do you mean the linear frame buffer above 1 MB?

Gunther

[Manos]

Hi Gunther.

Thank you for reply.
I thought that VBE supports graphics for linear frame buffer above 1 MB.

Manos.