Anonymous wrote:

The NTVDM CPU encountered the following illegal instruction CS:03ff IP:0214 OP:617272 […]
Show full quote

The NTVDM CPU encountered the following illegal instruction
CS:03ff IP:0214 OP:617272

And it changes.
I think this is useless for your purposes since it doesn't apperar to come from
dos/32a. I tried redirecting the output of ORION2 to a file, but it is still empty after the error.

I see. Sporadic crashes of the entire NTVDM were unexpected, there is little I can do to remedy this since I don't have the game. Thanks for reporting this anyway.

Dark Forces will run for about 5mins before dieing with tons of illegal writes and reads in the dosbox log window.

edit: Using DOS32A 7.33 that is. Dark Forces works fine with its DOS4GW within DOSBOX.

narech: You might be able to reproduce the results with the demo version of the game, which is probably floating around somewhere on the 'net

I've been able to reproduce moo2 crash in native WinXP (NTVDM) using the demo version from Atari's website + DOS binary from the latest 1.31 patch. I cannot however get moo2 nor df (demo) to crash in DOSBox; they seem to be working fine with both DOS/32A & DOS/4GW. If anyone has more info or noticed similar behaviour of DOS/32A + other games and can suggest a reproduceable usecase leading to a crash, don't hesitate to post them.

- NK

What DOSBOX build are you using? I'm using Gulikoza's CVS build with D3D so that may be the problem.....

I use CVS+D3D, 0.63 retail and 0.63 debugger. Different versions could cause problems but I don't think that's the reason for the crashes. Since the general description of the problem seems to be sporadic failures of a game after it's been running for some time I suspect there might be a latent bug somewhere in the DOS Extender's client code. Unfortunately, since I can't reproduce it, I cannot fix it.

Well with Dark Forces running natively in XP, using just VDMSound, it seemed stable with DOS32A.

I know the original post was edited, but the topic's name wasn't.
So here goes - a new version (7.35) has come out in May.

Try and see if it solves more problems.

From updates.txt:

[2005-05-19] DOS/32 Advanced DOS Extender, version 7.35 ========================================== […]
Show full quote

[2005-05-19]
DOS/32 Advanced DOS Extender, version 7.35
==========================================

DOS Extender (DOS32A.EXE):
--------------------------
+ mouse callback code cleanup
+ allocation of up to 2Gig under Clean system (Int 15h, AX=E820h)
+ with verbose mode active and not under external DPMI the entry point
of application will trap to internal debugger

Thank you for the heads up, lwc. I updated the topic title. 😎

I've been running the latest DOSBox CVS, stock except for compiling in native Munt (MT-32 emulator) support. I tried testing Dark Forces (full version, original CD) with DOS/32A as a drop-in replacement for DOS4GW.EXE and the game seems to freeze up with a whole bunch of illegal read/write messages in the DOSBox console window. The first time I tested, it happened only after a minute or so, but the second time took several minutes before I saw the problem.

I had previously been testing with DOS4GW and have never encountered this problem.

It could be a compatability issue between DOSBox and DOS/32A.

Was: interesting but wrong theory... removed to avoid any confusion.

Cheers,

- NK

Not good. After countless debugging sessions involving a modified version of DOSBox, lots of coffeine and a hammer I've figured out what's wrong with Dark Forces running under DOS/32A. In short, this is a manifestation of "Problem 5" described in http://dos32a.sourceforge.net/wwwroot/manual/html/util/6.htm .

For the technically inclined: DF installs an exception handler for Division by zero CPU error. Apparently, there is code in DF whose logic causes that error and judging from disassembly and the pattern of the crashes it is not system related, e.g. it seems to be something as trivial as GFX or AI. For some reason they are not handling it with "if" statements (tight schedule?) but choose to hardcode this:

exception0_handler:
push ebp
mov ebp,esp
add dword ptr [ebp+10h],2 // this skips the "idiv ecx" opcode that causes Exception0
pop ebp
retf

Since DOS/32A does not follow DPMI spec regarding stack frames for exception handlers (which is my fault: far too much aggressive optimization) this causes the stack to become completely screwed up and ultimately leads to game crashes.

Since this is documented, I won't tag this as a bug, but until I figure out a good way of handling this,.. this is a WONTFIX.

Too bad,

- NK

Wow. Great troubleshooting! At least we know and you know what that means!

Knowing is half the battle! (Well mabye not in this case....)

Well, I've fixed it. In other words DF now appears to work correctly with DOS/32A in DOSBox. This might also allow other apps to run with DOS/32A which previously failed. Since there is quite a severe change in the kernel it will require a lot of testing. As a side effect the changes break the debuggers (both internal and SD) which relied upon being fed with non-standard exception stack frames 🙁 .

- NK

/suck up mode enabled

😲

Wow, thanks for following up on that one and implementing a fix. Can't wait to play with the next release.

narech, there's something subtle I've discovered in dos32a: in M.A.X., the intro movie is smooth with dos4gw, but a little chunky in dos32a. It's not the amount of cycles, I've checked that. It looks as if there were two threads and timeslices are distributed differently. It's by no means grave (I don't care, since overall speed is the same), but I thought I mention it.

For some reason I get random lockups in DF with CVS builds from http://ykhwong.x-y.net/ . Can't reproduce that with my local build of DOSBox (albeit I use MSVC8 Beta2). This is not related to the DivByZero problem, I can still debug the game which appears to be going in an endless loop. PM me about experimental builds of dos32a if you want to help out testing.

The new v9 is still some way off. There have been some radical changes in both client and kernel code. Compatibility is at a premium.

@moe:

It looks as if there were two threads and timeslices are distributed differently.

I'm not sure what you mean.

Well, its like, the movie player gets it's turn showing some video, then something else is happening (sound? some other interrupt handler?) for a while, then video gets it's turn again. This is just a guess, but the symptoms are little pauses in video playback every half to full second. With dos4gw, video runs steady without any noticeable pause. As already said, actual overall speed is fine, and sound doesn't show any irregularities.

but the symptoms are little pauses in video playback every half to full second

Weird. Something may be getting called with interrupts disabled, perhaps through a callback. Or it could be DTB being too small. Try changing DTB size: http://dos32a.sf.net/wwwroot/manual/html/util/3f.htm . I don't have the game so I can't test it.

- NK