So it's used internally only? Shouldn't matter then. I thought it was some
large buffer for something.
DOS OVL file writes to this memory which function to run and then writes to IO port to activate it 😀
Just in case, I tried your suggestion, but as you already anticipated, it didn't change anything.
Then the ball is back to gulikoza 😀 No seriously, no idea how this stuff
works at all. Using dosbox dos memory (0xd800+) as transfer area sounded
like a bad idea to me at first, but i think it's safe to assume that the extender
maps the whole <1mb when switching to (in the worst case) v86 mode.
Maybe you can kick in the dosbox debugger on glide calls and see what
code is around there, or something like that.
It's not glide 😀
As a desperate attempt, I pulled out my voodoo2 and installed win98 on a spare machine. The game obviously works. But something came to me...the game does not switch to 3D mode until the flying sequence. So initglide, open, shutdown is just an initialization test to see if voodoo hardware is present. It passes this test or it would fail with no voodoo hardware error. Now to the interesting (or not so interesting) part:
I've stripped down everything from glide...all...just left a bunch of return statements. Still nothing. Then I tested some glide test programs (which at this point couldn't do anything), and afterwards tried to run the software version - IT DIDN'T WORK. Just to be sure, I completely removed the glide2x.ovl, so the test programs didn't load...the software version still failed. As the last test, I loaded up Doom in the Qbix 0.65beta (sorry, the only "official" dosbox build I have installed 😀), exited, and then ran AD in software mode. The game did not load. The debug builds I have all stopped on loading the same file, I assume the 0.65beta does too. The game obviously doesn't like something, why it only shows in glide mode is beyond me 🙄
Just to clarify...the software version loads the fist time it is started in all the cases (even if you quit and run it again), but does not seem to load if something was loaded before it.
Two things to maybe try: disable ems (vcpi might switch permanently to
v86 mode) and umb. And maybe add a program that clears that memory
region and gets the ports right (if they save some state).
Well, all my recent tests have been done with XMS only. And the MS-DOS boot image variant also failed in all possible combinations, so there's not much left that could be the cause.
Is there anything in VGA/VESA emulation that could permanently change state? The hang happens shortly before switching to VESA 16-bit mode, and the next file that would be loaded if it didn't hang ends in ".pal", sounds like there is already some kind of video initialization in progress.
Just print out what ints are called (cpu.cpp) along with the cs:eip, then use
the last one (or the last "easy" one) as start for debugging.
Can you enter the debugger when the screen is black, or is dosbox hanging
completely?
Hah! Got it!
The hang occurred while waiting for a keyboard controller ACK (0xFA). It was never issued, because when CMD_SETOUTPORT was issued, it never got reset to CMD_NONE again, so all keyboard commands were ignored after that.
Here's a patch that makes Schleichfahrt 3dfx work, although I have no idea if it is actually correct or should be fixed differently.
Index: keyboard.cpp
===================================================================
RCS file: /cvsroot/dosbox/dosbox/src/hardware/keyboard.cpp,v
retrieving revision 1.35
diff -u -r1.35 keyboard.cpp
--- keyboard.cpp 9 Feb 2006 11:47:49 -0000 1.35
+++ keyboard.cpp 28 Nov 2006 20:14:48 -0000
@@ -150,6 +150,7 @@
return;
case CMD_SETOUTPORT:
MEM_A20_Enable((val & 2)>0);
+ keyb.command=CMD_NONE;
break;
case CMD_SETTYPERATE:
{
Well, glide output is poor. HUD is missing, mission briefing is missing, fog is buggy, but at least the ground is showing correctly 😉
wrote:Just print out what ints are called (cpu.cpp) along with the cs:eip, then use the last one (or the last "easy" one) as start for […]
Just print out what ints are called (cpu.cpp) along with the cs:eip, then use
the last one (or the last "easy" one) as start for debugging.
Can you enter the debugger when the screen is black, or is dosbox hanging
completely?
The debugger did work, the problem was in a small "in al, 60; cmp al, fa; jne $ip-6" loop that never got 0xfa from port 60 in response to a SETLEDS command.
This is the second time the debugger actually helped me track down an error, I am terribly proud. Usually, I don't understand what's going on in there, I am bad at reading assembler.
BTW, your tip to print out interrupts being called, couldn't that be built into the debugger somehow? I guess it's a common trick to find a start, it would be useful to have a command that starts interrupt tracing or soemthing like that.
SCREENSHOTS!!!
Resetting the keyboard command flag might make sense,
should be somewhere in the docs, or bochs.
Okay, here are some Screenshots 😉
BTW, someone who is capable might want to split this thread, since the problem turned out to be not related to glide at all. Although the rendering errors, the missing HUD foremost, is a severe problem, the game is unplayable this way.
Cool 😀 The fix should be fine btw., got to test this against various windows
versions yet.
> BTW, your tip to print out interrupts being called, couldn't that be built
> into the debugger somehow?
It's not usefull as is, mostly it ends up excluding several ints at all because
it is too slow otherwise. Would need some configurable command for
this (somebody implement a softice-like interface? please.....)
