VGA Non-standard Resolutions Corrections

Post suggestions, correct errors or omissions, or anything else about the site
Great Hierophant
Less than a nibble
Posts: 9
Joined: February 10th, 2014, 8:49 am

Re: VGA Non-standard Resolutions Corrections

Post by Great Hierophant »

DOSGuy wrote:
Great Hierophant wrote:You may want to mention the PCjr./Tandy 1000 Modes 08h, 09h and 0Ah.
Good call. I wasn't going to mention the Tandy modes because they don't come from IBM (though the Tandy 1000 was otherwise PC-compatible), but those modes were actually introduced with the PCjr, which is indeed an IBM standard. The PCjr supported all CGA modes, but the PCjr modes are unique because none of them were supported by later IBM standards. Nevertheless, here they are:

08h = 160x200x16c
09h = 320x200x16c
0Ah = 640x200x4c

The Tandy 1000 supported all of these modes, as well as the CGA text modes (00h through 03h). Ironically, the Tandy 1000 supported these modes in order to compete with the PCjr, but it outlasted the PCjr by so many years that most of the games to ever use these modes were created for Tandy, so they're usually known as "TGA" or Tandy graphics modes!
Ironically, the Tandy is virtually 100% compatible with CGA on the hardware level and the PCjr. is, ironically almost as incompatible in hardware.

Pinball Fantasies has the same forced stretching as Extreme Pinball with a different resolution. Cut the horizontal resolution in half and it looks almost identical to the 320x240. Actually, the 320x240 resolution looks cropped on the sides compared to the 360x350 resolution
Malvineous
8-bit mega nerd
Posts: 292
Joined: March 17th, 2007, 6:40 pm
Location: Brisbane, Australia
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by Malvineous »

Wow this is a really interesting thread! Especially about Magic Pockets, having played this game for years and assuming it was only ever VGA capable.
DOSGuy wrote:followed by MOV AX,1000 and MOV BX,000D before another INT 10h. x86 is little endian (the least significant byte goes first), so this means that AL=10h and AH=00h when INT 10h is called.
Actually you have those values backwards! The little endian byte order only affects numbers that are stored as bytes, so if AX=1234 then AH=12 and AL=34. If you were to look at the machine code (raw bytes) for a "MOV AX,1234" instruction you would see the bytes "34 12" because that's where the swap occurs. Once the numbers are presented in assembly code, the swap has already been done for you.

You might find it a bit easier to set a breakpoint on interrupt 10h however, and then run the game, and it will stop every time int 10h is called. Then you can just examine the registers and either get your answer, or continue if it's not setting the video mode and DOSBox will stop the next time int 10h is called.
DOSGuy wrote:I was also hoping that I might find some useful information at memory address 000A:0000, but all I ever find there is 40h ("@") and a bunch of nothing. Okay, so I'm not good enough with a debugger to figure this out. Does anyone know what to do here?
What were you looking for here? 000A * 16 = absolute memory address A0h, which is in the interrupt vector table, so divide by 4 to get 28h, so what you are looking at at this address is the location of the handler for interrupt 28h. The "bunch of nothing" is probably because many interrupts around this number are not used.

Alternatively if you want the location of interrupt 10h, multiply it by 4 to get 40h and then look at 0000:0040 to find the segment and offset of the handler. For me it says "20 13 00 F0" and because we're looking at bytes now, we *do* have to swap them, so the hander is at F000:1320. If you look at this in the code view ("C F000:1320") the first instruction even tells you it's the DOSBox callback handler for "Int 10 Video". For some reason you can't put a breakpoint here (probably DOSBox optimisation) but you can use "BPINT 10" to break into the debugger whenever int 10h is called.

However I have just noticed when confirming this works, that if you look at the message list in the debugger it will display a note like this whenever the video mode is changed:

Code: Select all

