DOS ain't dead

As many of you already know, HX DOS Extender, the best DOS extender in the world with Win32 API support is no longer maintained by Japheth. One major issue that HX 2.17 (the last version by Japheth) exists is that it only supports a SBPro/SB16 sound card. More recently however, Ruslan Starodubov, the author of modern sound cards support for QuickView Pro 2.60 (DOS multimedia player), has decided to update HX 2.17 to support these modern sound cards such as AC97 and Intel HDA too. Yesterday (Feb 15, 2016) he released HX 2.17+, which currently features experimental support for Intel HDA sound cards (he will add support for AC97 etc later). The download page is at:

http://sound-dos.ucoz.ru/load/new_hxdos_extender_2_17/1-1-0-8

Please note that this is a very important milestone in the history of DOS, as the vast majority of DOS sound apps/games out there (except for certain programs such as QV 2.60, MPXPLAY and Hammer of Thyrion) currently don't support modern sound cards such as AC97/HDA directly, and there is no SB16 emulation driver available for these modern sound cards; however, since DOSBox (the best DOS emulator) provides good SB16 emulation and we are able to run DOSBox under HX DOS Extender, so if HX DOS Extender supports modern sound cards like HDA, then all DOS sound apps/games that work in DOSBox would be able to play sound through DOSBox's SB16 emulation of these sound cards under HX DOS Extender. This is functionally pretty much like a SB16 emulation driver for modern sound cards in real DOS. Once we are able to get sound cards like AC97/HDA to work reliably with HX, then the no sound issue with the majority of DOS sound apps/games on modern PCs will be completed resolved by the SB16 emulation of these sound cards within HX+DOSBox in real DOS. So please don't hesitate to test your HDA sound cards under HX 2.17+ now and report any issues encountered (you may try for example the TEST\PLAYWAVE program from HX 2.16/2.17 to see if it works on your system). In case you want to try a recent DOSBox build that run under HX, you can download the one built with MinGW below with long filename, mouse copy/paste and DBCS support (zipped with required DLLs):

http://bit.ly/1laDvGX

Download both HX and DOSBox, then make sure DOSLFN is loaded and run DOSBox with "dpmild32 -g dosbox.exe". In my experiences it currently works best with Japheth's HX 2.16, which is still accessible from the page below (please get both HXRT and HXGUI packages). When using with HX 2.17 or 2.17+, you might need to replace its VESA32.DLL file with the one from HX 2.16.

http://web.archive.org/web/20140904175113/http://www.japheth.de/HX.html

Wengier

Wow, a great new, Ruslan made a great work in the past to enable DOS sound. I think that the last step to ideal state would be to implement SB emulator into JEMMEX (or separate driver) and remove the DOSbox overhead.
Sure I will test it.

---
DOS gives me freedom to unlimited HW access.

> I think that the last step to ideal state would be to implement SB emulator
> into JEMMEX (or separate driver) and remove the DOSbox overhead.
> Sure I will test it.

Yes, you are quite right about what the most ideal state of SB emulation under DOS would be. But considering the high difficulty for writing a full SB16 emulator for modern sound cards to work in DOS, I don't expect such a driver to happen any time soon. I cannot for example find any sample source code of DOS SB emulation driver for any existing sound card on the Internet. The SB16 emulation of modern sound cards under HX + DOSBox in real DOS would be the best we can get at the moment.

Yes, the PCI soundcard support in HX-DOS is a "big thing".
I was rather considering to motivate Ruslan to write a DigPak/AIL/Miles sound system driver for such cards.
Just like in past some people from Vogons community did with some other cards, f.e. here:
http://www.vogons.org/viewtopic.php?f=24&t=39270

---
DOS-u-akbar!

Yes, in case of HXDOS emulator it's much more simple as win32 app use some API cals for sound that can be easily trapped instead of DOS native which tries to talk SB directly so need to setup some IO/DMA traps and decode what the program tries to do with SB DSP (need to hold some emulator states). I didn't say that's easy :)
BTW I remember that a lot of demos used MIDAS sound library and some DJGPP Allegro. Eric Auer also mention some MIDPAK DPMI audio API that I never heared about. It may be easier to find entrypoints to this library functions i na DOS program and trap them instead DSP HW access...
DOSbox is OK for many games but there are still some late '90 demos that run very poor in dosbox (~1FPS) even on i7 @4,5GHz...

