I thought DOSBox always reports the same amount of conventional memory free no matter how many TSRs you have loaded?

Have you tried changing the IRQ of the emulated SoundBlaster?

Have you tried searching Google and the forums for this error message?

you could try to change the emulated soundblaster in dosbox.conf
the sb16 emulation isn't as far evolved as the soundlbaster pro emulation.
(well not a correct term)

Hunterz: dosbox accounts for TSRs. It's just that in general dosbox doesn't a need for loading tsr as it's quite complete.

I've tried sb1,sb2,sbpro1,sbpro2 and sb16 for the type and IRQs 5 and 7. All give the same result. What's weird is that other games using the Miles sound drivers work perfectly.

I've e-mailed Bethesda Softworks' support department but, to be honest, I don't really expect much help from them.

Well, admittedly, Bethesda replied quickly, but is was as useless as expected. Just the standard drivel of making a bootdisk. I don't think they've even heard of DOSBox or VDMSound.

They've definitely heard of VDMSound, as they included it with hand-burned disks they were sending people on request a couple years ago to help get Daggerfall working under Win2K.

The reply you got was probably an automated response, and your email probably hasn't been read by a human.

There's a link to DOSBOX right on their Arena free download page I believe.

I remember eyeing DeltaV when it was a new release. I've never actually played it though. Is it any good?

Okay, I've sent them a reply. I hope this gets solved.

Delta V isn't a very good game. The graphics are rather good and it's nice for a quick blast, but it gets boring rather quickly (the programmers seemed to be more concerned with creating a technically impressive game rather than making on that's fun to play).

I've been testing loads of games, though (359 thus far), because I'm creating a DVD with all my old DOS games on them and a frontend I created myself (see screenshot below), which dynamically generates optimal DOSBox config files for each of them. Thus far, Delta V CD is the only game I haven't gotten to work properly, with the exception of some minor graphical glitches in KQ6CD and Thexder. Also, I had to patch Dynamix' Ghost Busters 2 to fix a bug in their digitised sound routine 😒

I'm also adding freeware re-releases, such as Beneath a Steel Sky, Arena, Betrayal at Krondor etc. as well as cheats and walkthroughs for each adventure game. It's for my own personal use, and can't give it away since I do actually own all these games, but a fun project nonetheless.

So much for Bethesda:
"Delta V is not supported in Windows XP, I gather you already know that. There is not much we can do to help you here. We sent the documentation we have and that is the limit of the support we can give for this title."

Oh well, didn't expect much anyway.

In other words, anyone who ever heard of that game at Bethesda probably doesn't even work there any more 😒

Yep. I've already unpacked the EXE file. Time to get out my trusty debugger and see if I can find what's going on here. I've been doing that a lot lately, fixing bugs in old games. I suppose I should set up a patch archive.

Good grief!!! It's a copy-protection routine that misfires!!!

The program checks the modification timestamp for one of the files on the CD and gives this cryptic error message if there is a mismatch with what it expects (probably an invalid date stored on the CD). Patching out the copy protection makes the game work flawlessly.

Quite why this doesn't happen without sound enabled is anyone's guess. Why it happens on an original CD is even more mysterious!

which date does it compare it against ?
can you see something that might indicate a bug in dosbox ?

The game checks for 16:31:46 on October 12th 1994.
Windows reports the file on CD to be 01:31:46 on October 13th 1994.

Since Windows gives the same timestamp as DOSBox, I think the actual value stored on the CD is deliberately faulty and that the ISO parser in the real MSCDEX (not WinXP's version of it) translated this incorrect value differently than the WinXP's implementation.

hmm that is indeed weird. maybe our imgmount could "correct" for it. but it's very tricky material.

could it be a timezone problem (localtime can take in account the current timezone)

Good one about the timezone! Changing my timezone to PST does change the timestamp to what the game expects. That is very annoying (and impossible to correct for in some cases).

BTW, I'm not using imgmount, but mounting a directory, which is how I found this bug.

well I wonder if we can correct for the timezone somehow as dos didn't have clue about it.

but somehow it feels like windows messing up. as why would somebody change the date on file if the timezone is different. it makes little sense to me.

That is because WinNT stores the timestamp in Zulu time. This helps in keeping things straight during the switch to/from DST. DOS and Win9x store timestamps in local time.

There's no way to correct for it, since it is impossible to tell under which system the timestamp was generated. Even if you did it for everything on CD, it wouldn't help in my case with a directory mounted as CD.

well for dosgames it's reasonable to assume that the cdroms were made on a dos like system.

the timestamp on the cdrom is the correct one. and dosbox should just find a way to bypass windows it's intelligence.
Which might give some problems though for newly created files.

Anyway It's fairly simple to detect if we are on 9x or nt. so it might be possible to display times inside dosbox as localtime instead of zulu time.

but not sure. Been ages since I worked under that bugged os 😀

On 9x, it's simple: don't do anything. Windows gives you what you want.
On NT, you'd have to compensate. IIRC, the CDROM ISO image contains a timezone identifier and timestamp stored in that timezone. NT adjusts from that timezone to Zulu and then on to your local timezone. In the case of DeltaV, the stored timezone was PST/GMT-8 and my timezone is GMT+1, so WinXP added 9 hours to the timestamp. DOSBox already gets the time in localtime (your localtime, not the localtime where the file was generated -- you'd have to extract that from the ISO image).

When I copied the file to the hard drive, WinXP converted this to Zulu time (adding 8 hours) and re-adjusts whenever it needs to display the time (so it still shows the same as on the CD). All terribly confusing.

Personally, I wouldn't bother including this in DOSBox.