or even better F000? Since most of it seems to be empty...

Did anybody really test if emm386 works if the d000-segment is "free"?

We obviously cannot test it in dosbox cause D000 is not free in dosbox.
And on a real machine FRAME=D000 is used as default so it works.

You can simply move the stuff from d000 (callbacks+dos temp seg)
to e000 and see what happens. That's why i asked if somebody
already done this.

I've changed dos_memseg (and the check, too) to e000 but emm386 still complains.

I *think* emm386 searches for some rom (writeprotected complete
segment or something like that) thus it doesn't really matter where the
code of dosbox (callbacks etc.) resides. Maybe even some 0x55 0xaa
is enough.

There are the I and E options to unconditionally include/exclude segments. Normally, EMM386 will autodetect if a given address is usable. On certain chipsets (and in DOSBox, it seems), that failed, and using an I=foo-bar will force EMM386 to consider that area "usable".

robertmo wrote:

1. mouse: a) try the mouse driver from here: Der Patrizier: Mouse Problems b) or try ctmouse http://cutemouse.sourceforge.net/ […]
Show full quote

1. mouse:
a) try the mouse driver from here:
Der Patrizier: Mouse Problems
b) or try ctmouse
http://cutemouse.sourceforge.net/

Heh, those two worked even worse than TRMosue... MOUSE.COM even caused these peculiar palettes in QFG3 EGA graphics:

By the way, TRMouse does work in QFG3, I was wrong earlier; it doesn't work sometimes if a different mouse-using game was loaded before QFG3 though.
So, Countdown is the only problematic game out of the ones I tested, it appears.

2. ems:
try adding this parameter FRAME=E000 in the emm386.exe line

Qbix wrote:

and disable umb in dosbox.conf

When I do that, I get "WARNING: Option ROM or RAM detected within page frame." Even though this option gives 15296KB of available expanded memory, the game still crashes and gets corrupted.
I guess the noems option is the only one that works for now.
By the way, disabling or enabling umb in DOSBOX.CONF doesn't seem to make any difference.

> By the way, disabling or enabling umb in DOSBOX.CONF doesn't seem to make any difference.

It has only an effect if XMS is enabled in dosbox.conf, as it uses
the xms interface.

Big Red Adventure works perfectly when I use D=64
What do you think about setting D=64 as default in dosbox? Normally D=32 is default. You have already set files= and buffers= higher. Time for setting D= higher now 😀

Were you able to set D=64 for Big Red Adventure in DOSBox without booting real MS-DOS on an HD image?

No, I use a HDD image.

I have also noticed that intro always freezes (black screen) after the russian guy turns on the projector with Sound Blaster MIDI (with Adlib it is OK). This also happens on a real computer so I guess it is not a dosbox problem. I have tried underdogs version of the game and also a CD version of the game. Has anyone got a solution for that?

Try two things: use the line "DEVICE=EMM386.EXE NOEMS D=64" in CONFIG.SYS and run the game with Frameskip=0. It does not crash for me this way.

You have my vote for this rather annoying game intro, it would be nice to have a D=64 option without the need of installing real DOS in dosbox.

By the way, is there any reason why the CD version plays the MIDI tracks instead of the CD AUDIO tracks it has? Kind of odd...

Lonelines:
I suppose cd audio tracks are just for listening in your cd player.
I think Sam&Max also has cd audio tracks that are not used in game.

SirGraham:
I always use frameskip=0, and i don't think this option should affect this. Nevertheless it is good that it works for you. Maybe there is something broken with my versions of the game...

Lonelines:
Actually Big Red Adventure plays cd audio tracks for me, (some of them are midi/fm depending what you chose in setup) but most of them are cd. (There are about 60 audio tracks on the cd, so i guess if game has more of them the rest is played from midi/fm, but at least at the beginning almost everything is from cd.