After an interesting discussion here (http://masm32.com/board/index.php?topic=2224.0) 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 (https://www.virtualbox.org/) here. For the DOS OS I would recommend FreeDOS (http://www.freedos.org/). Here (http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox) 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. (http://masm32.com/board/index.php?topic=2100.15) Anyway, I've an i5 laptop with a NVIDIA GeForce GT 630M here. The graphics adaptor provides only four 256 color modes:
Quote
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
Hi Gunther, the program works fine under DOSBox 0.74 with every available display mode :t
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.
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%.)
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
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 ).
Andreas,
Quote from: japheth on August 20, 2013, 02:55:07 AM
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
Quote from: Gunther on August 20, 2013, 02:40:52 AM
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.
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).
Hi sinsi,
Quote from: sinsi on August 20, 2013, 01:21:52 PM
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.
Quote from: sinsi on August 20, 2013, 01:21:52 PM
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
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.
Quote from: sinsi on August 20, 2013, 01:21:52 PM
- 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.
Andreas,
Quote from: japheth on August 20, 2013, 06:46:13 PM
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
Does anybody know the source of VESA BitBlt function under FLAT/UNREAL mode ?
Manos.
Hi Manos,
I haven't good news for you.
Quote
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
Hi Gunther.
Thank you for reply.
I thought that VBE supports graphics for linear frame buffer above 1 MB.
Manos.
Manos,
Quote from: Manos on December 27, 2013, 11:01:28 PM
I thought that VBE supports graphics for linear frame buffer above 1 MB.
Manos.
that's right. You can use it in FLAT mode. The archive vesaflat.zip contains an example.
Gunther
Gunther,
Your example SetSVGAPixel is familiar to me.
I am interesting for BitBlt and lines, but without use pixel by pixel.
Manos.
Manos,
that's the point. There's an old book from Microsoft Press: Programmer's Guide to PC Video Systems by Richard Wilton. It contains old DOS examples for line and circle drawing (Bresenham). Another source could be Mike Abrash's book (http://www.drdobbs.com/parallel/graphics-programming-black-book/184404919), which can be downloaded by Dr. Dobbs. It's about VGA, but the ideas can be used for the LFB, too. I hope that helps.
Gunther
Thank you Gunther.
Manos.
Manos,
you're welcome.
Gunther
used to have this book - wish i still did
at this price, i may get one :biggrin:
$0.01 + 3.99 shipping
http://www.amazon.com/gp/offer-listing/1556151039/ref=dp_olp_all_mbc?ie=UTF8&condition=all (http://www.amazon.com/gp/offer-listing/1556151039/ref=dp_olp_all_mbc?ie=UTF8&condition=all)
(http://ecx.images-amazon.com/images/I/41Ci6624kyL._SL500_SX258_BO1,204,203,200_.jpg)
there is also an updated version of the book
even though much of the stuff is obsolete - a great reference and well written
Dave,
Quote from: dedndave on December 28, 2013, 03:48:18 PM
there is also an updated version of the book
even though much of the stuff is obsolete - a great reference and well written
yes, of course. It contains also procedures for different Mode X resolutions.
Gunther
you can find Mode X stuff in PDF form, on the web
do you have the newer version or the older one (pictured) ?
what i liked about it - it was a full reference on VGA registers
and - it had some code, too - that could be adapted to 32-bit
Hi Dave,
I have the newer edition in hard copy and the older as a text
file. And both come with the code, new on a diskette and the
older as a ZIP. Fun stuff.
For Mode X, I have a PDF of Micheal Abrash's "Graphic
Programming Black Book".
Cheers,
Steve
Dave,
Quote from: dedndave on December 28, 2013, 11:36:51 PM
do you have the newer version or the older one (pictured) ?
what i liked about it - it was a full reference on VGA registers
and - it had some code, too - that could be adapted to 32-bit
to be honest, I've the German translation (second edition) from 1994. There are pictures inside.
Gunther
Steve,
Quote from: FORTRANS on December 29, 2013, 12:35:42 AM
I have the newer edition in hard copy and the older as a text
file. And both come with the code, new on a diskette and the
older as a ZIP. Fun stuff.
You're one of the lucky ones. I've the source code on a diskette, but no appropriate drive. :(
Gunther
Quote from: Gunther on December 29, 2013, 03:33:57 AM
You're one of the lucky ones. I've the source code on a diskette, but no appropriate drive. :(
Hi Gunther,
Well, if you need it, I am sure something could be worked
out. I will see if I can find a link to the older files.
Regards,
Steve
Steve,
Quote from: FORTRANS on December 29, 2013, 05:23:18 AM
Well, if you need it, I am sure something could be worked
out. I will see if I can find a link to the older files.
that would be fine.
Gunther
Hi,
Found the link to the older files.
http://alexfru.narod.ru/emiscdocs.html
Look for "VGAGUIDE.ZIP" and "VGAG-SRC.ZIP". If you want the
newer source, you can send me an e-mail address or the like.
As you have the book, I am assuming it is okay to send you the
source files. They do differ a bit from the older edition.
Cheers,
Steve N.
Steve,
thank you for the link. :t I'll send you a PM with the mail address. One question: What's a CHP file?
Gunther
Hi Gunther,
Quote from: Gunther on December 30, 2013, 03:11:31 AM
What's a CHP file?
It is a text file of a chapter of the book.
Cheers,
Steve N.
Steve,
Quote from: FORTRANS on December 30, 2013, 03:39:09 AM
It is a text file of a chapter of the book.
thank you. I can open it with an editor. Works fine.
Gunther
awesome Steve (Y)
they also had the advanced dos programming book by Dr Ray Duncan :biggrin:
Dave,
Quote from: dedndave on December 30, 2013, 06:33:23 AM
awesome Steve (Y)
they also had the advanced dos programming book by Dr Ray Duncan :biggrin:
yes, of course. There's a lot of other interesting material, too.
Gunther
yes - i downloaded a few - didn't want to go nuts on the guys server, though :P