DOS ain't dead

Open Source DOS Sound standards! (Developers)

This may sound crazy but i am tired of how quiet DOS is on my newer PCs

the SB Live! dos drivers suck because they do not support the original 1st generation sound blasters!

I am so unsatisfied with the dos multimedia output .... specifically sound!

I want to contribute to FreeDOS by making open source like a mother fucker dos sound drivers for the OS so that newer cards that do not have native SB 1.0 support.. Can play sound and OPL3 emulation out of the newer cards...

This little project of mine needs alot of help
I want to include this into HX extender, and/or as separate fdos package, and/or stand alone software..

Using the awesome drivers from MPXPLAY and open source OPL3 emulation code and the judas sound system!!

basically make a sound driver and library for FreeDOS so we can always have sound <3!

I noticed there is like 3 card standards
1. the original ISA sb blaster family
2. AC'97
3. and the shitty and horrible Intel HDA

these are the major standards that i noticed and the intel hda is the new standard it is found in like all the newer computers nowadays

i also want to support the older cards but it would help if i can get the newest ones working!

I need help very badly! i am making a DOS game to learn about how DOS works!

I believe it's time to make an open software standard for sound hardware in DOS. Programming the cards are hard as fuck! holy shit!

Open Source DOS Sound standards!

> > This may sound crazy but i am tired of how quiet DOS is on my newer PCs> > > the SB Live! dos drivers suck because they do not support the original> 1st> > generation sound blasters> > + EMM386 + ... ++ .....
i know ;_;> > > I want to contribute to FreeDOS by making open source like a mother> fucker> > > I want to include this into HX extender> > would help Win32 apps used in DOS >

Open Source DOS Sound standards!

It was here already many times discussed. The problem is non existency of wide accepted DOS sound API. So DOS most applications access sound card hardware directly.
You certanly can define some sound API for new developped applications but how many DOS sound applications is still developped?

As I said before, there is not any wide accepted DOS sound API however there aore some, I recomend to make drivers for new cards for Miles sound system (whoch is very modular) and is used in many DOS games

Open Source DOS Sound standards!

Open Source DOS Sound standards!

In fact, you should focus on old SB and new HDA standards. AC'97 is dead and usually on motherboards that has onboard AC'97 you can replace it by legacy ISA SB or PCI SB live/audigy with emulation driver. On newer PC you have only intel HDA (SB live emulation doesn't work).

Currently there are available 2 opensource sound libs for DOS quite up to date:Judas 2.10dWSS
I suggest to adopt WSS library. It has wider souncards support and it's more up to date. Khusraw was debugged it to work on many intel HDA verisons. It is used in mplayer DOS port and works well. So you can simply to link it with your application using DJGPP. Or if you're a hardc0re dude you can get inspired from WSS how the drivers works and implement it to JEMMEX/JLM to make regular legacy SB emulation driver for any old DOS program (already dreamed about it many times :) Sorry I couldn't help you with this task (don't have sound prog experiences).

Open Source DOS Sound standards!

> In fact, you should focus on old SB and new HDA standards. AC'97 is dead> and usually on motherboards that has onboard AC'97 you can replace it by> legacy ISA SB or PCI SB live/audigy with emulation driver. On newer PC you> have only intel HDA (SB live emulation doesn't work).

Open Source DOS Sound standards!

My dream of the heart is to have it as a SYS driver or as a multifunctional COM or EXE program (with switches to run with) written in FASM with sources... So that people who want to learn assembler could also earn from such a program. But, of course, any language would be nice.

And it would be very helpful to catch (or is it called "hook"?) the interrupts which old programs send to the Sound Blaster cards and remap them to the actual sound card. Like when you run DOOM it "thinks" you have a SB but the sound is played on your real device. Or when you start something like GW-BASIC and type "beep" it beeps on your HDA PC speaker.

There is another example on the topic I'd like to submit which is ichinit:

Open Source DOS Sound standards!

ICHINIT is some obsolete code used by previous Judas lib. Now it's included in. Again I recommend to use WSS code as it is better optimized for new HDA codecs. Khusraw and I and other members was testing and debugging it in latest mplayer release. But to make a TSR/driver you would need rewrite it.

Open Source DOS Sound standards!

Open Source DOS Sound standards!

> My dream of the heart is to have it as a SYS driver or as a multifunctional> COM or EXE program (with switches to run with) written in FASM with> sources... So that people who want to learn assembler could also earn from> such a program. But, of course, any language would be nice.

> And it would be very helpful to catch (or is it called "hook"?) the> interrupts which old programs send to the Sound Blaster cards and remap> them to the actual sound card. Like when you run DOOM it "thinks" you have> a SB but the sound is played on your real device.

This is possible (infamous "emulation driver") but::

1. very difficult
2. very ugly and hacky (some programs will work, some not, you can't make such a thing "bug-free")

This had been discussed already 1'000'000'000'000 times on various forums ... people ask about I/O port trapping, while they don't have any code to access the real sound hardware.

> Or when you start> something like GW-BASIC and type "beep" it beeps on your HDA PC speaker.

Very difficult, better patch the binary

If you have the time+knowledge+whatever, I'd suggest you to work on WSS, or WSS+MPXPLAY, or turn the WSS code into a TSR written in FASM (there is DOSSOUND TSR by Georg Potthast, but no longer updated, and not open source, see old discussions).

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

Open Source DOS Sound standards!

> This had been discussed already 1'000'000'000'000 times on various forums> ... people ask about I/O port trapping, while they don't have any code to> access the real sound hardware.

The cleanest and most transparent way is to implement it in SMI mode ruling over pmode and rmode but it's even more complicated because bios vendors use verious methods of protection SMI handler - it may need BIOS hack so this means not much portable to different mobo :( It should be task for BIOS writers but nobody of them cares about dos...

Open Source DOS Sound standards!

> If you have the time+knowledge+whatever, I'd suggest you to work on WSS, or> WSS+MPXPLAY, or turn the WSS code into a TSR written in FASM (there is> DOSSOUND TSR by Georg Potthast, but no longer updated, and not open source,> see old discussions).

Open Source DOS Sound standards!

> ... people ask about I/O port trapping, while they don't have any code to> access the real sound hardware.

Later versions of MS EMM386 and 386MAX both include an API to let you trap (virtualize) I/O port access from real mode applications. I use it in my USB joystick driver (USBJSTIK). JEMM does not currently implement the API.

Open Source DOS Sound standards!

> Later versions of MS EMM386 and 386MAX both include an API to let you trap> (virtualize) I/O port access from real mode applications. I use it in my> USB joystick driver (USBJSTIK). JEMM does not currently implement the API.

But many games runs in pmode - dos4gw and those couldn't be simply trapped...?

Open Source DOS Sound standards!

> But many games runs in pmode - dos4gw and those couldn't be simply> trapped...?

Unfortunately, the way EMM386 et al trap the I/O ports only works from real (actually, V86) mode. In order to allow I/O ports to be virtualized from "real" DOS (without the aid of hardware virtualization) from PMode, you must drop down to real/V86 mode to do the I/O. Modern compilers could be written to do this automatically, I'm sure.

Other options are to always use (or develop) a BIOS/DOS (software) level API and never access hardware directly, or for applications to learn how to access all hardware directly (USB, FireWire, BlueTooth, ...).

Over time, I see the hardware virtualization of peripheral devices (serial ports, sound cards, networks, etc.) in VM's in a DOS-compatible fashion completely disappearing, and the need for software-level emulation arising again. Applications that aren't written with this scenario in mind will become completely useless, IMO.

Open Source DOS Sound standards!

> In order to allow I/O ports to be virtualized from> "real" DOS (without the aid of hardware virtualization) from PMode, you> must drop down to real/V86 mode to do the I/O.

Do you think that moder CPUs HW virtualization extension could solve it even in pmode? But if it's not too complex to use it under DOS... This would be interesting project as currently near every new desktop PC has CPU with VTX.

BTW it would be quite easy to implement own SMI routines (i think it's written in C) in Coreboot/Seabios but unfortunatelly it supports still very few modern motherboards.

Open Source DOS Sound standards!

> Do you think that moder CPUs HW virtualization extension could solve it> even in pmode? But if it's not too complex to use it under DOS... This> would be interesting project as currently near every new desktop PC has CPU> with VTX.

It theoretically could, but that's not the route the VM's are taking. For USB, e.g., what's happening (at least with some VM's, like VMWare and VirtualBox) is that the guest OS (DOS) is expected to provide its own USB drivers for "uncommon" devices like printers. The VM virtualizes the USB host controllers, but doesn't virtualize the USB devices -- it makes the guest OS provide its own drivers for the actual (not virtualized) devices. Even the virtualization that is provided for "necessary" devices like keyboards and mice is less than optimal, and I see that getting worse over time rather than better.

VM's, while nice in some respects, are certainly not the panacea a lot of people seem to believe them to be. If you are content to live within the limitations a particular VM chooses to confine you to, go for it. I am not.

> BTW it would be quite easy to implement own SMI routines (i think it's> written in C) in Coreboot/Seabios but unfortunatelly it supports still very> few modern motherboards.

I see several problems with that route, too. First of all, as you already stated, a lot of hardware isn't (and probably never will be) supported. There's a lot of old hardware out there still in use, and a large percentage of it doesn't even have hardware virtualization capabilities. There's PC/XT class hardware out there still in use (30 years old) -- what makes you believe the hardware we think is "unusably ancient" today (more than a couple of years old) won't still be in use somewhere in the world 30 years from now?

Also, AFAIK, SMM (or any type of hardware based virtualization) isn't virtualized in any VM (I could be wrong about that, though). If so, such virtualization techniques could only be used in "real" DOS on relatively modern hardware, not in a VM. In a VM I think your only option is software virtualization, which is very difficult to accomplish and much more limited in capabilities.

Open Source DOS Sound standards!

Open Source DOS Sound standards!

> It theoretically could, but that's not the route the VM's are taking. For> USB, e.g., what's happening (at least with some VM's, like VMWare and> VirtualBox) is that the guest OS (DOS) is expected to provide its own USB> drivers for "uncommon" devices like printers. The VM virtualizes the USB> host controllers, but doesn't virtualize the USB devices -- it makes the

Yes I know it emulate HW at low level and special VM drivers are needed. But I had something different in my mind. Do you know how hardware CPU Virtualization support helps the VM software? What is the difference if VM runs on old CPU without HW virt. support and with it? If it also would help under d dos e.g. for IO or memory trapping or better/faster service handling...

> Also, AFAIK, SMM (or any type of hardware based virtualization) isn't> virtualized in any VM (I could be wrong about that, though).

Open Source DOS Sound standards!

> Yes I know it emulate HW at low level and special VM drivers are needed.

Actually it doesn't necessarily take /special/ VM drivers, it just takes drivers for whatever elements the VM provides access to and isn't already virtualized (or isn't virtualized properly). What's virtualized is usually some subset of keyboards, mice, joysticks, disks, network cards, sound, USB hosts, serial, and parallel ports. Some VM's provide a lot of those different elements, some only a few. Of the different elements I've personally tried to any extent in different VM's (keyboards, mice, disks, and USB), all are problematic. I have a very difficult time believing the elements I haven't tried yet are going to perform any better than the ones I have.

> Do you know how hardware CPU Virtualization support helps the VM software?

Not exactly, but I do know that it's up to the VM to decide which peripheral hardware is virtualized. For the vast majority of users and applications, the limited number of virtualized elements they provide may be good enough. If the VM doesn't correctly virtualize the particular peripheral hardware you're wanting access to, you have to virtualize it yourself (without hardware assistance).

> What is the difference if VM runs on old CPU without HW virt. support and> with it?

It doesn't matter -- all that matters is what the particular VM decides to virtualize for you. Whether it does it with hardware assistance or not is immaterial.

> If it also would help under d dos e.g. for IO or memory trapping or> better/faster service handling...

It's conceivable that it could outside of a VM, though I don't know enough to say for sure. Even if it could, though, I personally don't think it's worth pursuing. Since it can't be used inside VM's, and VM's are what most people seem to be using these days, it doesn't make sense to spend a lot of effort on it. Solutions that /require/ special hardware, or that won't work in a VM as well as on real hardware (both old and new), aren't worth a large investment of time, IMO.

I don't know for sure about this either (it seems you know a LOT more about this stuff than I do), but I think the CoreBoot/SeaBIOS/UEFI route for "directly" booting DOS is going to be a virtualized environment too, probably not much different (at least in a practical sense) than the current VM's.

> Yes AFAIK it's not virtualized but I meant it just for real DOS.

Like I said, I'm not going to personally spend much effort exploring this, since I think it has such limited application. If you (or someone else) wants to figure it out and share your knowledge, I would certainly take a look -- especially if you could provide access to it through a common API.

Open Source DOS Sound standards! yay!

> I am not speaking about virtual machines!> > There should be sound to come out of physical computers!

If only it were that easy.

The problem is, there never have been any official standards, only de facto ones. The de facto standard for DOS sound is Sound Blaster, and hardware (and VM) manufacturers who have any interest in DOS compatibility at all will emulate SB. Newer hardware is almost never directly compatible with SB, but some will provide a special DOS utility to provide SB emulation.

If I were to write a USB sound driver (which I might actually try to do someday), it would virtualize a SB. However, unless something changes with regard to virtualization techniques from real/V86 mode, the virtualization would not work properly from protected mode (e.g., DPMI). You would need to make provisions in your program for that if you want it to work in the future with "real" DOS.

If you want your program to work with the most hardware (real and virtualized) with the least amount of work, assume Sound Blaster. You can add other (non-SB) possibilities later on if you decide SB isn't enough.

Open Source DOS Sound standards! yay!

> > If only it were that easy.> > The problem is, there never have been any official standards, only de facto> ones. The de facto standard for DOS sound is Sound Blaster, and hardware> (and VM) manufacturers who have any interest in DOS compatibility at all> will emulate SB. Newer hardware is almost never directly compatible with> SB, but some will provide a special DOS utility to provide SB emulation.> > If I were to write a USB sound driver (which I might actually try to do> someday), it would virtualize a SB. However, unless something changes with> regard to virtualization techniques from real/V86 mode, the virtualization> would not work properly from protected mode (e.g., DPMI). You would need> to make provisions in your program for that if you want it to work in the> future with "real" DOS.> > If you want your program to work with the most hardware (real and> virtualized) with the least amount of work, assume Sound Blaster. You can> add other (non-SB) possibilities later on if you decide SB isn't enough.

Well we should start somewhere and maybe implement the driver into the FreeDOS Kernel!

Open Source DOS Sound standards! yay!

Open Source DOS Sound standards! yay!

> then please wait a very long time
This has been an interesting discussion to follow - so thanks for raising it.

Speaking of development whilst trying to understand who you are and where you are coming from I took the time to look at your website and reviewed your PWD batch file. Are you aware that you can just use "CD" ot it'ss own to provide the current path information and should be more compatible across all DOS vers.

Open Source DOS Sound standards! yay!

> Speaking of development whilst trying to understand who you are and where> you are coming from I took the time to look at your website and reviewed> your PWD batch file. Are you aware that you can just use "CD" ot it'ss own> to provide the current path information and should be more compatible> across all DOS vers.

yes i am just experimenting with creating a freedos package from scratch

I am sparky4
A computer hacker who loves computers alot!
I knew about FreeDOS since 2007
I Really like FreeDOS and i wanna help out since it is a great OS!
I am usually sleepy and/or busy

I am currently looking at kernel code and waiting for reply from the developers and/or Jim Hall about FreeDOS installer

I gotta start somewhere!

I honestly believe it is very possible to emulate the sound blaster and opl3 in DOS and the machine's actual hardware is Intel HDA and sound will come out

Is it difficult?
fuck yes... but thats the challenge!
I want to tackle it but i need to learn much much more!

Open Source DOS Sound standards! yay!

> Is it difficult?> fuck yes... but thats the challenge!> I want to tackle it but i need to learn much much more!

Yes, so start studying _yourself_ and go on. You have free access to whole Intertnet (I well remember the ancient times of BBS, Internet was unreachable for most of people here) full of knowledges so you can learn about programming and necessary hardware standards. Don't expect that anybody else do the job instead of you, we have or lives with our worries and duties... Someone would rather help you with some specific problem hen you show up some code.
Take the challenge :)