DOSBox fork for retrocoding and emulation accuracy

category: general [glöplog]
I've been developing a fork of DOSBox for awhile now called DOSBox-X. The goal is to make emulation as accurate as possible and allow a lot of choices to emulate whatever PC hardware combo you want.

I run a lot of old demoscene stuff against it to test it since old demoscene programs are usually very picky about hardware. I'm building a part of the DOSBox-X Wiki to list ideal dosbox.conf settings and tips to get old demos to run.

Github project

For retrocoding I also made DOSLIB as a reference source base for writing DOS programs using the Open Watcom compiler. There's probably plenty of mistakes but I think I've made good progress so far.

How accurate do you intend this fork to be?
added on the 2015-03-17 10:12:57 by mudlord mudlord
As accurate as I can make it. Good enough hopefully that you can develop against DOSBox-X, and reasonably expect it to run on the actual hardware. I have some old 486/Pentium/PII hardware lying around that I can use as a "gold standard" for how hardware should behave.

A lot of the accuracy work so far has gone into VGA, Sound Blaster, keyboard, timer, and CPU timing. It's good enough for old demos to do VGA raster trickery that the original DOSBox can't handle very well, for example, the "truecolor" trick in Majic 12's "show" demo. Also to document what the hardware is like.
Sorry, I meant I already use the old hardware as a reference for emulation.
Make sure to have very acurate cycle timing and high resolution timers on all systems. What I often encountered in demos from the 1996-2000 era is that they time the display refresh cycle and then use that interval to update the display without actually waiting for display refresh. This causes heavy tearing when caturing. Bomb - State of mind is an example.
added on the 2015-03-17 10:30:32 by raer raer
And kudos for doing the fork! Demo emulation in DOSBox is lacking, which is sad...
added on the 2015-03-17 10:31:34 by raer raer
can we have a compiled version ?
added on the 2015-03-17 10:33:41 by Barti Barti
Hm, my demo testing says that's not specific to 1996-2000 demos. There are some demos in the 1992-1994 era that time vertical retrace as well. Crystal Dream II does it, then uses it to follow your VGA raster while drawing and page flipping, but it gets the retrace wrong when you use the dynamic core and things flicker on the screen.
Sure! Compiled versions are in the Releases section of the Github project.
Compiled builds are for Windows 32-bit and 64-bit made with Visual Studio 2008. Otherwise primary development is done from Linux.
I just want to applaud your efforts as I think improving DOBbox's compatibility be able to run old demos (and probably some games) like you're doing is a valiant effort.

Could also be very cool in conjunction with something like this http://www.pouet.net/topic.php?which=9288&page=1.
added on the 2015-03-17 10:47:46 by Canopy Canopy
really good job, I'm actually working on TCF mine 4k full dos asm, and it runs fast, faster than any versions of dosbox.
added on the 2015-03-17 10:56:42 by Barti Barti
Do you plan on getting your changes merged into DOSBox? Spontaneously I think that would be a good goal, to reduce fragmentation. Unless of course the DOSBox has some kind of philosophical difference with getting demos to run properly..
added on the 2015-03-17 11:21:08 by Tjoppen Tjoppen
the DOSBox team*
added on the 2015-03-17 11:21:35 by Tjoppen Tjoppen
One thing I would like is proper CGA composite emulation.
DOSBox treats CGA as a single display... which it isn't.
It is more akin to a C128, where you have a composite output and an RGBI output.
WinVice solves that by simply having two separate displays... which is what things look like in reality.
CGA could use something like that as well. Or at least some way to switch monitor-types on-the-fly. DOSBox currently tries to detect whether composite is required by monitoring register writes.
This is not accurate, as composite is simply 'always on' when you have a composite monitor connected.
added on the 2015-03-17 11:41:45 by Scali Scali
BB Image
added on the 2015-03-17 11:48:22 by psenough psenough
Tjoppen: Unfortunately they are very hostile towards accepting anything that fixes things that are not games...

TheGreatCodeholi: Would be cool to incorporate the existing MMX patches, to get things like Impulse Tracker's SB16+Filter driver running.
Great to hear someone is improving on teh box of teh Dos =) BB Image

I analyze this thing for myself for quite a time and know some issues. Maybe i'll contribute ;)
added on the 2015-03-17 13:21:35 by HellMood HellMood
How do those changes compare to the Daum fork (which is already much more advanced than vanilla DB) and do you plan to merge your changes with his?

As for improvements: Better MMX support would be high on my list as well.
added on the 2015-03-17 13:52:50 by tomaes tomaes
Thanks for the new Win32/64 builds. I've found that recent builds of DosBox-X and Daum have a lot in common. The number of config settings has gotten out of control, but I'm grateful for the in-program menus. Still, it would be nice to have tuned presets for various systems, like 8088 XT, 386/VGA, 486/SVGA, etc.

Regarding the tearing, I find that setting forcerate=60 helps. But that can sometimes cause timing issues.
added on the 2015-03-17 17:21:43 by phoenix phoenix
phoenix: Sometimes Daum will merge changes from my branch, and later I'll merge some changes from his. Then every so often I'll check what the main DOSBox branch has committed and incorporate some of their changes too. All the configuration options are there so you can do what it takes to get the demo/game to work. I plan on adding presets, but to accomplish that I have to disentangle initialization order from their section-based configuration code.

Scali: How about a keyboard shortcut to switch between composite/RGB CGA, and a configuration setting to startup on one or the other?
Tjoppen: Unfortunately they are very hostile towards accepting anything that fixes things that are not games...

That is utterly fucking retarded.
actually another reason for all the options is so that when you are retro-coding, you can test your program under a wide variety of situations. Such as, what if my code fails to turn on the A20 gate, there's less than 512KB RAM, the IO or video RAM is slow, the VESA BIOS offers 24bpp instead of 32bpp or only 8/16bpp or doesn't offer 320x200 highcolor modes, etc.
knoeki: you like to add features for 0,1% of the user base? :)
Well, the thing is that officialy DOSBox is only a games emulator. There have been people in the past using it to try to get their old business database system from the stoneage to run and managed to break stuff, which I guess is one of the reason why the authors decided to not support anything that's not a game. For a similar reason there is no official MMX support in DOSBox (there are virtually no DOS-only games that require it, plus it requires more maintenance effort from their side for a hardly used feature). Yay for unofficial branches.
Solution: Make a game with your demo effects!