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?
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.
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!)
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
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.
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.
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.
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).
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.
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.
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. 😀
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.
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.
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:
1LOCALS @@
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:
1vsb_qemm.asm(78): Warning! W095: size not specified -- BYTE PTR is assumed 2vsb_qemm.asm(80): Warning! W095: size not specified -- BYTE PTR is assumed 3vsb_qemm.asm(86): Warning! W096: size not specified -- WORD PTR is assumed 4vsb_qemm.asm(97): Warning! W095: size not specified -- BYTE PTR is assumed 5vsb_qemm.asm(104): Warning! W095: size not specified -- BYTE PTR is assumed 6vsb_qemm.asm(107): Warning! W095: size not specified -- BYTE PTR is assumed 7vsb_qemm.asm(109): Warning! W095: size not specified -- BYTE PTR is assumed 8vsb_qemm.asm(134): Warning! W096: size not specified -- WORD PTR is assumed 9vsb_qemm.asm(136): Warning! W095: size not specified -- BYTE PTR is assumed 10vsb_qemm.asm(137): Warning! W096: size not specified -- WORD PTR is assumed 11vsb_qemm.asm(139): Warning! W095: size not specified -- BYTE PTR is assumed 12vsb_qemm.asm(144): Warning! W095: size not specified -- BYTE PTR is assumed 13vsb_qemm.asm(145): Warning! W097: size not specified -- DWORD PTR is assumed 14vsb_qemm.asm(150): Warning! W095: size not specified -- BYTE PTR is assumed 15vsb_qemm.asm(153): Warning! W095: size not specified -- BYTE PTR is assumed 16vsb_qemm.asm(156): Warning! W095: size not specified -- BYTE PTR is assumed 17vsb_qemm.asm(159): Warning! W096: size not specified -- WORD PTR is assumed 18vsb_qemm.asm(457): Warning! W095: size not specified -- BYTE PTR is assumed 19vsb_qemm.asm(581): Warning! W096: size not specified -- WORD PTR is assumed 20vsb_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.
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.