VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1180 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I think I may have discovered a new demo effect on CGA.

It turns out the CGA does not buffer the mode select register. You can change it mid-display and it takes effect immediately.

I have a screenshot and YouTube video of the VGA test program from DOSLIB running the effect on an 8088 CGA at the bottom of this issue tracker:

https://github.com/joncampbell123/dosbox-x/issues/256

Perhaps if you have a need to do a "splitscreen" with the upper half graphics and the lower half 16-color text.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1181 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote:
TheGreatCodeholio wrote:

I don't have the means to test MT32 emulation, so it will only end up in DOSBox-X if someone writes a patch or submits a pull request for me to merge.

There's a patch file already provided with the source code of MUNT: https://github.com/munt/munt/tree/master/DOSBox-mt32-patch

It does not apply cleanly to DOSBox-X, sorry.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1182 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:
In pic.cpp: […]
Show full quote

In pic.cpp:

	if (CPU_CycleLeft > 0) {
if (PIC_IRQCheck)
PIC_runIRQs();
...
}

if (PIC_IRQCheck)
PIC_runIRQs();

PIC_runIRQs runs 2x if CPU_CycleLeft >0. Is that as intended?

No, but removing it seems to break the Panic! demo. Visual effects run at half their normal speed.
I'll see how I can refactor this if possible.

EDIT: Moving that check into the if() block doesn't break anything.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1184 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I just found another potential performance boost. There's code inside the normal loop to call GetTicks() and compare against a 500ms interval just to maintain a FPS counter. Some performance could be gained by not calling SDL_GetTicks() that often, so I lifted it out to the top of the function. Can you confirm that improves performance?

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1185 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:
This line is repeated 2x in cpu.cpp: […]
Show full quote

This line is repeated 2x in cpu.cpp:

if (enable_cmpxchg8b) reg_edx |= 0x100; /* CMPXCHG8B */

It only looks like it's repeated 2X. The MSR and CMPXCHG8B checks are copy-pasta'd once for Pentium and Pentium MMX cases.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1186 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote:

It only looks like it's repeated 2X. The MSR and CMPXCHG8B checks are copy-pasta'd once for Pentium and Pentium MMX cases.

I see now, sorry about that.

I've been surveying all your recent commits! The real time meter looks very interesting, and I would think it would help the speed demo community (such as for Doom) that the emulation was running at the expected speed.

The change for potential performance looks interesting, too. I'll confirm that next.

Reply 1187 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

It is possible to further conserve space by changing the way "RunningProgram" is printed in the title bar. The lines are in GFX_SetTitle() (sdlmain.cpp). It appears 5x, but an example:

		sprintf(title,"%s%sDOSBox-X %s, %d cyc/ms, %s",
dosbox_title.c_str(),dosbox_title.empty()?"":": ",
VERSION,(int)internal_cycles,RunningProgram);

RunningProgram is set above with "%s", although some other lines use "%8s". Instead, it can change to "%.8s" so that shorter names are not padded with spaces.

Reply 1188 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:
It is possible to further conserve space by changing the way "RunningProgram" is printed in the title bar. The lines are in GFX_ […]
Show full quote

It is possible to further conserve space by changing the way "RunningProgram" is printed in the title bar. The lines are in GFX_SetTitle() (sdlmain.cpp). It appears 5x, but an example:

		sprintf(title,"%s%sDOSBox-X %s, %d cyc/ms, %s",
dosbox_title.c_str(),dosbox_title.empty()?"":": ",
VERSION,(int)internal_cycles,RunningProgram);

RunningProgram is set above with "%s", although some other lines use "%8s". Instead, it can change to "%.8s" so that shorter names are not padded with spaces.

What does %.8s do? I'm not familiar with that use of printf.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1189 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

I should have the performance test soon. With %8s, program name should always display 8 characters in the title bar, but with %.8s the maximum number of characters is 8 while the minimum number of characters is the length of program name. I didn't verify, but %8.8s should correspond to %8s.

Reply 1190 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Benchmarked in Quake with and without the recent FPS/RT meter code in dosbox-x. There appears to be no discernible cost in running the meters. I also tested by removing that code entirely and the effect is <1%.

Thanks!

Reply 1191 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Further tested the real time meter. I have two questions.

First, is the internal timings meter necessary now that the real time meter is now included in dosbox-x? I may have this wrong, but it seems that the real time meter is measuring the rate of ticks assigned to the emulator versus real time; and the internal timings meter is measuring the rate of ticks processed by the emulator versus that expected to occur in the emulator. So, the internal timings is internal to the emulator only while the real time meter is comparing against a real clock. If this is correct, then what would cause the emulation to fall behind on processing ticks?

The second question is about the real time meter in practice. I compared the dosbox-x page fault method (core=normal) to the vanilla dosbox method in the Quake timedemo. While the FPS was low, the vanilla dosbox method shows the real time meter at 100% with small deviations. It would sometimes show a value as low as 95%. However, in the dosbox-x method, it would deviate by values that were a bit larger, but more obvious are the dips to 92%. Could this be caused by a 5% difference in performance between the methods or is it possible that the page fault method could influence the emulation timings as compared to real time?

Reply 1192 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:

Further tested the real time meter. I have two questions.

First, is the internal timings meter necessary now that the real time meter is now included in dosbox-x? I may have this wrong, but it seems that the real time meter is measuring the rate of ticks assigned to the emulator versus real time; and the internal timings meter is measuring the rate of ticks processed by the emulator versus that expected to occur in the emulator. So, the internal timings is internal to the emulator only while the real time meter is comparing against a real clock. If this is correct, then what would cause the emulation to fall behind on processing ticks?

The second question is about the real time meter in practice. I compared the dosbox-x page fault method (core=normal) to the vanilla dosbox method in the Quake timedemo. While the FPS was low, the vanilla dosbox method shows the real time meter at 100% with small deviations. It would sometimes show a value as low as 95%. However, in the dosbox-x method, it would deviate by values that were a bit larger, but more obvious are the dips to 92%. Could this be caused by a 5% difference in performance between the methods or is it possible that the page fault method could influence the emulation timings as compared to real time?

Many things can slow down emulation speed vs realtime, including disk I/O, idle loops that check a variable constantly, or anything that doesn't decrement the CPU cycles count more than one value.

In vanilla DOSBox (and the code I just replaced) the FPS timing is checked once per instruction (in the inner normal loop before executing another instruction, while in DOSBox-X performance is gained (theoretically at least) by checking only once before going into a loop executing instructions. This loop can execute anywhere from a very short time to up to 1ms (one tick) in emulator time. The cost of this change is that the FPS and RT timing code cannot assume that they are executed exactly 500ms apart in emulation time.

Looking at how I have the internal timing code arranged right now, a guest page fault will prevent the "increaseticks" code from executing. I did that to avoid a goto jump from within to without an exception handler. It seems to me though the "increaseticks" label could be removed, and the "goto increaseticks" could be replaced with a "break" statement to just break out of the while(1) loop. If that's true, then the internal timing code could be moved out to the bottom of the function so that it always executes even after a guest page fault.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1193 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Just FYI: You asked for a Win32 build back there, so I gave it a try in VS2015 with current code. It gives a zillion errors in this form:

1>d:\development\dosbox-x-master\include\mem.h(135): error C3861: 'le16toh': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(138): error C3861: 'le32toh': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(141): error C3861: 'le64toh': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(148): error C3861: 'htole16': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(151): error C3861: 'htole32': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(154): error C3861: 'htole64': identifier not found

Those were the only errors, but they happened with each file that included mem.h. I suppose there's an easy fix, but I don't know what it might be.

Last edited by emendelson on 2017-04-25, 13:23. Edited 1 time in total.

Reply 1194 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t
TheGreatCodeholio wrote:

It turns out the CGA does not buffer the mode select register. You can change it mid-display and it takes effect immediately.

Yes, only the 6845 has latched registers. Everything else can be modified immediately afaik.
Same goes for Hercules by the way. You can switch pages and such mid-screen (DOSBox did not support this, because it only did per-frame rendering. I patched it to per-scanline, to be more exact. It needs to be per-pixel/cycle of course).

EGA and VGA are different, because they don't use a real 6845 with additional discrete logic. They use an 6845-ish integrated circuit, where the additional logic is also in there.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1195 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
emendelson wrote:
Just FYI: You asked for a Win32 build back there, so I gave it a try in VS2015 with current code. It gives a zillion errors in t […]
Show full quote

Just FYI: You asked for a Win32 build back there, so I gave it a try in VS2015 with current code. It gives a zillion errors in this form:

1>d:\development\dosbox-x-master\include\mem.h(135): error C3861: 'le16toh': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(138): error C3861: 'le32toh': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(141): error C3861: 'le64toh': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(148): error C3861: 'htole16': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(151): error C3861: 'htole32': identifier not found
1>d:\development\dosbox-x-master\include\mem.h(154): error C3861: 'htole64': identifier not found

Those were the only errors, but they happened with each file that included mem.h. I suppose there's an easy fix, but I don't know what it might be.

Visual Studio lacks endian.h. Those are macros to byte-swap a value to/from host to little endian. Since Windows is little endian, you could make a header file with defines for each one that just passes the value through unmodified.

http://man7.org/linux/man-pages/man3/endian.3.html

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1196 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
TheGreatCodeholio wrote:

Visual Studio lacks endian.h. Those are macros to byte-swap a value to/from host to little endian. Since Windows is little endian, you could make a header file with defines for each one that just passes the value through unmodified.

http://man7.org/linux/man-pages/man3/endian.3.html

I didn't realize it would be that easy, but even this is beyond my abilities. I hope someone else who is interested in this project might be willing to write this file. My totally ignorant sense of this is that it would need a very few lines of code.

Reply 1197 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
emendelson wrote:
TheGreatCodeholio wrote:

Visual Studio lacks endian.h. Those are macros to byte-swap a value to/from host to little endian. Since Windows is little endian, you could make a header file with defines for each one that just passes the value through unmodified.

http://man7.org/linux/man-pages/man3/endian.3.html

I didn't realize it would be that easy, but even this is beyond my abilities. I hope someone else who is interested in this project might be willing to write this file. My totally ignorant sense of this is that it would need a very few lines of code.

Sarcasm noted 😀
Endian byte-swapping macros are used, because we're emulating a little endian processor. That means byte order. I'm trying to write new code in a way that lets it write little endian bytes to the DOS VM even if the host processor DOSBox-X is running on is big endian.

Like this:

/* host to little endian. Windows is little endian, therefore no change */
#define htole16(x) (x)
#define htole32(x) (x)
#define htole64(x) (x)
/* little endian to host. Windows is little endian, therefore no change */
#define le16toh(x) (x)
#define le32toh(x) (x)
#define le64toh(x) (x)

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1198 of 2397, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

But I wasn't being sarcastic! I really don't know how to do this, and I wasn't asking you to do it! (It's always annoying when someone asks someone else to write something...) There are a lot of Win32 types around here who could write that file in three minutes if they wanted to build for Windows, as surely someone else will want to do. There was absolutely zero sarcasm - I'm too grateful for this project to be sarcastic about it!

Last edited by emendelson on 2017-04-25, 15:11. Edited 1 time in total.

Reply 1199 of 2397, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

You just need to stop using those project files but use mingw(64?) for this 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper