I'm not aware of any "official" means of identification, and interrupt function idiosyncrasies could be subject to change. An identifier that seems reliable for all machine types is the BIOS copyright and version strings at F000:E000. Searching the 128 bytes starting from that address for the string "DOSBox" is probably more future-proof than testing specific memory offsets.

BTW, please describe the code that borks DOSBox, particularly if it could represent a compatibility issue for games.

ripsaw8080 wrote:

An identifier that seems reliable for all machine types is the BIOS copyright and version strings at F000:E000. Searching the 128 bytes starting from that address for the string "DOSBox" is probably more future-proof than testing specific memory offsets.

That is exactly what I had come up with. I'll go with that for now.

BTW, please describe the code that borks DOSBox, particularly if it could represent a compatibility issue for games.

I don't believe it can, but I'll post the code anyway. The tool I'm writing is a benchmark for 16-bit DOS machines and emulators (with DOSBox specifically in mind -- more on this in a week when I finish it), and one of the things it does to ensure non-skewed numbers is make sure the floppy drive motor is off before measuring timings. Many 286 to 486 machines slow down the CPU, bus, or both during floppy accesses for greater compatibility with complicated floppy disk copy protection schemes, so it's important to check before benchmarking. (It will be a common task to run this benchmark from a bootable floppy disk, hence the concern.)

When running this code on a DOSBox session with fixed cycles (I tried as high as cycles=fixed 20000), there is no problem. But when running it with these specific settings:

1priority=higher,normal
2core=auto
3cputype=auto
4cycles=max

...then the code locks up DOSBox 0.74 (in Windows 7, the program hits a status of Not Responding). This is on a 2009-era 3.2GHz Core i7.

Here's the code (sorry for the mixture of pascal and asm):

1Procedure WaitFloppySpindown;
2{Waits for all floppy drives to spin down, or 5 seconds, whichever comes
3first.  This is desirable because many 486 and lower computers slow down to
48MHz while the floppy drive is operational (for compatibility with old copy
5protection schemes, amongst other reasons).}
6const
7  maxWaitSecs=5; {wait up to five secs for the disk drive motors to shut off}
8  threshold=trunc(maxWaitSecs*18.2);
9var
10  l:longint;
11  TicksSinceMidnight:longint ABSOLUTE $0040:$006C;
12  DriveMotorStatus:Byte ABSOLUTE $0040:$003F;
13begin
14  l:=TicksSinceMidnight;
15  repeat
16    asm
17      hlt {do nothing; wait for something interesting}
18    end;
19  until (DriveMotorStatus and $0F=0) or (TicksSinceMidnight-l > threshold);
20  {wait an additional second, as some machines need more safety margin}
21  l:=TicksSinceMidnight;
22  repeat
23    asm
24      hlt {do nothing; wait for something interesting}
25    end;
26  until (TicksSinceMidnight-l > 18);
27end;

I wanted to log this in the DOSBox debugger to see where specifically it was dying, but while it used to work for me a few months ago, it doesn't seem to be working now -- when I run the debugger version, ALT-Pause doesn't break into the debugger (am I hitting the right key? What should the keymapper definition look like?)

Have you tried your program on a DOSBox build of straight SVN source? I ask because a change was made to the HLT instruction in revision 3683 that could possibly apply to the problem you describe. If HLT is indeed the source of the problem, you could simply avoid using it.

I have not tried on an SVN build because I lack the knowledge (and patience to learn) how to compile DOSBox for Windows from source. Is there a regularly-published Windows SVN build I can try?

(Also, if anyone could answer my debugger question, that would be great. I don't know why ALT-PAUSE isn't working; i was able to get into the debugger before, but maybe I was doing something different or using a different key or something)

http://www.emucr.com/search/label/DOSBox

Use the most recent build from EmuCR labeled as "DOSBox SVN rXXXX" for testing; other builds are probably not vanilla SVN source.

Alt-Pause is the correct key to break into the debugger in a debug build; however, it may not work if DOSBox has become unresponsive with the problem you describe. Ensure that the key is working by trying to break into the debugger while idling at the prompt. Deleting the mapper file is the easy way to reset the key mappings to default, and there is a shortcut for doing that (under the DOSBox Start Menu group on Windows).

ripsaw8080 wrote:

Use the most recent build from EmuCR labeled as "DOSBox SVN rXXXX" for testing; other builds are probably not vanilla SVN source.

This fixes the problem! The SVN build I used was 3786. Good catch!

Alt-Pause is the correct key to break into the debugger in a debug build; however, it may not work if DOSBox has become unresponsive with the problem you describe. Ensure that the key is working by trying to break into the debugger while idling at the prompt. Deleting the mapper file is the easy way to reset the key mappings to default, and there is a shortcut for doing that (under the DOSBox Start Menu group on Windows).

This is clearly not working for me, even after resetting the mapper. I can get into the debugger by running a program with DEBUG PROGNAME.EXE but I need to be able to break into a program that's been running for a while.

What is frustrating for me is that this used to work -- I analyzed some 3-D games about 6 months ago. I don't understand what's changed that is preventing me from breaking into the debugger.

Okay, I fixed my mapper problem -- running DOSBox.exe -resetmapper did not fix my ALT-PAUSE problem, but dosbox-74-debug.exe -resetmapper worked. So I'm all good now.

I guess my last question would be, "Why does the debug version use a different mapper, and where is that located?"

Probably the debug version uses a different config file and mapper file. The console should show you which when you start the debug version.

Nope - the debug version actually uses the same mapper filename as vanilla 0.74. Funny thing is, I just ran dosbox-074-debug.exe for the first time (been using ykhwong's debug build until now), and it gave me the exact same problem.

Turns out the cause is quite simple: 0.74 (non-debug version) doesn't map the Debugger event by default. If you have a saved mapper file from 0.74 when you run 074-debug, it'll use that file, and "hand_debugger" will remain undefined until you do a -resetmapper.

For reference, the default location under Win7 would be %appdata%\Local\DOSBox\mapper-0.74.map, and the
definition for alt-pause should be:

1hand_debugger "key 19 mod2" 

Another mystery solved 😀 Thanks!

Well, it could be said that you ran into trouble because you didn't follow the advice given...

ripsaw8080 wrote:

Deleting the mapper file is the easy way to reset the key mappings to default, and there is a shortcut for doing that (under the DOSBox Start Menu group on Windows).

If you look at what that menu shortcut does, it runs DOSBox with an -erasemapper parameter, not -resetmapper. 😉

both should work though.

You could check if the debugger and regular version use a different configuration file that might specify a different mapper file.

and of course console should be shouting about the problem too if you bothered to read it 😉

Qbix wrote:

both should work though.

They both work in the sense that they function as intended, but they don't do the same thing. When the debug and non-debug build of a given version of DOSBox share the same mapper file, which they do by default, using -resetmapper instead of -erasemapper creates the kind of problem discussed here because the non-debug build does not write a debugger keybind into the mapper file. Deleting the mapper file ensures that both builds are using their default key mappings.

To avoid issues with sharing a mapper file between builds one has only to change the name of the mapper file in the conf, assuming that each build has its own conf (not sharing a conf).

I was refering to erasemapper and resetmapper. They both do the same thing.

of course manually deleting it is even better. There is a limit on how much logic one can and should put in a function that tries to delete the right file.

ripsaw8080 wrote:

I'm not aware of any "official" means of identification, and interrupt function idiosyncrasies could be subject to change. An identifier that seems reliable for all machine types is the BIOS copyright and version strings at F000:E000. Searching the 128 bytes starting from that address for the string "DOSBox" is probably more future-proof than testing specific memory offsets.

The current BIOS version string reports DOSBox FakeBIOS v1.0. I'm not sure if this is a good idea as far as it being future-proof, but (going forward) has having the actual DOSBox version number (DOSBox BIOS vN.NN) as part of the BIOS string been considered?