Try with fullresolution=original with scaler=none . Also turn off any scaling your graphics card may do.

The 70hz part seems to be working fine, or if it is forced into a 60hz refresh rate, I can't tell. If I use the opengl output with FRAPS it does go up to 70hz frame rate.

With scaler set to none I get a smaller window centered on the screen. The aspect ratio is also wrong.

What is interesting is that the dos prompt and the credits in pinball dreams are displayed differently. I don't know what to make of that. I am pretty sure the actual resolution is 640x480 or 800x600.

I am using windows XP 32 bit and an nvidia 980ti graphics card.

Hmm, try setting up custom resolutions in the nvidia control panel for 320x and 640x400 and 640x480.
If you are using some adapter to convert to VGA then that may be an issue.
You may have to use the normal2x scaler as well.
Also you may want to use fulldouble=true

Also if using higher than 355.98 drivers it's possible the Nvidia driver is doing something odd. I don't know what an adapter to VGA would look like to the nvidia driver. If higher than 355.98 then scaling is not available so I want to say that everything is probably scaled to the desktop res. So if using 355.98 or less you could create custom resolutions through the nvidia control panel and verify the scaling option.

I am using analog VGA right from the DVI-I, so I don't think it is a DAC issue. Or if it is, there isn't much of a way for me to get around it.

I am using driver 355.98. I can't set a custom resolution of 320x because nvidia doesn't think my display supports it. It definitely does, I have used it for DOS before, but nvidia doesn't think so. I can try 640x400 with a normal 2x. That should work pretty well.

I am going to try windows 10 next. I might be able to force something in that OS I can't in XP.

I had more success creating custom resolutions in windows 10 as well as fully disabling all forms of software scaling.

I am not sure of dosbox is capable of running in 320x200 or a similar resolution or not, but I think it will try to find the closes resolution available to your graphics card. Without any custom resolution that seems to be 640x480, or thereabouts, and it scales appropriately.

I created a 320x200 resolution in the CRU and then ran dosbox without scaling and with resolution set to original. When I load the game, the command prompt looks fine (probably 640x480), the introduction borks my monitor, and then the credits role, which I think are a different resolution, because those look great. Then the game starts and I am borked again.

I think if I can get the timings correct for 320x200 and other common DOS resolutions that dosbox might use them.

I am using the custom resolution tool. It has automated timing for a given resolution/refresh rate for different standards (CVT, GRF, ect), and I tried each of them for 320x200 without much success. When I test them in windows I get a tiny square in the middle of the screen and when dosbox attempts to use them my monitor bugs out. Does anybody know where I can find the correct setting in CRU for DOS resolutions or know how to calculate it? I think I might be close.

Ok, I have had a bit of success. If I up the refresh rate for 320x200 to 140hz, double 70hz, then dosbox will use it and it works fine.

I think this is because 320x200@140hz has a horizontal sync rate of about 30khz instead of 15khz. Anything in the PC range pixel clock wise seems to work a lot better.

Dosbox will even automatically switch to different resolution as required. For example, pinball dreams has one display res for the game and a different one for the intro credits.

The only issue is that 320x200 has big thick ol' scanline which are not at all how DOS looks.

I think if I get all the display timings correct I can get 320x200@70hz working correctyly. I just don't know enough about how VGA timings work to figure out the math. I'm lost.

In the meantime, I tried 640x400 at 140hz with a 2x scaler and it looks pretty good! The scanlines aren't nearly as chunky which is a lot closer to what DOS looks like, and I don't need aspect correction for it to look right (although I do have to fiddle with my monitor settings).

I think I am close! If someone who actually understands this stuff can help me get the VGA timings correct I think it will work.

edit: 640x400@70hz also works. Pretty close. Actually I am just an idiot. Nevermind that.

With the 200 lines video modes you have to double the scan lines when you setup that video mode. Otherwise you get a 15 kHz horizontal frequency and that is too low. The original VGA always scan doubled those low resolutions to keep the horizontal refresh high enough (and it looks sharper). So a 320x200 resolution is always output as 640x400 on a real VGA card from the DOS era. DOSBox does the same if you use normalx2 scaler. Textmode on VGA uses 720x400 by the way so you’d have to add that resolution too.

digistorm wrote on 2021-01-27, 07:52:

With the 200 lines video modes you have to double the scan lines when you setup that video mode. Otherwise you get a 15 kHz horizontal frequency and that is too low. The original VGA always scan doubled those low resolutions to keep the horizontal refresh high enough (and it looks sharper). So a 320x200 resolution is always output as 640x400 on a real VGA card from the DOS era. DOSBox does the same if you use normalx2 scaler. Textmode on VGA uses 720x400 by the way so you’d have to add that resolution too.

Yes, you are right about the scan doubling. 640x400 looks pretty good, but I think I am stilling missing something.... because 70hz is still to low on the horizontal sync to work. I think I end up with 28 or 29khz no matter if I use CVT timing or GFT, instead of 31.778 which is the DOS VGA standard. Setting it to 140hz "fixes" the problem but it still isn't totally correct either.

Do you know of DOSBOX discriminants between text modes? With a 2x scaler wouldn't it double 720x400 text mode to 1440x800?

I found what appears to be the exact display timings for some common VGA modes.

http://tinyvga.com/vga-timing
http://tinyvga.com/vga-timing/640x400@70Hz

From what I have been reading, CGA and EGA compatibility modes in VGA cards would use this display timing as well.

The problem I am having with Dosbox is that it doesn't emulate the scan doubling that happens internally the VGA card, rather if the game is rendered in 320x200 it uses that as that as the basis for any resolution scaling. This makes sense for fixed pixel displays as 320x200 is easier to work with, but it makes using Dosbox that way I am trying to very hard. To get proper 13h mode I need to enable a 2x scale, but this is not correct for text modes like 720x400 or high resolution VGA and SVGA modes. It doesn't seem to be possible to handle all cases correctly in Dosbox at the same time.

but it makes using Dosbox that way I am trying to very hard

How are you trying to use it? like this:

I want to use Dosbox to help me emulate an ideal DOS environment

Have you tried vgaonly?
What is an "ideal" environment for you?
You can't have one dosbox session handle everything, that's what multiple configuration files are for.

UniPCemu does actually emulate the VGA in such a way, emulating all known features of it (including scan doubling etc.). It can both render to 1:1 and 4:3 aspect ratio(using 800x600 monitor and up, which is configurable in 600p, 768p, 1024p and 4K).
Edit: Although when forcing aspect ratio(required for some video modes, like mode 13h and other 320x200 video modes), it's impossible to not use any kind of stretching, since the ratio of the VGA output(including all VGA rendering methods) isn't 4:3. You can't have 4:3 for all video modes and not stretch while sending VGA output, as the VGA output isn't 4:3 itself, thus always requiring some stretching.

Success!

I had assumed that Dosbox, when set to a 2x scale, would scale everything by 2x. That isn't true. It looks like it only scales low resolution outputs like 320x200, while keeping high res outputs like text modes or high res graphics 1-1!

What's more, although DOS VGA standards includes a whole mess of different resolutions, with some exceptions, most of them end up 720x400 or 640x400 at the end of the day. There a few games and applications that run with 350 lines instead, but they end up using the same total number of vertical lines as 640x400 or 720x400, just centered to the screen.

For example, the title screen in Lemmings VGA mode.

In DOS on my Voodoo 3

With Dosbox at 640x400

Now gameplay, which is 320x200 doubled to 640x400

Voodoo 3

Dosbox

The voodoo 3 is stretching the horizontal axis on the title screen a bit more. I spent over an hour trying to add a 640x350 res mode to match it (which Dosbox will use if available ), but I finally gave up. The screenshot is 640x350 centered to 640x400 in software, and I think it looks good enough.

I went looking for some kind of authoritative source on VGA timings that I could use, and what I learned is that every graphics vendor would implement their own timings a bit differently. An ATI card for example might have a slightly higher pixel clock than an S3 running the same display modes. I think you can measure the VGA timings of a computer with an oscilliscope, and it would be pretty cool to document some reference display modes and timings for reference hardware (like IBM computers and S3 cards, ect) but I lack the equipment and know how to do it myself.

