Not sure what you were struggling with for so long, as you only have to put DOS32A.EXE renamed as DOS4GW.EXE in the game directory...

Some time ago I found a workaround for the popping sounds when using DOS4GW as the extender, which at least works in DOSBox 0.74 and SVN with default settings, is to allocate a single page of EMS memory before running the game. It seems the popping is related to DMA, and using EMS where the allocated number of pages is NOT an integral of 4 prevents it. The game doesn't need EMS, this workaround just manages to avoid the problem. However, DOS/32A is a more off-the-shelf solution.

this thread highly interests me! 😁
I've been wanting a working "32bit" EOB3 since the game was new, there was even a flyer inside the game that promised the new 32bit engine will be released soon as a patch and it would be awesome... alas this never happened.
I did mess with the previously released aesop32 engine and was getting the the annoying pop sounds... tbh I didn't notice anything faster on my p200mmx system - maybe the difference is more apparent in slower systems...
At any rate thanks for the extra info on this, will give it a spin and report back!

ripsaw8080 wrote:

Not sure what you were struggling with for so long, as you only have to put DOS32A.EXE renamed as DOS4GW.EXE in the game directory...

Some time ago I found a workaround for the popping sounds when using DOS4GW as the extender, which at least works in DOSBox 0.74 and SVN with default settings, is to allocate a single page of EMS memory before running the game. It seems the popping is related to DMA, and using EMS where the allocated number of pages is NOT an integral of 4 prevents it. The game doesn't need EMS, this workaround just manages to avoid the problem. However, DOS/32A is a more off-the-shelf solution.

I was struggling with finding a fix in the first place. Not with replacing DOS4GW. As you said, just replacing the EXE is the easiest method. I just updated the EXE files so that other don't have to worry about it (if they use my installer.) Finding out that the DOS4GW extender was causing the problem was an accident. My modern system (the one connected to the internet,) was offline for a bit, and I had deleted DOS4GW accidently. So, I grabbed DOS32a from another game I use it on (also had issues with DOS4GW,) and used it instead. Was rather surprised when the popping (which wasn't as loud on my vintage system as in DOSBox,) was gone.

That's when I started experimenting, and later started writing the installer.

I use my own build of DOSBox, but had the same problems in both 0.74, the SVN, & the DAUM build. What is interesting is your phraseology suggests that DOS32/A doesn't work with those. I haven't had any problems in any of the builds I tried (.74, latest SVN, my own build, or DAUM.) Even on default setting. About the only issue I've found is some times when I exit, DOS32a reports that a vector has been changed. Not an issue in DOSBox. Been meaning to look into it later, because I primarily play these games on my vintage system.

Just tried both methods: renamed dos32a.exe and FeedingDragon's patch, they both worked the same 😀

@FeedingDragon
is your patch modifying EYE.RES as well? there are certain annoying bytes there no longer in the same place... 🤣

keropi wrote:

Just tried both methods: renamed dos32a.exe and FeedingDragon's patch, they both worked the same 😀

@FeedingDragon
is your patch modifying EYE.RES as well? there are certain annoying bytes there no longer in the same place... 🤣

Yes, it applies the full Aesop 32 patch... That is, it de-compiles the eye.res file, builds the 3h.bin file, then re-compiles the eye.res with the new 3h.bin file. Then it cleans up after itself. You probably noticed the large amounts of quickly scrolling text as it de-compiled re-compiled the file.

FeedingDragon wrote:

I use my own build of DOSBox, but had the same problems in both 0.74, the SVN, & the DAUM build. What is interesting is your phraseology suggests that DOS32/A doesn't work with those.

DOS/32A does work in DOSBox. I have no idea why you thought what I wrote suggested otherwise...

FeedingDragon wrote:

some times when I exit, DOS32a reports that a vector has been changed.

That's normal behavior. You can set an environment variable (e.g. "SET DOS32A=QUIET") to eliminate warning messages if they're annoying you.

BTW, what is superior about the 32-bit interpreter compared to the original 16-bit interpreter? Never was able to figure out what the attraction is...

ripsaw8080 wrote:

DOS/32A does work in DOSBox. I have no idea why you thought what I wrote suggested otherwise...

The line, "when using DOS4GW as the extender, which at least works in DOSBox 0.74 and SVN with default settings" sounded like DOS4GW works while others don't. At least that's the way it came across to me. Re-examining the line, I guess you meant that the "fix" works in at least those versions of DOSBox.

Going to edit my original post.... Been thinking about it, by cleaning up, I mean that unneeded files are removed/deleted. So, once it's applied, the only way to go back is to re-install. I don't have a problem with that myself, as I have both the floppy version, and a couple of CD versions (compilations.)

As for what the update does.... I'm not 100% sure. I do remember that when I first played it, I had problems with crashes and such. This supposedly reduces that. I haven't gotten back to EOB3 yet (still re-playing EOB1.) I'll find out more when I get to it. From what I read, the Aesop 32 version is primarily more stable, and has smoother game play later in the game. I never got that far in it before (too many crashes,) but I've read that later in the game it starts to really bog down, and this supposedly fixes that.

ripsaw8080 wrote:

FeedingDragon wrote:

some times when I exit, DOS32a reports that a vector has been changed.

That's normal behavior. You can set an environment variable (e.g. "SET DOS32A=QUIET") to eliminate warning messages if they're annoying you.

The message itself doesn't bother me, it's just that I didn't know exactly what it means. I did some searching, the vector changed was for IRQ 5 (my SoundBlaster is there,) so I assume it has to do with the way the game is handling sound. Less worried about it now 😀

yep, sorry about that eye.res , I forgot it gets converted as well... I did see the scrolling info 😁

the only thing I noticed with the AESOP32 patch is that you no longer need EMS for the sfx or something. Running stock EOB3 without EMS makes it complain about sfx not being able to play... otherwise I too have no idea what is improved, speed-wise they seem the same on a fast machine.

What I wish is that someone could treat EOB3 like EBO1/2 were treated by CFOU! : http://eob.wikispaces.com/EOB2+AGA+GAME
basically the amiga versions became the best ones with the new automap feature...

I would love to see EOB3 converted to the Amiga. I actually liked the Amiga versions better than the PC. Especially if I could also port the MT-32 music as well.

I also noticed that AESOP32 eob3 freezes after a while if you have smartdrv write-behind cache option enabled. Remove the write-behind option and all is good.
Normal AESOP16 version does not have this issue.

I did some more testing, AESOP32 version does work faster on my p200mmx , I was wrong before when I said there is no difference. 😒

keropi wrote:

I also noticed that AESOP32 eob3 freezes after a while if you have smartdrv write-behind cache option enabled. Remove the write-behind option and all is good.
Normal AESOP16 version does not have this issue.

I did some more testing, AESOP32 version does work faster on my p200mmx , I was wrong before when I said there is no difference. 😒

I was about to post that it hasn't given me any such problems.... Then I double checked, I turn SMARTDRV off. With the hard drives I have installed it doesn't make that big a difference for DOS games, and this gives me more RAM to play around with. Was never a big fan of write caching anyway. Read cache, yes, but not write.

well, if you have ram to spare (like me) then some write cache is good when you create/decompress archives or use ftp to transfer files ... not a biggie though, write-behind can be switched on the fly

FeedingDragon wrote:

You probably noticed the large amounts of quickly scrolling text as it de-compiled re-compiled the file.

That's great EOB3 got some attention! Might you know a way to compile a EoB-1 portrait (31x32 .bmp) into EYE.RES?

Many tools allow to get the original EoB-1 portrait from .cps file. I did it. But how to convert it into EoB-3 palette?

I know XWE (last beta) decodes EoB-3 portraits with EoB-3 palette. But it doesn't allow saving anything in this format.