I would suggest a generalized implementation that chooses the part of the screen to output with an SDL rect, and the target rectangle with another SDL rect. The rectangle would be chosen according to user preferences on how to crop/zoom and simulation of CRT monitor positioning controls.

DOSBox already has code that can stretch-blit the rasterized output to the aspect ratio you need. So you could just rasterize the border and active picture area and let that code squeeze/stretch it to the aspect ratio.

After testing it for a while, I would say it is a great build. So far I have only found the following small issues in the Win32 pre-built version of this branch on my machine (Widows 8.1 X64):
1. It reports error ‘Packed file is corrupt’ when starting some applications (two samples in the attached Zip file).
2. Left-Shift + Right-Shift does not work. Ykhwong’s Daum build has this same issue too.
3. When in idle prompt, its CPU usage is relatively high; also the CPU gets switched to high power mode. Ykhwong’s Daum build has this same issue also.
And these 3 issues don’t exist in the official DosBox on my machine. I hope fixing them does not break other patches.

cyberwalker wrote:

After testing it for a while, I would say it is a great build. So far I have only found the following small issues in the Win32 […]
Show full quote

After testing it for a while, I would say it is a great build. So far I have only found the following small issues in the Win32 pre-built version of this branch on my machine (Widows 8.1 X64):
1. It reports error ‘Packed file is corrupt’ when starting some applications (two samples in the attached Zip file).
2. Left-Shift + Right-Shift does not work. Ykhwong’s Daum build has this same issue too.
3. When in idle prompt, its CPU usage is relatively high; also the CPU gets switched to high power mode. Ykhwong’s Daum build has this same issue also.
And these 3 issues don’t exist in the official DosBox on my machine. I hope fixing them does not break other patches.

"Packed file is corrupt" sounds like the program used an older version of Microsoft's EXEPACK utility. See also https://github.com/joncampbell123/dosbox-x/issues/7

You can avoid "packed file is corrupt" by running the game through DOSBox's LOADFIX command.

TheGreatCodeholio wrote:

cyberwalker wrote:

After testing it for a while, I would say it is a great build. So far I have only found the following small issues in the Win32 […]
Show full quote

After testing it for a while, I would say it is a great build. So far I have only found the following small issues in the Win32 pre-built version of this branch on my machine (Widows 8.1 X64):
1. It reports error ‘Packed file is corrupt’ when starting some applications (two samples in the attached Zip file).
2. Left-Shift + Right-Shift does not work. Ykhwong’s Daum build has this same issue too.
3. When in idle prompt, its CPU usage is relatively high; also the CPU gets switched to high power mode. Ykhwong’s Daum build has this same issue also.
And these 3 issues don’t exist in the official DosBox on my machine. I hope fixing them does not break other patches.

"Packed file is corrupt" sounds like the program used an older version of Microsoft's EXEPACK utility. See also https://github.com/joncampbell123/dosbox-x/issues/7

You can avoid "packed file is corrupt" by running the game through DOSBox's LOADFIX command.

Thanks for the reply. Yes, LOADFIX will fix Issue 1, which is not really an issue of DosBox-x’s. I did not know DosBox-x had changed memory allocation.

A system menu (with About box, etc.) and clipboard-pasting for DOSBox-X Win32

Again, none of this is my code except for trivial details; all the working bits were written by the anonymous updater of the dbDOS fork.

Here are three patch files that will add and About box and some other items (easily modified) to the system menu in DOSBox-X and also add the clipboard pasting feature that Jon has already merged into Git.

I could not figure out how to make the system menu work with current Git code, so I created the patch against the most recent release version, here:

https://github.com/joncampbell123/dosbox-x/re … 971e15c20c4.zip

The three files make extensive changes to sdlmain.cpp and minor changes (for the clipboard paste feature) to keyboard.h and keyboard.cpp.

I've also uploaded an executable to show briefly how this works.

I hope someone finds these useful.

emendelson wrote:

A system menu (with About box, etc.) and clipboard-pasting for DOSBox-X Win32 […]
Show full quote

A system menu (with About box, etc.) and clipboard-pasting for DOSBox-X Win32

Again, none of this is my code except for trivial details; all the working bits were written by the anonymous updater of the dbDOS fork.