755315839: INT10:Set Video Mode D
755315839: VGA:Blinking 0
755315866: INT10:Set Video Mode 3
755315866: VGA:Blinking 8
755777706: VGA:h total 100 end 80 blank (80/98) retrace (85/97)
755777706: VGA:v total 449 end 400 blank (407/442) retrace (412/414)
755777706: VGA:h total 0.03178 (31.47kHz) blank(0.02542/0.03114) retrace(0.02701/0.03082)
755777706: VGA:v total 14.26806 (70.09Hz) blank(12.93341/14.04562) retrace(13.09230/13.15585)
767609659: INT10:Set Video Mode D
767609659: VGA:Blinking 0
I'm not 100% sure of the calculations to get the video mode from the VGA line counts (mode 3 is 720x400x16 I believe, so not sure how to calculate the 720 pixels across) but it certainly seems to give you plenty of info!
User avatar
DOSGuy
Website Administrator
Posts: 1063
Joined: September 2nd, 2005, 8:28 pm
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by DOSGuy »

Malvineous wrote:
DOSGuy wrote:followed by MOV AX,1000 and MOV BX,000D before another INT 10h. x86 is little endian (the least significant byte goes first), so this means that AL=10h and AH=00h when INT 10h is called.
Actually you have those values backwards! The little endian byte order only affects numbers that are stored as bytes, so if AX=1234 then AH=12 and AL=34. If you were to look at the machine code (raw bytes) for a "MOV AX,1234" instruction you would see the bytes "34 12" because that's where the swap occurs. Once the numbers are presented in assembly code, the swap has already been done for you.
Are you sure? It doesn't seem to make sense for AH to be 10h and AL to be 00h when INT 10h is called because, according to Wikipedia, there is no function associated with AH=10h. It works as a call to set the video mode to 10h if AH=00h and AL=10h, even though it doesn't make sense for EGA's 640x350x16c mode to be called by a 320x200x16c mode.
Malvineous wrote:
DOSGuy wrote:I was also hoping that I might find some useful information at memory address 000A:0000, but all I ever find there is 40h ("@") and a bunch of nothing. Okay, so I'm not good enough with a debugger to figure this out. Does anyone know what to do here?
What were you looking for here?
That was just a blunder on my part: I was trying to find the front of the video buffer at 0xA0000, but I forgot that Real Mode only accesses 1 MB of RAM and I needed to offset to A000:0000. That's really cool that you found DOSBox's implementation of INT 10 in the BIOS area, though!
Thank you for the breakpoint advice! I'm going to try that out.
Today entirely the maniac there is no excuse with the article.
User avatar
DOSGuy
Website Administrator
Posts: 1063
Joined: September 2nd, 2005, 8:28 pm
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by DOSGuy »

In a previous post I had mentioned that VGA handled all of the new modes introduced with MCGA -- in addition to adding Mode 12h -- suggesting that VGA is basically comparable to MCGA. Well, according to the list I previously linked to, there is a difference: the number of pixels per character in text mode. The list on Columbia University's website claims the following character dimensions:

MDA: 9x14
CGA: 8x8
EGA: 8x14 in CGA modes, 9x14 in MDA mode
MCGA: 8x16
VGA: 9x16

This creates an effective resolution of:
MDACGAEGAMCGAVGA
Mode 0/1n/a320x200320x350320x400360x400
Mode 2/3n/a640x200640x350640x400720x400
Mode 7720x350n/a720x350n/a720x400
I had, up until now, classified text mode games as one of three types: 40x25 color, 80x25 color, and 80x25 mono. I just finished analysing the screenshots DOSBox took of all of those games, presumably set to the default of svga_s3. All of the screenshots are 640x400. I counted the pixels in the 80x25 screenshots and the characters are 8x16, matching the 640x400 resolution of the screenshot without any stretching. The odd thing about that is that the 640x400 effective resolution was unique to MCGA! The 40x25 screenshots are 16x16, but they are horizontally doubled and look correct when skewed back to 8x16, giving an effective resolution of 320x400... again, an effective resolution unique to MCGA. DOSBox seems to use 8x16 characters in SVGA modes, outputting an image equivalent to MCGA, the only IBM graphics standard not emulated by DOSBox (other than 8514)! I assume that's the correct behavior, but it seems ironic.

<edit>Correction, DOSBox doesn't emulate MDA either.</edit>

I just ran DND in each video mode. As a cga machine it produced a 640x400 screenshot (vertically doubled from 640x200), as an ega machine the screenshot was 640x350, and under vgaonly the screenshot was 720x400, so each mode is using the correct number of pixels per character. Now I'm curious why the S3 Trio uses 8x16 pixel characters when running in CGA modes instead of the higher quality 9x16 pixel characters from VGA.

