VOGONS

Common searches


Dos Sound Driver

Topic actions

First post, by jmdlcar

User metadata
Rank Newbie
Rank
Newbie

I got this from my Linux OS and I use MS-Dos 6.11 a long long time ago. I do not have any type of Window installed. What I want to do is run my ID Software and some more games. Can some one tell if there is a driver for my Laptop?

Here is the output my Linux shows.

SOUND CARDS: […]
Show full quote

SOUND CARDS:

HDA-Intel - HDA Intel
Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC9228 Analog [STAC9228 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 7: STAC9228 Digital [STAC9228 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0

Reply 1 of 22, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

There is no DOS driver for HDA audio chipsets. The HX extender can apparently work for some Win32 compatible console software, however.

Any reason to not try DOSBox?

All hail the Great Capacitor Brand Finder

Reply 2 of 22, by jmdlcar

User metadata
Rank Newbie
Rank
Newbie

I thought DosBox was a Computer. My last Window I use was XP then I started using Linux. I guest I will need to find a Computer that has a P2 or P3 CPU and sound card in it. I am 70 years old now and wanted to try Dos again. I have it on a USB and I am using it on my Laptop which I have Linux on the Hard Drive. The Dos works on the USB but no sound other the that it works great.

Update:

I can get the HP DC5750 Desktop for free so do you think this sound card will work?
https://www.ebay.com/itm/PCI-E-Express-5-1ch- … hkAAOSw7z1aEMrS

The Computer has PCI-E-Express slot. Will I have a problem finding the driver for it

If this message is in the wrong place please move it.

Reply 3 of 22, by Malvineous

User metadata
Rank Oldbie
Rank
Oldbie

Download DOSBox, you'll save yourself weeks of frustration.

No modern commercially produced audio hardware will work with DOS any longer. The hardware has all changed and it stopped being backwards compatible in the early 2000s. Once PCI came around the hardware quickly stopped working in DOS, and PCI-Express has replaced PCI so it is even less compatible with DOS.

The DOSBox program emulates lots of different hardware very well, and in some cases is better than the original hardware (e.g. good luck funding a GUS card, but DOSBox will emulate one quite well.) DOSBox works very well under Linux too.

(btw where is @collector? He's usually the first one here to point out that someone posted in the wrong forum!)

Reply 4 of 22, by Jo22

User metadata
Rank l33t++
Rank
l33t++
jmdlcar wrote:

I got this from my Linux OS and I use MS-Dos 6.11 a long long time ago.[..]
What I want to do is run my ID Software and some more games.[..]

On *nix systems, there's also DOSemu (and DOSBox, of course). 😀

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 6 of 22, by digger

User metadata
Rank Oldbie
Rank
Oldbie

Good to read that I'm not alone in this. I've been wanting to extend VSB (Virtual Sound Blaster) to support newer AC'97 and Intel HD Audio chipsets, but first, I need to port the existing assembly code from TASM to an open source assembler. This has proven to be much easier said than done. I've also mentioned this in this topic. I guess I should open a separate topic on this, since there seem to be enough people genuinely interested in such a solution.

Reply 7 of 22, by keenmaster486

User metadata
Rank l33t
Rank
l33t
digger wrote:

Good to read that I'm not alone in this. I've been wanting to extend VSB (Virtual Sound Blaster) to support newer AC'97 and Intel HD Audio chipsets, but first, I need to port the existing assembly code from TASM to an open source assembler. This has proven to be much easier said than done. I've also mentioned this in this topic. I guess I should open a separate topic on this, since there seem to be enough people genuinely interested in such a solution.

THANK YOU. I've been making noise about this for years but nobody seems interested.

VSB, however, is a difficult program to run to say the least. It is very picky about what it runs on and how, and many games aren't compatible with it due to the fact that it must run in real mode.

I think a better place to start would be the TSRs for the OPL2LPT and OPL3LPT projects, which could theoretically be utilized to emulate Adlib sound on any number of modern sound cards if you really want to put this much work into it.

jmdlcar wrote:

I want Dos to be ran the way it is meant to be ran. Sorry.

Kudos to you - you need a period-correct PC. DOS really won't run the way it was meant to be run on anything other than that.

Find yourself something from about the 1994-ish era, just before Windows really took over the market.

World's foremost 486 enjoyer.

Reply 8 of 22, by jmdlcar

User metadata
Rank Newbie
Rank
Newbie
keenmaster486 wrote:
jmdlcar wrote:

I want Dos to be ran the way it is meant to be ran. Sorry.

Kudos to you - you need a period-correct PC. DOS really won't run the way it was meant to be run on anything other than that.

Find yourself something from about the 1994-ish era, just before Windows really took over the market.

Can you tell me is it a 386 or 486 or higher? What is the fastest CPU speed? That way everything is in the same era.

Reply 9 of 22, by keenmaster486

User metadata
Rank l33t
Rank
l33t

What years do the games you want to play date to?

You mentioned ID Software. Is this Commander Keen we're talking about, or something more advanced like DOOM?

World's foremost 486 enjoyer.

Reply 10 of 22, by jmdlcar

User metadata
Rank Newbie
Rank
Newbie
keenmaster486 wrote:

What years do the games you want to play date to?

You mentioned ID Software. Is this Commander Keen we're talking about, or something more advanced like DOOM?

I have the full version of wolfenstein-3d and doom and few other games.

It going to hard to find a 486 computer I just wish the HP DC5750 computer would work. I think I found Dos network driver for it.

Reply 11 of 22, by jmdlcar

User metadata
Rank Newbie
Rank
Newbie

I found out today that I can boot Dos from a USB but it won't on a 2GB Hard Drive. I partition the Hard Drive with 2GB for Dos and the rest of the Hard Drive for Linux. It was a 80GB Hard Drive. It was formatted from a boot able CD I type format c: /s then I copy the Dos file then I try to boot up then I got the error.

So I do need to fine a old Computer somewhere for sure. Tell then this project is on hold.

Reply 12 of 22, by Plasma

User metadata
Rank Member
Rank
Member
digger wrote:

Good to read that I'm not alone in this. I've been wanting to extend VSB (Virtual Sound Blaster) to support newer AC'97 and Intel HD Audio chipsets, but first, I need to port the existing assembly code from TASM to an open source assembler. This has proven to be much easier said than done. I've also mentioned this in this topic. I guess I should open a separate topic on this, since there seem to be enough people genuinely interested in such a solution.

Open Watcom 2.0 can assemble TASM sources with little to no modifications (use the -zcm=tasm switch for ideal mode).

Reply 13 of 22, by digger

User metadata
Rank Oldbie
Rank
Oldbie
Plasma wrote:

Open Watcom 2.0 can assemble TASM sources with little to no modifications (use the -zcm=tasm switch for ideal mode).

I just tried that, both with Open Watcom versions 1.9 and 2.0 beta (open-watcom-2.0-2017-11-01), and it didn't work with either version. 🙁 Strangely enough, I got exactly the same errors when I omitted the -zcm argument and even when I set it to a bogus value, such as -zcm=blabla. It's as if the zcm switch is being completely ignored for some reason. This was the case for both versions I tried.

So far, I've also tried converting the TASM code to NASM code using the Nomyso script, but that didn't work either. I started an attempt to manually port the code from TASM to FASM, but that's proven to be a lot more complicated than I had hoped. See also this thread I opened in the Flat Assembler forum.

Maybe I should really open a separate topic for this. And maybe it would be better to start from scratch anyway.

Reply 14 of 22, by Plasma

User metadata
Rank Member
Rank
Member

The code looks like a sloppy combination of ideal and masm syntax. WASM doesn't support the "smart" directive or multiple passes so you will have to make some changes. It's also more strict and throws errors for things TASM lets you get away with, like omitting the proc name from ends/endp. But I guarantee making those changes will be easier than porting everything to FASM.

Reply 15 of 22, by digger

User metadata
Rank Oldbie
Rank
Oldbie

I'd like to give it another go, this time targeting WASM instead of FASM, but I'll still need some help with that. Particularly the restructuring of the code to allow single-pass assembly seems like a lot of work to me. Or am I overestimating that? Anyway, thanks for the pointers you've given so far and for any further help that you can provide with this. 😀

Reply 17 of 22, by digger

User metadata
Rank Oldbie
Rank
Oldbie
Plasma wrote:

It shouldn't need much restructuring, mostly just specifying variable sizes when they are used before they are declared.

Okay, I'll look into that. But what about the fact that the -zcm option doesn't seem to make any difference? I would at least expect different errors depending on the zcm value, as well as a specific error if I specify something non-existent, such as -zcm=bogus_assembler.

Reply 18 of 22, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++
digger wrote:
Plasma wrote:

It shouldn't need much restructuring, mostly just specifying variable sizes when they are used before they are declared.

Okay, I'll look into that. But what about the fact that the -zcm option doesn't seem to make any difference? I would at least expect different errors depending on the zcm value, as well as a specific error if I specify something non-existent, such as -zcm=bogus_assembler.

Is the compiling bombing out before it is even supposed to process the -zcm directive? If so, then I would expect the change of the value for -zcm to not make a difference.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK

Reply 19 of 22, by digger

User metadata
Rank Oldbie
Rank
Oldbie
cyclone3d wrote:

Is the compiling bombing out before it is even supposed to process the -zcm directive? If so, then I would expect the change of the value for -zcm to not make a difference.

Actually, I take that back. There is in fact one line that wasm accepts when -zcm=tasm is specified:

LOCALS  @@

From what I understand, this directive is specific to TASM's Ideal mode, but apparently it's redundant, since it exactly defines the default behavior in Ideal mode, i.e. the fact that variables prefixed with "@@" are to be treated as locals. However, even though wasm appeared to accept this line when the aforementioned zcm parameter was specified, it still failed on the reuse of a variable name with that prefix in two different routines. I worked around that by renaming the variable in one of the routines. After making some other changes as well, I was finally able to eliminate all errors, leaving only the following warnings:

vsb_qemm.asm(78): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(80): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(86): Warning! W096: size not specified -- WORD PTR is assumed
vsb_qemm.asm(97): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(104): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(107): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(109): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(134): Warning! W096: size not specified -- WORD PTR is assumed
vsb_qemm.asm(136): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(137): Warning! W096: size not specified -- WORD PTR is assumed
vsb_qemm.asm(139): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(144): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(145): Warning! W097: size not specified -- DWORD PTR is assumed
vsb_qemm.asm(150): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(153): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(156): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(159): Warning! W096: size not specified -- WORD PTR is assumed
vsb_qemm.asm(457): Warning! W095: size not specified -- BYTE PTR is assumed
vsb_qemm.asm(581): Warning! W096: size not specified -- WORD PTR is assumed
vsb_qemm.asm(1290): Warning! W599: alignment request greater than segment alignment

But then I hit another weird snag: wasm didn't preduce any output, other than an .err file containing the aforementioned warnings. No object file or anything! 😕

I'm kind of stuck, right now. What else could I possibly be doing wrong? If the assembler completes with warnings, but with no errors, why isn't it generating any object code? I tried this with the WASM versions in both Open Watcom 1.9 and a recent build of Open Watcom 2.0, with the same disappointing result. I tried it with both the Linux and DOS versions of WASM, the latter inside a DOSBox session, to no avail.

Strangely enough, if I explicitly specify a target object file in a non-existent or non-accessible path, using the -fo parameter, it specifically complains about not being able to open said file. But it doesn't appear to generate any object file when a correct path is specified, or when the -fo parameter is omitted.

Does anyone here have a clue of what I'm doing wrong? I'm attaching the versions of the files with the changes I made to eliminate all the errors in wasm, at least with -zcm=tasm.

Attachments

  • Filename
    vsb_qemm_with_wasm_changes.7z
    File size
    6.4 KiB
    Downloads
    88 downloads
    File comment
    The files with the changes I made to eliminate errors when assembling with WASM. Unpack this and build it with "wasm vsb_qemm.asm -zcm=tasm". It should result in an object file, but it doesn't, for some weird reason. See the repository at https://github.com/volkertb/temu-vsb for the original versions of these source files.
    File license
    Fair use/fair dealing exception