There is another problem. The "Save Current Program To Disk" option never works.

i doubt that this is freeware to distribute.
Second. Why should this work ? It's not a game.

There was an old post where one problem about sound blaster in GW was fixed (included in DosBox 0.74 SVN):
suggested patch for sblaster.cpp

From the DosBox 0.74 SVN:

2011-04-19 19:46 c2woody

* [r3696] src/hardware/sblaster.cpp: fix sb halt/continue sequence when no transfer in progress (thanks to tcostin, fixes some GameWizard crash)

So I thought this problem about GW too, could be probably fixed. Sorry if not

well that commit might fix a game as well. I doubt that saving to disk will improve a game.
I think that if you boot a version of DOS inside dosbox that saving to disk will have a higher change of working than using our very own (very unusual) version of DOS.

Oh and actually use an svn built if you haven't

Bad luck.

It seems not right to distribute this. Besides as Qbix said GW is not a game. Remember: DOSBox main goal is to run MS-DOS games.

I have investigated a bit the problem using the standard DosBox 0.74 debugger. Just before the hang this is what DosBox debugger shows:

DOSMISC:DOS:Multiplex Unhandled call 1605
CPU:CPU:LOCK
CPU:CPU:LOCK
CPU:CPU:LOCK
CPU:CPU:LOCK
CPU:CPU:LOCK
CPU:Illegal/Unhandled opcode 63
CPU:Illegal Unhandled Interrupt Called 6

And the last two lines (bold ones) repeat in a loop...

This is the line that causes the first error
(DOSMISC:DOS:Multiplex Unhandled call 1605):

F000:15C0 FE382E00 callback 002E (DOS Int 2f)

Looks like the call to int 2F having AX=1605 is not handled by DosBox.
This is the info about int 2f with AX=1605:

http://www.delorie.com/djgpp/doc/rbinter/id/15/45.html

Also, the other 2 errors:

0000:0024 6313 arpl [bp+di],bx ss:[0311]=152A --> this causes CPU:Illegal/Unhandled opcode 63

F000:1060 FE380300 callback 0003 (default) --> this causes CPU:Illegal Unhandled Interrupt Called 6

INT 2F/1605 is not handled by DOS, so DOSBox does the same. It's a Windows call.

The memory address of the illegal opcode is in the interrupt table, a sign that the program has crashed *before* it got there. You should be looking at what happens between INT 2F/1605 and when execution jumps-to/calls someplace it shouldn't.

INT 6 repeats because it hasn't been hooked to handler code, so it just tries to execute the same invalid instruction over and over.

ripsaw8080, sorry but my asm and IBM PC architecture knowledge is very limited. This is exactly what DosBox executes (I have deleted the registers and flags values from these log lines):

...
01C2:00002B70 mov ds,ax
01C2:00002B72 mov ax,1605
01C2:00002B75 int 2F
01C2:0000122C pushf
01C2:0000122D test byte cs:[0FC0],03 cs:[0FC0]=3001
01C2:00001233 jne 00001243 ($+e) (down)
01C2:00001243 popf
01C2:00001244 jmp far word cs:[0C3F] cs:[0C3F]=15C0
F000:000015C0 callback 002E (DOS Int 2f)
F000:000015C4 iret
01C2:00002B77 mov cs:[2B5B],si cs:[2B5B]=0000
01C2:00002B7C mov cs:[2B5D],ds cs:[2B5D]=0000
01C2:00002B81 pop es
01C2:00002B82 pop ds
01C2:00002B83 ret
01C2:00002AB8 call 00002B84 ($+c9)
01C2:00002B84 cli
01C2:00002B85 push ds
01C2:00002B86 push es
01C2:00002B87 xor ax,ax
01C2:00002B89 call far word cs:[2B5B] cs:[2B5B]=0000
0000:00000000 pusha
0000:00000001 adc [bx+si],al ds:[0000]=0000
0000:00000003 lock or [bx+si],al ds:[0000]=0000
0000:00000004 or [bx+si],al ds:[0000]=0000
0000:00000006 jo 00000008 ($+0) (no jmp)
0000:00000008 or [bx+si],al ds:[0000]=0000
0000:0000000A jo 0000000C ($+0) (no jmp)
0000:0000000C or [bx+si],al ds:[0000]=0000
0000:0000000E jo 00000010 ($+0) (no jmp)
0000:00000010 or [bx+si],al ds:[0000]=0000
0000:00000012 jo 00000014 ($+0) (no jmp)
0000:00000014 pusha
0000:00000015 adc [bx+si],al ds:[0000]=0000
0000:00000017 lock pusha
0000:00000018 pusha
0000:00000019 adc [bx+si],al ds:[0000]=0000
0000:0000001B lock pusha
0000:0000001C pusha
0000:0000001D adc [bx+si],al ds:[0000]=0000
0000:0000001F lock movsw
0000:00000020 movsw
0000:00000021 inc byte [bx+si] ds:[0002]=0000
0000:00000023 lock arpl [bp+di],bx ss:[0311]=152A
0000:00000024 arpl [bp+di],bx ss:[0311]=152A
F000:00001060 callback 0003 (default)
F000:00001064 iret