This proves that DND is using either Mode 02h or 03h, which is interesting because, despite the availability of 16 colors, DND is a monochrome game. I guess Mode 07h was a poor choice for programmers because it wasn't supported by CGA and MCGA, whereas Mode 02h/03h were supported by everything except for MDA.

Okay! So I tried out "bpint 10" in the debugger, and that interrupt gets called A LOT, so it works better to use "bpint 10 00" (only break if AH=00) if you want to be able to actually play the game. I just tried this with Castle Adventure and it initially set Mode 03h, but then switched to Mode 02h before displaying the (shareware) notice, presumably because the game is monochrome and Mode 02h would be better for monochrome monitors. It then switches to Mode 00h when the game begins, since the game is in 40x25 mode, and returns to Mode 03h on exit. Tetris starts in Mode 3h for the title and setup screens before switching to Mode 1h in-game. DND checks the video mode and, if Mode 03h, doesn't change the video mode. For some reason, it checks the video mode before every user input, so things will really slow down if you have "bpint 10 0f" set. DOSBox enters Mode 03h by default (it's listed in the output at "0: INT10:Set Video Mode 3"), so if the game doesn't call INT 10 with AH=00, the game can be assumed to be Mode 03h.

So, getting back to Great Hierophant...
DOSGuy wrote:Magic Pockets have five video options: EGA, Colour VGA, Mono VGA, Four Colour CGA, Tandy 16 colour.

...

There are a lot of games that offer "Mono VGA" as an option, which would normally refer to Mode 11h (640x480xmono) ... Magic Pocket's "Mono VGA" option, in fact, displays 16 shades of gray. The EGA palette of 64 colors doesn't have 16 shades of gray, whereas VGA can select up to 256 colors to be chosen from a palette of 262,144 colors. So it must be Mode 13h, right? Not so fast! VGA can also use any of the colors from that 262,144 color palette in the CGA and EGA modes, so I also tested that video mode in CGA and EGA. Nothing happens with DOSBox set to cga, but it runs under ega with 8 of the CGA colors! Could this actually be VGA Mode 0Dh?

The "Colour VGA" mode is indeed 320x200x16c under svga_s3, not 640x400x16c as it appears when using vgaonly. ... So it must be a lazy port to Mode 13h, right? Even though the colors are different from the "EGA" mode, it could still actually be Mode 0Dh using the VGA pallette, so I also tested that video mode in CGA and EGA. Nothing happens in DOSBox set to cga, but it runs in ega with 8 of the CGA colors, looking identical to "Mono VGA"! Could both VGA modes actually be Mode 0Dh?
So, now it's confirmed using the DOSBox debugger. Both "Colour VGA" and "Mono VGA" are Mode 0Dh using the VGA palette!

"Four Colour CGA" is confirmed by the debugger to be Mode 04h and "Tandy 16 colour" is confirmed to be Mode 09h. Now here's where it gets weird. My earlier discovery has now been confirmed by breakpoint: when you use the "EGA" option, INT 10 sets the video mode to 10h (640x350) despite the game outputting at 320x200! I can see it in the AL register, and it's listed in the output.
DOSBox Debugger wrote:80456840: INT10:Set Video Mode 10
80456840: VGA:Blinking 0
80517678: FILES:file open command 0 file data\new.pip
80538300: VGA:h total 114 end 40 blank (45/87) retrace (48/52)
80538300: VGA:v total 262 end 200 blank (225/273) retrace (225/228)
80538300: VGA:h total 0.06370 (15.70kHz) blank(0.02514/0.04681) retrace(0.02682/0.02905)
80538300: VGA:v total 16.68816 (59.92Hz) blank(14.33143/17.38881) retrace(14.33143/14.52252)
80538300: VGA:Width 320, Height 200, fps 59.922727
80538300: VGA:double width, double height aspect 1.411765
What's going on here? DOSBox is set to an ega machine, but Mode 10h is being set to 320x200. The only common resolution I can find with an aspect ratio of 1.411765 is 1440x1020. That shrinks to 720x510 or 360x255, neither of which apply to this situation. (My monitor is set to 1920x1080 if that has any relevance.)

