DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-19 @ 07:58

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-23 @ 01:48

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/maste ... 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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-23 @ 01:58

hail-to-the-ryzen wrote:In pic.cpp:
Code: Select all
   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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-4-23 @ 02:59

Great!
hail-to-the-ryzen
Newbie
 
Posts: 81
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-23 @ 14:02

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-23 @ 18:21

hail-to-the-ryzen wrote:This line is repeated 2x in cpu.cpp:
Code: Select all
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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-4-24 @ 00:29

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.
hail-to-the-ryzen
Newbie
 
Posts: 81
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-4-24 @ 01:35

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:

Code: Select all
      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.
hail-to-the-ryzen
Newbie
 
Posts: 81
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-24 @ 02:01

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_SetTitle() (sdlmain.cpp). It appears 5x, but an example:

Code: Select all
      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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-4-24 @ 02:07

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.
hail-to-the-ryzen
Newbie
 
Posts: 81
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-4-24 @ 03:17

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!
hail-to-the-ryzen
Newbie
 
Posts: 81
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2017-4-25 @ 05:19

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?
hail-to-the-ryzen
Newbie
 
Posts: 81
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-25 @ 10:04

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 13:15

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:

Code: Select all
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-4-25 @ 13:23, edited 1 time in total.
emendelson
Oldbie
 
Posts: 697
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby Scali » 2017-4-25 @ 13:17

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.
Scali
l33t
 
Posts: 2974
Joined: 2014-12-13 @ 14:24

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-25 @ 14:18

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 this form:

Code: Select all
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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 14:23

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.
emendelson
Oldbie
 
Posts: 697
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2017-4-25 @ 14:28

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.
User avatar
TheGreatCodeholio
Member
 
Posts: 438
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby emendelson » 2017-4-25 @ 14:56

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-4-25 @ 15:11, edited 1 time in total.
emendelson
Oldbie
 
Posts: 697
Joined: 2010-2-14 @ 02:00

Re: DOSBox-X branch

Postby Dominus » 2017-4-25 @ 15:10

You just need to stop using those project files but use mingw(64?) for this ;)
User avatar
Dominus
DOSBox Moderator
 
Posts: 7372
Joined: 2002-10-03 @ 09:54
Location: Vienna

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest