VOGONS

Common searches


VIDEO - Overscan border (SDL1)

Topic actions

Reply 80 of 100, by NY00123

User metadata
Rank Member
Rank
Member

Before anybody continues, it may be better to halt now. I've realized that for true emulation of overscan, involving several modifications to vga_draw.cpp at the least (so more columns are drawn, and similarly more rows) instead of sdlmain.cpp (and little modifications of other files), "some" more work will be required, involving lots of info I'm not so familiar with. (And even if I were, that'd still be much more to change without errors.)

Nevertheless, thanks for all the great info so far. Regarding the CRTC register values table for CGA modes you've referred to, VileRancour, looks like it is also found in the following reference, although it talks about the EGA rather than the CGA (but it's still the 6845 and the data is identical); See page 17 in the relevant section, which is page 58 in the PDF: https://archive.org/details/bitsavers_ibmpcca … 2Apr84_25079400

Finally, I can still modify the patch so, at least, you'd get the correct overscan border dimensions in very specific few cases. I currently consider the following few cases, to be handled on (emulated) VGA hardware and basing on the behaviors of the GTX 460 here (which are clearly a guess):
- Mode 0Dh (320x200x16-colors): I guess the vertical bars have the thickness of 8 pixels, while the vertical ones are 3 pixels tall.
- Mode 13h (320x200x256-colors): The thickness of the vertical bars seems like 4 pixels, while the vertical ones probably still have the same height.
- Finally, maybe have no bars at least in some SVGA modes.

Reply 81 of 100, by NY00123

User metadata
Rank Member
Rank
Member

Alright, here is the updated patch, which is more of a hack. Basically, once the patch is applied, a list of (probably wrong) guesses of overscan border sizes is stored in sdlmain.cpp, associated with the (emulated video card side) video modes. There are differences between the VGA cases, and all non-VGA cases (as a whole). For VESA modes (and possibly more) you get no overscan borders at all.

Attachments

  • Filename
    dosbox_overscan_20131109.diff
    File size
    19.24 KiB
    Downloads
    67 downloads
    File comment
    Updated overscan border patch targetting r3842 (November 9th, 2013)
    File license
    Fair use/fair dealing exception

Reply 82 of 100, by NY00123

User metadata
Rank Member
Rank
Member

While testing a Windows build...

As I've guessed, it is a bad idea to use floating point numbers (of type double) for the representation of overscan dimensions relatively to the dimensions of the displayed area (without the borders), as ratios.

So, I've basically changed to rational numbers formed of integer numerators and denominators. Furthermore, a bit more has changed.

And so the patch is updated, and there's also a Windows EXE now. Again, it is minimal. For instance, it looks like output=ddraw is not built in.

This is still mostly based on modifications of sdlmain.cpp, which result in several limits, like:
- The fact that I consider it hackish in a way, although much simpler to implement.
- The lack of "screen shaking" effects.
- The possibility of the overscan borders and background appearing to not get updated uniformly upon color change, say in the case of CGA hardware. Don't remember how I've reproduced this, but it has occurred in Alley Cat.

EDIT (Yeah, right after VileRancour's last post that follows *this* one): On a related note... or unrelated...you'll decide. Anyway, let's try Crystal Caves for the very first time. 😮 (Surprising a few, I suppose?)

Attachments

  • Filename
    dosbox_overscan_win32_20131110.zip
    File size
    1.15 MiB
    Downloads
    55 downloads
    File comment
    Windows build, based on r3842 after applying the patch (November 10th, 2013)
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_overscan_20131110.diff
    File size
    21.46 KiB
    Downloads
    67 downloads
    File comment
    Updated overscan border patch targetting r3842 (November 10th, 2013)
    File license
    Fair use/fair dealing exception
Last edited by NY00123 on 2013-11-10, 15:48. Edited 2 times in total.

Reply 83 of 100, by VileR

User metadata
Rank l33t
Rank
l33t
NY00123 wrote:

For instance, it looks like output=ddraw is not built in.

For that, you just need to have ddraw.h in the include path - it's available in various MS SDKs but for lack of a handy link, I'm attaching it here for convenience. (Not that it's terribly important, but more output= options would be good for testing a patch like this.)

Filename
ddraw.h
File size
241.04 KiB
Downloads
53 downloads
File license
Fair use/fair dealing exception
NY00123 wrote:

- The possibility of the overscan borders and background appearing to not get updated uniformly upon color change, say in the case of CGA hardware. Don't remember how I've reproduced this, but it has occurred in Alley Cat.

Might have something to do with the fact that DOSBox updates the display only when the framebuffer is updated (rather than updating on every frame)? Of course, I guess going around that would need more work on the vga_draw.cpp side.

Anyhow, nice work - will give this some testing soon.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 84 of 100, by NY00123

User metadata
Rank Member
Rank
Member
VileRancour wrote:
NY00123 wrote:

For instance, it looks like output=ddraw is not built in.

For that, you just need to have ddraw.h in the include path - it's available in various MS SDKs but for lack of a handy link, I'm attaching it here for convenience. (Not that it's terribly important, but more output= options would be good for testing a patch like this.)

I've cross-compiled a Win32 build with MinGW from Linux. It seems like ddraw.h is missing.
To compare, MinGW-w64 seems to have more headers ready, but it fails on some CD-ROM related source files from the DOSBox source code.

I guess that if somebody wants, then the same individual can attach a Windows build. Although, if that MinGW-w64 compilation issue can be fixed with a few efforts then it'd be good.

Anyhow, nice work - will give this some testing soon.

Thanks for your comments so far, as well as even (just) considering the possibility of trying this!

EDIT: Oh, another thing I've forgotten to write beforehand in another post, I suppose... and also in this post...
Basically, if the overscan handling was to be relocated from sdlmain.cpp to vga_draw.cpp and done properly, then any captured image or video would include the borders. (Or so I guess.)

Reply 85 of 100, by NY00123

User metadata
Rank Member
Rank
Member

Just for reference, in case it helps anybody, I'm adding this post with the following:

- Some manuals can be found at: http://www.minuszerodegrees.net/oa/oa.htm
To be more specific, the IBM Enhanced Graphics Adapter (EGA) manual has a table of CRTC register assignments based on the video mode, beginning at page 64 of the manual (68 in the PDF). A similar table can be found in the IBM Color/Graphics Monitor Adapter (CGA) manual, at page 17 (21 in the PDF).
- I have attached a patch with a few modifications that may help getting (somewhat) proper overscan support, including fixes for some CGA register values (based on a table as found in one of the manuals). Let's just say for now that the patch has already been tested...

Attachments

Reply 86 of 100, by NY00123

User metadata
Rank Member
Rank
Member

A second attempt of mine at overscan handling can be found in this post. With the help of the "fixes patch" posted earlier, this is now another attempt at overscan, with its own limitations as before.

Some of the limitations in mind:
- Mainly tested with CGA and (S)VGA hardware, in a few video modes.
- The color of the borders may be wrong, which is palette-related. This is especially noticeable in Alley Cat with emulated SVGA hardware, but can be observed in other games, too (but not all).
- For video mode 0x0D (320x200) with (S)VGA hardware, the thickness of each horizontal overscan bar is 3 pixels. Truly, it should be more like 3.5 pixels. More precisely, due to line doubling, on a real (S)VGA setup you should get 320x400 pixels on the screen, and the common thickness of the horizontal bars is 7 pixels. Similar limitations may apply for other modes.
- Due to the nature of the patch itself, it may easily make the emulation different. That is, less precise, possibly even unstable...
- With this patch, overscan=auto will enable the borders only if fullresolution is not set to "original", even if a non-fullscreen window is in use. This is done for technical reasons and reasons of, let's call it, "safety". You can still try overscan=forced, but then fullscreen might result in some troubles (on the host side), so you've been warned!

Anyway, in contrary to the patch I've posted earlier, this patch has virtually zero modifications to sdlmain.cpp, while most of the modifications are found in vga_draw.cpp. The borders' dimensions are based on the contents of the (emulated) CRTC registers in a more direct manner, rather than the hackish way done in the preceding overscan patch. Furthermore, the overscan is now just a part of the image sent to the scaler.

On a minor, final note, the addition of ddraw.h to the MinGW tree has helped with getting ddraw output to be available, as expected. Thanks to VileRancour for the hint!

UPDATE: Although less relevant to this specific post, I've just realized this: Regarding the preceding attempt with an overscan patch, you may have noticed that, although the color may be picked to be the correct one, it differs a bit from, say, a background color, which should rather be identical. It's all about the difference between the implementation of vga.cpp:VGA_GetBorderColorRGB from preceding overscan patchs, and vga_dac.cpp:VGA_DAC_Sendcolor (also in vanilla DOSBox from SVN).

Attachments

  • Filename
    dosbox_overscan2_win32_20131117.zip
    File size
    1.12 MiB
    Downloads
    57 downloads
    File comment
    Windows build, based on r3849 after applying the patch (November 17th, 2013)
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_overscan2_20131117.diff
    File size
    29.89 KiB
    Downloads
    47 downloads
    File comment
    Another overscan border patch, targeting r3848/3849 (November 17th, 2013)
    File license
    Fair use/fair dealing exception

Reply 87 of 100, by VileR

User metadata
Rank l33t
Rank
l33t

Works really nicely! A few things tested so far:

- VGA 320x200 works as expected (with your caveat in mind)
- CGA mode: games like Bricks (freeware) and Trixter's CGA Compatibility Tester all seem to give proper results when adjusting the screen position left/right/up/down
- Lost Tomb's "screen shake" works beautifully in CGA (RGB/composite) and PCjr modes

Bugs and/or funny stuff found:

- I know you didn't mention EGA testing, but with machine=ega the borders don't look like they should; text mode and hi-res mode have no borders, and in 320x200... well:

cc1_ega_border.png
Filename
cc1_ega_border.png
File size
14.52 KiB
Views
1570 views
File license
Fair use/fair dealing exception

- Moon Patrol (like other Atarisoft CGA games) lets you roll the screen left and right with F9 and F10, respectively. If you roll it to the right too much, the window will eventually stretch to amusing proportions:

Filename
moonpatlol.png
File size
9.92 KiB
Downloads
No downloads
File license
Fair use/fair dealing exception

EDIT: I guess the patch is trying to accomodate the entire image no matter what, thus causing the visible area to grow.
Question is, would real CGA hardware allow you to roll the screen *that* far to the right? Obviously the image would just get cut off as it moves beyond the visible area; but some wrapping or capping might happen before it gets to the point shown in the screenshot, because that's quite a bit wider than the total duration of a single scanline (=456 low-res pixels).

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 88 of 100, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

The patch works with the screen shaking effect of King's Quest III when the wizard kills you, but has problems with the Joust in Defender of the Crown.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 89 of 100, by VileR

User metadata
Rank l33t
Rank
l33t

I tested a couple of other Atarisoft games against the patch, to see how they fare with the screen-shifting thing. Gremlins behaves the same as Moon Patrol. Jungle Hunt shows the same issue, but here it also occurs when shifting to the left - I managed to get the window up to 1280 pixels wide...
So, Jungle Hunt would be a good one to test on real hardware. Can anyone with an actual CGA machine report what happens when the screen is rolled all the way to the left, and all the way to the right? (Great Hierophant?)

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 91 of 100, by NY00123

User metadata
Rank Member
Rank
Member

Thanks for trying the patched DOSBox, as well as the reports so far!

- Yeah, CRTC register values for the EGA are not yet corrected, at least when comparing to the table from the IBM Enhanced Graphics Adapter (EGA) manual (see my post above for a link).
- Right now, for (S)VGA/EGA hardware, the patch uses only the horizontal/vertical blanking registers to determine the overscan border dimensions. For other kinds of hardware, the retrace registers are used. It is probably the case that, for (S)VGA/EGA, the retrace registers should be used as well.
- For any axis (horizontal/vertical), maybe the time period consisting of blanking, but no retrace, should also be drawn (with black color), at least optionally.
- The idea of a viewport is good, although it leads to a whole different (but related) problem: What about analog CRT monitor controls for moving/stretching the output, independently of anything done software-side? I guess it can be left as a different problem for now.

Reply 92 of 100, by NY00123

User metadata
Rank Member
Rank
Member

Just for reference, I am attaching the following *incomplete* patch. The idea here is to add the overscan borders at the scaler code, rather than VGA code (vga_draw.cpp).

For now only the horizontal borders are drawn, and this may not work well with all scalers. While I've known that you should get plain borders even with a scaler like hq2x, which I don't mind, I've just realized the opinion may be different when a scaler like rgb2x is used...

Attachments

  • Filename
    dosbox_overscan_20131119.diff
    File size
    29.72 KiB
    Downloads
    45 downloads
    File comment
    Overscan patch targetting r3849 (November 19th, 2013)
    File license
    Fair use/fair dealing exception

Reply 93 of 100, by NY00123

User metadata
Rank Member
Rank
Member

Alright, here is a small update. Technically, it is very similar to the patch from Nov 17. The main difference being that the scaler can tell where is the overscan and pick the (hopefully) correct color. Captured images still have random overscan colors, though.

Some comments:
- Apart from the above change, I have applied a few more modifications. One of them should hopefully fix some crash, although chances are it's not authentic. I'm looking at stuff like that "screen rolling" feature.
- If you want the correct (odd) number of scanlines in a horizontal bar, for the video mode of 0x0D on VGA hardware (200-lines, doubled to 400), try machine=vgaonly.
- OK, with machine=cga and some flashing in Alley Cat, I confirm that the bottom bar of the border contains a (more or less) permanent line of tearing. Might be timing-related, and I don't know what is the situation with the real thing.

Attachments

  • Filename
    dosbox_overscan_20131119_2.zip
    File size
    1.14 MiB
    Downloads
    46 downloads
    File comment
    Win32 build based on the second patch for today (November 19th, 2013)
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_overscan_20131119_2.diff
    File size
    35.95 KiB
    Downloads
    61 downloads
    File comment
    Overscan patch targeting r3849, second for today (November 19th, 2013)
    File license
    Fair use/fair dealing exception

Reply 94 of 100, by NY00123

User metadata
Rank Member
Rank
Member

UPDATE: While testing this with the overscan patch, some things have looked wrong. Eventually this has lead to an update. Hence, I'm attaching the second "overscan fixes" patch for today (filename ending with the digit 2) which, again, is *not* an overscan patch on its own.

*** Older post contents begin after this location ***

I am attaching an update to the "dosbox_overscan_fixes" patch posted earlier (back on Oct 17). As before, it is *not* an overscan patch per-se. It just consists of a few modifications that should help with overscan handling. This is a modification of the patch dosbox_overscan_fixes_20131116.diff, which adds a table of CRTC registers for the EGA, copied right off that EGA manual. It is assumed that the adapter has more than 64K of graphics memory, and an EGA monitor is in use (with no full compatibility with CGA monitors in mind).

Let's hope I haven't made any typo in the table or elsewhere...

Attachments

Reply 95 of 100, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
VileRancour wrote:

I tested a couple of other Atarisoft games against the patch, to see how they fare with the screen-shifting thing. Gremlins behaves the same as Moon Patrol. Jungle Hunt shows the same issue, but here it also occurs when shifting to the left - I managed to get the window up to 1280 pixels wide...
So, Jungle Hunt would be a good one to test on real hardware. Can anyone with an actual CGA machine report what happens when the screen is rolled all the way to the left, and all the way to the right? (Great Hierophant?)

Eventually, if you go too far to the left or the right in Jungle Hunt, the screen will loose sync and roll uncontrollably in a diagonal manner.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 96 of 100, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
NY00123 wrote:
Alright, here is a small update. Technically, it is very similar to the patch from Nov 17. The main difference being that the sc […]
Show full quote

Alright, here is a small update. Technically, it is very similar to the patch from Nov 17. The main difference being that the scaler can tell where is the overscan and pick the (hopefully) correct color. Captured images still have random overscan colors, though.

Some comments:
- Apart from the above change, I have applied a few more modifications. One of them should hopefully fix some crash, although chances are it's not authentic. I'm looking at stuff like that "screen rolling" feature.
- If you want the correct (odd) number of scanlines in a horizontal bar, for the video mode of 0x0D on VGA hardware (200-lines, doubled to 400), try machine=vgaonly.
- OK, with machine=cga and some flashing in Alley Cat, I confirm that the bottom bar of the border contains a (more or less) permanent line of tearing. Might be timing-related, and I don't know what is the situation with the real thing.

Alley Cat does have a flashing background on occasion, and this is intentional. I notice no flickering line at the bottom of the border, even with the vertical size of my monitor squished as far as it can go.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 97 of 100, by NY00123

User metadata
Rank Member
Rank
Member

Thanks for testing on real hardware! That is surely very useful.

Great Hierophant wrote:

Eventually, if you go too far to the left or the right in Jungle Hunt, the screen will loose sync and roll uncontrollably in a diagonal manner.

Hmm, sounds like fun... interesting to know that this was (and is) even possible with software like that! Oh well, truly low level access...

Alley Cat does have a flashing background on occasion, and this is intentional. I notice no flickering line at the bottom of the border, even with the vertical size of my monitor squished as far as it can go.

What I've meant is that, while the border is flashing (say after completing a task), a line can be seen inside the bottom border. Guess that's what you've checked, though, and the result is as I've suspected. Chances are the line is seen with the patched DOSBox due to a very wrong approach of mine: After the vertical timer wakes up, the top border is processed and drawn first, then the display area is (plus some of the left and right borders) and then the bottom border follows. Not knowing much about this, I have a feeling this is the very wrong way. (I guess that with real hardware the process begins at the top-left corner of the display area.)

On a side note, I'm attaching yet another (small) update to that "overscan fixes" patch.

Attachments

Reply 98 of 100, by NY00123

User metadata
Rank Member
Rank
Member

Alright, updated overscan patch and Win32 build are attached. The last "overscan fixes" patch is integrated, so (unless I've added some typo) the correct EGA register values should be in use for the known video modes, and a bit more is changed as a result.

Furthermore, the top border is not added to the timing before the display area. It is technically drawn first by the render code, but that's it. Looks like this solves the earlier tearing issue in Alley Cat.

Oh yeah, about the "overscan fixes" patch and what it does: You may notice that the left border in some 200-lines modes, with CGA hardware (and now also EGA), is shorter than before. Reason is that the horizontal sync width is programmed to be 10 characters long for all CGA modes (as shown in a manual above), while I tried effectively forcing this to 5 for modes with a display width of 320 pixels beforehand for the sake of visual consistency, thinking this is the right way. Looks like this is not the case, though.

There surely is a LOT which is unknown...

Attachments

  • Filename
    dosbox_overscan_win32_20131121.zip
    File size
    1.14 MiB
    Downloads
    68 downloads
    File comment
    Win32 build based on r3850 + overscan patch (November 21st, 2013)
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_overscan_20131121.diff
    File size
    55.56 KiB
    Downloads
    61 downloads
    File comment
    Overscan patch targeting r3850 (November 21st, 2013)
    File license
    Fair use/fair dealing exception

Reply 99 of 100, by NY00123

User metadata
Rank Member
Rank
Member

ok, I think that a little help may be useful, because there's something which doesn't seem to make sense to me, at least in regards to the horizontal sync pulse (and possibly more).

Basically, if I don't make any mistake, it seems like on (S)VGA compliant hardware and for video mode 0Dh, the sync pulse ends at the very end of the scanline (if not later), leaving no room for a left overscan bar. Maybe the CRT monitor's beams' repositioning is completed earlier, though, so this is not an issue at all.

Let us concentrate at (S)VGA hardware and video mode 0Dh (320x200, double-scanned to 320x400, with 16 distinct choices of colors for the display area pixels). Let us further concentrate at a set of CRTC register values which is picked for this mode.

Ignoring register no. 0Fh (Cursor Location Low), the exact same values are given in the following situation:
- Emulated (S)VGA hardware in DOSBox (output=vgaonly,svga_s3), running a small app that tries to dump the CRTC values for this mode.
- DOSEMU with direct access to the VGA portion of a GTX 460, again running the same app.
- Column 0Dh of the CRTC registers table found here (see "2.4. Standard video modes"): http://brokenthorn.com/Resources/OSDevVid2.html

Basically, the set of CRTC values for mode 0xDh (as given in DOSBox/DOSEMU) is the following:

2D 27 28 90 2B 80 BF 1F 00 C0 00 00 00 00 00 00 9C 8E 8F 14 00 96 B9 E3 FF

Let us concentrate at the first six register values (same in all 3 sources above):

2D 27 28 90 2B 80

As far as I remember, in mode 0Dh on (some) VGA-compatible hardware, there should be small overscan borders surrounding the display area (possibly colored black). Let us see if it is really the case, considering the above 6 values.

Here I'm basing on info as found here:
[1] http://www.stanford.edu/class/cs140/projects/ … vga/crtcreg.htm
And also here:
[2] http://wiki.osdev.org/VGA_Hardware#Timing_Model

Analyzing the above six values:
- 2Dh is the horizontal total minus five, so the horizontal total itself is 32h=50 characters long, or 400 pixels long in our case.
- 27h=39 is the index of the last character of a scanline in the displayed area. In pixels this translates to 312, which is to be expected.
- I'm a bit unsure about the following value of 28h=101000b=40. Supposedly, the horizontal blanking should start here (see [1]). But then, as I see it, there'd be no right border at all. So maybe the value of 28h rather refers to the index of the *last* character *before* the horizontal blanking begins, as hinted in [2].
- For the fourth value of 90h we should concentrate at bits 0-4 (see [1]), obtaining the value of 10h, and then add bit no. 5, which is bit no. 7 of the sixth value of 80h (see [1]). So we end with the value of 10h+20h=30h=110000b=48. According to [1], after the character counter reaches the value of 28h, a blanking begins, and it ends when the lower 6 bits of the counter are 110000b. Now, if the char no. 30h is the first where there's no blanking, the width of the left overscan bar is 2 characters. But maybe, as is the case with the start of the blanking, it's rather 30h+1h=31h, so the width is 1 character (same as right border if 1 is added everywhere).
- The fifth value of 2Bh=101011b=43 is where the horizontal sync pulse begins; Or maybe it's rather one char later again (see [2]).
- The low 5 bits of the sixth value of 80h, which simply represent the number 0, should be the lower 5 bits of the character counter when the retrace period ends. In practice this means that the character encounter reaches the value of 32h, which is the horizontal total, hence gets reset, and then the retrace period ends (if not one character later).

In the very last point (but also some more) there is the unclear situation, which I wonder about.