Using CRU, I got this from a VGA micro controller website and it works really well for 13h and 640x400 text modes compared to my voodoo 3 in DOS:

When using the default S3 graphics in DOSBox this is all I needed, but when using VGAonly mode I had to add a 720x400 resolution as well. I couldn't find a set of reference timings for that resolution, so I just increased the active pixels to 720 and called it a day.

I also needed to add some 640x480 display modes (60hz, 72hz, 75hz) because some graphics use 480 line display modes with various refresh rates. Fortunately, I don't think the resolutions eat up your limited detail display slots in CRU. I have attached a CRU export from my computer incase anybody else is trying to do what I am doing.

If anyone knows of more common display modes and some games that use them I would like to test it.

I found this really interesting reference for oddball DOS resolutions. I am going through a process of trying them out on my two computers and seeing what I end up with.

https://nerdlypleasures.blogspot.com/2014/09/ … tions-when.html

Afaik 720x400 on VGA is just like 640x480, but with stretching to fit the same screen area. At least, that's what UniPCemu does in it's standard 800x600 raster(in the VGA 4:3 mode).
That's exactly what the real VGA is supposed to do as well?

Although VGA-compatible cards should produce the same output, although with slightly different vertical refresh rates for some mode perhaps due to oscillator differences (if any)? The basic 800x600 raster spec(640 horizontal and 480 vertical used) is what all VGA cards pretty much apply to. At least for all VGA-compatible modes. All SVGA modes are vendor specific.

So it's no surprise that the video card BIOS sets it up with the same timings for those.

superfury wrote on 2021-01-28, 20:11:

Afaik 720x400 on VGA is just like 640x480, but with stretching to fit the same screen area. At least, that's what UniPCemu does […]
Show full quote

Afaik 720x400 on VGA is just like 640x480, but with stretching to fit the same screen area. At least, that's what UniPCemu does in it's standard 800x600 raster(in the VGA 4:3 mode).
That's exactly what the real VGA is supposed to do as well?

Although VGA-compatible cards should produce the same output, although with slightly different vertical refresh rates for some mode perhaps due to oscillator differences (if any)? The basic 800x600 raster spec(640 horizontal and 480 vertical used) is what all VGA cards pretty much apply to. At least for all VGA-compatible modes. All SVGA modes are vendor specific.

So it's no surprise that the video card BIOS sets it up with the same timings for those.

I will have to take a look at UniPCemu and see what options it gives me. Another thing I am interested in trying is Dosbox within retroarch, because retroarch has so many more scaling options available than mainline Dosbox.

I am no expert, but here is what I think is true. The horizontal resolution doesn't matter that much. You can have 800 pixels, or 640, or any other number, and you end up with a pretty similar output. If you use the same back porch, front porch, and sync speed the only thing that changes is the pixel clock. The horizontal refresh rate will stay the same (ideally 31.475 or there abouts).

The vertical resolution DOES matter. 400 lines and 600 lines are very different resolutions in CRT land. You would have to use software to scale and filter that correctly.

Feel free to educate me if I am wrong about that.

One thing that could be interesting is using a "super resolution", like 2560x400, as that is similar to what retroarch does when emulating odd ball 15khz signals for systems like the SNES and Mega Drive, ect. it might be easier to get some of the weirder DOS resolutions working that way compared trying to figure out different resolutions and sync speeds for each of them.

There are also a limited number of resolutions you can force through EDID (what CRU does), especially with Nvidia cards. So finding a minimum number of resolutions that work would well enough would be useful.

UniPCemu does everything as documented, with the exception of the 16-bit DAC color modes on the Tseng chips. In that case, it'll halve the horizontal pixel clock effectively for all display areas when rendering to keep VGA compatibility in the forced(no scaling) mode. So both overscan and active display areas skip every other pixel rendering(which is a duplicate due to the way the rendering is setup). If it doesn't do that, you'll end up with a 1600x600x64K output instead of a proper 800x600x64K output (due to the way the DAC latches every 2 pixel clocks), which makes it wrongly scaled also.

I know you kind of did it above but if you could go back over what you had to do and re-check again and summarize what you had to do with dosbox itself and on the host then that would be helpful.
I noticed a mistake with vgaonly being in the language part of the attached config?

