Hard-coded memory addresses seem more like a bug than a feature.

Its nice work though 😀

aqrit wrote:

Hard-coded memory addresses seem more like a bug than a feature.

Its nice work though 😀

Well, for the win32 version of DOSBox 0.74, a pointer to the base is at 0x01D3A1A0 and the start of the code is that + 0x1A20.

But the memory address in the cheat-codes are relative to the currently running exe.

The good thing about the cheat-codes is that when the next DOSBox comes out, assuming most of it works in the same way, all i'll really need to do is change the base offset and they should work.

Also, the cheat codes work like this:

[size][offset][value]

e.g:

116286E63 = [1][16286E][63]

krax wrote:

Well, for the win32 version of DOSBox 0.74, a pointer to the base is at 0x01D3A1A0 and the start of the code is that + 0x1A20.

Even if you compile it yourself?

TeaRex wrote:

krax wrote:

Well, for the win32 version of DOSBox 0.74, a pointer to the base is at 0x01D3A1A0 and the start of the code is that + 0x1A20.

Even if you compile it yourself?

Well, no this only works on the precompiled version.

I rewrote nearly all of it, so it generally looks nicer, has more stuff you can do with it. And now you can more easily change settings for you're own compiled of DOSBox or other versions, by editing config.h

If there are any bugs, or questions etc. Please post them.

EDIT:
I accidentally uploaded DOSShark with the wrong subsystem. Re-uploaded.

Also, the UPX part is optional, if you don't want to pack with UPX, just remove the line from make.bat

krax wrote:

Hi, I wrote a cheat-code system for DOSBox, currently it only works with version 0.74 for win32 and I thought I might as well share it with the forums.

The cheat codes are in a gameshark style, and should be interchangeable with future version of DOSShark.

Thanks for your contribution!

Just a general note for people that are more familiar with/comfortable with it, Cheat Engine (http://en.wikipedia.org/wiki/Cheat_Engine) works with DosBox as well. Just load the program you want within Dosbox before you use the standard Cheat Engine features - Dosbox produces pretty minimal overhead, so you won't be swamped with false positive/slow performance.

-Frob

I know this thread is very old and I'm doing quite a bit of necromancy here.

But I have to say:

THANK YOU!

This tool is exactly what I've been looking for! Sure, I could use Cheat Engine but then each time I play a game the memory adresses are different.
Otherwise I have to fight around with pointers and stuff.

This little tool does just what I want and one I have found a code, I can use it everytime I play the game.

The only thing that would be even better would be a cheat similar system implented into DOSBox itself.

DOSBox is just for playing the games, not necessarily for finishing them. :-)

I just noticed something very strange:

I don't seem to able to activate more than the topmost code in both versions of DOSShark.
I mean I can activate them and they change from an X to an O but nothing happens. The code is correct because whenever I load it in an empty list as the topmost code, it works.

Am I doing something wrong?

All right! Thanks to the included source code, I was able to find the reason. There was a variable missing in the "inject_thread" part. It always used the first line instead of advancing to the next.
I compiled it again and now it works.

This is so great!

Hello, any chance you could compile a 0.73 version? 'cause there's one particular game I want to try it on and, at the moment, this game doesn't run on 0.74 dosbox

what game is that?

It's a Korean platformer titled "Eol-ui Moheom"

Can't confirm that. Eol-ui Moheom works just fine in DOSBox 0.74 and the latest SVN. I think you got a corrupted copy, or something is messed up on your side. Here I used the default config file and I just ran EOL_GAME.EXE and the game launched immediately. Soundcard was detected automatically and I just started a new game.

Thank you for the reply, so it's sure the problem is on my side, don't know, soundcard conflict perhaps? I searched on this forum: this was already discussed ( Re: Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel Error ). So I guess my only viable options are a) change the source as suggested in that thread or b) the changes in dosshark to make it work with dosbox 0.73?

If you get a message in the status window about an exit due to DMA wrapping, that is specific to 0.74. If DMA wrapping is the problem you run into, at what point in the game does it happen? You might be able to work around the problem with loadfix (experiment with various allocation sizes), but 0.73 or SVN may be the only sure solution.

Thanks for the reply and sorry if I'm dragging this out of topic.
The game just exits due to DMA wrapping when the player collects the first item. The fix suggested is in dma.cpp, DMA_Init() change the call to DMA_SetWrapping(0xffffffff); so now can I ask if you have the already modified 0.74 ver. I haven't quite well understood how to compile my customized ver.

I suspect this DOSShark cheat program won't work with a self-compiled (and modified) build of 0.74, anyway, unless your build environment matches very closely to the one used in the official Win32 build (MinGW cross-compiled in Linux, if I'm not mistaken).

Tried turning off ems and loadfix -26 eol_game.exe and I could get through first level power-ups.
Now that I can also use DOSShark I think I'll try to play it all through...thanks for the help