In normal circumstances (pure DOS and video BIOS determined resolutions), nothing changes at all as far as video signal itself goes and the monitor cannot tell a difference. Your case sounds like a bad custom resolution type thing since the 640x400@70Hz is supposed to be a 31kHz resolution but the timings used are definitely not matching that of what a video BIOS for VGA would use. I am unsure how one would go about changing timings for this particular resolution+refresh rate combo.

CRU maybe? does need vista and later though...

otherwise if you are on nvidia, i would look if there is a driver that has the custom resolution menu.

mgtroyas wrote on 2025-04-03, 11:08:

If I understand it correctly, when a PC requests the 320x200 video mode, the VGA card double-scans and extends the image to 640x400 resolution.

When a PC is set to the good old VGA 320x200 256c Mode 13h video mode, the VGA adapter will double-scan it to generate a video mode of 320x400, not 640x400.

However, because VGA signal does not carry a pixel clock signal line, there is no physical distinction between a video signal of 320x400 vs 640x400, so one can talk about this 320x400 video mode as if it was 640x400. If you deal with the Feature Connector (like e.g. CRT Terminator does), then you would see that pixel clock is actually for 320x400.

mgtroyas wrote on 2025-04-03, 11:08:

I have a CRT that doesn't like the 640x400@70Hz video mode I'm trying to use to run DOSBox on Windows XP, it says it's 29,2kHZ

This is a little bit weird, since the hsync rate should be 31.5 kHz for all of 320x200@70Hz and 640x400@70Hz and 640x480@60Hz. It is a little bit surprising to see that a hsync rate of 29.2 kHz is being generated. Something is configured a bit off here in the driver. It could be e.g. a VGA border present vs absent thing, or something like that.

mgtroyas wrote on 2025-04-03, 11:08:

it displays 320x200@70Hz without problem saying it's 720x400@70Hz and 31kHZ.

This is a slight bug of the CRT. It should not be saying 720x400 about the 320x200 video mode. It has misinterpreted the video mode horizontal resolution. Although given that it is an analog CRT, it does not matter what it states as the horizontal resolution.

Hi, thank you all for the quick responses.

I know it sounds strange but the video mode calculator indeed gives a horizontal frequency under 30kHz, and I've used that calculator to create many custom resolutions. It roughly matches the 29,1kHZ-29,2kHZ that appears on the OSD.

Wen I was using my Philips 109B6 seems it wasn't so strict with the lower limit, as that mode worked. But now I switched to a SyncMaster 957MB and found this problem.

Indeed it's not a bad custom resolution because on the Catalyst drivers, when using VGA output, you cannot define detailed custom resolutions, only add non-existent standard ones via width, height and refresh rate.

In fact 640x480@60Hz is also under 30kHz, but is slightly higher and the SyncMaster seems to accept it. Probably the designers had it in account but not the other.

And yes i know, Nvidia drivers allowed me to define custom resolutions easily (I have a GTX 750Ti), CRU doesn't work on XP, AMD Custom Timing Tool works on DVI output but not on VGA, I'm in the worse scenario to define advanced custom resolutions but for now I only try to understand the situation: why the double-scaled INT 13h mode is detected by the monitor and indeed correctly labeled, but the explicit 640x400@70Hz isn't...

Edit: I realize now, on the "int13h" capture the 31kHz means the card is setting the video mode using DMT standard, as in the 640x480 calculator screenshot we can see +2kHz of difference in DMT from CVT. But in the last capture the 29.2kHz denotes is not using DMT, but something more near to CVT, because perhaps that mode doesn't exist on DMT as it's weird the fields are empty on the DMT column on the capture of the 640x400 video mode calculator.

mgtroyas wrote on 2025-04-03, 20:44:

the video mode calculator indeed gives a horizontal frequency under 30kHz

That explains why you are getting the < 30 kHz result. The video mode calculator computes standard DMT/CEA/CVT video mode timings, but the Mode 13h 320x200 timings are from pre-standardization era. The first standardized mode was VGA 640x480 60Hz (which is 31.5 kHz).

The parameters that are missing are the VGA overscan border.

Try these parameters for a 31.5 kHz 640x400 70 Hz video mode:

Horizontal polarity: -
Horizontal front porch: 12 clocks (pixels)
Horizontal sync: 96 clocks
Horizontal back porch: 36 clocks
Horizontal left overscan border: 28 clocks
Horizontal visible: 600 clocks
Horizontal right overscan border: 28 clocks
-> Horizontal active = 28+600+28 = 656 clocks
-> Horizontal total = 12+96+36+28+600+28 = 800 clocks

Vertical polarity: -
Vertical front porch: 6 lines
Vertical sync: 2 lines
Vertical back porch: 27 lines
Vertical top overscan border: 7 lines
Vertical visible: 400 lines
Vertical bottom overscan border: 7 lines
-> Vertical active = 7+400+7 = 414 lines
-> Vertical total = 6+2+27+7+400+7 = 449 lines

Pixel clock: 25.2 MHz
-> Hsync rate = 25.2 MHz / 800 = 31.5 kHz
-> Vsync rate = 31.5 kHz / 449 = 70.15 Hz

This is the timings geometry from the 320x200 video mode, except with pixel clock and horizontal clocks doubled.

Ok... you nailed it... let's begin saying that fortunately I was wrong, AMD Custom Timing Tool, the FirePro oriented tool that happens to work with Radeon cards, does indeed work also on VGA output. I wasn't able to save custom video modes because they weren't allowed, as I experienced months ago when using DVI... but now I know why they weren't allowed and I had to edit them manually on the registry... because they were under 30kHz. Nobody likes poor modes under 30kHz, although the Philips CRTs cope with them.

So when I realized I was again able to create custom modes, I decided to try the values you gave me... and they worked! In fact so well they were detected natively as "720x400@70Hz" exactly as you expected. The problem now was... the active area is, as you state, 656x414 pixels, the image Windows sends is 640x400, but it doesn't draw the overscan borders, instead the image is stretched to fill and so looks blurred.

So I manually edited the registry values (see detail on my linked post), first just active area back to 640x400 and... it worked! Now the image is pixel perfect. Yes, it's not centered, I needed to compensate adding a little H and V front porch... and it also worked. So can oneself play with these values at wish? Standard video modes are that, standards, but any modified video modes are also accepted by monitors? Where's the limit?

Anyway, being a complete smooth scrolling snob, I detected a slight hiccups each 7 seconds or so. Mmmm I don't really like that 70.15Hz refresh rate you got in your example. So I did a quick google search and entered this site and it states:

Their line frequency is exactly twice that of the NTSC television system, or almost twice that of the PAL television system. Thi […]
Show full quote

Their line frequency is exactly twice that of the NTSC television system, or almost twice that of the PAL television system. This makes it fairly easy to implement a VGA input on a television set that uses line doubling for the television signals so the line deflection already runs on 31 kHz.
"640 x 400 VGA text"
Clock frequency 25.175 MHz
Line frequency 31469 Hz
Field frequency 70.086 Hz

Mmm that could be? Sounds legit. So I just changed clock frequency from 25.2 MHz to 25.175 MHz, rebooted, went straight to the Prehistorik 2 Hybrid cracktro smooth scrolling text I loved so much back in the day on my 286 and... no hiccups anymore! (at least I couldn't detect them, lets hope I don't see them tomorrow morning!).

So this has been an interesting rabbit hole, I've learned more about how video modes work than I suspected. I'll share my registry entry so people in the future in my situation (me included when I forget) can apply them.

Have in mind it's saved in hexadecimal but Little-Endian. The non-zero values meaning:

180 02 -> 280H -> 640 = Horizontal resolution in name
290 01 -> 190H -> 400 = Vertical resolution in name
346 -> 70 = Refresh rate in name
403 = no idea
502 = no idea
620 03 -> 320H -> 800 = H Total
780 02 -> 280H -> 640 = H Active
810 -> 16 = H Front Porch (can be changed)
960 -> 96 = H Sync
10C1 01 -> 1C1H -> 449 = V Total
1190 01 -> 190H -> 400 = V Active
120D -> 13 = V Front Porch (can be changed)
1302 = V Sync
1457 62 -> 6257H -> 25175 = Clock Frequency (kHz) 
1503 = no idea
1602 = no idea
1701 = no idea
1880 -> 128 = no idea

mgtroyas wrote on 2025-04-04, 22:15:

So can oneself play with these values at wish? Standard video modes are that, standards, but any modified video modes are also accepted by monitors? Where's the limit?

Yes, these values can all be modified. Old CRTs mainly had the following limits:
- limit on hsync kHz rate (must be between X and Y kHz, see if you can find the CRT manual)
- limit on vsync Hz rate (between X and Y Hz)
- hsync and vsync duration must be > a certain number of clock cycles/scanlines (never publicized anywhere. If you try too short sync timings, like one clock of hsync, the CRT might not be able to properly sync to next scanline)

From the description you give, there are two effects that read like high level emulation/compatibility behavior that the "modern" AMD adapter is doing:

mgtroyas wrote on 2025-04-04, 22:15:

the active area is, as you state, 656x414 pixels, the image Windows sends is 640x400, but it doesn't draw the overscan borders, instead the image is stretched to fill and so looks blurred.
being a complete smooth scrolling snob, I detected a slight hiccups each 7 seconds or so.
I just changed clock frequency from 25.2 MHz to 25.175 MHz, rebooted, [...] and... no hiccups anymore!

These suggest that the adapter is doing some kind of higher level video mode mapping/translation. If one operated in DOS and programmed the current resolution for the adapter, these behaviors wouldn't be able to occur when using a CRT. Great to hear that you got it to work.

mgtroyas wrote on 2025-04-04, 22:15:

Yes, it's not centered, I needed to compensate adding a little H and V front porch... and it also worked. So can oneself play with these values at wish?

If you add to the front porch values, try taking away an equal amount from the back porch values to keep the total clock/scanline counts the same. That way the total hsync/vsync frame timings won't be disrupted.

You can also try adjusting the VGA overscan/border clock/scanline counts balance, left/right top/down to center the image.

I wrote a description of the video signal format at https://oummg.com/manual/#video_frame_anatomy that uses the DOS 320x200 @ 70 Hz video mode timings as an example. Maybe that can be helpful here.

Thank you very much, the video frame explanation is very clear written, it would have been very useful when I started reading about it.

Yes, the ATI card is clearly doing some "GPU scaling". Perhaps the drivers (or Windows) expect a standard video mode and if the custom active timing is not one of them then it stretches the image from the nearest one.

I've done some tests using Quake from DOS as from console it allows to switch to multiple resolutions via command "vid_mode", and the "bf" command flashes all the screen, including the offset if available. There are basically two groups of video modes: the standard 320x200 VGA plus the unchained Mode-X ones (320x240, 360x480, etc), all of them have an offset and changes color, and the VESA modes (320x240, 640x400, 640x480 and above), none of them have offset defined and so no one shows border color effect.

Windows is surely using VESA video modes, not any Mode-X, that's why the borders are nowhere to be seen. DOSBox should a) allow outputting in 320x200 and similar resolutions using the appropiate BIOS calls (probably not supported by SDL) and b) should also bypass the offset color changes from the game to the BIOS or whatever NTVDM does with DOS executables. This could have been a good idea on XP times, but probably since Vista it hasn't been possible anymore so probably that's something is not going to happen.

Regarding centering the image, the ATI custom video mode format only accepts Front Porch and Sync as parameters, as it also knows active and total image size, it deducts Back Porch. On my 640x400 custom video mode, selecting "0" Front Porch sticks the image to the right border of the monitor, and value of 32 sticks it to the left border. But Front+Back Porch = 64 (160 Blank minus 96 Sync) so I'm not finding the logic, I'd have to test more video modes and see.

Another config for 640 x 400 70kHz:

"640 x 400 VGA text" Clock frequency 25.175 MHz Line frequency 31469 Hz Field frequency 70.086 Hz […]
Show full quote

"640 x 400 VGA text"
Clock frequency 25.175 MHz
Line frequency 31469 Hz
Field frequency 70.086 Hz

One line:
8 pixels front porch
96 pixels horizontal sync
40 pixels back porch
8 pixels left border
640 pixels video
8 pixels right border
---
800 pixels total per line

One field:
5 lines front porch
2 lines vertical sync
28 lines back porch
7 lines top border
400 lines video
7 lines bottom border
---
449 lines total per field

Sync polarity: H negative,
V positive
Scan type: non interlaced.

http://martin.hinner.info/vga/timing.html

Of couse SyncMaster will show any 320x200 (640x400) as custom or as "known 720x400" preset

Mov AX, 0xDEAD wrote on 2025-04-06, 15:11:

Another config for 640 x 400 70kHz:

Hello, thank you, but we've tried this some posts above, seems the concept of border has sense on traditional VGA video modes but on Windows (VESA?) it doesn't exist anymore, if the active area is bigger than expected the videocard just stretches the image to fill it, so I had to rework the timings to have the right active area, right refresh rate, etc.