And the last three lines repeat in a loop... Can you tell me something? Thanks a lot

You're already off at the far call, not the bold lines.
Anyways it is not intended to be supported.

It appears to be making a questionable assumption when EMS is active that the call to INT 2F/1605 will return a V86 mode enable/disable callback address. That works in MSDOS with EMS provided by EMM386, but I wonder what would happen with an EMS board... Anyway, your success rate with this application will be higher in general if you boot real DOS in DOSBox, but you can work around this particular problem with ems=false.

ripsaw8080 wrote:

It appears to be making a questionable assumption when EMS is active that the call to INT 2F/1605 will return a V86 mode enable/disable callback address. That works in MSDOS with EMS provided by EMM386, but I wonder what would happen with an EMS board... Anyway, your success rate with this application will be higher in general if you boot real DOS in DOSBox, but you can work around this particular problem with ems=false.

ems=false solves the memory search hang, now works, thanks! But what consequences can have having ems=false to the games?

The other problem, "Save Current Program To Disk" option, doesn't works.

IT IS NOT SUPPOSED TO WORK.

what consequences can have having ems=false to the games?

Well, I think it's fairly obvious that some games require EMS to run, or to have certain features, so ems=false can be a limitation. It would be possible to avoid the problem with ems=true if INT 67/DE00 indicates that VCPI is not present:

1    case 0xDE:        /* VCPI Functions */
2        if (!vcpi.enabled) {
3            LOG(LOG_MISC,LOG_ERROR)("EMS:VCPI Call %2X not supported",reg_al);
4            reg_ah=EMM_FUNC_NOSUP;
5        } else {
6            switch (reg_al) {
7            case 0x00:        /* VCPI Installation Check */
8                if (((reg_cx==0) && (reg_di==0x0012)) || (cpu.pmode && (reg_flags & FLAG_VM))) {
9                    /* JEMM detected or already in v86 mode */
10                    reg_ah=EMM_NO_ERROR;
11                    reg_bx=0x100;
12                } else {
13                    reg_ah=EMM_FUNC_NOSUP;
14                }
15                break;

((reg_cx==0) && (reg_di==0x0012)) happens to be true when GW makes the call, so DOSBox is reporting that VCPI is present. I don't know the history behind this JEMM check or what games it is for; maybe the devs recall.

JEMM games only work with emm386 and the check assures that vcpi is reported for those games.

It's possible to have some EMS capability with disabled VCPI using the ems=emsboard setting in SVN builds; and GW seems to have no problem with that.

OK, I will try with ems=emsboard in the config file. Is there a nightly build of DosBox? That will be a great idea, so users can have the last DosBox EXE compiled with the fixes to let us try our bugs/issues/enhacements.

I don't have the "environment" installed to compile... Ripsaw8080, can you attach here the DosBox 0.74 SVN EXE here?

There are SVN builds availlable. Currently a nightly build is not needed since there are no daily changes 😉