WinUAE - Trainer Plugin
 

Hi

and Merry Christmas to all,

on these vacation days i've discovered the wonderful world of the SPS images

It's really a different experience to know i'm running the game "AS IT WAS" without any modification (thanks to all the guys who contributed and continue to contribute to the preservation project).

The first thing i did was to play "Gods" by Bitmap Brothers.

The second thing i did was to say "oh this is getting difficult and i would like to see the final of the game".

The third thing i said was "hey i don't have a trainer!"

The fourth thing i said was "ok we try to install action replay and see what we can do". This phase is currently ongoing (with no result for the moment :))

The summary of all the above was "damn, i want the game intact and i can't have a trainer" so the result was:

"Hey wait a minute we are in a sandbox environment, and the WinUAE is the Uber-powerful sandboxer and can read and write anywhere in the game with relative easyness"

SO

why not add to winuae a section in which "Trainer Plugins" can be loaded?

Each plugin would have its own configuration menus in which we could activate or deactivate the options.

In this way we would have a totally non-intrusive method to play SPS images (which don't need to be unlocked) in a trained way, with the trainer running "outside" the game memory address-space.

I think this would be a cool way to Really complete a restoration process.

SPS Images + Unobstructive and un-modifying trainer.

Hope this will be considered :)

You can use https://www.cheatengine.org/

Sometime figuring out the exact numbers may be a bit tricky, but its easier with CE.

Hi Dan,

thank you very much for the suggestion, it's another way i'll try to find something :great

To add something to the main post,

a plugin would allow programmers (or even the original programmer of the original trainer)

to just put the right addresses (or functions) inside the plugin

(taken in case directly from the disassembled original intro).

It seems quite quick and effective to me.

This has been requested previously. I won't do it until someone finds method that works properly with games that don't load to static absolute addresses.

There must be enough context in trainer data to enable trainer logic to find the data that needs to be modified, even if game code/data has been moved (due to relocation, use of different memory config etc.)

Hi Toni,
don't you think the logic of finding the right address to patch (even dynamic addresses) would to be a burden of the plugin developer (not yours)?

You would just provide an interface to read and write to memory addresses and a programmable listener to which the plugin developer could hook the trainer logic.

Example
LISTEN(<on address A>,<every clock>,<trainer function to execute>)
or LISTEN(<start address A>, <end address B>,<every 1 second>,<trainer function to execute>)
or LISTEN(<start address A>, <end address B>,<once>,<trainer function to execute>)

I think this method covers every possible situation (static value or dynamic).
The plugin developer would eventually concatenate the listeners

Example (in case of static address)

declare LISTENER1 (<Address wich memorize the player lives>,1,PatchLives())

declare PatchLives()
{
IF LISTENER1.Value < 3 then WRITE(3,LISTENER1.Address)
}

in case of dynamic address we have 2 parallel listeners
declare LISTENER1 (<Address wich memorize the game level>,1,NullFunction())

declare LISTENER2 (CheckDynamicAddress(),1,PatchLives())

declare CheckDynamicAddress() RETURNS <ADDRESS>
{
if LISTENER1.Value = 1 then Return <ADDRESS A>
if LISTENER1.Value = 2 then Return <ADDRESS B>
if LISTENER1.Value = 3 then Return <ADDRESS C>
}
declare PatchLives()
{
WRITE(3,LISTENER2.Address)
}

Something like that :)

In any case you give the programmer the tools and the channels to bash his head against eheh

To Summarize pheraps this minimal instruction API set would be a start:

READ(<ADDRESS>)
READBLOCK(<START ADDRESS>,<END ADDRESS>)
WRITE(<ADDRESS>,<VALUE>)
WRITEBLOCK(<START ADDRESS>,<END ADDRESS>,<BLOCK>)
STARTLISTEN(<ADDRESS>,<frequency>,<hook function>)
STARTLISTENBLOCK(<START ADDRESS>,<END ADDRESS>,<frequency>,<hook function>)
STOPLISTEN(<ListenID>)
STOPLISTENBLOCK(<ListenBlockID>)

EDIT:
It would be useful this function too

FREEZE(<ADDRESS>)

which block a value to being modified (infinite lives or energy)

Yeah but I am not going to make it anything complex, no scripting or similar and it should be usable without too much assembler knowledge.

Also, as I said, I am not going accept use of absolute addresses. Neither I am going to make it easy to make bad trainers that only work with some specific config and crack variant.

It should work like this:

Trainer text file includes long enough fingerprint byte "string" (with option to mask specific bytes so that for example absolute addresses are ignored when matching).

When "fingerprint" is found, address of fingerprint is used to calculate address to patch code (for example to disable variable modification) or used to calculate actual address of variable which gets modified or frozen.

It can hooked up to CPU emulator so that only code that actually runs gets matched (and can be matched before code to be patched runs), some temp decrunch/load space etc gets automatically ignored.

Most importantly: It must work with dos loadable games (="undefined" load address).

Mm after some thinking pheraps i'm understanding your mechanism of fingerprint.

What i don't understand at the moment is the "necessity" of this mechanism.

You say you don't want "partial trainer" to work on "different cracked" versions.

But i think almost any amiga game cracked has been trained at the time, so you could get the already patched .ADF with the original crack intro trainer.

The plugin architecture i was thinking about would apply only on untouched SPS with no crack and no unlocking.

In that case the SPS image has itself already a hash or number (rarely more than 3 different SPS version of the same game) and i can assume the 3 versions are almost 99.9% identical.

So being a relation of 1:1 to the SPS game there will be always 1 address to patch in the same address space (1 version of the game 1 memory configuration to patch).

So searching for a "fingerprint" is superflous because the address to patch will be same in every version of the SPS.

I explain better.

