Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
sparky4

Homepage E-mail

hell,
20.12.2012, 05:09
 

Open Source DOS Sound standards! (Developers)

Post reply

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!:-)

---
CRAZY wwww
DOS386

20.12.2012, 05:42

@ sparky4
 

Open Source DOS Sound standards!

Post reply

> 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 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 :-)

> and/or as separate fdos package,
> and/or stand alone software
?

or:brew DUGL drivers : http://dugl.1114869.n2.nabble.com/Sound-drivers-f1114926.html

> 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
More (bad) "standards":

- ISA ESS (partially compatible with ISA SB, partial supp in MPX)
- ENS 1370 1371 1373 (partial supp in MPX)
- EMUblah, SB512

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

Homepage E-mail

hell,
20.12.2012, 05:51

@ DOS386
 

Open Source DOS Sound standards!

Post reply

> > 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 :-)
>

<3 i hate silent quake2

> > and/or as separate fdos package,
> > and/or stand alone software
>
> ?
>

to be included in FreeDOS

> or:brew DUGL drivers :
> http://dugl.1114869.n2.nabble.com/Sound-drivers-f1114926.html
>

that developer needs to be here!!
I am trying to make an open standard!

> > 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
>
> More (bad) "standards":
>
> - ISA ESS (partially compatible with ISA SB, partial supp in MPX)
> - ENS 1370 1371 1373 (partial supp in MPX)
> - EMUblah, SB512
yuck sounds nasty!

---
CRAZY wwww
DOS386

20.12.2012, 05:54

@ sparky4
 

Open Source DOS Sound standards!

Post reply

> that developer needs to be here!!
http://www.bttr-software.de/forum/user.php?id=49

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

Homepage

Czech republic,
20.12.2012, 07:46

@ sparky4
 

Open Source DOS Sound standards!

Post reply

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?

Anyway, for new projects you can use sound libraries Judas (see thread http://www.bttr-software.de/forum/board_entry.php?id=10911) or WSS (search in this forum)

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

---
DOS-u-akbar!
sparky4

Homepage E-mail

hell,
20.12.2012, 17:40

@ Laaca
 

Open Source DOS Sound standards!

Post reply

universal for all cards!
wwww

---
CRAZY wwww
RayeR

Homepage

CZ,
21.12.2012, 03:35

@ sparky4
 

Open Source DOS Sound standards!

Post reply

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.10d
WSS
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).

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

Homepage E-mail

hell,
21.12.2012, 03:45

@ RayeR
 

Open Source DOS Sound standards!

Post reply

> 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).
ok i will <3

---
CRAZY wwww
Cyril

Homepage

Ukraine,
23.12.2012, 10:58

@ sparky4
 

Open Source DOS Sound standards!

Post reply

Could I also join the party? ;-)

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:

http://www.piotrkn22.republika.pl/judas/current/ichinit.zip

It's an asm program (TASM, to be precise) which does little but initialize the HDA audio card. It's a bit outdated (new cards are not supported) but might still be helpful.

Also I'm very willing to do some testing, if needed.
RayeR

Homepage

CZ,
23.12.2012, 18:31

@ Cyril
 

Open Source DOS Sound standards!

Post reply

> There is another example on the topic I'd like to submit which is ichinit:
>
> http://www.piotrkn22.republika.pl/judas/current/ichinit.zip
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.

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

Homepage

Czech republic,
24.12.2012, 11:18

@ RayeR
 

Open Source DOS Sound standards!

Post reply

I partially agree.
However WSS does not contain sound mixer but Judas has it.

Anyway, WSS does not support Soundblaster Live. Is somebody able to add SB Live support into WSS?
Khursaw?

---
DOS-u-akbar!
RayeR

Homepage

CZ,
24.12.2012, 14:57

@ Laaca
 

Open Source DOS Sound standards!

Post reply

> Anyway, WSS does not support Soundblaster Live. Is somebody able to add SB
> Live support into WSS?
> Khursaw?
Aha, but you can go via SBEMU it should detect SB16... SB live is more specific and it would take some extra effort to implement it but Khusraw probably has not time :\

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

Homepage

Czech republic,
24.12.2012, 16:06

@ RayeR
 

Open Source DOS Sound standards!

Post reply

You are right, SBEMU works good, but anyway, native SB Live support would we nice.

---
DOS-u-akbar!
sparky4

Homepage E-mail

hell,
24.12.2012, 09:18

@ Cyril
 

Open Source DOS Sound standards!

Post reply

> Could I also join the party? ;-)

yes of course!

---
CRAZY wwww
DOS386

24.12.2012, 09:47

@ Cyril
 

Open Source DOS Sound standards!

Post reply

> 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 ***
DOS386

24.12.2012, 09:49

@ DOS386
 

Open Source DOS Sound standards!

Post reply

or turn WSS into a DUGL drivers

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

Homepage

CZ,
24.12.2012, 15:02

@ DOS386
 

Open Source DOS Sound standards!

Post reply

> 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...

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

Homepage E-mail

hell,
28.12.2012, 22:45

@ DOS386
 

Open Source DOS Sound standards!

Post reply

> 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).
I need to do alot of research and fooling around!

---
CRAZY wwww
bretjohn

Homepage E-mail

Rio Rancho, NM,
31.12.2012, 00:23

@ DOS386
 

Open Source DOS Sound standards!

Post reply

> ... 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.
RayeR

Homepage

CZ,
31.12.2012, 02:21

@ bretjohn
 

Open Source DOS Sound standards!

Post reply

> 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...?

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

Homepage E-mail

Rio Rancho, NM,
01.01.2013, 19:21

@ RayeR
 

Open Source DOS Sound standards!

Post reply

> 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.
RayeR

Homepage

CZ,
02.01.2013, 23:40

@ bretjohn
 

Open Source DOS Sound standards!

Post reply

> 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.

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

Homepage E-mail

Rio Rancho, NM,
03.01.2013, 20:00

@ RayeR
 

Open Source DOS Sound standards!

Post reply

> 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.


My opinion, FWIW.
sparky4

Homepage E-mail

hell,
08.01.2013, 02:36

@ bretjohn
 

Open Source DOS Sound standards!

Post reply

Where shall we start?

---
CRAZY wwww
RayeR

Homepage

CZ,
08.01.2013, 04:02

@ bretjohn
 

Open Source DOS Sound standards!

Post reply

> 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).

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

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

Homepage E-mail

Rio Rancho, NM,
09.01.2013, 01:41

@ RayeR
 

Open Source DOS Sound standards!

Post reply

> 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.
sparky4

Homepage E-mail

hell,
09.01.2013, 21:55

@ bretjohn
 

Open Source DOS Sound standards! yay!

Post reply

I am not speaking about virtual machines!

There should be sound to come out of physical computers!

I am sleepy~

---
CRAZY wwww
bretjohn

Homepage E-mail

Rio Rancho, NM,
10.01.2013, 18:59

@ sparky4
 

Open Source DOS Sound standards! yay!

Post reply

> 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.
sparky4

Homepage E-mail

hell,
10.01.2013, 23:25

@ bretjohn
 

Open Source DOS Sound standards! yay!

Post reply

>
> 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!

---
CRAZY wwww
tom

Homepage

Germany (West),
11.01.2013, 00:55

@ sparky4
 

Open Source DOS Sound standards! yay!

Post reply

> Well we should start somewhere
forget about 'we'. open source projects don't work this way.

you proposed this problem. it's up to you to come up with a solution, not 'we'.

if you are not able to come up at the very least with some
'I will do it this ... way, any objections'
this isn't going anywhere.

good luck.


> and maybe implement the driver into the FreeDOS Kernel!
 CBS
sparky4

Homepage E-mail

hell,
11.01.2013, 01:01

@ tom
 

Open Source DOS Sound standards! yay!

Post reply

then please wait a very long time

---
CRAZY wwww
Arjay

11.01.2013, 01:31

@ sparky4
 

Open Source DOS Sound standards! yay!

Post reply

> 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.
sparky4

Homepage E-mail

hell,
12.01.2013, 08:57

@ Arjay
 

Open Source DOS Sound standards! yay!

Post reply

> 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!

---
CRAZY wwww
RayeR

Homepage

CZ,
12.01.2013, 21:49

@ sparky4
 

Open Source DOS Sound standards! yay!

Post reply

> 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 :)

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

04.02.2013, 15:28

@ sparky4
 

Open Source DOS Sound standards WOW!!!

Post reply

> forget about 'we'. open source projects don't work this way
> Well we should start somewhere and maybe implement the driver into the
> FreeDOS Kernel!
Don't do this. This won't solve any of aforementioned problems, and it creates many new problems.

> regard to virtualization techniques from real/V86 mode, the
> virtualization would not work properly from protected mode (e.g., DPMI)
We did arrive in the virtualized hell now :-(

Again, look at DUGL and WSS: a b c ;-)

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

Homepage E-mail

hell,
07.11.2013, 18:38

@ DOS386
 

Open Source DOS Sound standards WOW!!!

Post reply

ok
><

---
CRAZY wwww
sparky4

Homepage E-mail

hell,
29.12.2012, 21:27

@ sparky4
 

Open Source DOS Sound standards!

Post reply

ohh!!

is there any open source sound emulation drivers for dos that exists?

---
CRAZY wwww
Back to index page
Thread view  Board view
22762 Postings in 2122 Threads, 402 registered users (1 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum