VOGONS


First post, by kolano

User metadata
Rank Oldbie
Rank
Oldbie

My prior post seemed to get bogged down with details around DOSBox doubling the width of Mode X modes with vertical resolution 400+. Still trying to work out rendering Dial8's 376x564 Mode X resolution (i.e. it's mode 11).

svga_s3 vs vgaonly:
With either machine type, I get only 376x282 resolution output.
ZajK1Pn.png

linewise and multiscan:
With either linewise or multiscan turned on individually I also only get 376x282 resolution output. With both enabled I get 752x564 output, but it's just that the pixels are doubled in both directions.
uss8JHS.png

Either way it seems like only the top half the image is output.

Can anyone let me know if it's possible to get the 376x564 output in DOSBox? If so, how? And if not, why?

Eyecandy: Turn your computer into an expensive lava lamp.

Reply 1 of 13, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Have you seen the 376x564 resolution working correctly on real VGA hardware? I'm guessing the answer is no, because it appears the program has an obvious bug. I looked at the mode 13h register tweaks used for 376x282 (option 4) and 376x564 (option 11) -- they're identical, and that's clearly not right. However, this bug or flaw is not difficult to fix: modify the byte at offset 87F5h in the executable from 61h to 60h and the 376x564 resolution will work as expected.

Reply 5 of 13, by kolano

User metadata
Rank Oldbie
Rank
Oldbie

As you've noticed I can't speak of how it works on real hardware, but can confirm that Ripsaw's patch fixes the issue (at least in DOSBox).

Thanks a lot Ripsaw for providing a fix for this. I had been going crazy trying to work out if there was a DOSBox config solution to the problem. I very much appreciate all the help you provide here. You do an awesome service for folks still loving DOS software, thank you so much.

I should have a patched version, along with a DOSBox pre-config /w the program up on my site soon. I'll update this once I do.

Eyecandy: Turn your computer into an expensive lava lamp.

Reply 6 of 13, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author
ripsaw8080 wrote:

Are you talking about before or after patching the program so option 11 isn't using the exact same register tweaks as option 4?

I don't think your patch makes a difference there. It appears that vrstart is lower than vbstart, causing retrace lines visible in options 4 and 11. The border at the bottom is wrapped into the display.

Two options to fix that:
- decrease vbstart. The border will be cut at the bottom.
- increase vrstart. When turning up brightness quite a few blank scanlines are visible at the top. It seems there is enough room.

The horizontal lines on the photo are caused by the camera.

Attachments

  • Filename
    ICN20030101120205.jpg
    File size
    87.95 KiB
    Downloads
    No downloads
    File license
    Fair use/fair dealing exception

1+1=10

Reply 7 of 13, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Changing the address line total in the maximum scan line register doesn't make a difference? How can that be the case? Maybe the problems with retrace and blanking make it a moot point?

This behavior in DOSBox is why the patch makes a difference there:

    if (!(IS_VGA_ARCH && (svgaCard==SVGA_None) && (vga.mode==M_EGA || vga.mode==M_VGA))) {
//Only check for extra double height in vga modes
//(line multiplying by address_line_total)
if (!doubleheight && (vga.mode<M_TEXT) && !(vga.draw.address_line_total & 1)) {
vga.draw.address_line_total/=2;
doubleheight=true;
height/=2;
}
}

Thus doubleheight=true for option 4, and after patching it's false for option 11.

Reply 9 of 13, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Hmm, do you think exchanging the values for vbstart and vrstart would fix that? Maybe that's more than necessary...

For your suggestion with changing only vrstart, try modifying the bytes at offsets 86DDh and 87F9h from 37h to 47h. This will change vrstart/vrend from 567/569 to 583/585. DOSBox doesn't care, but maybe your CRT will. 😉

Reply 10 of 13, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

With these changes the retrace lines are fixed.

I've hooked it up to a TFT and saw that the monitor is driven with 30kHz/50Hz. That might be out of range for several monitors. The Casper one I'm using is capable of CGA/Herc/EGA/VGA/800x600 reasonably, so it has no problem.

1+1=10

Reply 11 of 13, by kolano

User metadata
Rank Oldbie
Rank
Oldbie

OK, a patched version, per Ripsaw's initial patch, is now available from my site...
http://eyecandy.gnugget.net/Dial8/

H-a-l-9000/Ripsaw, are the later revisions you guys discussed just related to getting it working on specific displays, or are they generally needed? I know DOSBox doesn't seem to care, but would like to provide a patched version that works generally.

Eyecandy: Turn your computer into an expensive lava lamp.

Reply 12 of 13, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

That latter change would also make sense IMO. On the old 80ies CRT it removes the retrace lines and gets the border shaped identically on all sides. On a newer, maybe 1998 17" CRT the retrace lines are blanked automatically but the border width is also fixed. A more modern TFT screen will center the picture better on auto-adjust with the change.

1+1=10