user222 wrote:

jal wrote:

Drawing the screen, especially a graphics screen, takes quite some time, since the internal buffers have to be converted to output suitable for your display configuration. I'm quite sure DOSemu does this as well.

Is it because DOSBox updates the screen continously, while other emulators, including DOSEmu, only update the screen when necessary. Continously updating the screen would definitely take a lot of CPU time, notice what happens when you keep scrolling the scrollbar up and down.

I'm pretty sure all emulators update the screen continuously, as it is very unusual for the screen not to be changed at all during a long period of time. Escpecially in games, the area DOSbox focusses on, the screen will be updated continuously.

A problem with not updating the screen at all when nothing changes, is that it would be difficult to maintain a constant speed without the emulator feeling irrisponsive or jaggy at times, as the OS has to dedicate variable processor speed and resources to the emulator.

JAL

Most emulators (including dosemu when running without direct h/w access) take the screen buffer and render it at some intervals. DosBox emulates the VGA chip as close as rendering single scan lines just like a real monitor would do.

I've been pondering the DOSBOX conundrum lately (lol) with regards to its demanding video emulation. I was remembering how my old Diamond Speedstar Pro ISA 1MB (FPM DRAM, 70-80ns) could run SVGA DOS games very well on a 486.

DOSBOX obviously must emulate a framebuffer like those old ISA VGA cards. A ISA card has like 10MB/s max theoretical bandwidth between it and the CPU. And that old FPM DRAM on probably a 32-bit bus isn't exactly lighting quick.

So, what on earth prevents DOSBOX from getting at least that kind of performance on modern systems? Is it that the APIs just don't let enough be accessed fast? I mean, we're not talking hundreds of MB/s necessary.....at least if it's comparable to ISA video cards. So what is the big bottleneck?

The bottleneck is that there is nothing to be transferred anywhere. Dosbox emulates the chip itself. It does not (can not / must not) program your real video hardware, apart from asking for a frame buffer at a given resolution. The rest, like scan line updates, palette setting, timing registers, how those bytes in the (emulated) frame buffers map to coloured pixels on your screen, and all the other gory subtleties of VGA chips are emulated by dosbox. That's quite a bit of work and has not much to do with moving the bytes around.

And before you ask, no it is impossible to use your hardware to do that processing. That's the point of emulation: not to use any hardware, because it could be incompatible/behave wrong/crash your PC/inaccessible.

How much does DOSBOX benefit from a big L2 cache? With tons of screen data being whipped around and everything else it sounds like latency would be a big concern. And now days we have chips with 1MB-2MB L2 cache a lot of times, and A64 S939's dual channel ~50ns latency RAM controller. Is this stuff that can be optimized for?

the problem is that its too cross platform &
it dousen't use any computer hardwere i think .it seems to be very lost in its own deep thinking relly .seems it trys to emulate too mouch or something i think

thier are meny good views here on how to look at the dosbox emu but all i can tell being the simple joe that i am is that when my p4 3000 mgz with 512 ram runs a dos game at like 486 33 mgz speed with crunchs

something needs to be optimzed

btw any one here ever try the project 64 nintendo 64 emulater. the thing had like a 93 mgz risk cpu and man it runs freewere demo roms better then dosbox can play warcraft2 ....

something needs to be optimzed

im just a simpe gamer passing by looking at things in a simple way

Since DOSBox uses SDL for all of its I/O, I would hope that it at least takes advantage of any accelerations/optimizations that SDL provides. If DOSBox is modular enough, I think it would be worth writing some more output modes that take advantage of OpenGL and/or Direct3D features for accelerating video emulation as much as possible. If OpenGL is used, it could even stay cross-platform.

jal wrote:

I'm pretty sure all emulators update the screen continuously, as it is very unusual for the screen not to be changed at all during a long period of time. Escpecially in games, the area DOSbox focusses on, the screen will be updated continuously.

A problem with not updating the screen at all when nothing changes, is that it would be difficult to maintain a constant speed without the emulator feeling irrisponsive or jaggy at times, as the OS has to dedicate variable processor speed and resources to the emulator.

Get "Screen Screw", a prank software. It continously draws lines on the screen. You'll notice it has a hard time covering up the DOSBox screen. It can cover up the screen of QEMU and VMWare when they're running MS-DOS, and in the DOS prompt. Move the mouse to the top left corner to exit "Screen Screw".

Get it here:
http://rjlsoftware.com/download/screenscrew.zip

I made simple modifications to DOSBox to update screen only when frame buffer is changed.
Originally CPU load was 100% in command prompt at my old K6-2-550MHz. After my modifications CPU load becomes ~30% (screen is updeted to draw cursor blinking).
But further modifications is needed - to update not whole screen, but only changed parts. Such approach will eliminate whole screen updates on mouse cursor move (for example).

Anonymous wrote:

I made simple modifications to DOSBox to update screen only when frame buffer is changed.
Originally CPU load was 100% in command prompt at my old K6-2-550MHz. After my modifications CPU load becomes ~30% (screen is updeted to draw cursor blinking).
But further modifications is needed - to update not whole screen, but only changed parts. Such approach will eliminate whole screen updates on mouse cursor move (for example).

Too bad that I don't even know how to compile or apply the patch at all. Can I get a binary file?