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:
| MDA | CGA | EGA | MCGA | VGA |
---|
Mode 0/1 | n/a | 320x200 | 320x350 | 320x400 | 360x400 |
---|
Mode 2/3 | n/a | 640x200 | 640x350 | 640x400 | 720x400 |
---|
Mode 7 | 720x350 | n/a | 720x350 | n/a | 720x400 |
---|
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.