---
DOS gives me freedom to unlimited HW access.

> Yes, in case of HXDOS emulator it's much more simple as win32 app use some
> API cals for sound that can be easily trapped instead of DOS native which
> tries to talk SB directly so need to setup some IO/DMA traps and decode
> what the program tries to do with SB DSP (need to hold some emulator
> states). I didn't say that's easy :)
> BTW I remember that a lot of demos used MIDAS sound library and some DJGPP
> Allegro. Eric Auer also mention some MIDPAK DPMI audio API that I never
> heared about. It may be easier to find entrypoints to this library
> functions i na DOS program and trap them instead DSP HW access...
> DOSbox is OK for many games but there are still some late '90 demos that
> run very poor in dosbox (~1FPS) even on i7 @4,5GHz...

This is great news, but the whole idea of having to run DOSBOX, a DOS emulator in native DOS, is stretching things... It makes everything slow, slow, slow. About a factor of 100x slower. Unless I'm missing something, the overhead is immense, and you need at least an I7 to play a simple game like Doom or Wolfenstein 3D at 30 fps framerate, and even then at 320x200 only?s Whereas on a modern system, those game would consume only ~2-3% of CPU / GPU.

The Quickview Pro and MPXPLAY sound support for modern cards is truly wonderful, and it is NATIVE DOS support, not an emulated DOS support.

Someone who has the skiils should try to write a MIDAS IDA and IDH sound driver as a wrapper for those many 100s of games and demos which reply on MIDAS. Same for Allegro.

> Someone who has the skiils should try to write a MIDAS IDA and IDH sound
> driver as a wrapper for those many 100s of games and demos which reply on
> MIDAS. Same for Allegro.

Interresting variant would be a VESA/AI driver for IDA and IDH sound cards because Digpak/Midpak/Miles can use VESA/AI as a wrapper.

---
DOS-u-akbar!

I never personally interested about sound programming in DOS so most of this names tells me nothing. I just remember Midas and Allegro (I read about vesa audio but never see game/demo using that neither any SB comes with such driver on diskette) and this libs are usually static-linked (no ext. driver module)...

---
DOS gives me freedom to unlimited HW access.

> This is great news, but the whole idea of having to run DOSBOX, a DOS
> emulator in native DOS, is stretching things... It makes everything slow,
> slow, slow. About a factor of 100x slower. Unless I'm missing something,
> the overhead is immense, and you need at least an I7 to play a simple game
> like Doom or Wolfenstein 3D at 30 fps framerate, and even then at 320x200
> only?s Whereas on a modern system, those game would consume only ~2-3% of
> CPU / GPU.

Personally I obviously did notice the overhead with DOSBox when I tried DOS apps/games under HX, but the a few apps or games I tested on the desktop computer that I bought a few years ago worked least okay this way. Not that many of them will run near as fast as in a native DOS when using on a modern PC, but at least at an acceptable speed in my testing. Some of them can in fact work pretty smoothly. To further speed up the applications under DOSBox, you may try to increase its CPU cycles etc. Moreover, Ruslan plans to write graphics hardware acceleration (OpenGL) for DOS based on the MESA project library. This will dramatically increase the rendering speed.

> Not that many of them will run near as fast as in a native DOS when using on a
> modern PC, but at least at an acceptable speed in my testing. Some of them
> can in fact work pretty smoothly.

Hehe, try e.g. this one (DOS version binary)

> Ruslan plans to write graphics hardware acceleration (OpenGL) for DOS based on the
> MESA project library. This will dramatically increase the rendering speed.

What chips he plan to support? No problem for 3Dfx but nVidia sucks at giving any documentaion. He may use Nouveau Linux driver that was created based on hacking & RE windows drivers but AFAIK it works usable only for 2D and 3D support is still very basic and poor compared to nvidia proprietary linux driver. But of course any acceleration is better than plain vesa LFB... Intel should have opensource linux drivers, about ATI I don't know.

---
DOS gives me freedom to unlimited HW access.

>> Hi! Maybe you guys could find a nice URL for the old
>> VM86 virtual 8 bit SB emulation VSB for Wengier?
>
> You mean this VSB?
>
> http://ericauer.cosmodata.virtuaserver.com.br/soft/by-others/
>
> 17519 1995-09-14 13:45:00 dos-virtual-soundblaster--vsb202.zip
> 135012 1996-12-18 18:45:22 dos-virtual-sound-blaster--vsb-src.zip
>
>> Another idea: JEMMEX could be patched to implement the
>> I/O port trap callback API of MS EMM386, it is smallish.
>
> What about SoftMPU? I know it's not exactly the same, but it was
> backported to native DOS from DOSBox (!). Of course, AFAIK, he never
> finished getting it to work with JEMM, so it's still exclusive to MS
> EMM386 only.
>
> http://bjt42.github.io/softmpu/

> Hehe, try e.g.
> this
> one (DOS version binary)

It appears that it can't be run from within DOSBox. Starting HEAVEN7D.EXE results in:

DOS/4GW Protected Mode Run-time Version 1.97
Copyright (c) Rational Systems, Inc. 1990-1994
MMX instruction set required!

Such games are apparently relatively recent, around year 2000. For them I think native SB support is better than any emulated ones.

> What chips he plan to support? No problem for 3Dfx but nVidia sucks at
> giving any documentaion. He may use Nouveau Linux driver that was created
> based on hacking & RE windows drivers but AFAIK it works usable only for 2D
> and 3D support is still very basic and poor compared to nvidia proprietary
> linux driver. But of course any acceleration is better than plain vesa
> LFB... Intel should have opensource linux drivers, about ATI I don't know.

He plans to support INTEL and Radeon chips it seems. Not sure about others. Some of the information is available from:

http://sound-dos.ucoz.ru/news/future_plans_in_2015_2016/2014-11-27-3

> >> Hi! Maybe you guys could find a nice URL for the old
> >> VM86 virtual 8 bit SB emulation VSB for Wengier?
> >
> > You mean this VSB?
> >
> > http://ericauer.cosmodata.virtuaserver.com.br/soft/by-others/
> >
> > 17519 1995-09-14 13:45:00 dos-virtual-soundblaster--vsb202.zip
> > 135012 1996-12-18 18:45:22 dos-virtual-sound-blaster--vsb-src.zip
> >
> >> Another idea: JEMMEX could be patched to implement the
> >> I/O port trap callback API of MS EMM386, it is smallish.

Interesting. Thanks. I never heard it before, although I indeed tried to look for such things in the past. As stated in its documentation it is only a partial SB emulator and it won't work with any DOS extenders either. However, given the existence of such a sample SB emulator, I might be able to ask Ruslan if he is able to write a similar driver for modern sound cards...

> DOS/4GW Protected Mode Run-time Version 1.97
> Copyright (c) Rational Systems, Inc. 1990-1994
> MMX instruction set required!

OK, I use advanced SVN Dosbox version that supports MMX under Windows (didn't tried it with HX yet). There are other DOS-only demos that need ~Pentium III power which run terribly slow in Dosbox so it's not 100% solution - in this cases SB emu driver would help.

> He plans to support INTEL and Radeon chips it seems. Not sure about others.
> Some of the information is available from:

Yes, I understand. Simply intel and ATI gives better opensrc and doc support than NV MFKRs...

---
DOS gives me freedom to unlimited HW access.

> OK, I use advanced SVN Dosbox version
> that supports MMX under Windows (didn't tried it with HX yet). There are
> other DOS-only demos that need ~Pentium III power which run terribly slow
> in Dosbox so it's not 100% solution - in this cases SB emu driver would
> help.

Yes, I tried to run the HEAVEN7D game within DOSBox SVN Daum (after changing cputype) under Windows, and it indeed loads, yet terribly slow as you said. As for HX support, DOSBox SVN Daum contains a number of additional libraries which makes it impossible to run under HX. I checked the binary under DOS+HX myself, and it did not work. On the other hand, the enhanced DOSBox SVN build linked from the first post of this thread (i.e. http://bit.ly/1laDvGX) will work fine under HX, but I agree that HX+DOSBox is not a 100% solution...

> > OK, I use advanced SVN Dosbox
> version
> > that supports MMX under Windows (didn't tried it with HX yet). There are
> > other DOS-only demos that need ~Pentium III power which run terribly
> slow
> > in Dosbox so it's not 100% solution - in this cases SB emu driver would
> > help.
>
> Yes, I tried to run the HEAVEN7D game within DOSBox SVN Daum (after
> changing cputype) under Windows, and it indeed loads, yet terribly slow as
> you said. As for HX support, DOSBox SVN Daum contains a number of
> additional libraries which makes it impossible to run under HX. I checked
> the binary under DOS+HX myself, and it did not work. On the other hand, the
> enhanced DOSBox SVN build linked from the first post of this thread (i.e.
> http://bit.ly/1laDvGX) will work fine under HX, but I agree that HX+DOSBox
> is not a 100% solution...


FWW,

I fixed the slowness of dosbox on Linux via these settings in the config file

core=auto
cputype=auto
cycles=60000
cycleup=10
cycledown=20

---
--
http://glennmcc.org/

> FWW,
>
> I fixed the slowness of dosbox on Linux via these settings in the config
> file
>
> core=auto
> cputype=auto
> cycles=60000
> cycleup=10
> cycledown=20

Right. With optimal settings most DOS apps/games should work okay from within DOSBox.

I had finally time to test new HX. In my case it recognized only Realtek HDA not the SB Audigy 2 (other Ruslan's drivers e.g. for QV does). 1st I tested with native Quake 2 for windows. Sound works there but all samples are high-pitched like if played at higher sample rate that they should be. Maybe 2x faster. Then I tried Dosbox that makes some sound too but in every game it's very choppy. Like you gate the sound output every 5th-10th of second. It doesn't matter what SB fs I set in Dosbox config or what CPU cycles I set.
So it's progress but in my case quite useless. I jut note that mplayer with WSS, mpxplay or Quake2/Hexen for DOS play fine on my Realtek HDA and SBA2.

---
DOS gives me freedom to unlimited HW access.

> I had finally time to test new HX. In my case it recognized only Realtek
> HDA not the SB Audigy 2 (other Ruslan's drivers e.g. for QV does). 1st I
> tested with native Quake 2 for windows. Sound works there but all samples
> are high-pitched like if played at higher sample rate that they should be.
> Maybe 2x faster. Then I tried Dosbox that makes some sound too but in every
> game it's very choppy. Like you gate the sound output every 5th-10th of
> second. It doesn't matter what SB fs I set in Dosbox config or what CPU
> cycles I set.
> So it's progress but in my case quite useless. I jut note that mplayer with
> WSS, mpxplay or Quake2/Hexen for DOS play fine on my Realtek HDA and SBA2.

As I pointed out in the first post, HX 2.17+ presently supports HDA sound cards only and the support is currently also experimental. During my testing I have noticed that it does not work equally well on all machines with HDA sound cards. On my Acer laptop for example it simply crashed when playing sound. That's why I encouraged feedback or other comments in order to get things better when the next version is released.

Wengier

Sure, I don't excpect it will be perfect 1st time. I'd like just to know how many people tested it and it worked smoothly for them. I forgot to note that I tested on Realtek RTL889/PCH P67. I hope he will add SBA support too...

> As I pointed out in the first post, HX 2.17+ presently supports HDA sound
> cards only and the support is currently also experimental.
> During my testing I have noticed that it does not work equally well on all
> machines with HDA sound cards. On my Acer laptop for example it simply
> crashed when playing sound. That's why I encouraged feedback or other
> comments in order to get things better when the next version is released.

---
DOS gives me freedom to unlimited HW access.

> I'd like just to know how many people tested it

I applaud Ruslan's work on extending HX! But like some others have expressed here, i probably won't be using/testing it, due the the overhead of DOSBox. I guess MPXPlay and LIVECD.EXE/ICHINIT.COM/AC97INIT.COM will have to do for now, to at least get me audio-file and CD-audio playability.

But it's always great to see continuing development in DOS!

- Doug B.

> I applaud Ruslan's work on extending HX! But like some others have
> expressed here, i probably won't be using/testing it, due the the overhead
> of DOSBox. I guess MPXPlay and LIVECD.EXE/ICHINIT.COM/AC97INIT.COM will
> have to do for now, to at least get me audio-file and CD-audio playability.

It is not meant only for DOSBox, it is meant for any Windows program which runs under HX's emulation. But it doesn't support AC97 yet.

---
Glory to God for all things

> As I pointed out in the first post, HX 2.17+ presently supports HDA sound
> cards only and the support is currently also experimental.
> During my testing I have noticed that it does not work equally well on all
> machines with HDA sound cards. On my Acer laptop for example it simply
> crashed when playing sound. That's why I encouraged feedback or other
> comments in order to get things better when the next version is released.

A feedback of the "it works well"/"it doesn't work well" type is seldom useful, it would have been much better if the source code was available.

---
Glory to God for all things

> Interresting variant would be a VESA/AI driver for IDA and IDH sound cards
> because Digpak/Midpak/Miles can use VESA/AI as a wrapper.

Re: HDA, for someone having the needed knowledge and time it would be easy to adapt or wrap the existing code for use with a certain DPMI sound card driver API, but a driver which would work in both real and v86 mode is much more difficult to implement because I don't know how you can read/write byte-sized MMIO registers with int 15h ah=87h.

---
Glory to God for all things

> Interesting. Thanks. I never heard it before, although I indeed tried to
> look for such things in the past. As stated in its documentation it is only
> a partial SB emulator and it won't work with any DOS extenders either.
> However, given the existence of such a sample SB emulator, I might be able
> to ask Ruslan if he is able to write a similar driver for modern sound
> cards...

Considering at least the different configuration required by various programs, such a SB emulation driver for modern sound cards is hardly feasible. The best approach would be the one you thought at, i.e. to run the program inside an emulator, but unfortunately for much too many cases DOSBox is too slow to be a real solution.

---
Glory to God for all things

> it would have been much better if the source code was available.

Fortunately I do have the source code for HX 2.17+'s DPCI.DLL available. It consists of both assembly and C code. I have uploaded it here:

http://bit.ly/1QLxTLM

> Fortunately I do have the source code for HX 2.17+'s DPCI.DLL available. It
> consists of both assembly and C code. I have uploaded it here:
>
> http://bit.ly/1QLxTLM

Thanks!

---
Glory to God for all things

> But it doesn't support AC97 yet.

Now Ruslan added support for sound cards such as ES1371 and AC97 to HX 2.17+'s DPCI.DLL. I have uploaded the new DPCI.DLL in the link below. It might now work better on some HDA sound cards too, although SB Live! and SB Audigy cards are still not yet supported.

http://bit.ly/1nsoFg0

Wengier

> Now Ruslan added support for sound cards such as ES1371 and AC97 to HX

Nice, so I tested again on my notebook Pentium-M, ICH4-M, ADI1981B AC'97.
Now the soundcard was detected. Quake 2 still freeze for some reason:

dkrnl32: exception C0000005, flags=0 occured at BF:379302
        ax=E9F000FF bx=0 cx=1CF00069 dx=0
        si=0 di=1C3C000 bp=0 sp=225C94
        exception caused by access to memory address E9F00103
        ip = Module 'dpci.dll'+3302
        [eip] = 89 78 04 01 F1 42 89 08 83 C0 08 83
        [esp] = 00005622 00000000 00000000 0037F030 70F0009C 00000000
dkrnl32: fatal exit!

Then I tried DOSBox, I tuned optimum cycles for ~18000 in my case. I got quite good sound in Dynablaster, Doom and DN3D. But in all this games I have ~0,5s nasty lag of sound effects behind the gfx (pres shot, see gun fired, hear nothing, wait... and there's sound later). But better than nothing, thanks.

---
DOS gives me freedom to unlimited HW access.

> Now Ruslan added support for sound cards such as ES1371 and AC97 to HX
> 2.17+'s DPCI.DLL. I have uploaded the new DPCI.DLL in the link below. It
> might now work better on some HDA sound cards too, although SB Live! and SB
> Audigy cards are still not yet supported.

I've had no time to test it with HDA yet, but I tested it with my ICH4 AC97 and it doesn't work, the computer resets whatever program I try (the programs run well - obviously, with no sound - without Ruslan's update, and with the DOS programs supporting the sound card, including Mpxplay, the sound is very good). For AC97 and HDA personally I would use a timer callback to update the DMA buffer instead of installing a sound card IRQ handler.

---
Glory to God for all things

Thank you both for testing the new DPCI.DLL. I have informed these new posts to Ruslan, who will hopefully address such issues in the future and add support for more sound cards too.

Wengier

> Now Ruslan added support for sound cards such as ES1371 and AC97 to HX
> 2.17+'s DPCI.DLL. I have uploaded the new DPCI.DLL in the link below.

This looks great I'll test when I have time (today I don't) and sit at my own PC (today I don't, the PC I'm sitting at just now has NO DOS at all!!!)

PS: sorry to all for lack of feedback about everything cool I've missed recently.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Does latest HX-DOS (2.17?) supports running onto 80386 or 80486 - compatible CPUs, with (or without? FPU)???

> Does latest HX-DOS (2.17?) supports running onto 80386 or 80486 -
> compatible CPUs, with (or without? FPU)???

I think you should test it yourself and find it out in this case.

Wengier

HX DOS Extender 2.17 works with 80486SLC/25Mhz CPU, 4Mb RAM system.

> HX DOS Extender 2.17 works with 80486SLC/25Mhz CPU, 4Mb RAM system.
So it should work on 386 too. I'll write a note if someone else asked later...

---
DOS gives me freedom to unlimited HW access.

> Does latest HX-DOS (2.17?) supports running onto 80386 or 80486

RTFM or RTFS: AFAIK HX core itself (HDPMI32 + DKRNL32 + ...) is supposed to work on bare 80386, just some rarely used hacks need 80486, but extra/external stuff (M$WCRT.DLL GLUE32.DLL ...) might need much more.

> As many of you already know, HX DOS Extender
> no longer maintained by Japheth

:-\

> Ruslan Starodubov, the author of modern sound cards support for
> QuickView Pro 2.60 (DOS multimedia player), has decided to
> update HX 2.17 to support these modern sound cards such as
> AC97 and Intel HDA too. Yesterday (Feb 15, 2016) ** released HX 2.17+
> which currently features experimental support

This seems to be great news ...

> So please don't hesitate to test your HDA
> sound cards under HX 2.17+ now and report any issues encountered

> I'll test when I have time

Done!



Results:

+++ DPCI.DLL indeed does contain DOS sound code
+++ my ES1371 is somewhat recognized
- very little docs and no source code
- package is messy, some files are same as in original HX packages,
. some are different, some are new, and some are apparently 3rd
. party (AKA M$) files ... even 16-bit NE stuff ... maybe the package
. would need a clean-up
- there are 2 versions of DPCI.DLL ("39 KiO" and "35 KiO")
- DPCI.DLL seems to be debug version (writes to screen)
- with 39 KiO, it searches for "hxsndhlp.ini" at hardcoded location "C:\",
. if not available, sound plays but volume is maximal, if found,
. no sound can be heard
- with 35 KiO, "hxsndhlp.ini" is not searched anywhere,
. sound plays but volume is maximal

> Fortunately I do have the source code for HX 2.17+'s DPCI.DLL available.
> It consists of both assembly and C code. I have uploaded it here:
> http://bit.ly/1QLxTLM

Link is dead

> Now Ruslan added support for sound cards such as ES1371 and AC97
> http://bit.ly/1nsoFg0

Works ... the "35 KiO" version ... but why hasn't it been included into the main package?

> There have also been modifed some other libraries included
> in the HXDOS-extender to be
> fully compatible with the new DPCI.DLL and games.
> (dsound.dll winmm.dll comdlg32.dll ole32.dll dkrnl32.dll
> duser32.dll dgdi32.dll it has been modified)
> {for sound support: winmm.dll & dsound.dll}

It would be cool to see a history file documenting the changes. Are there other improvements besides better sound support? Unfortunately during the last years of HX development (2010...2014) the released source code was always inconsistent and outdated compared with the binaries.

Thanks to Ruslan ... please release source code and document all your improvements.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Works ... the "35 KiO" version ... but why hasn't it been included into the
> main package?

You may get the latest "main package" from here: http://sound-dos.ucoz.ru/load/new_hxdos_extender_2_17/1-1-0-8

---
Glory to God for all things

> Download both HX and DOSBox, then make sure DOSLFN is loaded and run DOSBox
> with "dpmild32 -g dosbox.exe". In my experiences it currently works best
> with Japheth's HX 2.16, which is still accessible from the page below

Not anymore. Maybe it's a temporary blip (again), but I'm not getting my hopes up.

> (please get both HXRT and HXGUI packages). When using with HX 2.17 or
> 2.17+, you might need to replace its VESA32.DLL file with the one from HX
> 2.16.
>
> http://web.archive.org/web/20140904175113/http://www.japheth.de/HX.html

Very frustrating that even a huge archival site can't get their stuff together.

"Page cannot be displayed due to robots.txt." (but it was available here just fine for many many months!)

"See www.japheth.de robots.txt page." (which, ironically but unsurprisingly, isn't available at all anymore, which they foolishly directly link to! yeah sure, real wise, let's remove it even when nobody else has it either, why archive what can't be found??)

Sorry, not trying to overreact, I've already got it here locally, but it's still frustrating.

It's the Internet. Nothing lasts forever... esp. when somebody must maintain a hosting server, pay connectivity, electricity and storage for it. So I sometimes create Teleport mirrors of interesting sites that I want to save. I didn't mirrored whole Japhet's site but have many codes from there like HX, JWASM... Also I collect a lot of older drivers and utilities because they are constantly disappearing...

---
DOS gives me freedom to unlimited HW access.

Reporting this for curiosity's sake.... It looks like a person called neozeed2 (Jason Stevens) is "preserving" (his words) Japheth's HX on sourceforge: https://sourceforge.net/projects/hx-dos/

It doesn't look like any development is going on, but if you can believe the SF numbers, there have been 63 downloads this past week! (Apparently, the files were uploaded on 2016-02-18.)

- Doug B.

> In my experiences it currently works best with Japheth's HX 2.16,
> which is still accessible from the page below
>
> Not anymore. Maybe it's a temporary blip (again), but I'm not getting my
> hopes up.

Well, it seems back up again, but who knows for how long.

For the honour of DOS!

I hope you someone will read this, cause I have some news about the HX.DOS.Box (jokisownmayd) workaround for emulating ancient sound hardware. Actually I have found HX.DOS last year thanks to this thread. I started to experiment with it but for a long time I couldn't share really useful experiences. I use DR-DOS on a modern computer (Dell Inspiron 15 with HDA chipset) so this runtime is still the only way for me to get sounds other than PC speaker for the old programs, which don't have a native support for my circuitry, and, well I can mention only four DOS programs having that (QuickView, MPXPlay, Quake II, Hexen II). But it was a hard and long time to find really good configurations. So now I have a guide to get good quality sound without lagging. Note that it works on my hardware with my Caldera DR-DOS kernel, UMBPCI memory management and MS-HIMEM (also works with Jemm and Quarterdeck too, but those are inefficient for me because of other reasons). So nothing garantees it for other configs, but there are ways to get it work and it has some logic in the deep, and I think **************** is useful. So:

1. I have the DOSBox sound mixer's sampling rate to 4800 and the blocksize is set up to 4096. This is far larger than what you offer in the links, and for a long time I didn't even try it, but it works. I think the thing is: find the balance between the sampling rate and the block size so you can eliminate the beeping backgound generated with lower quality but still have constant and undistorted sounds. It's not as flexible as running DOSBox on Windows, but you can find working methods. Also the sound is less laggy than on lower sapmling rates, and really good. The probability to experience sound glitches (including lag) is also reduced.

2. I normally use extra procecces on the video. Modern scaling methods for example especially advmame2x or 2xsai, but it depends on the program itself. For World Wrestling Federation for example I use advmame3x. This radically reduces the amount and also the probability of the sound lags.

3. I found that if a sound glitch occure (lag or distortion) refreshing the screen output somehow makes HX.DOS to readjust stuff and restores the good sound. This can be done by modifying the games resolution or switching between the monitors (I use my laptop with an external CRT). If none of them is possible you can still adjust DOSBox' framedrop rate in fly, which less effective but works.

I have a theory of this. I think the problem originates from the HX.DOS multithread support. It probably divides the CPU cycles depending on multiple circumstances, but how it is divided may effect the syncronizing hardware outputs generated by different threads. In my theory, the thread containing significantly more calculations has a large probability to be laggy relative to other ones. I think the soundcard emulation are subject to this. By making the video output generation more "heavy" we make it's weight closer to that of sound output generation, thus the sound output gets less chance to late relative to the now similarly heavy video process. Also a different way of dividing the CPU cycles causes the sound distortion. By refreshing the vidio output we cause some necessary readjusting, thus the cycles are re-divided, maybe with the proper result. This is just a theory but this is the only frame I could explain to myself why the above method works. But it works

---
DOS isn't about why. It's about why not.

Hello,



https://i.postimg.cc/L6CS186c/342720855-5609868025779704-6861399490106330418-n.jpg


I installed Freedos I run dpmild32 -g dosbox.exe and nothing happens, no error messages.

What am I doing wrong ?


Thank you
Chris

Hello

Managed to run dosbox from inside freedos on a Acer Aspire ONE but no sound
What can I do now ?

> What can I do now ?

1) Forget this old stuff!
2) Use the latest HX ( v2.20 )
3) Download vsbhda ( a fork of SBEMU )
4) replace the hdpmi32i.exe binary of HX v2.20 with the one contained in vsbhda.zip
4a) optionally install the JemmEx.exe binary contained in vsbhda.zip ( not really required for DosBox ).
5) install vsbhda
6) run DosBox

Both HX and VSBHDA can be easily found at github.

---
MS-DOS forever!

> > What can I do now ?
>
> 1) Forget this old stuff!
> 2) Use the latest HX ( v2.20 )
> 3) Download vsbhda ( a fork of SBEMU )
> 4) replace the hdpmi32i.exe binary of HX v2.20 with the one contained in
> vsbhda.zip
> 4a) optionally install the JemmEx.exe binary contained in vsbhda.zip ( not
> really required for DosBox ).
> 5) install vsbhda
> 6) run DosBox
>
> Both HX and VSBHDA can be easily found at github.

