The last daum/yhkwong built is dated january 27th

Gui55 wrote:

Codeholio, about that last PM I sent you: I just confirmed it was a bug in your win32 builds; Whenever you try to mount multiple cd-rom images (.iso), with or without the IDE interface, DOSBox-X seems to crash. I fount this out by testing ykhwong's latest build against all of the DOSBox-X win32 releases, all with default dosbox.conf settings. Has anyone found this out on the Linux builds too, or is it only the Windows ones that do this?

Also, what do you mean by multiple cd-rom images? Do you mean multiple CD-ROM drives or do you mean multiple ISOs on one CD-ROM drive with disk swapping?

I just confirmed that DOSBox-X does not crash and handles multiple ISOs on one drive, and different ISOs across multiple CD-ROM drives. 32-bit Linux.

Same here. The CD swap function works perfectly.

Also, thank you for the recent additions to dosbox-x, especially the SB16 accuracy updates!

TheGreatCodeholio wrote:

I know that a few months ago I found several places where it was possible more than one array could refer to the same CDROM object, and cause segfaults when the object is deleted twice. I added code to detect that. Have you tried compiling a Win32 build of the latest DOSBox-X code?

No, I haven't. I just used the latest windows build of DOSBox-X that you compiled.

TheGreatCodeholio wrote:

Also, what do you mean by multiple cd-rom images? Do you mean multiple CD-ROM drives or do you mean multiple ISOs on one CD-ROM drive with disk swapping?

The latter; I simply type imgmount d: [ISO image1] [ISO image2] [...] -t cdrom -ide 2m and DOSBox-X crashes.

TheGreatCodeholio wrote:

I just confirmed that DOSBox-X does not crash and handles multiple ISOs on one drive, and different ISOs across multiple CD-ROM drives. 32-bit Linux.

truth5678 wrote:

Same here. The CD swap function works perfectly.

Also, thank you for the recent additions to dosbox-x, especially the SB16 accuracy updates!

Okay, so is it only the Linux builds that you both say work correctly? Or have either of you gotten the win32 builds to work correctly too? The "latest" win32 DOSBox-X build I'm referring to is this one:
http://hackipedia.org/Projects/DOSBox-X/dosbo … 97290-win32.zip

I've tested several win32 builds with CD swap emulation and all work. However, your imgmount command appears different than mine: imgmount d c:\dosbox\HDD\test_1.cue c:\dosbox\HDD\test_2.cue -t iso -fs iso.

Still no success. Oh well, I'll probably just wait and see if it will work in ykhwong's next SVN-Daum build (which I've been looking forward to for quite some time now! 😀 ) But anyhow, thanks for confirming that the win32 builds work for you.

Just an update: I just stumbled into the Sound Blaster emulation kludge in DOSBox that prevents the "Crystal Dream" demo's Sound Blaster support from working. See the NOTES in my latest commit, the details are ugly. When I complete more fixes to Sound Blaster emulation DOSBox will finally be able to run the demo the same way it used to work on real hardware!

I read your recent commit about the demo and its unusual way of timing audio playback. 😀 It's interesting in itself, but your debugging procedure is even more so. I wonder why there is a sample of early DOS games which relied on the true time to playback audio and not the sound card IRQ. Were the programmers trying to calibrate their game so it always ran in real time? However, your description of the problem was very clear and it's unfortunate that some of the related problems may have gone unnoticed due to incorrect hardware documentation.

TheGreatCodeholio wrote:

Just an update: I just stumbled into the Sound Blaster emulation kludge in DOSBox that prevents the "Crystal Dream" demo's Sound Blaster support from working. See the NOTES in my latest commit, the details are ugly. When I complete more fixes to Sound Blaster emulation DOSBox will finally be able to run the demo the same way it used to work on real hardware!

sweeet ! 😀

DOSBox-X is very exciting ! Thank you very much for your efforts !

truth5678 wrote:

I read your recent commit about the demo and its unusual way of timing audio playback. 😀 It's interesting in itself, but your debugging procedure is even more so. I wonder why there is a sample of early DOS games which relied on the true time to playback audio and not the sound card IRQ. Were the programmers trying to calibrate their game so it always ran in real time? However, your description of the problem was very clear and it's unfortunate that some of the related problems may have gone unnoticed due to incorrect hardware documentation.

Crystal Dream uses the same "Goldplay" technique I've mentioned before where instead of rendering audio in blocks to the DSP, it uses a hacked mode where the Sound Blaster DSP is told the block size is 65536 but the DMA controller is programmed in auto-init mode with a block size of 1 byte (or 2 if stereo), and then the demo has IRQ 0 (programmed to tick at the audio sample rate) update the one or two byte memory location with the latest audio sample. In this way, if you think about it, it allows the audio output code to support both Sound Blaster and LPT DAC, PC speaker, etc. without separate conditional code for one or the other so much.

What makes Crystal Dream exceptional about this is it's the first demo I've tested DOSBox-X against that uses Goldplay mode, but instead of setting up the usual IRQ to keep the Sound Blaster going, uses IRQ 0 instead to "nag" the Sound Blaster DSP into continuing playback. The way it does it clashes badly with the way DOSBox and DOSBox-X currently fakes DSP write status, and that's why audio output eventually stops.

Thank you for documenting this technique, its impact on the emulation, and solution. 😀 Many users compare the different emulators and how they run a few popular DOS games, but not realizing that the (vast) majority of the emulation work is related to running all the other ones.

Although not related directly, I read in another post about IRQ 0 used to time audio (MIDI) events in a Legend adventure game: Missing music in Gateway (MT-32 mode). This is a quote out of context, but I think this is the limitation as discussed by ripsaw: "...the PIT declining to activate IRQ 2 because IRQ 0 is active". However, in this case, the issue had been reproduced in real hardware, at least in some models.

Got it!

The latest commit is able to run the demo flawlessly.

Video capture (SB mono): http://jon.nerdgrounds.com/dl/dosbox-x/crysta … xed_sb_mono.avi
Video capture (SB Pro stereo): http://jon.nerdgrounds.com/dl/dosbox-x/crysta … bpro_stereo.avi

Thank you for the additional Sound Blaster accuracy updates! I mainly tested with sb16 and the audio sounds great (in both SC2000 and Quake), and I look forward to testing your many additions to sb emulation which will provide greater compatibility in the older DOS games or while selecting the other sb types.

Also, that's wonderful work on making the above demo work in dosbox-x! 😀 I listened to the audio recordings and they sound perfect.

More sound blaster study: https://www.youtube.com/watch?v=9rCV4B4ylOs&feature=youtu.be

BTW, I tried running "Internal Damage" in DOSBox-X and I stumbled across some very hacky behavior with the demo's Sound Blaster support and I need someone out there with an old Sound Blaster 1.x or 2.x (not Pro) to verify this:

When you run the demo and select "Sound Blaster" output, it will hang (just like it does on real hardware). Apparently the reason it hangs is that it seems to rely on using I/O port 22Dh for DSP reading/writing, rather than I/O port 22Ch. DOSBox debug builds will spew a lot of "unhandled sound blaster read" messages at that point while the demo is trying to send a DSP command (again, to port 22Dh!). I noticed that all the original Sound Blaster I/O ports sit at even addresses (0x22A, 0x22C, 0x22E), and I wonder if the EMF got away with the hack only because the original Sound Blaster simply ignored bit 0 of the I/O port and decoded only the upper 3 bits i.e. decoded 22Dh as 22Ch, 22Bh as 22Ah, etc. Can anyone out there pull out an ancient Sound Blaster and confirm this? You could just plug it in and then use DOS and DEBUG.EXE on the system to poke at ports 22A-22F to see if aliasing is occuring.

I added a quickie hack (option disabled by default) that emulates such aliasing and the demo comes right up in Sound Blaster mode (but with a lot of noise and hash amongst music, which may be another issue to resolve some time later).

Hey I have another discovery as well.

The code I replaced to make Crystal Dreams work, it looks like there was method to the madness after all. Some casual polling port 22Ch on my SB16 shows that even when the card isn't doing anything, the busy bit comes up by itself at some clock rate. I haven't determined at what clock rate yet. The old code that incremented write counter and returned 0xFF if bit 3 was wrong only because it wasn't based on time, but it was right in the number of I/O cycles it takes apparently to wait out one of these busy cycles.

In the recent video I posted, Direct DAC playback doesn't work properly because of this busy cycle. The IRQ 0 timer was programmed to check DSP busy status, and not carry out the command/data write if set. I was only able to get Direct DAC playback in that program working later on by writing the code to poll DSP write status a maximum of 8 times before using it's state to determine whether to write the DSP.

Perhaps that busy cycle, assuming no other compatibility issues, is the reason Crystal Dreams won't work on SB16. Which tells me that pre-SB16 hardware probably doesn't have this busy cycle. Can anyone confirm? You can do a quick check by booting up a DOS machine and using DEBUG.EXE to repeatedly type "i 22c" to show DSP status when the card is not doing anything. If some of them show 0xFF and some of them show 0x7F, then your card's DSP has the busy cycle too.

I hope someone can confirm soon that a pre-SB16 card is missing the "busy cycle" (Debug.exe, repeat: i 22c, report results). I saw the excellent youtube video and learned about your software and method to find properties of hardware. Also, I appreciate your latest updates!

There is a soundblaster emulator with source code here: http://www.softsystem.co.uk/products/soundfx.htm. It says it emulates nearly all the types, so I was hopeful it emulates direct dac playback, but the other parts look interesting. I located a number of SB documents, but I'm sure you have those. Here is a sample:
"Unlike earlier Sound Blasters, the SB16 is programmed with actual sampling rates instead of time constants. "

Okay, here's an update on the I/O port aliasing thing I brought up earlier:

I managed to get a hold of an old Sound Blaster 2.0 card, plug it in, and check. It looks like it is aliasing I/O ports by not decoding the LSB bit of the port number. Port 22Ch and 22Dh read back the same DSP status, ports 22EH and 22Fh read back the same value (0xAA in my test), port 22Ah and 22Bh same values. I'm guessing then Creative kept costs down by taking the low 4 bits of the port and decoding only the top 3 of that?

That explains how demos like EMF "internal damage" can get away with crap like talking to the DSP at 22Dh.

Now can anyone verify that the original Sound Blaster 1.xx does the same?

Maybe you should ask this in Marvin or in the Dosbox development forum. Probably those with real hardware aren't following this thread.

It is probably a good idea to post your SB findings to Dosbox development, so it doesn't get lost in your other code.