pouët.net

DOSBox fork for retrocoding and emulation accuracy

category: general [glöplog]
Quote:
knoeki: you like to add features for 0,1% of the user base? :)


No, I just prefer actual accurate emulation rather than a bunch of hacks to get some arbitrary software running.
added on the 2015-03-17 19:28:56 by ___ ___
Quote:
you like to add features for 0,1% of the user base? :)


If the work has already been done, and it doesn't conflict with the other goals of the project (such as causing a massive performance hit that can't be disabled, or making the code impossible to maintain) - sure.
added on the 2015-03-17 19:29:01 by gasman gasman
Quote:
Scali: How about a keyboard shortcut to switch between composite/RGB CGA, and a configuration setting to startup on one or the other?


Sounds like a good solution!
added on the 2015-03-17 20:57:02 by Scali Scali
I just checked through the source code, there's already a shortcut key in the mapper to switch between CGA RGB and composite mode. It's not assigned to anything by default, but it's there. I just committed a change that allows you to pre-set composite emulation at startup: machine=cga_composite. You need to go into the keymapper and assign a keyboard shortcut to "CGA Comp".
Quote:
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.


As far as I can tell that demo is making no effort whatsoever to time vertical retrace. Not even programming IRQ 0 to match it. A lot of late 1990's demos using VESA BIOS calls have that problem, except for some that figured out SVGA page flipping through the VESA BIOS. Some demos work fine but have tearline problems only if you use the dynamic core in DOSBox-X.
The tearline problem is not only on the dynamic core, probably because of low resolution timers...
added on the 2015-03-19 19:42:21 by raer raer
Wonder if you can make Copper by Surprise!Productions run correctly? This one really needs to be emulated, but you know... it uses some really obscure VGA trickery that isn't emulated by DosBox for obvious reasons.
added on the 2015-03-19 21:19:48 by TomoAlien TomoAlien
I'm currently coding for ModeX VGA (486 target) in OpenWatcom too, mostly C, assembler (using pragma aux or at least omitting stackframe BS) where needed.

I'm pretty happy with DOSBox, it's quite accurate, especially shit like VGA register out write timing. That is expensive on the real deal (I got a GUS/TSENG dx2 rig here) and DOSBox reflects that.

It's still a bit hit/miss though, some artifacts just aren't your fault.

What works well for me is devving on 2 DOSBox boxes (1 fast PC and 1 older MacBook), the older MB misses frames easily if you fuck up or if it's just slow or MIDAS has beef with the mixing code (tip: use SB to test performance) so I very quickly tended to fixing my timing and double/triple buffering stuff correctly.

I test on real HW about every 2 days.

I've modified and rebuilt DOSBox in the past to add VESA modes and whatnot but it seems to understand ModeX just fine, given that you're a good boy who reads the Black Book, and it's in some ways at times a better testing platform than that one 486 and it's turbo button.

Having said that, I'm open for questions and advice equally and I'll release the full source (github pull, preinstalled OpenWatcom and DOSBox configs for OSX & Win) after Revision for everyone to piss on or have fun with.
added on the 2015-03-19 21:45:34 by superplek superplek
Quote:
Wonder if you can make Copper by Surprise!Productions run correctly? This one really needs to be emulated, but you know... it uses some really obscure VGA trickery that isn't emulated by DosBox for obvious reasons.


I've tested that, yes. It works in DOSBox-X. It's traditional VGA raster trickery. You change something per scanline to do copper effects. There's an additional option you'll need to enable for DOSBox-X to emulate the wavy effects it does by screwing with the CRTC hsync start register of the VGA.
Quote:
Wonder if you can make Copper by Surprise!Productions run correctly? This one really needs to be emulated, but you know... it uses some really obscure VGA trickery that isn't emulated by DosBox for obvious reasons.

You will need to run this demo with a low cycle count (below 10000) because it uses a software delay in it's Adlib FM detection routine. Anything faster will not have music. Also do not use the forcerate option because music tempo is tied to the 70Hz refresh rate.
Quote:
Tjoppen: Unfortunately they are very hostile towards accepting anything that fixes things that are not games...

This is why we invented the ever-useful passive-aggressive bug report :]
added on the 2015-03-23 13:04:09 by Tjoppen Tjoppen
It would be cool if I could set up that I want 386/486 sx/dx, on specific mhz. Might not be the most accurate, but still cool if I could.
added on the 2015-03-23 13:13:17 by Optimus Optimus
Quote:
It would be cool if I could set up that I want 386/486 sx/dx, on specific mhz. Might not be the most accurate, but still cool if I could.


You could look at PCem for that: http://pcem-emulator.co.uk/
added on the 2015-03-23 17:14:26 by Scali Scali
I posted the latest version of DOSBox-X that might interest some people here. I found two demos that refused to run no matter what: "Digital Dreams" and "Radioactivity".

The "Digital Dreams" demo has anti-debugger code that mistook DOSBox's INT 1 and INT 3 vectors as a debugger because they didn't point to an IRET instruction.

"Radioactivity" refused to run because it thought EMM386.EXE was running even if ems=false. It turns out it's detection method was checking to see if INT 67h was NULL or not.

You can now run these two demos in DOSBox-X without problems.
Let me know when 8088 mph runs in DOSBox-X :)
added on the 2015-04-05 22:41:13 by Scali Scali
Quote:
Let me know when 8088 mph runs in DOSBox-X :)


It does have machine=cga_composite. Most of the parts work, a few parts trigger the composite mode, and some parts cause DOSBox-X to resize it's video window constantly between 640x2 and 1280x2 (what are you doing? Is this hacking the active display width per scanline like DoWhackaDo but on CGA??)

Challenge accepted :)
sorry, I meant a few parts fail to trigger the composite mode.
You'll also need to be able to emulate the 8088, CRTC and CGA memory waitstates cycle-exact for some effects to work properly (such as Kefrens bars and modplayer).
These parts don't even work correctly on any clones we've tried, even though they were 4.77 MHZ 8088 + CGA clone.
IBM 5150/5155/5160 will work though, as long as you also have a real IBM CGA (and old style CGA is the palette that the demo is designed for. New style CGA card will work properly timing-wise, but some colours will be wrong).
added on the 2015-04-05 23:09:58 by Scali Scali
That will take some time, but I'll keep it as a goal.

https://github.com/joncampbell123/dosbox-x/issues/44
how to setup PCem v9?
after launching app I see message:

No ROMs present!
You must have at least one romset to use PCem.
added on the 2015-04-06 08:18:49 by g0blinish g0blinish
I don't maintain PCem (because I can't get it to compile for Linux) but I know you have to download some ROM BIOS images for PCem to use. I believe the site can point you to where they have various 286, 386, and 486 BIOSes you can use, including the 1994-ish one with a "graphical user interface".
nope^(
I downloaded all ROMs, seems PCem doesn't detect one.
added on the 2015-04-06 09:53:28 by g0blinish g0blinish
Look at PCem's source code. It expects the BIOS images to exist in very specific locations relative to where you run the program.
gotcha\o/

place pcxt.rom to folder genxt.

but imho DosBox with debugger is good for catching bugs.
added on the 2015-04-06 11:34:09 by g0blinish g0blinish
bootable images here:
http://monkey-hole.co.uk/esa/os/
added on the 2015-04-06 12:00:01 by g0blinish g0blinish

login