Interview with Qbix - 30 April 2008

This is the third in a short interview series which began in March.

So, today I'm talking to Qbix, who (to the best of my knowledge) has never worked on a game. Instead, he works on the DOSBox project which lets all of us play DOS games! Awesome! So, what is your role in the development of DOSBox?

I'm one of the two project administrators. I'm the one who does most of the non-coding stuff like answering these questions. I try to keep DOSBox in a healthy state. So that includes doing (within the time constraints): answering emails, reviewing code patches, managing the forum (code wise) and coding on DOSBox itself.

How and when did the DOSBox project get started?

DOSBox was started around the time Windows 2000 was released. Windows 2000 didn't allow DOS games to be played very well, but it was a real improvement in terms of stability and security compared to Windows 98 SE. So it was bound to stay. This was bad news for both long time DOS game collectors and players.

Harekiet was at the time playing around with creating a few emulators. He had a z80 emulator and a few others. So he decided to create a DOS emulator. Windows 2000 didn't have an easy to use visualization API. So he decided to go with full CPU emulation. After a short time I joined up, as he had made me enthusiastic during all the talks we had.

How does DOSBox actually work? I mean, I know that it allows me to play DOS games, but how does it do that? Is it a Virtual DOS Machine (VDM) that allows real and protected mode DOS software to be run in a non-DOS operating system, which also emulates system, sound and video hardware?

DOSBox isn't a VDM, DOSBox is actually a full-blown PC emulator. So we emulate the CPU, timer, interrupt controller, sounds cards, video cards, BIOS, videobios and to make things easier to the end user: DOS, EMS client, XMS client, Mouse driver. Of course most of those details and emulated systems are hidden from the user.

DOSBox was designed to only emulate the features games needed, but currently we have almost emulated everything as every game is different and uses different features. We still don't emulate the rotation of the interrupt controller chip as no game depends on/uses that. It is interesting to read the logs of the development and see in which order parts were added/modified in order to support more games.

The emulation of the mouse, EMS, XMS and DOS happens with C/C++ code and not Assembly. This makes DOSBox different from other full PC emulators (and results in a lot of free conventional memory). To make this possible we have introduced an extra CPU instruction that isn't present on a real CPU. When this special instruction is emulated, DOSBox looks up the next instruction which contains a number of which C function should be executed. (All those C functions are stored in a table with their number). This makes it possible for us to code a mouse driver in C (which is easier/faster to write than ASM) and make it behave like a real loaded mouse driver. From these functions it is possible to read and modify the emulated CPU registers and the emulated memory. This system is also used to emulate most of the BIOS and VIDEO BIOS functions.

The emulated cycles in DOSBox are very important as they are responsible for the high resolution timing as well. The cycles are the amount of CPU instructions DOSBox attempts to emulate each millisecond. From SDL we get 1 ms(1000 Hz) timers. We interpolate this 1 ms to smaller intervals using the emulated cycles. For example if a game wants a 0.1 ms(10000 Hz) timer and DOSBox runs on 3000 cycles then we emulate 300 cycles and afterwards we run the timer; we emulate another 300 cycles and timer again. This way the game thinks the timer runs on 0.1 ms. This "high" resolution timer solution is very important for the sound card detection as well. The importance of the emulated cycles was one of the reasons why autocycle guessing took a long time to develop. Your machine has to be able to actually handle amount of cycles DOSBox guesses as else the timing provided to the games will mess up. The cycle guess code has had quite a few revisions already. Each revision makes it more complicated and takes into account more and more situations.

Windows XP's version of NTVDM (a Virtual DOS Machine that also attempts to emulate a Sound Blaster 16) plays many DOS games pretty well, but it can't always emulate the sound hardware. Vlad Romascanu wrote an SB16 emulator for NT-based Windows called VDMSound, which I've read was incorporated into the SB16 emulation in DOSBox. Is that correct?

Well they share the same OPL emulation (the Adlib part). Aside from that they are different (so the SoundBlaster emulation itself is different).

DOSBox seems to emulate VESA-standard SVGA, but it doesn't natively support proprietary SVGA chipsets. There's a Multiple SVGA Chipset patch that seems to work pretty well, especially when emulating the Tseng Labs ET4000. Is that not part of the standard build because it isn't complete enough yet? Are there plans to incorporate it in the future?