Here are three patch files that will add and About box and some other items (easily modified) to the system menu in DOSBox-X and also add the clipboard pasting feature that Jon has already merged into Git.

I could not figure out how to make the system menu work with current Git code, so I created the patch against the most recent release version, here:

https://github.com/joncampbell123/dosbox-x/re … 971e15c20c4.zip

The three files make extensive changes to sdlmain.cpp and minor changes (for the clipboard paste feature) to keyboard.h and keyboard.cpp.

I've also uploaded an executable to show briefly how this works.

I hope someone finds these useful.

You should be aware that release is over a month old and I've done quite a few fixes since that release, especially where it concerns reentrant page fault handling with Windows 95/98/ME.

TheGreatCodeholio wrote:

You should be aware that release is over a month old and I've done quite a few fixes since that release, especially where it concerns reentrant page fault handling with Windows 95/98/ME.

I tried to work against the current version, but when I compiled, I keep getting five linker errors about (if I remember correctly) unresolved GFX_--- symbols in vga_dac.obj. I couldn't figure out how to solve that, so I went ahead with the release version. If someone can suggest a way to fix that problem with vga_dac.obj, I'll go back and try again.

TheGreatCodeholio wrote:

I would suggest a generalized implementation that chooses the part of the screen to output with an SDL rect, and the target rectangle with another SDL rect. The rectangle would be chosen according to user preferences on how to crop/zoom and simulation of CRT monitor positioning controls.

DOSBox already has code that can stretch-blit the rasterized output to the aspect ratio you need. So you could just rasterize the border and active picture area and let that code squeeze/stretch it to the aspect ratio.

Yea, that would really add to the 'analog feel' of real CGA/EGA/VGA systems!
And it would finally show proper borders in games/demos that use them 😀

But I would be most excited about a proper emulation of CGA composite.

reenigne wrote:

With the decoders I've written, I've used borders of 10% on each side, giving 768x240 which is a pretty close match to image area you've mentioned (720*910/858 ~= 764). It'd be a nice thing for emulators to have image size and position controls like real monitors as well, but I doubt such controls would be accepted into DOSBox SVN.

I suppose for NTSC you'd also want some hue/saturation controls?
I guess you could make the routines 'self-calibrating' to some extent, but having controls may be better.

One thing I was thinking of was to make the routines GPU-accelerated. But that's only interesting if the NTSC processing is actually a performance issue. We only have to process 620x200 bits really, so it may not be that bad even with CPU-only code.

reenigne wrote:

I had a brief look at the DOSBox SVN source and it looks like all the infrastructure for this is already there (for SVGA modes). So this shouldn't be a big problem.

Yea excellent. I suppose all the regular modes can be left untouched then, if DOSBox can already switch from regular VGA modes to direct colour SVGA ones and back.
CGA composite modes could be implemented in the same way then, leaving all other modes alone, rather than having to convert everything to direct colour.

Scali wrote:

I suppose for NTSC you'd also want some hue/saturation controls?

DOSBox already has a tint/hue control for CGA composite (F11/Alt+F11). Saturation, contrast and brightness would good to add, but there was resistance to adding these to SVN (read through the long thread at CGA Composite Mode under DOSBOX (Commited r3804) for details).

Scali wrote:

One thing I was thinking of was to make the routines GPU-accelerated. But that's only interesting if the NTSC processing is actually a performance issue. We only have to process 620x200 bits really, so it may not be that bad even with CPU-only code.

I know from previous experiments that my 2006 Core 2 Duo laptop is capable of doing the decoding in real-time on the CPU. For DOSBox we only need to decode the parts of the image that have changed, so performance shouldn't be a significant problem in practice.

Hi. I'd like to find the person who did the GUS stereo fix and maybe knows something about the other code.

Points of discussions are:

http://hackipedia.org/Platform/x86/Sound/AMD/Interwave/
InterWave IC Am78C201 Programmers Guide v2, (SDK) 1996.pdf (6.208MB)
page 7-19

and the software on GUS ACE CD

http://www.vogonsdrivers.com/index.php?catid=8
Ultrasound ACE Driver CD-ROM 406.24 MiB

acecd\demos\unreal2
ACECD\GAMES\OMF (and others)

I lost my ACE somewhere (perhaps gave it away long ago) and it has bothered me long time that the dosbox GUS sounds nothing like how I remember.
In addition, it sounds nothing like the GUS ACE recordings I found on youtube:

https://www.youtube.com/watch?v=Q3R3oiM6-6k
https://www.youtube.com/watch?v=i0FNUDLdT4A
https://www.youtube.com/watch?v=dGFmhXthj6E (sounds almost like I remember but perhaps more reverb than normal)
https://www.youtube.com/watch?v=KTjnt_WSJu8 (left and right channels appear swapped here when compared to the acecd\demos\unreal2\second.exe)

The first issue I noticed that the Dosbox X current build has:
for (i = 8; i < 15; i++) pantable = (Bit32u)(-128.0*(log((double)(15 - i) / 7.0) / log(2.0))*(double)(1 << RAMP_FRACT));
yet it sounded using headphones like all sounds were still near the midpoint compared to all the hardware recordings from various people and my own memory of it.

So I modified the above line such that
pantable[14] ended up around 1365557 (+-20000) and it seemed like the "extremes" of the pan seemed correct in the demos\unreal2 demo, but that's as far as I've got. The games sound all very different and the bouncing ball section of music in the unreal2 demo suggests the pan "curve" is not what it should be.

avx wrote:

Hi. I'd like to find the person who did the GUS stereo fix and maybe knows something about the other code. […]
Show full quote

Hi. I'd like to find the person who did the GUS stereo fix and maybe knows something about the other code.

Points of discussions are:

http://hackipedia.org/Platform/x86/Sound/AMD/Interwave/
InterWave IC Am78C201 Programmers Guide v2, (SDK) 1996.pdf (6.208MB)
page 7-19

and the software on GUS ACE CD

http://www.vogonsdrivers.com/index.php?catid=8
Ultrasound ACE Driver CD-ROM 406.24 MiB

acecd\demos\unreal2
ACECD\GAMES\OMF (and others)

I lost my ACE somewhere (perhaps gave it away long ago) and it has bothered me long time that the dosbox GUS sounds nothing like how I remember.
In addition, it sounds nothing like the GUS ACE recordings I found on youtube:

https://www.youtube.com/watch?v=Q3R3oiM6-6k
https://www.youtube.com/watch?v=i0FNUDLdT4A
https://www.youtube.com/watch?v=dGFmhXthj6E (sounds almost like I remember but perhaps more reverb than normal)
https://www.youtube.com/watch?v=KTjnt_WSJu8 (left and right channels appear swapped here when compared to the acecd\demos\unreal2\second.exe)

The first issue I noticed that the Dosbox X current build has:
for (i = 8; i < 15; i++) pantable = (Bit32u)(-128.0*(log((double)(15 - i) / 7.0) / log(2.0))*(double)(1 << RAMP_FRACT));
yet it sounded using headphones like all sounds were still near the midpoint compared to all the hardware recordings from various people and my own memory of it.

So I modified the above line such that
pantable[14] ended up around 1365557 (+-20000) and it seemed like the "extremes" of the pan seemed correct in the demos\unreal2 demo, but that's as far as I've got. The games sound all very different and the bouncing ball section of music in the unreal2 demo suggests the pan "curve" is not what it should be.

Yes. I added the code as a "guess" to what the panning register does, then left it at that. Prior to this fix the calculation was flawed in a way that panning was ineffective and all audio was locked to center. If you have any suggestion on how to properly calculate these values go ahead and suggest it.

I could come up with something if I had a way to manipulate the pan table without stopping the dosbox (at all) - some sort of slider for each value in the pan table. This kind of thing would also be useful for adding surround module support for Adlib (used by Dune) as that could be implemented with the FreeVerb code, matching the values based on how the recordings from Adlib Gold with surround module sound. But I can only do that if someone else puts in the code to get where I can do things by ear and tweak it live like you would when creating a hardware synthesizer or using some synth creation tool.