This has been a fun voyage of discovery! Thank you to Great Hierophant for starting this topic, and to Malvineous for showing me how to figure this out!
Today entirely the maniac there is no excuse with the article.
Malvineous
8-bit mega nerd
Posts: 292
Joined: March 17th, 2007, 6:40 pm
Location: Brisbane, Australia
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by Malvineous »

DOSGuy wrote:
Malvineous wrote: Actually you have those values backwards! The little endian byte order only affects numbers that are stored as bytes, so if AX=1234 then AH=12 and AL=34. If you were to look at the machine code (raw bytes) for a "MOV AX,1234" instruction you would see the bytes "34 12" because that's where the swap occurs. Once the numbers are presented in assembly code, the swap has already been done for you.
Are you sure? It doesn't seem to make sense for AH to be 10h and AL to be 00h when INT 10h is called because, according to Wikipedia, there is no function associated with AH=10h. It works as a call to set the video mode to 10h if AH=00h and AL=10h, even though it doesn't make sense for EGA's 640x350x16c mode to be called by a 320x200x16c mode.
Here's a perfect test, if you have debug.exe available from MS-DOS:

Code: Select all

C:\>debug
-a
xxxx:0100 mov ah,11
xxxx:0102 mov al,22
xxxx:0104
-g=100 104

AX=1122 ...
As to why INT 10h is being called with an invalid value, it could be just a bug. When I was reverse engineering OPL3/FM music, it was very surprising how many games would do invalid things. It became very clear to me that a lot of programmers didn't really understand the hardware and were just going from guides or other code, and as long as it didn't cause problems, it was left in!

However, in this case, it looks like INT 10h, AH=10h, actually performs a number of different functions...if you look at the right list ;-)
User avatar
DOSGuy
Website Administrator
Posts: 1063
Joined: September 2nd, 2005, 8:28 pm
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by DOSGuy »

"SET INDIVIDUAL DAC REGISTER (VGA/MCGA)"

Interesting. But at any rate, it's been confirmed that Magic Pockets does indeed set the Video mode to 10h when run in "EGA" mode. The big question is why a 640x350 mode is outputting at 320x200.
Today entirely the maniac there is no excuse with the article.
Malvineous
8-bit mega nerd
Posts: 292
Joined: March 17th, 2007, 6:40 pm
Location: Brisbane, Australia
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by Malvineous »

Well, using debug again, I did this:

Code: Select all

-a
xxxx:0100 mov ax,0010
xxxx:0103 int 10
xxxx:0105 int 20
xxxx:0107
-g
Program terminated normally
-
And DOSBox said this in the debug window:

Code: Select all

2388224254: INT10:Set Video Mode 10
2388224254: VGA:Blinking 0
2390715496: VGA:h total 100 end 80 blank (80/98) retrace (84/96)
2390715496: VGA:v total 449 end 350 blank (356/443) retrace (387/389)
2390715496: VGA:h total 0.03178 (31.47kHz) blank(0.02542/0.03114) retrace(0.0266
9/0.03051)
2390715496: VGA:v total 14.26806 (70.09Hz) blank(11.31281/14.07746) retrace(12.2
9791/12.36147)
2390715496: VGA:Width 640, Height 350, fps 70.086303
2390715496: VGA:normal width, normal height aspect 1.371429
So DOSBox is indeed setting the display to 640x350 when mode 10h is used (at least with machine=svga_s3).
User avatar
DOSGuy
Website Administrator
Posts: 1063
Joined: September 2nd, 2005, 8:28 pm
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by DOSGuy »