It's possible we could make things easier in dosbox for CRT users but I don't have one anymore so difficult to test so my knowledge is based on what I had to do when I did and from when helping other users.

Host:
CRU - Windows Vista+?
CRU settings: Dos.7z
Video card settings: Disable scaling?

Dosbox:
fullresolution=original
fulldouble=true
output=surface (may not matter much)
scaler=normal2x
machine=vgaonly (but not always)
aspect=false

DosFreak wrote on 2021-01-28, 23:06:

I know you kind of did it above but if you could go back over what you had to do and re-check again and summarize what you had […]
Show full quote

I know you kind of did it above but if you could go back over what you had to do and re-check again and summarize what you had to do with dosbox itself and on the host then that would be helpful.
I noticed a mistake with vgaonly being in the language part of the attached config?

It's possible we could make things easier in dosbox for CRT users but I don't have one anymore so difficult to test so my knowledge is based on what I had to do when I did and from when helping other users.

Host:
CRU - Windows Vista+?
Specific settings: Dos.7z

Dosbox:
fullresolution=original
fulldouble=true
output=surface (may not matter much)
scaler=normal2x
machine=vgaonly
aspect=false

Ah, you caught me 😜. I manually changed the dosbox.conf that I uploaded here earlier instead of using my working copy. Sorry about that. You got the settings correct.

VGAonly is not required, but it can fix issues you might run into with the S3 graphics option that is the default. Namely, the lemmings loading screen being green instead of brown.

The basic steps are to download CRU from here:
https://www.monitortests.com/forum/Thread-Cus … ion-Utility-CRU

CRU modifies the EDID which is Vista+ on windows. Alternatively, you can use any other method of adding custom resolutions, like modelines in linux or in a CRT Emu driver or what have you.

CRU allows one to create a custom resolution in the detail pane. The steps are documented on the download page.

Alternatively, you can import/export settings, which is the bin file that I uploaded before.

The most challenging thing about matching DOS display modes with Dosbox is figuring out the exact VGA timing, which Dosbox probably can't help with... not unless it emulates the analog parts for some reason and it can tell me what the DAC is doing. Some nice to have features though would be to allow dosbox to scale the output to an arbitrary horizontal resolution, and an easier way to expose the resolution and refresh rate that DOS is emulating would be nice too.

mothergoose729 wrote on 2021-01-28, 23:22:

Ah, you caught me :P. I manually changed the dosbox.conf that I uploaded here earlier instead of using my working copy. Sorry a […]
Show full quote

DosFreak wrote on 2021-01-28, 23:06:

I know you kind of did it above but if you could go back over what you had to do and re-check again and summarize what you had […]
Show full quote

I know you kind of did it above but if you could go back over what you had to do and re-check again and summarize what you had to do with dosbox itself and on the host then that would be helpful.
I noticed a mistake with vgaonly being in the language part of the attached config?

It's possible we could make things easier in dosbox for CRT users but I don't have one anymore so difficult to test so my knowledge is based on what I had to do when I did and from when helping other users.

Host:
CRU - Windows Vista+?
Specific settings: Dos.7z

Dosbox:
fullresolution=original
fulldouble=true
output=surface (may not matter much)
scaler=normal2x
machine=vgaonly
aspect=false

Ah, you caught me 😜. I manually changed the dosbox.conf that I uploaded here earlier instead of using my working copy. Sorry about that. You got the settings correct.

VGAonly is not required, but it can fix issues you might run into with the S3 graphics option that is the default. Namely, the lemmings loading screen being green instead of brown.

The basic steps are to download CRU from here:
https://www.monitortests.com/forum/Thread-Cus … ion-Utility-CRU

CRU modifies the EDID which is Vista+ on windows. Alternatively, you can use any other method of adding custom resolutions, like modelines in linux or in a CRT Emu driver or what have you.

CRU allows one to create a custom resolution in the detail pane. The steps are documented on the download page.

Alternatively, you can import/export settings, which is the bin file that I uploaded before.