(I recommend applying these changes for now, as I probably move on to something else now that I'm happy with how the music I care about sounds)

This is what I have now but needs more extensive testing (try various values in some tracker or other signal gen soft)

static Bit16u const pantablePDF[16] = { 0, 13, 26, 41, 57, 72, 94, 116, 141, 169, 203, 244, 297, 372, 500, 4095 };

for (i = 0; i < 16; i++) pantable = pantablePDF[15 - i] * 2048; // 2048 sounds like it gives the right amount when multiplied with 500 based on compare with the linked videos (still a guess but I can't tell the sound apart from the videos now)

PanLeft = pantable[(val & 0xf)]; PanRight = pantable[0x0f - (val & 0xf)]; //I may've swapped these but need more evidence to be sure which is right. (could be same if swapped these back and removed the 15- from [15-i] above. - the curve has steeper slope in one end so who knows if this is now right or not

Also I'm not sure how this whole "& 0xf " thing interacts with the i < 16 - as I commented the for (i = 0; i < 8; i++) pantable = 0; --- maybe that needs to be uncommented again but needs to be verified on a tracker soft..

UPDATE (2015-07):

Seems there's more going on here. I tested Star Control 2 now - it does not sound right with these changes, while every other thing I tried does. However SC2 sounds right with the old stereo patch. Perhaps it or the other games use the panning mode toggle or something.

Other issues noticed:

acecd\demos\unreal2 freezes partially toward the end - music keeps running
ACECD\GAMES\OMF audio has some sort of glitching in the menu music on left channel
acecd\mods\iplay.exe plays the music way too fast

Doom sounds different from the video : https://www.youtube.com/watch?v=diW3-y40wP0 (doom, 2nd half is gus, not ace)
I'd like to have Doom recording from ACE to be sure what it was like as I don't remember (used Yamaha XG card for Doom later).

Some more hardware cap videos
https://www.youtube.com/watch?v=s91t56pCG0s 2nd reality, gus
https://www.youtube.com/watch?v=cpNGBzd2SLE https://www.youtube.com/watch?v=W2xU9T85iV8
https://www.youtube.com/watch?v=HNL4c-pBPBE https://www.youtube.com/watch?v=LyGpEx8vAXU wacky wheels
https://www.youtube.com/watch?v=ZQk5oXBqzeI (triton demo, not ace)
https://www.youtube.com/watch?v=A0xVxRP3cp8 (heretic,max)

edit:

new issues:

Doom, when using esc key to bring up and exit the menu repeatedly (just press esc many times) - the menu pop-up pop-out sound sometimes cuts in the middle. edit: well that issue disappeared after alt-tabbing to write this but
- there is still tiny glitch when holding the esc key down or rapidly pressing up/down in the menu - this glitch does not sound with SB as SFX card very likely a bug

Just out of curiosity comparing:

ONESTOP.MID
GUS ACE https://www.youtube.com/watch?v=GUYgKrXogsM (onestop.mid desc lacks but ACE pictured and sounds real) (unknown which patches)
GUS (?) https://www.youtube.com/watch?v=wAwxAI7bKps (unknown which patches)
Roland Virtual Sound Canvas https://www.youtube.com/watch?v=OLYtBFLxHzA (VSC has some weird stuff, it's kinda close to SC-55 but not really - I think with some sort of midi translation mapping it could be fixed)
Roland SC55mk2 https://www.youtube.com/watch?v=OcUYtvasztw
Yamaha Motif XF8 https://www.youtube.com/watch?v=g0r2PCEwxOU
Various https://www.youtube.com/watch?v=BiO0ldUEsNs (OneStop.mid played on 21 different tone generators)
Yamaha DGX-640 https://www.youtube.com/watch?v=NvF-mN14T1A (well balanced mix but a bit "safe", so invidual parts are better with some of the others. good jack of all trades master of none)
Minecraft (lol) https://www.youtube.com/watch?v=mp6YkMIeWGg

As far as the most mind-blowing (sounds like a real top notch CD recording) MID's go that I played on my 486, the Yamaha XG demos DARKNESS.MID 05Spain.mid / FAROLILO.MID beat the sh1t out of anything I've heard .MID-wise. You'd need savihost + MidiYokeSetup.msi + s-yxg50 VST (in savihost) to listen.

I agree there are still some issues with GUS emulation. I've also noticed occasional glitches with some demos. Some other demos and test programs seem to get stuck waiting for a GUS IRQ somehow. But: as far as I know, DOSBox does not emulate the GUS ACE, it only emulates a GUS classic.

I suppose I could throw together some kind of overlay menu that halts the game and lets you play around with these parameters.

Would it help if there was a program that played a 1KHz tone from a GUS while letting you play with the volume/panning registers? Then you just connect the GUS out to a line in on another computer and measure the loudness of the tone for each setting?

After the value-relations copied from the Interwave PDF into the pan table(~*2048), the music sounds right but to actually verify this for sure it would be preferable to create some sort of test MOD file to play that varies the pan values or use the gus sdk to test the pan modes and values, then record from both real gus and the emulator.

However as far as my ears go, the changes in the last post fix the pan issue for the games/demos mentioned.

The glitch bug and the incorrect playback speeds are problems I can't really fix as they require more indepth knowledge than I have time/interest to get involved with.
Someone who has programmed directly to the GUS sdk would probably be the best person to fix those as they could create more easily repeatable tests.

the GUS vs ACE is more about the belief/observations that the ACE sounds is more "clean". In the recorded videos this appears to be case. So to "emulate" the GUS instead of ACE, you'd maybe need some more EQ or high pass filtering. This is kinda similar deal as with Amiga 500 having filtering modes for the audio. WinUAE has a toggle for the filter and the effect is more pronounced.

And as far as the gus.cpp goes, I don't see any sign of emulating the effects mentioned in the InterWave IC Am78C201 Programmers Guide v2, (SDK) 1996.pdf chapter 7 ... There's few games that load patches into GUS and use it as synth (instead of "dumb pipe for pcm"), maybe those patches contain parameters that change the effects. I don't know how to implement that effects stuff. The Settlers video linked above is a demo of this - there's way too much reverb in it and desc says "custom tunings" - as the sounds are same as original but just more reverb, it suggests the video author found a way to increase reverb for the patches used by the game.

re: test tone stuff: I don't have GUS at hand, all I could do was to check agains the youtube videos and the dosbox gus sounds good now after changes posted earlier.

However it would still be really nice to have some way to incorporate the freeverb (comes with the munt code, already in dosboxX) into the dosbox mixer. So you could configure dosbox mixer to add reverb to each sound source. This would allow the Adlib emulation to be then matched by ear (using the overlay you mentioned) to sound like this recording from Adlib Gold with surround module (and maybe if someone has time the adlib code could be changed to emulate the surround module, but would be much less work to just add the reverb adjustment to the mixer):

https://www.youtube.com/watch?v=71icIsoA_v0&l … B135F33&index=7

Another nice to have would be to have ASIO support (so you could then get lower latency with ASIO4ALL). Currently I think dosbox uses DirectX for audio and it has notorious latency (try running AXS synth in dosbox with GUS)

PS. with the pan table fixed, check out TTD and Epic Pinball. Both sound nicer than anything I've seen uploaded to youtube atm. (There current uploads are incorrect - not enough stereo width)

edit: found another emulation attempt here but might not do any difference to DosBox - it doesn't seem to have the pantable from the pdf either. https://github.com/qemu/qemu/tree/master/hw/audio

reenigne wrote:

Scali wrote:

Reenigne already has a good NTSC decoding routine for that.

And I'm planning to adapt it to work with DOSBox Real Soon Now (like, within the next week or two).

Ok, so it was closer to three... But I've made a first pass at the patch for DOSBox SVN and posted it over at the big composite CGA thread.

One more GUS issue: When music is playing in OMF and I go to the dosbox menu to press Mute. Then leave the menu .. then go back to menu and unmute, there is a loud glitch.

I've built the latest version of Dosbox-X but I'm having some issues with Soundblaster 16 emulation. Specifically, it doesn't seem to work in games that use the Miles sound driver (the one with setsound.exe). If I try to detect the SB16 all that happens is I get a few clicks and then a "No Device Found" error. Choosing the Soundblaster Pro driver instead does work. Also, the SB16 does seem to work in games that use different drivers (HMI for example).

Does anyone have any ideas about this?