WhiteFalcon wrote on 2022-06-20, 05:47:

...
but working in real mode on a real machine (P75 + S3Trio) means there is no way for double buffering. My plan is just to have a custom mouse cursor for a potential first person point'n'click adventure game, so nothing too demanding on the hardware. With the lack of a virtual screen, I am using the same old technique I remember working well in VGA 320x200...

Hi,
This is not true. Even in real mode you can achieve hardware assisted double, or even triple buffering in some modes (depending on the size of available video memory). You do not need protected mode for this. The necessary functions have been available from VESA 1.2 (that version did not define linear frame buffer modes or protected mode interface yet). So the functions are available in case of banked modes and thus works from real mode programs.
1. You can query the available virtual screens for a given video mode by calling VESA Function 01h Return VBE Mode Information and looking at the byte value of NumberOfImagePages (at offset 29) in the returned ModeInfoBlock struct.
2. You can call VESA Function 06h - Set/Get Logical Scan Line Length to set the length of a logical/virtual scan line.
3. Then you can call VESA Function 07h - Set/Get Display Start to set the actual starting pixel of the virtual screen.
This way you can achieve virtual scrolling or double/triple/quad buffering depending on the size of the virtual area.
http://www.phatcode.net/res/221/files/vbe20.pdf

How did I miss that?? Thank you! Will have to look into that then. I want to keep the requirements low, but VESA 1.2 is totally okay and a 256kB gfx card wont cut it in 640x480x8 anyway. Would be nice to keep it down to 512Kb, but 2x640x480 = 600kB so I guess 1MB would be the requirement then.

WhiteFalcon wrote on 2022-06-20, 07:45:

How did I miss that?? Thank you! Will have to look into that then. I want to keep the requirements low, but VESA 1.2 is totally okay and a 256kB gfx card wont cut it in 640x480x8 anyway. Would be nice to keep it down to 512Kb, but 2x640x480 = 600kB so I guess 1MB would be the requirement then.

You can keep to 640x400, which has the added bonus of higher refresh rate, albeit non-square pixels, depending on how you configure your screen... IIRC Links 386 used 640x400 as its default resolution, because it would work on most low-end VGA cards.

A good idea to fit it in 512kB even with double buffering! 640x400 is a good resolution, its just that the plan was to use 640x400 for the viewport and the bottom 80 for inventory.

Falcosoft wrote on 2022-06-20, 07:22:

Hi, This is not true. Even in real mode you can achieve hardware assisted double, or even triple buffering in some modes (depen […]
Show full quote

Hi,
This is not true. Even in real mode you can achieve hardware assisted double, or even triple buffering in some modes (depending on the size of available video memory). You do not need protected mode for this. The necessary functions have been available from VESA 1.2 (that version did not define linear frame buffer modes or protected mode interface yet). So the functions are available in case of banked modes and thus works from real mode programs.
1. You can query the available virtual screens for a given video mode by calling VESA Function 01h Return VBE Mode Information and looking at the byte value of NumberOfImagePages (at offset 29) in the returned ModeInfoBlock struct.
2. You can call VESA Function 06h - Set/Get Logical Scan Line Length to set the length of a logical/virtual scan line.
3. Then you can call VESA Function 07h - Set/Get Display Start to set the actual starting pixel of the virtual screen.
This way you can achieve virtual scrolling or double/triple/quad buffering depending on the size of the virtual area.
http://www.phatcode.net/res/221/files/vbe20.pdf

It seems that the virtual screen functions are available only from VESA 2.0 up, my S3 Trio with VESA 1.2 probably wont even return the info in the mode struct. I wrote the struct definition following the VESA 1.2 specification which is why I even missed those fields connected with the offscreen memory. I am testing it now in DOSBox set to "vesa_oldvbe" which returns 1.2 as version, same as my old PC. And "OffScreenMemSize" is giving me 0 for mode 0x101 (640x480x8). A workaround could be UniVBE perhaps. But the mentioned games do work for me even without UniVBE on VESA 1.2 so there has to be a way..

WhiteFalcon wrote on 2022-06-20, 08:46:

It seems that the virtual screen functions are available only from VESA 2.0 up, my S3 Trio with VESA 1.2 probably wont even return the info in the mode struct. I wrote the struct definition following the VESA 1.2 specification which is why I even missed those fields connected with the offscreen memory. I am testing it now in DOSBox set to "vesa_oldvbe" which returns 1.2 as version, same as my old PC. And "OffScreenMemSize" is giving me 0 for mode 0x101 (640x480x8). A workaround could be UniVBE perhaps. But the mentioned games do work for me even without UniVBE on VESA 1.2 so there has to be a way..

There is always the possibility of inaccuracies in DOSBox. I think it could be wise to test with a real VGA card on a machine, e.g. with UniVBE. If you have a retro PC available, that is...

WhiteFalcon wrote on 2022-06-20, 07:58:

A good idea to fit it in 512kB even with double buffering! 640x400 is a good resolution, its just that the plan was to use 640x400 for the viewport and the bottom 80 for inventory.

Well, if you haven't produced any assets yet, you can still change the design to something like 340 : 60 or so, which is roughly the same aspect ration between viewport and inventory.

Alternatively you could hide the inventory and only show it when the mouse cursor touches the bottom of the screen...

Of course, I do, but not at hand. My aim is for it to work on the real PC, using DOSBox only as an alternative as I only have access to the real PC a few times per year.

True with 640x400, yet now facing the problem with maybe no access to double buffering and perhaps no way to solve it another way on VESA 1.2.. Kind of took away my enthusiasm 🙁

I think you can do double buffering in 640x400 IF the VBE mode returns at least eight 64KiB banks of video memory (512KiB). You can use function 07h to set the screen start to flip back and forth between the pages (or even implement soft scrolling vertically).

6.9 Function 07h - Set/Get Display Start […]
Show full quote

6.9 Function 07h - Set/Get Display Start

This function selects the pixel to be displayed in the upper left corner of the
display from the logical page. This function can be used to pan and scroll
around logical screens that are larger than the displayed screen. This function
can also be used to rapidly switch between two different displayed screens for
double buffered animation effects.

Input: AH = 4Fh Super VGA support
AL = 07h Display Start Control
BH = 00h Reserved and must be 0
BL = 00h Select Display Start
CX = First Displayed Pixel in Scan Line
DX = First Displayed Scan Line

Output: AX = Status

Input: AH = 4Fh Super VGA support
AL = 07h Display Start Control
BL = 01h Return Display Start

Output: AX = Status
BH = 00h Reserved and will be 0
CX = First Displayed Pixel in Scan Line
DX = First Displayed Scan Line

WhiteFalcon wrote on 2022-06-20, 08:46:

It seems that the virtual screen functions are available only from VESA 2.0 up, my S3 Trio with VESA 1.2 probably wont even return the info in the mode struct. I wrote the struct definition following the VESA 1.2 specification which is why I even missed those fields connected with the offscreen memory. I am testing it now in DOSBox set to "vesa_oldvbe" which returns 1.2 as version, same as my old PC. And "OffScreenMemSize" is giving me 0 for mode 0x101 (640x480x8). A workaround could be UniVBE perhaps. But the mentioned games do work for me even without UniVBE on VESA 1.2 so there has to be a way..

Hi,
No. Look at the ModeInfoBlock definition in the documentation:

ModeInfoBlock struc ; Mandatory information for all VBE revisions ModeAttributes dw ? ; mode attributes WinAAttributes db ? ; wi […]
Show full quote

ModeInfoBlock struc
; Mandatory information for all VBE revisions
ModeAttributes dw ? ; mode attributes
WinAAttributes db ? ; window A attributes
WinBAttributes db ? ; window B attributes
WinGranularity dw ? ; window granularity
WinSize dw ? ; window size
WinASegment dw ? ; window A start segment
WinBSegment dw ? ; window B start segment
WinFuncPtr dd ? ; real mode pointer to window function
BytesPerScanLine dw ? ; bytes per scan line
; Mandatory information for VBE 1.2 and above
XResolution dw ? ; horizontal resolution in pixels or characters
YResolution dw ? ; vertical resolution in pixels or characters
XCharSize db ? ; character cell width in pixels
YCharSize db ? ; character cell height in pixels
NumberOfPlanes db ? ; number of memory planes
BitsPerPixel db ? ; bits per pixel
NumberOfBanks db ? ; number of banks
MemoryModel db ? ; memory model type
BankSize db ? ; bank size in KB
NumberOfImagePages db ? ; number of images
Reserved db 1 ; reserved for page function
RedMaskSize db ? ; size of direct color red mask in bits
RedFieldPosition db ? ; bit position of lsb of red mask
GreenMaskSize db ? ; size of direct color green mask in bits
GreenFieldPosition db ? ; bit position of lsb of green mask
BlueMaskSize db ? ; size of direct color blue mask in bits
BlueFieldPosition db ? ; bit position of lsb of blue mask
RsvdMaskSize db ? ; size of direct color reserved mask in bits
RsvdFieldPosition db ? ; bit position of lsb of reserved mask
DirectColorModeInfo db ? ; direct color mode attributes
; Mandatory information for VBE 2.0 and above
PhysBasePtr dd ? ; physical address for flat memory frame buffer
Reserved dd 0 ; Reserved - always set to 0
Reserved dw 0 ; Reserved - always set to 0
; Mandatory information for VBE 3.0 and above
LinBytesPerScanLine dw ? ; bytes per scan line for linear modes
BnkNumberOfImagePages db ? ; number of images for banked modes
LinNumberOfImagePages db ? ; number of images for linear modes
LinRedMaskSize db ? ; size of direct color red mask (linear modes)
LinRedFieldPosition db ? ; bit position of lsb of red mask (linear modes)
LinGreenMaskSize db ? ; size of direct color green mask (linear modes)
LinGreenFieldPositiondb ? ; bit position of lsb of green mask (linear modes)
LinBlueMaskSize db ? ; size of direct color blue mask (linear modes)
LinBlueFieldPosition db ? ; bit position of lsb of blue mask (linear modes)
LinRsvdMaskSize db ? ; size of direct color reserved mask (linear modes)
LinRsvdFieldPosition db ? ; bit position of lsb of reserved mask (linear modes)
MaxPixelClock dd ? ; maximum pixel clock (in Hz) for graphics mode
Reserved db 189 dup (?) ; remainder of ModeInfoBlock
ModeInfoBlock ends

As you can see NumberOfImagePages field belongs to the " Mandatory information for VBE 1.2 and above" block.
But as you have written right "OffScreenMemSize" blongs to the "VESA 2.0 and above" block and is only meaningful in case of linear frame buffer modes. But you do not need this field to use virtual resolutions from real mode.
As a test you can try this real mode Turbo Pascal test program that was written to test Nvidia Maxwell/Pascal+ GPU bug. It uses Function 07 explicitly. It should work in DosBox or with your VESA 1.2 S3 card.
Download FALCO_VBEVSTST.zip from the first post:
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)

Or you can also use Univbe's video mode tests without activating Univbe itself. Press spacebar until you get to the virtual scrolling test when you are testing a Banked vide0 mode.
download/file.php?id=41407

Or try the best 😀
Here is a full real mode program that uses Vesa 1.2 640x480 256 color mode and uses as many virtual pages as available to achieve smooth animation (but it will be slow on a Pentium 75):
https://falcosoft.hu/rotary_engine.zip

Ps: I have tested and all the above programs/tests work in vesa_oldvbe mode of DosBox...
So the point is you can use the virtual resolution related functions in VESA 1.2 and you do not need the"OffScreenMemSize" field for anything (which for the record has not been mentioned by me at all so I do not understand why you tried to use it). You only need the
" NumberOfImagePages" field to determine if virtual resolutions are available in VESA 1.2 modes.

Falcosoft wrote on 2022-06-20, 09:54:

Hi, No. Look at the ModeInfoBlock definition in the documentation: […]
Show full quote

Hi,
No. Look at the ModeInfoBlock definition in the documentation:

ModeInfoBlock struc ; Mandatory information for all VBE revisions ModeAttributes dw ? ; mode attributes WinAAttributes db ? ; wi […]
Show full quote

ModeInfoBlock struc
; Mandatory information for all VBE revisions
ModeAttributes dw ? ; mode attributes
WinAAttributes db ? ; window A attributes
WinBAttributes db ? ; window B attributes
WinGranularity dw ? ; window granularity
WinSize dw ? ; window size
WinASegment dw ? ; window A start segment
WinBSegment dw ? ; window B start segment
WinFuncPtr dd ? ; real mode pointer to window function
BytesPerScanLine dw ? ; bytes per scan line
; Mandatory information for VBE 1.2 and above
XResolution dw ? ; horizontal resolution in pixels or characters
YResolution dw ? ; vertical resolution in pixels or characters
XCharSize db ? ; character cell width in pixels
YCharSize db ? ; character cell height in pixels
NumberOfPlanes db ? ; number of memory planes
BitsPerPixel db ? ; bits per pixel
NumberOfBanks db ? ; number of banks
MemoryModel db ? ; memory model type
BankSize db ? ; bank size in KB
NumberOfImagePages db ? ; number of images
Reserved db 1 ; reserved for page function
RedMaskSize db ? ; size of direct color red mask in bits
RedFieldPosition db ? ; bit position of lsb of red mask
GreenMaskSize db ? ; size of direct color green mask in bits
GreenFieldPosition db ? ; bit position of lsb of green mask
BlueMaskSize db ? ; size of direct color blue mask in bits
BlueFieldPosition db ? ; bit position of lsb of blue mask
RsvdMaskSize db ? ; size of direct color reserved mask in bits
RsvdFieldPosition db ? ; bit position of lsb of reserved mask
DirectColorModeInfo db ? ; direct color mode attributes
; Mandatory information for VBE 2.0 and above
PhysBasePtr dd ? ; physical address for flat memory frame buffer
Reserved dd 0 ; Reserved - always set to 0
Reserved dw 0 ; Reserved - always set to 0
; Mandatory information for VBE 3.0 and above
LinBytesPerScanLine dw ? ; bytes per scan line for linear modes
BnkNumberOfImagePages db ? ; number of images for banked modes
LinNumberOfImagePages db ? ; number of images for linear modes
LinRedMaskSize db ? ; size of direct color red mask (linear modes)
LinRedFieldPosition db ? ; bit position of lsb of red mask (linear modes)
LinGreenMaskSize db ? ; size of direct color green mask (linear modes)
LinGreenFieldPositiondb ? ; bit position of lsb of green mask (linear modes)
LinBlueMaskSize db ? ; size of direct color blue mask (linear modes)
LinBlueFieldPosition db ? ; bit position of lsb of blue mask (linear modes)
LinRsvdMaskSize db ? ; size of direct color reserved mask (linear modes)
LinRsvdFieldPosition db ? ; bit position of lsb of reserved mask (linear modes)
MaxPixelClock dd ? ; maximum pixel clock (in Hz) for graphics mode
Reserved db 189 dup (?) ; remainder of ModeInfoBlock
ModeInfoBlock ends

As you can see NumberOfImagePages field belongs to the " Mandatory information for VBE 1.2 and above" block.
But as you have written right "OffScreenMemSize" blongs to the "VESA 2.0 and above" block and is only meaningful in case of linear frame buffer modes. But you do not need this field to use virtual resolutions from real mode.
As a test you can try this real mode Turbo Pascal test program that was written to test Nvidia Maxwell/Pascal+ GPU bug. It uses Function 07 explicitly. It should work in DosBox or with your VESA 1.2 S3 card.
Download FALCO_VBEVSTST.zip from the first post:
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)

Or you can also use Univbe's video mode tests without activating Univbe itself. Press spacebar until you get to the virtual scrolling test when you are testing a Banked vide0 mode.
download/file.php?id=41407

Or try the best 😀
Here is a full real mode program that uses Vesa 1.2 640x480 256 color mode and uses as many virtual pages as available to achieve smooth animation (but it will be slow on a Pentium 75):
https://falcosoft.hu/rotary_engine.zip

Ps: I have tested and all the above programs/tests work in vesa_oldvbe mode of DosBox...
So the point is you can use the virtual resolution related functions in VESA 1.2 and you do not need the"OffScreenMemSize" field for anything (which for the record has not been mentioned by me at all so I do not understand why you tried to use it). You only need the
" NumberOfImagePages" field to determine if virtual resolutions are available in VESA 1.2 modes.

Neat! Thank you for the tips and examples, I will try it on my real PC when I get the chance again. And also here in DOSBox. As you apparently have experiences with this, how do you go about using it for double buffering? I mean you probably set the start offset from 0 to 307200 and back (for 640x480) and it should be possible to use and alternation of the method I mentioned in the first post, storing the background and restoring after the flip. But how about the banks, does the second screen start on a bank boundary, i.e. 307200? Or do you need to just consider it all as one piece of memory which will make the bank calculation for PutImage/Sprite a bit more complicated? I am somewhat afraid the latter is the case, which will again make it a bit over my head. Nevertheless it would make it completely flicker free.

root42 wrote on 2022-06-20, 09:24:

I think you can do double buffering in 640x400 IF the VBE mode returns at least eight 64KiB banks of video memory (512KiB). You can use function 07h to set the screen start to flip back and forth between the pages (or even implement soft scrolling vertically).

6.9 Function 07h - Set/Get Display Start […]
Show full quote

6.9 Function 07h - Set/Get Display Start

This function selects the pixel to be displayed in the upper left corner of the
display from the logical page. This function can be used to pan and scroll
around logical screens that are larger than the displayed screen. This function
can also be used to rapidly switch between two different displayed screens for
double buffered animation effects.

Input: AH = 4Fh Super VGA support
AL = 07h Display Start Control
BH = 00h Reserved and must be 0
BL = 00h Select Display Start
CX = First Displayed Pixel in Scan Line
DX = First Displayed Scan Line

Output: AX = Status

Input: AH = 4Fh Super VGA support
AL = 07h Display Start Control
BL = 01h Return Display Start

Output: AX = Status
BH = 00h Reserved and will be 0
CX = First Displayed Pixel in Scan Line
DX = First Displayed Scan Line

Agree, it should be doable with 512kB in theory. This page switching is totally new for me, didnt have much experience with ModeX (where this is a must) if any at all. And it also depends if VESA 1.2 supports it, which seems to be the case.

Falcosoft wrote on 2022-06-20, 09:54:

Hi, No. Look at the ModeInfoBlock definition in the documentation: […]
Show full quote

WhiteFalcon wrote on 2022-06-20, 08:46:

It seems that the virtual screen functions are available only from VESA 2.0 up, my S3 Trio with VESA 1.2 probably wont even return the info in the mode struct. I wrote the struct definition following the VESA 1.2 specification which is why I even missed those fields connected with the offscreen memory. I am testing it now in DOSBox set to "vesa_oldvbe" which returns 1.2 as version, same as my old PC. And "OffScreenMemSize" is giving me 0 for mode 0x101 (640x480x8). A workaround could be UniVBE perhaps. But the mentioned games do work for me even without UniVBE on VESA 1.2 so there has to be a way..

Hi,
No. Look at the ModeInfoBlock definition in the documentation:

ModeInfoBlock struc ; Mandatory information for all VBE revisions ModeAttributes dw ? ; mode attributes WinAAttributes db ? ; wi […]
Show full quote

ModeInfoBlock struc
; Mandatory information for all VBE revisions
ModeAttributes dw ? ; mode attributes
WinAAttributes db ? ; window A attributes
WinBAttributes db ? ; window B attributes
WinGranularity dw ? ; window granularity
WinSize dw ? ; window size
WinASegment dw ? ; window A start segment
WinBSegment dw ? ; window B start segment
WinFuncPtr dd ? ; real mode pointer to window function
BytesPerScanLine dw ? ; bytes per scan line
; Mandatory information for VBE 1.2 and above
XResolution dw ? ; horizontal resolution in pixels or characters
YResolution dw ? ; vertical resolution in pixels or characters
XCharSize db ? ; character cell width in pixels
YCharSize db ? ; character cell height in pixels
NumberOfPlanes db ? ; number of memory planes
BitsPerPixel db ? ; bits per pixel
NumberOfBanks db ? ; number of banks
MemoryModel db ? ; memory model type
BankSize db ? ; bank size in KB
NumberOfImagePages db ? ; number of images
Reserved db 1 ; reserved for page function
RedMaskSize db ? ; size of direct color red mask in bits
RedFieldPosition db ? ; bit position of lsb of red mask
GreenMaskSize db ? ; size of direct color green mask in bits
GreenFieldPosition db ? ; bit position of lsb of green mask
BlueMaskSize db ? ; size of direct color blue mask in bits
BlueFieldPosition db ? ; bit position of lsb of blue mask
RsvdMaskSize db ? ; size of direct color reserved mask in bits
RsvdFieldPosition db ? ; bit position of lsb of reserved mask
DirectColorModeInfo db ? ; direct color mode attributes
; Mandatory information for VBE 2.0 and above
PhysBasePtr dd ? ; physical address for flat memory frame buffer
Reserved dd 0 ; Reserved - always set to 0
Reserved dw 0 ; Reserved - always set to 0
; Mandatory information for VBE 3.0 and above
LinBytesPerScanLine dw ? ; bytes per scan line for linear modes
BnkNumberOfImagePages db ? ; number of images for banked modes
LinNumberOfImagePages db ? ; number of images for linear modes
LinRedMaskSize db ? ; size of direct color red mask (linear modes)
LinRedFieldPosition db ? ; bit position of lsb of red mask (linear modes)
LinGreenMaskSize db ? ; size of direct color green mask (linear modes)
LinGreenFieldPositiondb ? ; bit position of lsb of green mask (linear modes)
LinBlueMaskSize db ? ; size of direct color blue mask (linear modes)
LinBlueFieldPosition db ? ; bit position of lsb of blue mask (linear modes)
LinRsvdMaskSize db ? ; size of direct color reserved mask (linear modes)
LinRsvdFieldPosition db ? ; bit position of lsb of reserved mask (linear modes)
MaxPixelClock dd ? ; maximum pixel clock (in Hz) for graphics mode
Reserved db 189 dup (?) ; remainder of ModeInfoBlock
ModeInfoBlock ends

As you can see NumberOfImagePages field belongs to the " Mandatory information for VBE 1.2 and above" block.
But as you have written right "OffScreenMemSize" blongs to the "VESA 2.0 and above" block and is only meaningful in case of linear frame buffer modes. But you do not need this field to use virtual resolutions from real mode.
As a test you can try this real mode Turbo Pascal test program that was written to test Nvidia Maxwell/Pascal+ GPU bug. It uses Function 07 explicitly. It should work in DosBox or with your VESA 1.2 S3 card.
Download FALCO_VBEVSTST.zip from the first post:
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)

Or you can also use Univbe's video mode tests without activating Univbe itself. Press spacebar until you get to the virtual scrolling test when you are testing a Banked vide0 mode.
download/file.php?id=41407

Or try the best 😀
Here is a full real mode program that uses Vesa 1.2 640x480 256 color mode and uses as many virtual pages as available to achieve smooth animation (but it will be slow on a Pentium 75):
https://falcosoft.hu/rotary_engine.zip

Ps: I have tested and all the above programs/tests work in vesa_oldvbe mode of DosBox...
So the point is you can use the virtual resolution related functions in VESA 1.2 and you do not need the"OffScreenMemSize" field for anything (which for the record has not been mentioned by me at all so I do not understand why you tried to use it). You only need the
" NumberOfImagePages" field to determine if virtual resolutions are available in VESA 1.2 modes.

Tried the three programs you posted, the rotary thingy is very cool, even not considering your expert-level VESA access! And after some more reading it seems that while you can access more of the memory, hence have another screen buffer, you access it as a chunk of memory with bank switches, which seems to be rather complex to work with. I was happy to be able to eke out a working PutImage function, albeit a slower one, now this turns it on its head 😒
The vbetest reports 2MB VRAM and also a linear framebuffer! But that is either a thingy of DOSBox or the program runs in protected mode. Can imagine accessing the linear framebuffer from real mode.

WhiteFalcon wrote on 2022-06-20, 13:13:

Tried the three programs you posted, the rotary thingy is very cool, even not considering your expert-level VESA access! And after some more reading it seems that while you can access more of the memory, hence have another screen buffer, you access it as a chunk of memory with bank switches, which seems to be rather complex to work with. I was happy to be able to eke out a working PutImage function, albeit a slower one, now this turns it on its head 😒
The vbetest reports 2MB VRAM and also a linear framebuffer! But that is either a thingy of DOSBox or the program runs in protected mode. Can imagine accessing the linear framebuffer from real mode.

I haven't read into the details of accessing the framebuffer. But wouldn't it be simply a case of computing the linear address and then doing addr >> 16 to get the bank number?

The few games I was able to get working with VESA graphics were so much easier on the eyes than the regular graphics. TIE Fighter, especially, as the craft looked smoother and had a more life-life feel. I think Dark Forces may have had a hidden VESA mode, as when I played it in Windows and moved the DOS screen into a Windowed mode, the graphics suddenly got far better looking, as a VESA title should have looked.

WhiteFalcon wrote on 2022-06-20, 11:03:

Neat! Thank you for the tips and examples, I will try it on my real PC when I get the chance again. And also here in DOSBox. As you apparently have experiences with this, how do you go about using it for double buffering? I mean you probably set the start offset from 0 to 307200 and back (for 640x480) and it should be possible to use and alternation of the method I mentioned in the first post, storing the background and restoring after the flip. But how about the banks, does the second screen start on a bank boundary, i.e. 307200? Or do you need to just consider it all as one piece of memory which will make the bank calculation for PutImage/Sprite a bit more complicated? I am somewhat afraid the latter is the case, which will again make it a bit over my head. Nevertheless it would make it completely flicker free.

Hi,
Actually selecting banks/windows is more simple than you think. You should not calculate addresses all the time. There is VESA function 05h Display Window Control. Notice that 'Window' is a different concept to multiple display pages. It works only in Banked video modes to overcome the 64K limit of the real mode video segment. This function has to be used in every mode where the mode requires more than 64K to present the full resolution regardless virtual pages are used or not.
Back to the point: VESA function 05h needs to be used only in the lowest level in your Putpixel (or similar routine). Namely:

1 
2mov ax, 0a000h  
3mov es, ax    ; es segment register stores video segment all the time.
4...
5...
6PUTPIXEL PROC   ; on enter dx contains original Window number (0 at start)    
7            push dx            
8            mov ax, word ptr[Y_coordinate]
9            mul word ptr [modeinfo.BytesPerScanLine]         ;  scanline in bytes. If you use Function 06h to set a different virtual width then you should use the value returned in BX instead.                    
10            mov di, ax            
11            add di, word ptr[X_coordinate]    
12            adc dx,0                
13            pop cx
14            cmp dx,cx
15            je @NOWINDOWCHANGE            
16            mov ax,4f05h                      ;Window number = dx and  Window number is already in dx !
17            xor bx, bx                                ;bh=function(0) bl=Window A(0)
18            int 10h           
19  @NOWINDOWCHANGE:
20            mov al, byte ptr[Color]            
21            stosb          ;Store al at address ES:DI
22            ret
23PUTPIXEL ENDP

The above code should work regardless you set the virtual display width to 2x the screen width for double buffering or you use 2x the screen height (2x scan lines).
BTW there is a description in VBE 3.0. documentation how triple buffering works. The idea is the same for double buffering it is just more simple:

Using Hardware Triple Buffering Hardware triple buffering is supported in the VBE/Core specification by allowing the application […]
Show full quote

Using Hardware Triple Buffering
Hardware triple buffering is supported in the VBE/Core specification by allowing the application
to schedule a display start address change, and then providing a function that can be called to
determine the status of the last scheduled display start address change. VBE Function 4F07h is
used for this, along with subfunctions 02h and 04h. To implement hardware triple buffering you
would use the following steps:
1. Display from the first visible buffer, and render to the second hidden buffer.
2. Schedule a display start address change for the second hidden buffer that you just
finished rendering (4F07h, 02h), and start rendering immediately to the third hidden
buffer. CRT controller is currently displaying from the first buffer.
3. Before scheduling the display start address change for the third hidden buffer, wait
until the last scheduled change has occurred (4F07h, 04h returns not 0). Schedule
display start address change for the third hidden buffer and immediately begin
rendering to the first hidden buffer. CRT controller is currently displaying from the
second buffer.
4. Repeat step 3 over and over cycling though each of the buffers.

The point is: for 640x480 double buffering you can either define an 1280x480 virtual screen with the help of Function 06h or use a 640x960 virtual screen.
In the first case your page 1 is from x=0 and your page 2 is from x=640.
In the second case your page 1 is from y=0 and your page 2 is from y=480.
In both cases you can use Function 07h to switch between page 1 and page 2.
While your page 1 is visible you draw on page 2 and vice versa.

I have written a little demonstration program in x86 assembly illustrating all the concepts we discussed above. You can compile it with TASM or JWASM. Set your linker to output a com file.
It uses 640x480 256 color VESA 1.2 banked video mode. It also sets and uses a 1280x960 virtual resolution for 4 different buffers. It draws a full Mandelbrot set across the 4 buffers.
After the program finished drawing you can press a key 4 times to display the content of the 4 different buffers. It requires at least 2MB video memory (works in DosBox). No error checking , contains magic constants etc. but I think it can help understand how banked mode virtual resolutions and hardware double/triple/quad buffering work.

1.286
2MANDEL SEGMENT
3assume cs:mandel,ds:mandel,ss:mandel
4org 100h
5  START:
6
7            mov ax,0a000h
8            mov es,ax
9            mov ax,4f02h
10            mov bx,101h
11            int 10h        ; sets 640x480 256 color mode
12
13            mov ax,4f06h
14            mov bx,0
15            mov cx,1280    ; sets virtual scanline width to 1280 px. Notice that you do not have to define height, but DX returns the maximum possible height.
16            int 10h
17
18
19            fld dword ptr [initb]
20            fstp dword ptr [b]
21            mov word ptr[loop1],0
22            jmp @A1
23    @L1:
24            inc word ptr [loop1]
25    @A1:
26            fld dword ptr[b]
27            fadd dword ptr[lp]
28            fstp dword ptr[b]
29            fld dword ptr[inita]
30            fstp dword ptr[a]
31            mov word ptr[loop2],0
32            jmp @A2
33    @L2:
34            inc word ptr [loop2]
35    @A2:
36            fld dword ptr[a]
37            fadd dword ptr[lp2]
38            fstp dword ptr[a]
39              CALL ITERATE
40
41            cmp bx,word ptr [maxi]
42            jae @NOPUT
43            CALL PUTPIXEL
44   @NOPUT:
45            cmp word ptr[loop2],1279
46            jne @L2
47            cmp word ptr[loop1],959
48            jne @L1
49
50            xor ax,ax   ;wait for keypress
51            int 16h
52            mov ax,4f07h  ;this block sets lower left page 2
53            xor bx,bx
54            mov bl,00h
55            mov cx,0
56            mov dx,480
57            int 10h
58
59            xor ax,ax   ;wait for keypress
60            int 16h

61            mov ax,4f07h  ;this block sets lower right page 3
62            xor bx,bx
63            mov bl,00h
64            mov cx,640
65            mov dx,480
66            int 10h
67
68            xor ax,ax   ;wait for keypress
69            int 16h
70            mov ax,4f07h  ;this block sets upper right page 4
71            xor bx,bx
72            mov bl,00h
73            mov cx,640
74            mov dx,0
75            int 10h
76
77            xor ax,ax  ;wait for keypress
78            int 16h
79            mov ax,4f07h  ;this block sets back original upper left page 1
80            xor bx,bx
81            mov bl,00h
82            mov cx,0
83            mov dx,0
84            int 10h
85
86            xor ax,ax
87            int 16h
88            mov ax,3
89            int 10h
90            mov ax,4c00h
91  INT 21h
92
93
94  ITERATE PROC
95            fld dword ptr [a]
96            fld dword ptr [b]
97            fild dword ptr [bout]
98            xor bx,bx
99            fldz
100            fldz
101            fldz
102            fldz
103    @ITER:
104            fmul st,st(3)
105            fadd st,st(0)
106            fadd st,st(5)
107            fincstp
108            fsub st,st(1)
109            fadd st,st(5)
110            fst  st(2)
111            fmul st,st(0)
112            inc  bx
113            fst  st(6)
114            fdecstp
115            fst  st(2)
116            fmul st(2),st
117            fdecstp
118            fadd st,st(3)
119            fcomp st(5)
120            fnstsw ax
121            and ah,41h
122            jz @OK
123            cmp bx,word ptr[maxi]
124            jb @ITER
125    @OK:
126            finit
127            ret
128  ITERATE ENDP
129
130
131  PUTPIXEL PROC
132            push dx
133            mov ax,1280
134            mul word ptr[loop1]
135            mov di,ax
136            add di,word ptr[loop2]
137            adc dx,0
138            pop cx
139            cmp dx,cx
140            je @NOPAGING
141            push bx
142            mov ax,4f05h   ;Window number=dx
143            mov bx,00h     ;bh=function(0) bl=window(0)
144            int 10h
145            pop bx
146   @NOPAGING:
147            add bl,byte ptr[color]
148            mov es:[di],bl
149            ret
150  PUTPIXEL ENDP
151
152
153
154
155  b    :DD ?
156  a    :DD ?
157  loop1:DW ?
158  loop2:DW ?
159  initb:DD -1.2
160  inita:DD -2.4
161  lp   :DD 0.0025
162  lp2  :DD 0.0025
163  bout :DD 4
164  maxi :DW 100
165  color:DB -2
166
167
168  MANDEL ENDS
169END START

root42 wrote on 2022-06-20, 13:28:

WhiteFalcon wrote on 2022-06-20, 13:13:

Tried the three programs you posted, the rotary thingy is very cool, even not considering your expert-level VESA access! And after some more reading it seems that while you can access more of the memory, hence have another screen buffer, you access it as a chunk of memory with bank switches, which seems to be rather complex to work with. I was happy to be able to eke out a working PutImage function, albeit a slower one, now this turns it on its head 😒
The vbetest reports 2MB VRAM and also a linear framebuffer! But that is either a thingy of DOSBox or the program runs in protected mode. Can imagine accessing the linear framebuffer from real mode.

I haven't read into the details of accessing the framebuffer. But wouldn't it be simply a case of computing the linear address and then doing addr >> 16 to get the bank number?

If that was the case I guess it would cancel out the benefits of the linearity 😀 What you described is the standard bank-based access I am using now.

RetroGamer4Ever wrote on 2022-06-20, 13:32:

The few games I was able to get working with VESA graphics were so much easier on the eyes than the regular graphics. TIE Fighter, especially, as the craft looked smoother and had a more life-life feel. I think Dark Forces may have had a hidden VESA mode, as when I played it in Windows and moved the DOS screen into a Windowed mode, the graphics suddenly got far better looking, as a VESA title should have looked.

Isnt that more like that when you run a DOS game in a sall window, the pixels are much smaller hence make it all look crisper, cleaner? VESA is just the standard for accessing higher resolutions and more colors on old gfx cards.