DOSBox fork for retrocoding and emulation accuracy
category: general [glöplog]
how to manage with .img?
copy files via .ima as floppy drive?
copy files via .ima as floppy drive?
Hohoo, thanks for working on such a thing! :-) Checking it right now.
Congrats for the initiative, man.
Maybe I'm dumb... I built this on my Fedora (21) machine and it went fine. Installed using 'sudo make install' and everything seems to work.
But there is no dosbox*.conf anywhere... Runing the -userconf option doesn't create the full .conf file with all parameters.
Can I just use a .conf file from mainline/SVN? What are the extra settings in your branch that I want to be able to edit?
But there is no dosbox*.conf anywhere... Runing the -userconf option doesn't create the full .conf file with all parameters.
Can I just use a .conf file from mainline/SVN? What are the extra settings in your branch that I want to be able to edit?
If DosBox maintainers aren't interested perhaps Bochs ones are, I always thought that Bochs provided more accurate emulation than DosBox.
Quote:
Maybe I'm dumb... I built this on my Fedora (21) machine and it went fine. Installed using 'sudo make install' and everything seems to work.
But there is no dosbox*.conf anywhere... Runing the -userconf option doesn't create the full .conf file with all parameters.
Can I just use a .conf file from mainline/SVN? What are the extra settings in your branch that I want to be able to edit?
There's so many options, so by default it does not write the option unless changed from it's default. You can write out all the options to dosbox.conf: "config -all -wc dosbox.conf".
Quote:
If DosBox maintainers aren't interested perhaps Bochs ones are, I always thought that Bochs provided more accurate emulation than DosBox.
Well, having played with Bochs, I can say it has some of the most accurate CPU emulation out there, but the rest of the hardware emulation is so-so, and the Sound Blaster emulation is terrible. If I remember correctly there's a reference in the Linux kernel IDE driver about Bochs and it's weird IDE emulation (you can get a completion IRQ right before the next instruction when you write the command to port 1F7h). But it's quite good if you want to play with some of the latest Intel Core AVX instructions and debug your custom OS switching into 64-bit long mode! DOSBox CPU emulation is slightly less accurate, but it has much more accurate Sound Blaster, GUS, and VGA emulation. Accurate enough to handle most of the VGA raster trickery out there. Also the native DOS kernel emulation means you don't have to fiddle with hard disk and floppy boot disk images to run a demo.
Quote:
Well, having played with Bochs, I can say it has some of the most accurate CPU emulation out there...
DOSBox CPU emulation is slightly less accurate, but it has much more accurate Sound Blaster, GUS, and VGA emulation.
Time to put the two together, and make the first semi-decent PC emulator?
Quote:
Time to put the two together, and make the first semi-decent PC emulator?
Perhaps. There's the question of DOSBox's "cores" and runtime changeable cputype vs Bochs design where the CPU chosen is statically compiled into the executable. So it might be more copying and adapting bits of code back and forth between Bochs, DOSBox, QEMU, etc. to continue development. I'm not sure if Bochs has the event system DOSBox's hardware emulation depends on for PIC events or VGA retrace tracking.
Okay, I take back some of what I said. Bochs has grown a lot since I last played with it 5-8 years ago!
http://svn.code.sf.net/p/bochs/code/tags/REL_2_6_8_FINAL/bochs/CHANGES
http://svn.code.sf.net/p/bochs/code/tags/REL_2_6_8_FINAL/bochs/CHANGES
What did you mean by 'accurate' CPU emulation by the way? Did you mean that it supports the most instructions, or that it actually tries to be cycle-exact?
Because if it doesn't try to be cycle-exact, then I think PCem may be the best starting point for a proper PC emulator.
Like DOSBox, it aims to emulate the whole hardware accurately, including raster timing and such, for demos/games.
The hardware emulation is not quite as mature yet as DOSBox is, in some areas. On the other hand, it has the beginnings of cycle-exact emulation of the CPU on a per-instruction basis (and you can select the CPU type and speed within the program).
Because if it doesn't try to be cycle-exact, then I think PCem may be the best starting point for a proper PC emulator.
Like DOSBox, it aims to emulate the whole hardware accurately, including raster timing and such, for demos/games.
The hardware emulation is not quite as mature yet as DOSBox is, in some areas. On the other hand, it has the beginnings of cycle-exact emulation of the CPU on a per-instruction basis (and you can select the CPU type and speed within the program).
In other news... I've been playing around a bit with PCjr/Tandy, and I found that DOSBox doesn't handle sample playback on the SN76496 very well. Eg Skate or Die or One on One.
The samples are played from a timer interrupt, where the 4-bit volume register is poked as a 4-bit DAC (similar to what people do on C64/SID).
But the timing in DOSBox isn't accurate enough, making the samples very noisy.
I know you've improved some of the sound handling in DOSBox-X, for 'Goldplay' style replayers and such... But have you also looked at PCjr/Tandy? And if not, would it be very difficult to add support for it, based on your codebase?
The samples are played from a timer interrupt, where the 4-bit volume register is poked as a 4-bit DAC (similar to what people do on C64/SID).
But the timing in DOSBox isn't accurate enough, making the samples very noisy.
I know you've improved some of the sound handling in DOSBox-X, for 'Goldplay' style replayers and such... But have you also looked at PCjr/Tandy? And if not, would it be very difficult to add support for it, based on your codebase?
Quote:
In other news... I've been playing around a bit with PCjr/Tandy, and I found that DOSBox doesn't handle sample playback on the SN76496 very well. Eg Skate or Die or One on One.
The samples are played from a timer interrupt, where the 4-bit volume register is poked as a 4-bit DAC (similar to what people do on C64/SID).
But the timing in DOSBox isn't accurate enough, making the samples very noisy.
Is there anything in the demoscene that uses that trick? As I understand DOSBox's codebase, things normally used for music tend to be rendered at 1ms resolution (or is it SDL audio blocksize?). Or do I need to go get a copy of Skate or Die to test and develop this?
I meant that Bochs' CPU emulation is very accurate in emulating the instruction even though it's not very cycle/time accurate. They've got the entire x86 instruction set implemented.
Quote:
Is there anything in the demoscene that uses that trick?
Not yet... that's what I was working on :)
Quote:
Or do I need to go get a copy of Skate or Die to test and develop this?
Well, with Skate or Die I at least know it works properly on real hardware.
My own stuff is not very mature yet, and not yet tested on the real thing.
Quote:
I meant that Bochs' CPU emulation is very accurate in emulating the instruction even though it's not very cycle/time accurate.
Ah okay... Well, especially for demos, having cycle-exact instructions is very important.
When watching older demos, you sometimes need to adjust the cycle-count from one effect to the next, because some effects are more math-heavy, and rely on performance of mul/div, while others are more memory-limited.
So the mul/div routines will run much faster relatively than the other routines in DOSBox.
It also makes it impossible to do development/profiling/optimizing with DOSBox, because you don't even remotely get a decent indication of performance on an actual machine.
Looking at DOSBox's mixer code, I think I know how I can make that work. Right now DOSBox uses the SDL audio callback to render all the channels. While OPL and Tandy synthesis is accurate, the changes to it's state are quantized to the SDL audio block size. It doesn't matter if your program changes a volume register 22000 times a second if DOSBox reads it once every 48000/1024 = 21ms and renders 1024 samples of state per SDL audio callback. But if you look at GUS, OPL, Tandy, etc. mixer callbacks they're all quite capable of rendering one sample at a time. If I modified DOSBox's mixer code to call the mixer callbacks at the sample rate then feed it to the SDL callback from, all output would reflect changes from the software at enough resolution to get what you want, right? At a resolution determined by whatever output sample rate SDL chose, at least.
It would have to be an option to enable since calling down through the mixer callbacks 48,000 times a second is not the most efficient method of emulation, of course.
It would have to be an option to enable since calling down through the mixer callbacks 48,000 times a second is not the most efficient method of emulation, of course.
what about registering the state changes with their dates and modifying the audio rendering to take any change into account at the right time ?
not register but rather recording state change, sorry.. in some kind of ring buffer I presume
Quote:
what about registering the state changes with their dates and modifying the audio rendering to take any change into account at the right time ?
That would be the correct way to do it. My method could be implemented in half an hour as a temporary way to get what you want, until the correct way is fully implemented later.
Quote:
Looking at DOSBox's mixer code, I think I know how I can make that work. Right now DOSBox uses the SDL audio callback to render all the channels. While OPL and Tandy synthesis is accurate, the changes to it's state are quantized to the SDL audio block size. It doesn't matter if your program changes a volume register 22000 times a second if DOSBox reads it once every 48000/1024 = 21ms and renders 1024 samples of state per SDL audio callback.
Ah, that would explain why you hear something resembling the sample, but with weird distortion.
Quote:
If I modified DOSBox's mixer code to call the mixer callbacks at the sample rate then feed it to the SDL callback from, all output would reflect changes from the software at enough resolution to get what you want, right? At a resolution determined by whatever output sample rate SDL chose, at least.
Yes, I guess that could be 'close enough'.
Using this method you can't realistically play back at much more than 16 KHz, I think.
So if the code updates at 44.1 KHz or 48 KHz, it should work fine.
I guess it does show a more fundamental problem in DOSBox though: the audio engines are not designed to be cycle-exact, so kludges are required in various places (I recall your 'Goldplay'-fix as well... initially I thouht the Crystal Dream code may have been buggy, but the problem was all in DOSBox, and you had already fixed it).
Quote:
initially I thouht the Crystal Dream code may have been buggy, but the problem was all in DOSBox, and you had already fixed it).
Their code is buggy. I have notes on the DOSBox-X wiki on what's wrong with their code, and why their code doesn't work on SB16 cards, and what my code means by "nagging the DSP".
https://github.com/joncampbell123/dosbox-x/wiki/Demoscene:Crystal-Dream-by-Triton-%281992%29
Quote:
Their code is buggy. I have notes on the DOSBox-X wiki on what's wrong with their code, and why their code doesn't work on SB16 cards, and what my code means by "nagging the DSP".
Yea, the init code was very buggy. But I patched that.
It's just that it still sounded weird in DOSBox, even though it now worked fine on real hardware.
I thought it was because of the way they set up DMA (DOSBox gives you some warnings in the debug window), but turns out that it wasn't that, but rather DOSBox not emulating the DSP quickly enough to keep their DMA-hack working.
OK. The change still stands, but I was wrong about what unit of time DOSBox quantizes by. Digging deeper, DOSBox uses a unit of 1ms for mixing audio, NOT the SDL audio blocksize. The mixer code renders from a callback set by TIMER_AddTickHandler which renders 1ms fragments into a buffer for the SDL audio callback to pick up. Tick handlers in DOSBox are called once per 1ms.
The change implemented so far:
- "Skate or die" the guitar chords sound a lot clearer now, not so lo-fi and muffled, among the other two Tandy voices.
- This change and the Goldplay hack don't get along very well, in fact, not at all. Probably breaks the direct DAC Sound Blaster output too or any other part of the codebase that uses the "stretched" buffered audio output. :(
- GUS and DMA sound blaster appear to work fine in this mode. Gravis Ultrasound emulation matters here because I've noticed mid 1990's DOS GUS-based demos will sometimes have random echo/attenuation errors in the music because of DOSBox's coarseness in audio rendering.
- The hack as implemented so far doesn't sound very good if DOSBox can't keep up with realtime.
The change implemented so far:
- "Skate or die" the guitar chords sound a lot clearer now, not so lo-fi and muffled, among the other two Tandy voices.
- This change and the Goldplay hack don't get along very well, in fact, not at all. Probably breaks the direct DAC Sound Blaster output too or any other part of the codebase that uses the "stretched" buffered audio output. :(
- GUS and DMA sound blaster appear to work fine in this mode. Gravis Ultrasound emulation matters here because I've noticed mid 1990's DOS GUS-based demos will sometimes have random echo/attenuation errors in the music because of DOSBox's coarseness in audio rendering.
- The hack as implemented so far doesn't sound very good if DOSBox can't keep up with realtime.
...still 1KHz isn't really enough to make digitized audio.
what I did in oricutron is just log writes to ay registers including cycle timing. Then when the SDL callback kicks in I convert the cycle times to sample times and render the whole buffer. This gives very good audio.
In Dosbox you'd have to convert all the different sound card drivers to use this method, but the end result would be worth it, imho. It just depends on you having enough time to do all that work!
In Dosbox you'd have to convert all the different sound card drivers to use this method, but the end result would be worth it, imho. It just depends on you having enough time to do all that work!
Okay. How's this?
before change: http://192.168.250.1/sk8ordiedosboxx/before.mp3
after change: http://192.168.250.1/sk8ordiedosboxx/after.mp3
real hardware reference: https://www.youtube.com/watch?v=I8_z_CI37JE
before change: http://192.168.250.1/sk8ordiedosboxx/before.mp3
after change: http://192.168.250.1/sk8ordiedosboxx/after.mp3
real hardware reference: https://www.youtube.com/watch?v=I8_z_CI37JE