The most challenging thing about matching DOS display modes with Dosbox is figuring out the exact VGA timing, which Dosbox probably can't help with... not unless it emulates the analog parts for some reason and it can tell me what the DAC is doing. Some nice to have features though would be to allow dosbox to scale the output to an arbitrary horizontal resolution, and an easier way to expose the resolution and refresh rate that DOS is emulating would be nice too.

Afaik Dosbox used CRT emulation on the sub-scanline level. So points like start/end retrace and blanking, totals etc.. Then it performed the rest of the scanline in blocks. Pretty much all others I know do that too.

UniPCemu otoh, performs them all on an emulated CRT with cycle-accurate timers. So it ticks seperate clocks(like at ~25MHz or ~28MHz for VGA, faster for SVGA clocks). And every clock performs an action(like rendering a pixel to display, latching a dword from VRAM, sending (part of it) to the DAC). The DAC can output multiple (same) pixels in one go(depending on previous latches), while the attribute controller can stall the DAC(for 8-bit/16-bit modes). The CRT emulation works by implementing two precalculated(register based) lists, which the clock ticks through(one list for horizontal and one list for vertical timings). Those bits in each entry direct things like starting/stopping retrace and blanking, total(resetting the counter (and increasing the vertical list item for horizontal total) and overscan as well.
Then there's some extra lists that do the same for data fetching from VRAM and it's latching, as well as some misc information required, like DAC ticking and the like.
Both run in parallel to each other. So there's a step for executing CRT timing(checked first) and one after that one for performing the memory-based processing, of which most are performed in parallel to another, but in a order as the data is processed according to the manuals, mostly based on said lists for decision making (and precalculated settings from registers). Most work using step-based counters which once expired, trigger an specific action. So sequencer/memory fetch according to timings->attribute controller(second parallel process in the main handling)->DAC and rendering(third parallel process). And all of those are selected based on the video mode(text vs graphics mode) and CRT state(overscan/totals/retraces disabling all of those).

Wrote about those in detail in the past on vogons, which shouldn't be hard to find.
Mostly based on FreeVGA documentation (except the lists handling itself and it's processing), combined with the ET4000 documentation(for extended modes and 16BPP support).

Although clocks can be ran as batches if multiple occur during a single CPU clock(one IPS clock or cycle-accurate clock) and are handled in floating point for timekeeping. So, for example, it's running an exact crystal as documented(for example CPU at 14.31818MHz, CGA at an integer divide of that(in cycle-accurate mode 808X), all other graphics cards and hardware at their respective frequencies, as documented. Only the CPU mode and speed can be toggled and changed(IPS vs cycle accurate, at a specified amount of cycles/IPS(both x1000 granularity) or default(machine and processor define which mode and speed(e.g. 808X+XT=4.77MHz CPU).

superfury wrote on 2021-01-29, 01:11:

Afaik Dosbox used CRT emulation on the sub-scanline level. So points like start/end retrace and blanking, totals etc.. Then it p […]
Show full quote

mothergoose729 wrote on 2021-01-28, 23:22:

Ah, you caught me :P. I manually changed the dosbox.conf that I uploaded here earlier instead of using my working copy. Sorry a […]
Show full quote

DosFreak wrote on 2021-01-28, 23:06:

I know you kind of did it above but if you could go back over what you had to do and re-check again and summarize what you had […]
Show full quote

I know you kind of did it above but if you could go back over what you had to do and re-check again and summarize what you had to do with dosbox itself and on the host then that would be helpful.
I noticed a mistake with vgaonly being in the language part of the attached config?

It's possible we could make things easier in dosbox for CRT users but I don't have one anymore so difficult to test so my knowledge is based on what I had to do when I did and from when helping other users.

Host:
CRU - Windows Vista+?
Specific settings: Dos.7z

Dosbox:
fullresolution=original
fulldouble=true
output=surface (may not matter much)
scaler=normal2x
machine=vgaonly
aspect=false

Ah, you caught me 😜. I manually changed the dosbox.conf that I uploaded here earlier instead of using my working copy. Sorry about that. You got the settings correct.

VGAonly is not required, but it can fix issues you might run into with the S3 graphics option that is the default. Namely, the lemmings loading screen being green instead of brown.

The basic steps are to download CRU from here:
https://www.monitortests.com/forum/Thread-Cus … ion-Utility-CRU

CRU modifies the EDID which is Vista+ on windows. Alternatively, you can use any other method of adding custom resolutions, like modelines in linux or in a CRT Emu driver or what have you.

CRU allows one to create a custom resolution in the detail pane. The steps are documented on the download page.

Alternatively, you can import/export settings, which is the bin file that I uploaded before.

The most challenging thing about matching DOS display modes with Dosbox is figuring out the exact VGA timing, which Dosbox probably can't help with... not unless it emulates the analog parts for some reason and it can tell me what the DAC is doing. Some nice to have features though would be to allow dosbox to scale the output to an arbitrary horizontal resolution, and an easier way to expose the resolution and refresh rate that DOS is emulating would be nice too.

Afaik Dosbox used CRT emulation on the sub-scanline level. So points like start/end retrace and blanking, totals etc.. Then it performed the rest of the scanline in blocks. Pretty much all others I know do that too.

UniPCemu otoh, performs them all on an emulated CRT with cycle-accurate timers. So it ticks seperate clocks(like at ~25MHz or ~28MHz for VGA, faster for SVGA clocks). And every clock performs an action(like rendering a pixel to display, latching a dword from VRAM, sending (part of it) to the DAC). The DAC can output multiple (same) pixels in one go(depending on previous latches), while the attribute controller can stall the DAC(for 8-bit/16-bit modes). The CRT emulation works by implementing two precalculated(register based) lists, which the clock ticks through(one list for horizontal and one list for vertical timings). Those bits in each entry direct things like starting/stopping retrace and blanking, total(resetting the counter (and increasing the vertical list item for horizontal total) and overscan as well.
Then there's some extra lists that do the same for data fetching from VRAM and it's latching, as well as some misc information required, like DAC ticking and the like.
Both run in parallel to each other. So there's a step for executing CRT timing(checked first) and one after that one for performing the memory-based processing, of which most are performed in parallel to another, but in a order as the data is processed according to the manuals, mostly based on said lists for decision making (and precalculated settings from registers). Most work using step-based counters which once expired, trigger an specific action. So sequencer/memory fetch according to timings->attribute controller(second parallel process in the main handling)->DAC and rendering(third parallel process). And all of those are selected based on the video mode(text vs graphics mode) and CRT state(overscan/totals/retraces disabling all of those).

Wrote about those in detail in the past on vogons, which shouldn't be hard to find.
Mostly based on FreeVGA documentation (except the lists handling itself and it's processing), combined with the ET4000 documentation(for extended modes and 16BPP support).

Although clocks can be ran as batches if multiple occur during a single CPU clock(one IPS clock or cycle-accurate clock) and are handled in floating point for timekeeping. So, for example, it's running an exact crystal as documented(for example CPU at 14.31818MHz, CGA at an integer divide of that(in cycle-accurate mode 808X), all other graphics cards and hardware at their respective frequencies, as documented. Only the CPU mode and speed can be toggled and changed(IPS vs cycle accurate, at a specified amount of cycles/IPS(both x1000 granularity) or default(machine and processor define which mode and speed(e.g. 808X+XT=4.77MHz CPU).

oh, interesting. I didn't realize you are the author of unipcemu. Thank you for taking the time 😀.

A lot of that is pretty over my head! But it sounds like unipcemu has the potential to be more accurate than dosbox. I have already found a case or two where dosbox has different behavior than my real hardware. I'll have to get unipcemu up and running and compare.

One thing I have noticed with Dosbox, it seems like it doesn't discriminate between the same resolution with different refresh rates. For example, a lot of my 640x480 test had my monitor at 75 hz. I had to remove 75hz and 72hz from my CRU setup in order to get Dosbox to correctly use 60hz. This is also a problem on jazz jackrabbit, because although 640x400 is close enough for what the game is trying to do, the 70hz refresh rate is not and I can't get it to use 60hz without modifying that line. Having two resolutions, one at 70hz and one at 60hz, unfortunately doesn't work. Which ever one is defined first in CRU AFAIK is the one dosbox selects regardless.