Malvineous wrote:So DOSBox is indeed setting the display to 640x350 when mode 10h is used (at least with machine=svga_s3).
I know that DOSBox outputs 640x350 in at least 51 games from the site, but in Magic Pockets it outputs at 320x200 when set as an "ega" machine, and 320x200, double width, normal height when set to "svga_s3" (thus the 640x200 screenshot on the Magic Pockets page), as seen below:
DOSBox Debugger wrote: 108739683: INT10:Set Video Mode 10
108739683: VGA:Blinking 0
108774575: FILES:file open command 0 file data\new.pip
108837007: VGA:h total 120 end 40 blank (45/87) retrace (48/52)
108837007: VGA:v total 262 end 200 blank (225/241) retrace (225/228)
108837007: VGA:h total 0.03813 (26.22kHz) blank(0.01430/0.02765) retrace(0.01525/0.0152)
108837007: VGA:v total 9.99086 (100.09Hz) blank(8.57994/9.19007) retrace(8.57994/8.69434)
108837007: VGA:Width 320, Height 200, fps 100.091444
108837007: VGA:double width, normal height aspect 2.903278
I've taken screenshots of every video mode (except Tandy) available in Magic Pockets' setup.exe, with DOSBox set to cga, ega, vgaonly, and svga_s3.
Four Colour CGAEGAColour VGAMono VGA
cga
cga_cga.png
ega
ega_cga.png
ega_ega.png
ega_vgacolor.png
ega_vgamono.png
vgaonly
vgaonly_cga.png
vgaonly_ega.png
vgaonly_vgacolor.png
vgaonly_vgamono.png
svga_s3
s3_cga.png
s3_ega.png
s3_vgacolor.png
s3_vgamono.png
Four Colour CGA (Mode 04h) displays at 320x200 in each machine type.
EGA (Mode 10h) displays at 320x200 in ega, and 620x200 (width doubled) in vgaonly and svga_s3, and appears to be using the VGA palette
Colour VGA (Mode 0Dh) displays at 320x200 in ega, 640x400 (h/w doubled) in vgaonly, and 320x200 in svga_s3
Mono VGA (Mode 0Dh) displays at 320x200 in ega, 640x400 (h/w doubled) in vgaonly, and 320x200 in svga_s3
You do not have the required permissions to view the files attached to this post.
Today entirely the maniac there is no excuse with the article.
Malvineous
8-bit mega nerd
Posts: 292
Joined: March 17th, 2007, 6:40 pm
Location: Brisbane, Australia
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by Malvineous »

In that case, I wonder whether Magic Pockets is setting mode 10h then altering the EGA registers directly to bring it back to 320x200? That's about the only way I can think it would be doing it.

I found an IBM EGA manual which includes a complete assembly listing of the EGA BIOS, so it wouldn't be that difficult (providing the hardware can do it) to figure out how INT 10h actually programs the chips on the EGA board and tweak them to get one mode's resolution with another mode's memory layout. This sort of thing happened a lot with the VGA, and I was surprised to find out that it was possible with the EGA too.

The only thing is that I would expect DOSBox to say it had set a 640x350 video mode, and then immediately afterwards say it had changed resolution to 320x200, so perhaps that theory isn't accurate.

Many EGA cards seem to support being connected to CGA monitors, so I wonder whether Magic Pockets is configuring the EGA as if it was connected to a CGA monitor? This would limit the maximum resolutions reachable, but it would also limit you to CGA's 16 colours (so no EGA palette available.)

Although the fact that all the EGA modes are 200 pixels high (whether shown on EGA or VGA) does make you think they are programming the card directly...

I guess the only way to know for sure is to start reverse engineering the Magic Pockets code around the INT10h call.
User avatar
DOSGuy
Website Administrator
Posts: 1063
Joined: September 2nd, 2005, 8:28 pm
Contact:

Re: VGA Non-standard Resolutions Corrections

Post by DOSGuy »

So, it turns out that Magic Pockets was never really using Mode 0Dh in the VGA modes. Before I started using the DOSBox Debugger to determine graphics modes, I labelled a huge number of games as VGA Mode 13h because they were 320x200x256c. When I run them in the DOSBox debugger, it turns out that many of them switch to Mode 0Dh, and DOSBox sometimes says that it has set a resolutions like 320x400 (height doubled), which Mode 0Dh doesn't support. The answer is "Mode X". The problem with Mode 13h is that it's slow. Switching to planar memory not only allowed for resolutions higher than 320x200, but also allowed for smoother graphics by allowing for double and triple buffering. Many games that required smooth animation used planar memory, even if they kept the resolution at Mode 13h's 320x200 (known as "Mode Y"). Some of the games currently listing as Mode 13h do use Mode 13h, but a lot of them actually set Mode 0Dh in the BIOS (perhaps because it's a 320x200 mode?) before switching to planar memory. Magic Pockets is actually using Mode Y in its Colour VGA and Mono VGA modes.
Today entirely the maniac there is no excuse with the article.
Post Reply