Yes in fact they are already inside the current development source of DOSBox (together with EGA and vgaonly). vgaonly is a special mode in which some obscure tricks programmers used are supported (like changing the palette during the screen updates (Lemmings title screen and kellogs)). EGA emulation is a nice feature as well. VGA isn't 100% the same as EGA after all. This allows, for example, Gaunlet II to run in EGA mode. It used to run only in CGA mode.

Sierra added DOSBox to their recent "Quest" compilations, which I assume DOSBox doesn't get any royalties for. Most open source projects have a license that prohibits commercial use so that people can't profit off of their work. Is it legal to include DOSBox in commercial software?

It is legal to do so. It is frustrating if they don't contact you about it: If something doesn't work people do end up knocking on our door. (Sierra didn't even respond to emails sent by us afterwards).

The status page shows that DOSBox is close to 100% in emulating almost everything that DOSBox does. What does the future hold for DOSBox?

SAVESTATES hopefully. There are still tons of classics that I never finished. Dangerous Dave for example. Currently I'm playing Supaplex and when I mess up just before the exit I sometimes wish that DOSBox had savestate support.

Other things:
Even better game compatibility.
Maybe some exotic stuff like Glide emulation.

Yeah, Dangerous Dave is pretty hard to complete. I always get greedy and go to the secret areas, but I usually lose a life to those invisible gaps in the platforms. :(

I've been impressed by how well Windows 3.1 runs in DOSBox. Is emulating hardware that Windows 3.1 may need one of the project's priorities, or is the focus 100% on running DOS software, and it's just a nice bonus that it happens to emulate a DOS environment well enough to also run Windows 3.x?

It's a bonus, sometimes we fix something specifically for win3.11, but only if it doesn't have a negative impact for speed or compatibility. Some other versions of Windows work as well. Win2.x and we actually know (and can fix) what is wrong with DOSBox for Windows 1.x but currently we have no reason to add support for that. Using disk images, it is even possible to run Windows 95 running Starcraft on DOSBox. That is kind of nice, but not currently a goal of DOSBox. With some patches (that are currently developer-only) you can even run (to some degree) Linux, NetBSD and Windows NT4 in DOSBox. A nice test for our hardware emulation, but again not a goal of DOSBox.

Does DOSBox run better, the same, or worse in Windows Vista? Is DOSBox pretty much OS-independent (and just needs an x86 processor to be present), or is there a possibility that future versions of Windows might break DOSBox or require massive changes to maintain compatibility?

Well DOSBox doesn't need a x86 present at all, else it wouldn't run on the old PPC Macs or the PSP. DOSBox is mostly OS independent, CD-ROM support using your real drive is an exception though. For Vista it works just as well as XP, aside from the fact that CD-ROM support using your real drive is somewhat broken. We are working on that, but for compatibility reasons it is always advised to use CUE/BIN images (even on XP).

I don't expect future versions of Windows to break DOSBox. We don't rely on the host for compatibility so we need no changes there either.

So DOSBox is a PC emulator. In that case, would it be possible to use code from MAME/MESS? Instead of using clock cycles, you could have DOSBox emulate a 8088/286/386, etc.

It's not that simple I'm afraid, the biggest problems are actually the callbacks I described earlier. Those are executed in C code and take only 1 clock cycle. Adding the correct amount for each of them and for each of their subfunctions isn't (easily) doable. Calculating the right amount of clock ticks for each regular instruction would slow down DOSBox as well.

Any hints about when the next version of DOSBox might come out?

No I don't know yet when I will release the next version. We recently did an internal beta release in order to determine if all the changes we made did happen to break a game. But I have no intention of making that release a public one.

Is there anything else you'd like to say or anything that you'd like to promote?

I would like to thank you for this interview. It's nice to be interviewed by somebody who wants to keep DOS games available and playable.

Thank you very much for your time, and best wishes for the DOSBox project and everyone involved!

The official website of the DOSBox project is DOSBox.com.

Visitors can discuss the interview or ask new questions in this interview's forum thread.