VGA Secret Mode Finder
category: code [glöplog]
In order to save 4 bytes compared to the standard VESA mode initialization for high resolution video modes (mode numbers > 100h) i wrote a mode finder (vga, graphics, 256 colors) that abuses the address calculation overflow of the VGA BIOS to write and read a pixel to determine the width of the screen, then after scanning, report every mode with a width greater than 0 (and assuming the width is less than 4000). I took some subroutines from "vesamodes.com" which lists all the modes above 100h. I didn't find something similar for the modes below 100h, so i did it myself. Dosbox reports mode 13h and 69h, my GT1030 and GT105M a lot more (see picture show)
code : here
binary : here
imgur picture show : here
As a by-product, my pet intro Dragon Fade now runs in 1360x768, while still being 32 bytes and having ESC support.
So now, for the questions:
Is there already a tool that does find these modes?
How to find the height of an unknown mode?
Can this be extracted from any VGA registers? (i tried and failed)
code : here
binary : here
imgur picture show : here
As a by-product, my pet intro Dragon Fade now runs in 1360x768, while still being 32 bytes and having ESC support.
So now, for the questions:
Is there already a tool that does find these modes?
How to find the height of an unknown mode?
Can this be extracted from any VGA registers? (i tried and failed)
wow, that's nice tool, thanks! :) as far as I know, WHATVGA from VGADOC package can find those "hidden" modes too and also allow to fiddle with VGA (and even some extended RAMDAC) registers.
you can also probe mode width via BIOS data area, and also get mode height as well (get a byte from 40:84, add 1 to it and multiply by word at 40:85)
technically it's possible, but keep in mind that SVGAs store high bits (those exceeding VGA limits of 8 bit per horizontal/10 bit per vertical timing position) of timing parameters in extended registers, whose layout is different from one vendor to another (and they are often protected so you can unlock them before reading!), so only VGA parts ([3d4 index 1]*8 + 1 for width and Vertical Display End register, scattered across many other regs for height) of those timings are available without tricks ;)
p.s. those "hidden" (and generally only available via VESA modeset call) are often a result of BIOS optimization to use same routines for mode init as for VGA modes, at least S3 does this, and jugding by your screenshot NVidia also :)
you can also probe mode width via BIOS data area, and also get mode height as well (get a byte from 40:84, add 1 to it and multiply by word at 40:85)
Quote:
Can this be extracted from any VGA registers? (i tried and failed)
technically it's possible, but keep in mind that SVGAs store high bits (those exceeding VGA limits of 8 bit per horizontal/10 bit per vertical timing position) of timing parameters in extended registers, whose layout is different from one vendor to another (and they are often protected so you can unlock them before reading!), so only VGA parts ([3d4 index 1]*8 + 1 for width and Vertical Display End register, scattered across many other regs for height) of those timings are available without tricks ;)
p.s. those "hidden" (and generally only available via VESA modeset call) are often a result of BIOS optimization to use same routines for mode init as for VGA modes, at least S3 does this, and jugding by your screenshot NVidia also :)
On my 1050 secrets.com finds only 13h, 21h, 22h, and 3Fh.
I wrote my own version of the test routine:
Runs with more results:
I wrote my own version of the test routine:
Code:
ORG 256
MOV DI,BP
main:
PUSH AX
INT 10H
MOV AH,3
INT 10H
JCXZ found
back:
MOV AX,3
INT 10H
POP AX
INC AL
JNS main
MOV SI,BP
result:
LODSB
AAM 16
ADD AX,'00'
MOV DL,AH
MOV AH,2
PUSH AX
INT 21H
POP DX
CMP DL,'9'
JNA @F
ADD DL,'A'-'9'-1
@@:
INT 21H
MOV DL,'H'
INT 21H
MOV DL,':'
INT 21H
LODSW
CALL PrintNum
MOV AH,2
MOV DL,13
INT 21H
MOV DL,10
INT 21H
CMP SI,DI
JNE result
RETN
found:
STOSB
INC DX
MOV AX,0C5AH
INT 10H
DEC DX
MOV CH,4096/256
.1:
MOV AH,0DH
INT 10H
CMP AL,05AH
LOOPNZ .1
DEC DI
JCXZ back
INC DI
INC CX
XCHG AX,CX
STOSW
JMP back
PrintNum:
PUSHA
SUB CX,CX
.1:
SUB DX,DX
MOV BX,10
DIV BX
ADD DL,'0'
PUSH DX
INC CX
TEST AX,AX
JNZ .1
.2:
POP DX
MOV AH,2
INT 21H
LOOP .2
POPA
RETN
Runs with more results:
Quote:
13H:320
21H:640
22H:800
3FH:1024
4BH:1280
4CH:4096
4DH:1280
5CH:800
5EH:1024
5FH:640
6EH:4096
6FH:4096
72H:4096
@wbc: whatvga is nice! works like a charm under dosbox, with lots of features, but fails to work on freedos (runtime error 200, even with all restrictive parameters from whatvga.doc) i tested the idea with the bios area, but i get very strange results for the height, they seem not to match at all :/
@tomcat, your version gives the sames modes for my GT105M that "secrets.com" gives, plus lot of "4096 width" modes which i clearly do not have :D On the fly, i can't (or won't :) spot the difference, so what are you doing differently?
@tomcat, your version gives the sames modes for my GT105M that "secrets.com" gives, plus lot of "4096 width" modes which i clearly do not have :D On the fly, i can't (or won't :) spot the difference, so what are you doing differently?
@tomcat, and more importantly, how does the patched dragon look on your system? =)
@tomcat (i forgot, the @F in your code should be @@ right?)
4096 could be 1024 in 32 bit modes... @F means the next forward local label (@@:) My test works on integrated intel gfx also, but completly different results.
@tomcat, i thought the same, one of the modes of the GT105M which i suspect to be true color because of the "blue-only palette" is reported with width 1360 by both your and my version. Between 0x4B and 0x4D (both 1360 width) there is 0x4C which is reported with 4096 by your version and might in fact be true color, the mode exists and can be set, but the patched dragon is in fact invisible there (setting pixels via bios doesnt work there). Anyway, it should report 5440 then ... seems there is still a bit of work to do right? Somewhere, somehow, the correct width/height/depth of the modes should be listable =)
Just for completeness : the source and the source of the -> source of "vesatest.com"
@HellMood here is the program, what you were searching for
nVidia
Intel
Code:
ORG 256
MOV DI,BP
search:
STOSW
PUSH AX
INT 10H
MOV AH,3
INT 10H
JCXZ @F
DEC DI
DEC DI
@@:
MOV AX,3
INT 10H
POP AX
INC AL
JNS search
MOV SI,BP
next:
LODSW
PUSH AX
XCHG CX,AX
MOV AX,4F01H
INT 10H
CMP AX,004FH
POP AX
JNE skip
AAM 16
ADD AX,'00'
MOV DL,AH
MOV AH,2
PUSH AX
INT 21H
POP DX
CMP DL,'9'
JNA @F
ADD DL,'A'-'9'-1
@@:
INT 21H
MOV DX,text1
MOV AH,9
INT 21H
MOV AX,[DI+12H]
CALL PrintNum
MOV DX,text2
MOV AH,9
INT 21H
MOV AX,[DI+14H]
CALL PrintNum
MOV DX,text3
MOV AH,9
INT 21H
MOV AL,[DI+19H]
CBW
CALL PrintNum
MOV DX,text4
MOV AH,9
INT 21H
MOV AX,[DI+10H]
CALL PrintNum
MOV DX,text5
MOV AH,9
INT 21H
skip:
CMP SI,DI
JNE next
RETN
PrintNum:
PUSHA
SUB CX,CX
.1:
SUB DX,DX
MOV BX,10
DIV BX
ADD DL,'0'
PUSH DX
INC CX
TEST AX,AX
JNZ .1
.2:
POP DX
MOV AH,2
INT 21H
LOOP .2
POPA
RETN
text1 DB 'H: $'
text2 DB 'x$'
text3 DB ' $'
text4 DB 'bit ($'
text5 DB ')',10,13,'$'
nVidia
Quote:
11H: 640x480 1bit (80)
12H: 640x480 4bit (80)
13H: 320x200 8bit (320)
21H: 640x480 32bit (2560)
22H: 800x600 32bit (3200)
3FH: 1024x768 32bit (4096)
4BH: 1280x720 8bit (1280)
4CH: 1280x720 16bit (2560)
4DH: 1280x720 32bit (5120)
5CH: 800x600 8bit (800)
5EH: 1024x768 8bit (1024)
5FH: 640x480 8bit (640)
6EH: 640x480 16bit (1280)
6FH: 800x600 16bit (1600)
72H: 1024x768 16bit (2048)
Intel
Quote:
30H: 640x480 8bit (640)
32H: 800x600 8bit (832)
34H: 1024x768 8bit (1024)
41H: 640x480 16bit (1280)
43H: 800x600 16bit (1600)
45H: 1024x768 16bit (2048)
50H: 640x480 32bit (2560)
52H: 800x600 32bit (3200)
54H: 1024x768 32bit (4096)
7DH: 1366x768 8bit (1408)
7EH: 1366x768 16bit (2752)
7FH: 1366x768 32bit (5504)
Quote:
@wbc: whatvga is nice! works like a charm under dosbox, with lots of features, but fails to work on freedos (runtime error 200
hah it's well known CRT bug, try TP7P5FIX or any other patcher :)
Here is the final version of my test code:
http://www.pouet.net/prod.php?which=81202
So the thing is,
generally you can set up the VESA video modes by short mode numbers.
is the same as
But the previous short code only works on PC with integrated intel gfx,
the second one works with intel, nvidia, dosbox and winxp as well.
http://www.pouet.net/prod.php?which=81202
So the thing is,
generally you can set up the VESA video modes by short mode numbers.
Code:
MOV AL,50H
INT 10H
is the same as
Code:
MOV BX,112H
MOV AX,4F02H
INT 10H
But the previous short code only works on PC with integrated intel gfx,
the second one works with intel, nvidia, dosbox and winxp as well.
@tomcat, great work. so the modes in question for the "blue-only" palette are in my case (GT105M)
From these, 0x4C is available, but setting pixels via BIOS does not work. But really more importantly, in mode 0x4D - in true color! - the BIOS pixel setting seems to address the blue channel! I have never heard of that behaviour, in fact i doubt that this should even be happening. Anyway there is now a VERY short way of doing true color effects in very high resolutions (once you know the mode number) and i really like that.
Now i'd like to establish that for every 256b (freedos) competition, THIS tool is run amongst others (like "whatreg" to show the starting values and "showme" to display the first 256b of the current segment) and the information made publically available before the compo (for example Function 2019)
@wbc, thanks again! that works, but the "vga mode test" shows weird results. if i run the "vesa tests" then it shows me (correctly) all the VESA modes, but without their "secret" number. well, since tomcat's final version display them, i'll just use both tools.
Can you "publish" the xmodes tool to the vorgons forums? i'll think that will be a nice addon to the toolkit =)
Code:
4Bh: 1360x768 8bit (1360) 14Bh
4Ch: 1360x768 16bit (2720) 14Ch
4Dh: 1360x768 32bit (5440) 14Dh
From these, 0x4C is available, but setting pixels via BIOS does not work. But really more importantly, in mode 0x4D - in true color! - the BIOS pixel setting seems to address the blue channel! I have never heard of that behaviour, in fact i doubt that this should even be happening. Anyway there is now a VERY short way of doing true color effects in very high resolutions (once you know the mode number) and i really like that.
Now i'd like to establish that for every 256b (freedos) competition, THIS tool is run amongst others (like "whatreg" to show the starting values and "showme" to display the first 256b of the current segment) and the information made publically available before the compo (for example Function 2019)
@wbc, thanks again! that works, but the "vga mode test" shows weird results. if i run the "vesa tests" then it shows me (correctly) all the VESA modes, but without their "secret" number. well, since tomcat's final version display them, i'll just use both tools.
Can you "publish" the xmodes tool to the vorgons forums? i'll think that will be a nice addon to the toolkit =)
Now i tested ALL true color modes for GT105M and GT1030. For the GT105M, ALL modes behaved like "256 shades of blue" modes, meaning, setting a pixel via BIOS puts that pixel into the blue plane. The GT1030 behaves differently though, writing a pixel via BIOS has the same intensity regardless of the value (so it's monochrome basically) and the color varies with the mode used, sometimes it's blue, sometimes it's green. So, no general "shades of blue" behaviour :|
Have you tried to write directly to the video memory? It should work.
I didn't make myself clear enough, i EXPLICITLY want to try the limits of using pixel setting via bios (AH = 0x0C, int 10h), since it's very short. It had been wonderful to get a blueish 256 colors palette for "free" with that trick, but apparently it only works on the GT105M ;)
I tested on Intel HD4000 and Nvidia GTX780, the results are consistent with the ones published here, so I guess one can assume a similar behaviour. Just with my old AMD Sempron Mobile onboard X300 laptop the tool doesn't output any result at all...anybody out there with AMD graphics to test ?
@Kuemmel, perhaps the information retrieval with VESA does not work? The card should be new enough to support VESA though ... What does secrets tell you?
I still have to test stuff on two further old notebooks at home. Will keep you all updated =)
I still have to test stuff on two further old notebooks at home. Will keep you all updated =)
Secrets seems to do something at first and then crashes, black screen of death on that AMD laptop...okay it's more than 15 years old and not quite common...
hacked XMODES a bit :) shaved 5 bytes then added debug features (PC speaker squeaking and displaying current testing mode number on POST card :)
and what it gives for my PIII/DOS machine' GeForce FX5500:
so, apparently NVidia keeps mode numbers constant through GPU families, so using these modes are safe on them.
unfortunately, it seem to output nothing on S3 Trio3D/2X (i assume video BIOS doesn't support VESA mode info extraction for those modes); secrets seems to test for a couple of minutes then hangs :(
and what it gives for my PIII/DOS machine' GeForce FX5500:
Code:
4h: 320x200 2bit (80)
5h: 320x200 2bit (80)
6h: 640x200 1bit (80)
Dh: 320x200 4bit (40)
Eh: 640x200 4bit (80)
Fh: 640x350 1bit (80)
10h: 640x350 4bit (80)
13h: 320x200 8bit (320)
20h: 320x200 32bit (1280) 10Fh
21h: 640x480 32bit (2560) 112h
22h: 800x600 32bit (3200) 115h
30h: 320x200 8bit (320) 130h
31h: 320x400 8bit (320) 131h
32h: 320x400 16bit (640) 132h
33h: 320x400 32bit (1280) 133h
34h: 320x240 8bit (320) 134h
35h: 320x240 16bit (640) 135h
36h: 320x240 32bit (1280) 136h
3Dh: 640x400 16bit (1280) 13Dh
3Eh: 640x400 32bit (2560) 13Eh
3Fh: 1024x768 32bit (4096) 118h
44h: 1280x1024 16bit (2560) 11Ah
45h: 1600x1200 8bit (1600) 145h
46h: 1600x1200 16bit (3200) 146h
47h: 1400x1050 8bit (1400) 147h
48h: 1400x1050 16bit (2800) 148h
58h: 800x600 4bit (100) 102h
5Ah: 1280x1024 4bit (160) 106h
5Bh: 640x400 8bit (640) 100h
5Ch: 800x600 8bit (800) 103h
5Dh: 1024x768 4bit (128) 104h
5Eh: 1024x768 8bit (1024) 105h
5Fh: 640x480 8bit (640) 101h
6Ah: 800x600 4bit (100) 102h
6Bh: 1280x1024 8bit (1280) 107h
6Eh: 640x480 16bit (1280) 111h
6Fh: 800x600 16bit (1600) 114h
72h: 1024x768 16bit (2048) 117h
78h: 320x200 16bit (640) 10Eh
79h: 1280x1024 32bit (5120) 11Bh
7Ah: 2048x1536 32bit (8192) 152h
so, apparently NVidia keeps mode numbers constant through GPU families, so using these modes are safe on them.
unfortunately, it seem to output nothing on S3 Trio3D/2X (i assume video BIOS doesn't support VESA mode info extraction for those modes); secrets seems to test for a couple of minutes then hangs :(
FreeDOS on my GTX 1080 with a 1920x1200 monitor gives:
So the overlaps agree, but there are a lot fewer of them (and then the 1920x1200 ones and a few more on top).
Code:
11h: 640x480 1bit (80)
12h: 640x480 4bit (80)
13h: 320x200 8bit (320)
21h: 640x480 32bit (2560) 112h
22h: 800x600 32bit (3200) 115h
3Fh: 1024x768 32bit (4096) 118h
44h: 1280x1024 16bit (2560) 11Ah
45h: 1600x1200 8bit (1600) 145h
46h: 1600x1200 16bit (3200) 146h
4Ah: 1600x1200 32bit (6400) 14Ah
4Bh: 1920x1200 8bit (1920) 14Bh
4Ch: 1920x1200 16bit (3840) 14Ch
4Dh: 1920x1200 32bit (7680) 14Dh
5Ch: 800x600 8bit (800) 103h
5Eh: 1024x768 8bit (1024) 105h
5Fh: 640x480 8bit (640) 101h
6Bh: 1280x1024 8bit (1280) 107h
6Eh: 640x480 16bit (1280) 111h
6Fh: 800x600 16bit (1600) 114h
72h: 1024x768 16bit (2048) 117h
79h: 1280x1024 32bit (5120) 11Bh
So the overlaps agree, but there are a lot fewer of them (and then the 1920x1200 ones and a few more on top).
New XMODES version is out :-)
Result for AMD Radeon R5 M430
Result for ATI RADEON 9600 PRO
Result for AMD Radeon R5 M430
Code:
10h: ?
11h: ?
12h: ?
13h: ?
30h: 640x480 8bit (640) 101h
32h: 800x600 8bit (832) 103h
34h: 1024x768 8bit (1024) 105h
38h: 1280x1024 8bit (1280) 107h
41h: 640x480 16bit (1280) 111h
43h: 800x600 16bit (1600) 114h
45h: 1024x768 16bit (2048) 117h
49h: 1280x1024 16bit (2560) 11Ah
50h: 640x480 32bit (2560) 112h
52h: 800x600 32bit (3200) 115h
54h: 1024x768 32bit (4096) 118h
58h: 1280x1024 32bit (5120) 11Bh
7Dh: 1920x1080 8bit (1920) 17Dh
7Eh: 1920x1080 16bit (3840) 17Eh
7Fh: 1920x1080 32bit (7680) 17Fh
Result for ATI RADEON 9600 PRO
Code:
10h: ?
11h: ?
12h: ?
13h: ?
2Fh: ?
30h: ?
31h: ?
34h: ?
36h: ?
3Bh: ?
3Ch: ?
3Dh: ?
3Eh: ?
3Fh: ?
40h: ?
41h: ?
42h: ?
43h: ?
44h: ?
46h: ?
4Bh: ?
4Ch: ?
4Dh: ?
4Eh: ?
50h: ?
51h: ?
52h: ?
53h: ?
54h: ?
55h: ?
56h: ?
5Bh: ?
5Ch: ?
5Dh: ?
5Eh: ?
60h: ?
61h: ?
62h: ?
63h: ?
64h: ?
65h: ?
66h: ?
6Ah: 800x600 4bit (100) 6Ah
6Bh: ?
6Ch: ?
6Dh: ?
6Eh: ?
70h: ?
71h: ?
72h: ?
73h: ?
74h: ?
76h: ?
7Ah: ?
7Bh: ?
7Ch: ?
7Dh: ?
7Eh: ?
BTW these secret short codes are rather useless.
If I set up a hires mode with this short code, then the bank switching doesn't work.
(unless the video mode was set up by the vesa function before...)
If I set up a hires mode with this short code, then the bank switching doesn't work.
(unless the video mode was set up by the vesa function before...)
so wait, i'm confused... this is about invalid modes or...?
@Tomcat thanks for putting the effort into it! =) A pity if bankswitching does not work, but as long as setting pixels with "int 0x10, ah=0x0c" works that is some very compact setup for doing (still) hires in extreme tiny intro :)
@Parzival, these modes are legal, it's just a shorter - hardware dependent - way to set them up. Unless you are really desperate for free bytes you should always go for the "standard" (VESA) way of setting hi res graphic modes.
@Parzival, these modes are legal, it's just a shorter - hardware dependent - way to set them up. Unless you are really desperate for free bytes you should always go for the "standard" (VESA) way of setting hi res graphic modes.