There are actually two versions of gods SPS.

I'll test my teory, but i can be quite sure that the 2 SPS of Gods will have the same 000224 address where it stores the lives number.

So what is the usefulness of "searching" it with a fingerprint?
You already know for sure where it is.

The addres will remain the same regardless the SPS of the game.

Your fingerprint theory perfectly apply on cracked or unprotected games where "with some probability" 000224 address has been remapped to a different address in order to make the crack working.

In this case the only elegant method of make a trainer working (one trainer to rule them all) is to search for the memory fingerprint.

But as i said before, in these cases, the trainer plugin is useless because for an unprotected game there is already (99.99% probability) the corresponding trained version.

And when there is not a trained version, is much more easy to make a new one from scratch on the SPS (1 version 1 fixed address).

Do you get my point?

No, not really.

You want Toni to implement some kind of trainer plug, sounds good :great

He's given you certain requirements before he'll think about this but you continue to question these.

...so you say that this trainer plug should only be used with SPS releases. Please tell us all how exactly you think that this can possibly be enforced?

Finally, what's so wrong with cracked / trained .ADFs? Unless of course they are missing important graphics / features etc. then I agree.

They are part of Amiga history and I for one love cracktros / trainers.

No. Many non-trackloading games would not work. They get "random" address (even number of floppy drives change it!). It needs to support this. It has always been my requirement which makes it non-trivial.

Track loading games usually use identical addresses but there are also some track loading games that load differently depending on if you have 512k or 512k+512k or even 1M chip.

I won't accept simple solution that can't work with at least 90% of games. "Correct" solution would also make trainers very generic, same trainer would (not 100% but very close) work with almost every "variant" of the game, including hd installable versions.

@DamienD and Toni Wilen
I'm not trying to enforce anything.
I'm trying only to understand the Toni point.

And thank you Toni for the very much enlightning information about games that "by design" do a memory remapping (!).

And yes, my bad i wasn't thinking about whdloaded games where a memory remapping can be most possible.

So in this case i agree 100% with you that the only elegant solution is to implement always some kind of "search for the block where it has been remapped" and then patch it (even if for the majority of the games is fixed).

Can you point me to a game where this kind of remapping is implemented?

I'm very curious!

Thank you very much.

PS.
For the sake of completeness
Gods v1.00 (1991)(Renegade)[0666]
Gods v1.00 (1991)(Renegade)[a][2877]
have the same 0224 address.

One way this could work would be for the trainer option be saved into the config for a specific game, and then winuae checks the MD5 checksum of the ADF/IPF?whatever images and if they don't match then winuae ignores the trainer options (greys them out maybe).

If the MD5 does match then the trainer options are enabled. Naturally the user could "override" this if searching for new trainer options etc..

One hard aspect is knowing what trainer options winuae would support.. There are so so many possibilities.

Try game that first boots to CLI screen, for example Dune 2 or Wings. Most HD installable games work this way.

Ok, after having done a quick realtime view of memory around 0224, near parts of cells memory are moving and changing constantly so the method of a fixed fingerprint calculation is not appliable (search for memory blocks that after hash results in fingerprint).
Restricting the area of fingerprinting we would have much higher probability of hash collision (same hash for different memory blocks).

A solution could to be find a fixed string (or graphic memory block) that appears at the beginning (or near beginning in the middle) of the game (using the hash method), that has ALWAYS the same distance (regardless the game version) from the address to patch, and use that address as the base address to add (or subtract) an OFFSET to find the right address to patch.

Not an impossible task but need the analisys of many versions of the game.

Thank you, i'll try Wings as soon as (what a game!).

Toni. Indeed and I guess it's still possible if winuae were to search for a sequence of bytes (maybe 1k of bytes) through memory. That would possibly be unique to the game itself. Woukd only be an issue if the exe is modified after.

Only way it can work is to find any code that modifies the variable (as I said above already) and ignore the parts of code that uses absolute addresses (that change between game runs). The rest of code should be 100% identical all the time.

Other variables near value you want to modify are usually way too dynamic. They can't be used for this purposes.

Then just tell the emulator to watch the instruction that modifies the value that trainer wants to change, when instruction is about to be executed, it can be:

- skipped (instruction becomes NOP)
- value that instruction wanted to modify is made frozen (nothing can change it anymore)
- set value to some static value

If you are familiar with action replay 3, you can test this relatively easily by first finding the value you can to modify (health, money whatever).
When found, use "fa" command to find instruction(s) that access the value (this is not reliable always, it depends how game was coded). Another method is to use memwatch breakpoints. (ms)

Values around the address (or addresses) that "fa" found would be the "fingerprint". Use disassembler to verify it. (minus possible absolute addresses. UAE could do this automatically if needed)

Pointless suggestion. Use a cracked + trained version.

Pointless post.. Move on if you have nothing constructive to say!!

Why should someone to go to all the trouble of putting a trainer feature into their emulator for a game that's already trained? Anyone with half a brain could see the stupidity of this.

I would see the fact that you are plainly trolling because you didn't even read the first post.

And I would see the fact that the remaing half brain of you didn't think about the fact that many games although "100% cracked" are not really working or completed or perfect and you have to try all the versions available to find the one (if any).

And here we are talking about "preservation" but i imagine your only preservation priority is to keep (after enabled the +80 trainer) the button pressed with the autofire on.

@Toni Wilen
As soon i'll go deep with your methodology.

And anyone with a full brain would see that you have nothing better to do than troll.. Honestly if you don't like the idea move on. Nobody asked you to comment, or get involved..

As for your comment. Not all games are trained, and not all options are trained. It's another feature that if toni wants to implement he will. If he believes it is pointless then he won't implement it will he! Nobody ever got hurt talking about these things!