dosbox has a debugger from itself. that one can not freeze memory but that functionality would be easy to add(as the debugger can allready break on memory changes)

most freeze application use the debugger registers on the cpu.
They are almost never used in games (maybe some extreme encryption/cdrom protection maybe)

You can just use GameWiz32.

STORE function doesn't work with DOS programs.

Didn't in native win98 either.

Qbix, does your post mean debugger registers are not implemented in dosbox [yet] ?

You mean, those programs would run if dosbox had these registers added or are there other parts which would need to be added?

dunno. debug registers are the most important.

but they will not be added i think. (might slow down a lot things.)
just stick to the dosbox debugger.
that one is much more powerful 😀 as it's completely in control of the machine (even time stops 😀

To run gamewizard, you need to edit int10_memory.cpp,
fct INT10_SetupRomMemory and change (at the beginning)
int10.rom.used=2; (was 3)
Don't ask why.

Then set up gamewizard with "video swapping=fast" as this
will use registers instead of an (unsupported) int10 call.
Now it should be possible to run it to some degree (could
crash every now and then, stuff not working etc.).

The memory freeze does a pretty simple thing, they check
the locations periodically and re-init them. This way
you don't get "hard"-frozen values as with debug regs,
but it works with games.

hth

Hm, forgot about that ems bug...
use ems=false or put the following into ems.cpp

static Bit8u EMM_AllocateMemory(Bit16u pages,Bit16u & dhandle) {
if (!pages) return EMM_ZERO_PAGES;
if ((MEM_FreeTotal()/4)<pages) { return EMM_OUT_OF_LOG;}
Bit16u handle=1;
while (emm_handles[handle].pages!=NULL_HANDLE) {
if (++handle>=EMM_MAX_HANDLES) { return EMM_OUT_OF_HANDLES;}
}
MemHandle mem=MEM_AllocatePages(pages*4,false);
if (!mem) E_Exit("EMS:Memory allocation failure");
emm_handles[handle].pages=pages;
emm_handles[handle].mem=mem;
dhandle=handle;
return EMM_NO_ERROR;
}

wd: Are these just workarounds to beat DOSBox and gamewizard into working with each other, or should some of this code actually be officially integrated into DOSBox?

The first one is a workaround, as dosbox looks
correct there. I debugged this some time ago,
but didn't get to the real cause, i think they
need the vga characters at a specific position
or so.
The second one is an ems bug in dosbox, i
guess it wasn't added because it did not turn
up somewhere else (or my fix was odd or i
forgot to send it 😉

Applied the patch. Still likes to hang up but in whole it runs. Thank you very much.

wd wrote:

The first one is a workaround, as dosbox looks correct there. I debugged this some time ago, but didn't get to the real cause, i […]
Show full quote

The first one is a workaround, as dosbox looks
correct there. I debugged this some time ago,
but didn't get to the real cause, i think they
need the vga characters at a specific position
or so.
The second one is an ems bug in dosbox, i
guess it wasn't added because it did not turn
up somewhere else (or my fix was odd or i
forgot to send it 😉

I've never seen it. at least I don't remember it.

well the ems patch seems to be correct.
it's stated clearly in ralphbrown that the handle only gets changed if there is no error.
modified ems code to match this behaviour.

is this now incorporated in the standard build?

Yes, I see it in the CVS changelog:

12005-01-12 13:44  qbix79
2
3	* src/ints/ems.cpp: Allocate memory changes handle only on succes.

This was after 0.63 was released, however, so you'll need to use a CVS build to have the fix.

Suppose it doesn't work though, see the int10.rom.used=2;
thing above.

With both patches applied, Game Wizard 3a Pro did run and executed most functions properly. In some cases it did odd things to the display - that's just like it behaved on 286.

Still, I'd prefer a built-in method but the thing I started is lost with my broken computer. It was ill-designed anyway. When I have something ready to present, I will present it.