Thanks for reporting problems here.
POST REPLY
Post Oct 04, 2016 01:20
That's correct. The only game I did not test is unlimited adventures. I don't own it.
Post Oct 04, 2016 05:35
Interesting regarding the different ways the loadfix affects things. I had split my lines up because Dosbox was terminating and I was trying to figure out what was going on (turns out due to how my install had updated with Galaxy my C mount was wrong). I'd be very curious what's going on under the hood between loadfix standalone eating up some memory and loadfix executing a program; it must affect the offset of the memory allocator which in turn affects the memory values you're peeking at.
Site Admin
Post Oct 04, 2016 06:36
Great, glad we got to the bottom of all of these games!
MrPopo wrote:Interesting regarding the different ways the loadfix affects things. I had split my lines up because Dosbox was terminating and I was trying to figure out what was going on (turns out due to how my install had updated with Galaxy my C mount was wrong). I'd be very curious what's going on under the hood between loadfix standalone eating up some memory and loadfix executing a program; it must affect the offset of the memory allocator which in turn affects the memory values you're peeking at.
I didn't delve too deeply as I don't quite understand x86 / DOS / bios enough - however the main obvious difference prior to starting the game on one versus two lines was the "stack pointer" register was different as the program loaded. Since it makes sense that a program works relative to the stack pointer its given by the O/S I can only assume this caused the game to move things around.

Initially I had hoped that I could pass the initial SP value through as part of the program's identifier but the problem was I could easy break this again by devising ways to break it such as running command.com again and starting the game on 1 or 2 two lines gave you the same stack pointer value but this ended up giving the players location in a third location -- so I quit it as a "rabbit hole".

Like I say, I'm not 100% sure why they differ and my DOSBox internals knowledge probably isn't good enough. I even added a bit of debug code to dump the contents of RAM prior to launch of MM2.exe and they were both practically identical - so I can only assume it's some external storage such as the registers or elsewhere.
Post Oct 05, 2016 19:20
Yeah, once you're doing that sort of memory inspection you're already in a land fraught with peril. You'll definitely want to keep an eye out if Dosbox ever revs to version 0.75; it wouldn't shock me if said release changed something in the memory allocator and it changes all the offsets (though hopefully to something as consistent as they are today).
POST REPLY