*moved*

h-a-l-9000:
I like this patch a lot. I've been trying it on some demos, and some of my own apps.. and also integrated it with the vsync patch I was working on. Here's a small bug report.

Update: I think it's not a real bug afterall. In fact, I think your patch fixed dosbox to work more like real hardware. After looking through the write_p3c0() code in vga_attr.cpp, I noticed that my code probably should be outputting 0x33 to 0x3c0 instead of 0x13. After making that change, my apps work fine under your patch. I'd still be curious to see what happens on real hardware though to be sure. The rest below was written before this update.

I noticed that it breaks the rendering of my vsync test apps. I already had them attached on the forums at the following location, as a part of the vsync patch diff (source for vsync.com is distributed too.. and forever.com is 45 bytes and hence readable/debuggable):
download link-
download.php?id=2439
thread link (first page, second post from bottom)-
Vertical retrace sync patch

It's because when I just modify the horizontal pel scrolling register and wait for retrace, VGA_DrawSingleLine() draws black rows instead of the row contents. I noticed this comment - "TODO else draw overscan color line black line should be good enough for now (DoWhackaDo)". If I remove the DoWhackaDo case from the code (and instead always use the 'vga.attr.enabled' case), then the apps work perfectly.

It would be best to test the apps on a real system too of course. I've only ever run them in Dosbox. So until it is tried on a real machine, I have to accept the possibility that your changes may have actually caused it to work correctly for the first time 😉

I just tested it in real hardware before reading your update - vsync.com doesn't work there.
My suggested fix is to write 0x20 to 3c0 after you are done updating the PEL. Writing 0x33 is illegal I think.

The patch doesn't work well anymore. With latest CVS, I get random crashes (weird ones, looking like buffer overflows) or misbehaviour (patch simply stopping to work). Has something important changed?

Since the crashes are not happening at the place they are caused, I had no luck tracking them down with gdb.

Writing 0x33 is illegal I think.

I've seen this done in some ega bios though, not sure what it's
supposed to do but it looks like the value should be changed
accordingly and the protection set after that (like 0x20 does).
Doesn't make too much sense to me though.

Illegal might have been the wrong word - just having the 0x20 bit set disables screen output. So if we want to see something we should always clear it after writing the other registers. The DoWhackaDo demo uses it to hide a part of the screen that would otherwise look corrupted.

I'm attaching the re-merged patch which works for me. Might be some patching problem?

Tried it, behaves a bit better, but still not good enough:

Tried latest CVS, core normal or dynamic, cycles max or 2000, X-Mas Lemmings. Mission briefing shows up correct (top half: winter palette, bottom half: brownish one), but it still reliably crashes at some mode switch. No crash with the same executable and machine=vga.

Note that this is a 64-bit build on a high-end dual core machine.

crashes at some mode switch.

Good hint - maybe adding PIC_RemoveEvents(VGA_DrawSingleLine); in vga_draw.cpp line 1119 helps?

1if (( width != vga.draw.width) || (height != vga.draw.height) ||
2		(aspect_ratio != vga.draw.aspect_ratio) || 
3		(vga.mode != vga.lastmode)) {
4		vga.lastmode = vga.mode;
5		PIC_RemoveEvents(VGA_VerticalTimer);
6		PIC_RemoveEvents(VGA_VerticalDisplayEnd);
7		PIC_RemoveEvents(VGA_DrawPart);
8		PIC_RemoveEvents(VGA_DrawSingleLine);
9		vga.draw.width = width;
10		vga.draw.height = height;
11		vga.draw.doublewidth = doublewidth;

Already tried that (there and at a few other locations), didn't help.

In VGA_KillDrawing too?

If you really like that patch maybe try to comment out the "if(!vga.demomode) {" in render.cpp. It will break the output but maybe it doesn't crash anymore. I didn't really know what I did there 😉

Or change the

1typedef struct {
2	struct { 
3		Bit8u red;
4		Bit8u green;
5		Bit8u blue;
6		Bit8u unused;
7	} rgb[256];
8	union {
9		Bit16u b16[256];
10		Bit32u b32[256];
11	} lut;
12	bool changed;
13	Bit8u modified[256];
14	Bitu first;
15	Bitu last;
16} RenderPal_t;

the 256 to higher values.

Got it!

In vga_draw.c, at the end of VGA_DrawSingleLine, I added a check for vga.draw.resizing, and while it is not a proper fix, it demonstrates the problem:

1    if (!vga.draw.resizing && vga.draw.lines_done < vga.draw.lines_total) {
2        if(readd) PIC_AddEvent(VGA_DrawSingleLine,vga.draw.delay.virtline);
3
4    } else {
5        RENDER_EndUpdate();
6    }

I don't have a complete overview of the vga hardware emulation, but it seems to be a race condition. Dual-core is the key: SDL event handlers run in a different thread on Linux (I checked that with gdb), so a race condition with the main emulation loop is possible, and dual-cores exhibit those more readily.

The reason why this isn't enough is that at certain cycles values, it still crashes, at other values there is heavy flickering in lemmings, where there is a palette change mid-screen, and sometimes that palette switch gets "stuck", i.e., doesn't happen anymore. Quite typical for a race condition, although I don't understand the code well enough yet.

Just a note.
With latest DOSBox 0.72 CVS build from ykhwong and machine set to demovga, Pinball Fantasies show correct colors in table select menus. 😎

Miki Maus wrote:

Just a note.
With latest DOSBox 0.72 CVS build from ykhwong and machine set to demovga, Pinball Fantasies show correct colors in table select menus. 😎

The demovga option does not seem to want to work in fullscreen with direct3d. It would be perfect if these two options could be made compatible.

Update:

- new approach that should have less issues
(translate to 16bpp instead of changing the renderer palette)
- updated to apply to CVS

To activate:
machine=vgaonly

ibmtiming is replaced by:

[cpu]
screenflip=value

(useful values are 0-1500 or thereabouts, 0 is default, it's the microseconds delay of latching the new screen address, change it if you have a game with flicker issues).

Nice, thanks!

Little hack for DoWhackaDo in scanline emulation mode.

Fix for the Wish demo (they use both A0000 and B0000 for video memory access)

MasterBlazer (ballblazer for PCs) does multiple palette shifts during gameplay. it's a good test case.

zaphod77 wrote:

MasterBlazer (ballblazer for PCs) does multiple palette shifts during gameplay. it's a good test case.

So did you test it? Or just recommend someone else does?

JAL

"Copper" relies on a fancy dac or crtc programming, some effects don't work with vgaonly (after copper bars, there should be stretching of a helicopter screen but it remains static, also "zooming" effect is problematic)
http://www.pouet.net/prod.php?which=2048

Also I couldn't get proper colors in Pinball fantasies yet (I tested using only latest version) 🙁

Great patch btw.

edit: The "Plasma" intro
(ftp://ftp.scene.org/mirrors/hornet/demos/1992/plasma.zip)
draws only one line if machine is set to "vgaonly". Draws full screen with "vga". although with graphical issues.