Thank you for trying to help

I did what you said and running dpmild32 -g c:\dosbox\dosbox just exits without an error message

Any ideas ?

> I did what you said and running dpmild32 -g c:\dosbox\dosbox just exits
> without an error message
>
> Any ideas ?

Well, the DosBox version that I use ( pretty old ) redirects STDOUT to file stdout.txt. After DosBox has exited, this file contains:


DOSBox version 0.74
Copyright 2002-2010 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file dosbox.conf
Memory sizes above 31 MB are NOT recommended.
Stick with the default values unless you are absolutely certain.
MIDI:Opened device:none
DOS keyboard layout loaded with main language code GR for layout gr


In case of errors there should be some hints inside what went wrong...


Btw, please open a new thread for this topic!

---
MS-DOS forever!

> > I did what you said and running dpmild32 -g c:\dosbox\dosbox just
> exits
> > without an error message
> >
> > Any ideas ?
>
> Well, the DosBox version that I use ( pretty old ) redirects STDOUT to file
> stdout.txt. After DosBox has exited, this file contains:
>
>
> DOSBox version 0.74
> Copyright 2002-2010 DOSBox Team, published under GNU GPL.
> ---
> CONFIG:Loading primary settings from config file dosbox.conf
> Memory sizes above 31 MB are NOT recommended.
> Stick with the default values unless you are absolutely certain.
> MIDI:Opened device:none
> DOS keyboard layout loaded with main language code GR for layout gr
>
>
> In case of errors there should be some hints inside what went wrong...


Also have a look at this:




Also I am using FreeDOS

> > What can I do now ?
>
> 1) Forget this old stuff!
> 2) Use the latest HX ( v2.20 )
> 3) Download vsbhda ( a fork of SBEMU )
> 4) replace the hdpmi32i.exe binary of HX v2.20 with the one contained in
> vsbhda.zip
> 4a) optionally install the JemmEx.exe binary contained in vsbhda.zip ( not
> really required for DosBox ).
> 5) install vsbhda
> 6) run DosBox
>
> Both HX and VSBHDA can be easily found at github.


I don't see no real error messages

> Also have a look at this:
>
>

You should probably set the BLASTER variable to a SB16 before loading vsbhda.exe - because the default is SB Pro, and, IIRC, the HX SB driver has problems with a SBPro.

> Also I am using FreeDOS

Not the best choice, but it should work...

---
MS-DOS forever!