Need advice from programmers that deal with memory sniping.

[Howard_Casto]

Here's the deal, I had a sort of revelation in my medicated stupor this week. 

For some time I have pressed to get an output system in place in mame (for afterburner and it's force feedback, gorf and it's multiple lights, the q-bert knocker, ect).  Although Aaron is psuedo-receptive to the idea I don't see it happening anytime soon.  It's just a lot to undertake to make all those different types of outputs generic and mappable. 

Ok here's the idea..... In the mame drivers, the memory addresses to control thes devices are in place and assigned a region in memory.  They don't do anything, but they are there and do change the proper data.  I am VERY weak in the skills department when it comes to intercepting memory, but shouldn't it be possible to have an external application that monitors the memory and then do something with the data?

The only issue I see is figuring out where the data resides.  As I said, I'm sorta dumb about this aspect of low-level programming so I would appreciate some help/advice/clarification.  I know this is done with console "enhancers" all the time but in those cases you are working with a known size of memory. 

[youki]

It will be very difficult to do that, even impossible.

Ok, you can manage to access MAME memory from an external process (it was  what i was doing a a prototype for my credit management from the FE , i wanted redirect a MAME function to my own function , that worked but no so reliable and terribly tricky).

The main problem, in your case, if that you want juste read data in a given location. It could seem simple, but the questions is how you find the location of the data you want read in the "live" memory!   For a function you can manage by finding a kind of signature and looking for it in the memory , but for a simple "memory zone" or a variable....

One solution would to make some test, by putting easly identifiable values in that memory zone (by modifying  temporary mame) ex:  0xCAFECAFE   , then you search the memory to find where is that zone.  There is strong change that the next time you run mame , it will be allocated at the same location in the process memory map.

But anyway , it will work only for one version of mame , compiled with the same compiler.  Because for the next mame version or for a version from another compiler the position will change.
In that case, i think it is lot of much easier to simply to our own mame version.

Why don't you make your own build adding this features?








 

[Buddabing]

What youki said.

You would have to do this within MAME.

The memory monitoring function is how gl.tter's Light Signal Engine worked. gl.tter is gone, but the memory monitoring code is still in BuddaMAME.

Basically, you can monitor an address and have an arbitrary event happen when the address hits a certain value. Gl.tter used this to trigger an animation when Mr. Do's ball was released. You could easily do the same for the Gorf lights, etc.

[Howard_Casto]

That's what I assumed but I was hoping some smarty pants would know some method I don't. 

Ah well, it was worth a shot. 

A custom mame build isn't an option, at least not for me anyway.  I think my custom build lasted like 4 versions before I lost interest. 

[headkaze]

FYI the API functions to read/write memory from an external process are VirtualAllocEx, WriteProcessMemory, ReadProcessMemory and VirtualFreeEx. I don't see why you couldn't have a play with a RAM editor like Hackman Hex Editor, but it would probably require knowledge of assembler to make any real ground with it. With knowledge of x86 assembler (and how it compiles into binary) would make searching for data in RAM easier, rather than some arbitrary memory offset that will change with each new Mame compile.

I guess there are also other questions about the Force Feedback data itself, does Mame even interpret the data from the ROM and place it in memory? Is it ignored, and what else? How is it stored in the ROM etc. Although it's a long shot, but it would be a good learning process to figure it out, and I don't doubt you have the skills to pull it off.

Like youki, I did some interesting things with Mame by attaching a dll to the Mame process to intercept the DirectInput using a wrapper for CoinDrop. It is quite a complex thing to do, but not impossible. Something like that has to be written in C++ though, I think there would be too many problems writing something like that in VB. But I can give you the source for CoinDrop if you PM me (and noone else so don't bother asking), only because I trust that you won't abuse it.

Just a final note on the dll attaching the Mame process, after doing it this difficult way, Tom told me an easier way to intercept DirectInput is to use DirectInput in background mode to poll it. Not sure if that would be of any help to you.

[u_rebelscum]

I guess there are also other questions about the Force Feedback data itself, does Mame even interpret the data from the ROM and place it in memory? Is it ignored, and what else? How is it stored in the ROM etc. Although it's a long shot, but it would be a good learning process to figure it out, and I don't doubt you have the skills to pull it off.

Mame doesn't do anything with FF; that's what Howard is trying to address.

The original game did do the FF, though.  Mame emulates the game, and the original game had a place(s) in it's memory handling the FF.  So somewhere in the emulated memory, there is a location that can be watched for the FF.  IOW, we're looking at the PC memory in the mame app in the "game memory" area, not the OSD directInput part of mame, for the FF signals.

The location in the game memory of course will vary from driver to driver (hopefully FF games with the same hardware will do FF in the same area).  The signal will also vary, as well as the original FF. 

And do we know where in the games' memories the FF is?  Besides Outrun and qbert's knocker, I guess.  As long as a driver that's not being worked on is picked, I think the location in the game memory will be consistant.  There still is the different compile ==> different locations in mame app problem, though.

I like the ability to work on part of the "FF whole" that using an external app would give.  Smaller, more manageable chunks at a time.  Different FF translation models could be tested without editing mame itself.  Hopefully a favorite generic FF could be built from the test results, and as part of the process of finding the FF memory locations, the areas mame would map to FF would be found.  This way mame FF could be researched in parts, and let mame app skip much of the WIP stage.

That said, I know nothing about watching external apps' memory, so my view shouldn't count much.   From the sound of you guys, it wouldn't be easy to find the "game memory" loaction inside mame.

[Howard_Casto]

Well I don't know if the mame driver developers knew they hooked up the ff memory address (as it's seldom labeled in the comments)  but it is almost always there. 

It's there for afterburner games and the games from that system.  It's used in gorf to control the artwork, and games that just had one too many lights to hook up in mame are also hooked up (terminator 2 and others).  And of course start button and coin slot lights are hooked up and used with the keyboard leds. 


Of course the real challenge would be to do something with that data.  With lights it's simple enough as it's a simple 0=off 1=on or a bit array that controls multiple lights, similar to how the parallel port works.  The force feedback of afterburner and the like would be rather complicated.  Afterburner had ff in the joystick as well as a motor for rolling the cockpit.  Galaxy force is even worse.  Games like terminator 2 would be easy enough to figure out though.  Also rail chase and rail chase 2 had a pair of hydrolic rams in the seat, I think that'd be farily easy to do something with as well. 


But since there isn't an easy way to access the memory externally, we are screwed. 

[headkaze]

Mame doesn't do anything with FF; that's what Howard is trying to address.

Why are you stating the obvious here? Are you confused about what I was trying to say? Obviously Mame dosn't do anything with the data, my question was about whether or not Mame processed the data in some way, stored it in memory etc.

Well I don't know if the mame driver developers knew they hooked up the ff memory address (as it's seldom labeled in the comments)  but it is almost always there.

This seems to answer the question... there is a reference to the ff memory address, so it can be accessed and applied in some way via Mame or an external process. The easiest method would be to modify the Mame source to process this ff data through the DirectInput API, but it's not what Howard wanted to do.

My comments about DirectInput were not about getting the ff data, but demonstrating a method of intercepting (or hijacking) the DirectInput API's. Which in this case would not help if there is no ff data being fed into it in the first place. But it's the method of hijacking the API's which I wanted to make a point about, which is related to reading an external processes memory.

As Howard points out there is a reference to the ff memory, so I don't see why you couldn't read that data externally.

But since there isn't an easy way to access the memory externally, we are screwed.

I disagree, it is easy to read memory externally (see the API functions I posted above), the hard part is locating the memory area to read. Judging by what you've said about there being a reference to the ff memory being present in the driver, then it would be a matter of reading that location (which I assume is a pointer to another address in memory to the actual ff data). But overall, as the other coders have pointed out in this thread, it's not an easy thing to do, but there would be plenty of people out there that could do it.

[nobbo]

hey guys,

i had a crazy idea and i was going to make a topic for it but i have a feeling that this thread confirms that my idea is crazy indeed, so apologies if you think i'm going slightly off topic 

anyway, i am starting to think about the setup of my cab, and i want to have a second monitor displaying controls via j5 or the like, but what i was thinking was for fighting games such as street fighter etc, how cool it would be if rather than display the generic controls for the game if there would be some programming hack that would allow you to capture the character that the player/s are using and then display the relevant combos and special for that character only........whacked i know 

the reason i posted this in here was that, by the way i read it anyway, that capturing the memory and interpreting it would be the way to pull it off...

by the way, if i am completely wrong on this, i would be more than interested to hear some alternative thoughts on this

cheers

[youki]

To do that i would rather go to the way of Graphic recognition.

i didn't really think about that, but it could be something like that.

A FE  run mame and the game.

If the game is SF2  (or another fighting game in a predefined list)

-the FE (in background) try to detect the validation of charactere selection screen  and make a screencapture.  (i should be possible , but could required some specific "code" for each different game or set of game)

-Then the FE in background analyze the screencapture  ( like a OCR would do with text) identifie the character and display information on the other screen.    It would require  surely an characters image data bank , but it should work.

But we can surely think to other solution.

[Howard_Casto]

hey guys,

i had a crazy idea and i was going to make a topic for it but i have a feeling that this thread confirms that my idea is crazy indeed, so apologies if you think i'm going slightly off topic 

anyway, i am starting to think about the setup of my cab, and i want to have a second monitor displaying controls via j5 or the like, but what i was thinking was for fighting games such as street fighter etc, how cool it would be if rather than display the generic controls for the game if there would be some programming hack that would allow you to capture the character that the player/s are using and then display the relevant combos and special for that character only........whacked i know 

the reason i posted this in here was that, by the way i read it anyway, that capturing the memory and interpreting it would be the way to pull it off...

by the way, if i am completely wrong on this, i would be more than interested to hear some alternative thoughts on this

cheers

J5 supports the command.dat which has character moves in it. 

When I get my dual screen manager finished it'll allow you to navigate through j5 while mame is operating (assuming of course you make some dedicated controls just for it). 

[youki]

The problem is that i don't want generic control, for the game he wants only the control of the players he selected....

if rather than display the generic controls for the game if there would be some programming hack that would allow you to capture the character that the player/s are using

[Howard_Casto]

Yes I know but that is totally and completely improbable.  Even the method you posted would never work.  (Not to mention nobody would be crazy enough to spend that much time on such a minor annoyance). 

Emulation doesn't work in that way.... none of the programmers know the values of anything in a particular game, they just know what processors and circuits need to be emulated and run a rom through it.  Now things like inputs/outputs can be detected as they are a physical part of the board and thus their data is seperated and sent to addresses. 

Game data, however, can't be determined unless you use a memory sniper or a cheat system and TONS of spare time to figure it out.  This is how mame cheats are created, but it isn't a practical thing to do universally. 

[youki]

Even the method you posted would never work.

No, i 'm sure it could work , but as i said you need to have a kind of data bank to store specific information on recognition for each game you want make it work.  But that 's sure it is a crazy job!

  (Not to mention nobody would be crazy enough to spend that much time on such a minor annoyance). 

I won't bet on that.  I saw so many guys doing so crazy things with such a minor annoyance.  Just for the challenge for instance. 

Emulation doesn't work in that way.... none of the programmers know the values of anything in a particular game

I know how emulator works , i have already made a limited one for C64 few years ago , and i have a work in progress on a tiny arcade one. 
In the case of "character choosed detection" you don't need to know game data. Here how i would proceed :

-Install a global Hook for keyboard input in the FE
-The FE load the game and load "Detection data" for the game  in his memory.
Detection data contains a key sequence that indicate the keys sequence the user uses to reach the character selection page of the game.
(ex :  key 5 (insert coin) , key 1 (player1 start) , (here the user is on the character selection screen) , CTRL key (for player 1 button 1) to valide the choice.

- The FE using the hook and the "dectection sequence loaded (specific to each game)" , detect the validation of the character selection screen , and make a screencapture at this moment.

-The FE in background , extract from the captured screen the image of the selected personnage. (depending on the game, can be for instance a rectange up left the screen, or we can detect a higlighted rectangle around a character somewhere. Of cource it is specific to each game and require "Graphic detection data" and a more or less complex algorthime , but doable for sure)

-Once the FE extracted the image , it compares to his graphic detection data to determine which one it is. And then display combo information, or what you want on the second screen.


But i agree it is not simple , and it is lot of work for something just "fun".  I won't start something like that now.

[nobbo]

sorry guys for opening up a can of worms 

seriously though this has the potential to be a good discussion as there has been some very good points brought up...

working in the document imaging business, i deal with OCR software quite frequently, and i would say that although youki's method is technically possible, the sheer overhead of doing it would make it a very unlikely option as far as capturing a screenshot and then reading the character name (thats how i read it anyway).

in saying that though, the point about the key sequence got me thinking....(prepare for crazy thought number 2)

using the original street fighter 2 for example, where on the fighter selection screen, there are 2 rows of characters with 4 in each row. if you were to give each one an ID number of 1-4 on the first row, and then 5-8 on the second row, by capturing the joystick movements you would be able to determine which fighter the player has chosen. this would be done by assigning left a value of -1, right +1, up -4, and down +4.

by capturing the joystick movements from the time the player pressed start to when the player presses a button to select the character, you would be able to tell what their final choice was and then go from there...

the only problem i could see in this method would be if the player moved the joystick before the selection screen came up, because then of course it would stuff the whole sequence up...

let me know what you think

cheers

[Howard_Casto]

You can't validate anything with a screen capture because  mame allows different filters and the ability to turn off hardware stretch and such.  What your system detects as the selection screen might not be the same on another pc, with different color, filter, rendering and bit-depth settings.  Buddah manages to do so in his video capture code because he searches for two identical frames or solid colors, which is easy to do. Also he's constantly taking a screenshot and comparing it externally (which is what you would have to do pretty much) and this slows mame to a crawl, making it unplayable, not to mention it means you have to use a custom build of mame.  

You can't validate anything with keypresses because you don't know if they pressed said keys in the character selection screen or not. (The only way to do so accurately would be to use the screenshot method, which as we've both pointed out probably isn't going to even work.)  You can't just set a delay, because different systems will have a slightly different delay between when one presses start and when one actually gets to the selection screen.  And since missing even one keypress would throw the whoel matrix off, I don't see it beign very acurate.  And of course the question of which keys also comes to mind.  The app would have to read mame's default cfg, and mame's cfg files, and mame's ini files and mame's ctrlr files and be compatable with all major versions of mame.  I have to do this sort of stuff for j5 and just parsing all the data is a full-time job.    

And remember, on top of all of that, many games allow player 2 to join in at any time, dumping you back to the selection screen again.  And there isn't any way to detect gameover, so if a player presses start to continue (In some games you aren't dumped back to the selection screen and just continue as the selected character.), the program thinks you are in select mode again and you get a randomly changing profile throughout the duration of the rest of your game. 

Technically it might be possible, but considering it would literally take weeks to figure out how to do a single game and there are several hundred fighters in mame... as I said, it is totally improbable to do so.  

You two guys seem to think it's a simple as counting the joystick presses and a few other trivial things, but unfortunately this isn't the case. 

I'm not sure where these "worms" you speak of are though.  Here's the thing, Youki isn't willing to do it, I'm not willing to do it, there might be 3 or 4 more people on the boards qualified to do it (that actually are willing to do software for this community) and none of them have volunteered, so even if youki argues to the contrary it seems pretty apparent to me that it is, indeed more trouble than it's worth. 

And I'm not being mean or negative, I'm just being practical. 

Sorry man. 

[youki]

if youki argues to the contrary it seems pretty apparent to me that it is, indeed more trouble than it's worth.

I agree with that, i just say It is doable.   And i don't say it easy , just doable for somebody really motivated!!!

You can't validate anything with keypresses because you don't know if they pressed said keys in the character selection screen or not.

Yes, you can.  Because you work on Key sequences ,not on simple key press.   Insert Coin , following of a player start , following of joystick moves, folllowing of a player 1 button 1.   There is strong chance, for one given game, that you started the game, and select a player.   Of course there is surely tons of "exception" and special case to manage.... but it is just for fun, not a professionnal use, if you can make it works at 90% it could be enough.


Anyway as you said , i don't thing somebody will try that anyway.

[Buddabing]

Most likely, each game has a memory address which stores the player. Maybe there's a 1 there for Sub-Zero, 2 for Scorpion, etc.

With the MAME debugger, you could step through the code and examine memory immediately before and after selecting a character. Or, in a game that saves states, you could take a state save before and after selecting a character and examine the state saves.

You should be able to find which memory addresses and values are relevant. Once that is done, you can either use a custom build of MAME to monitor the addresses, or you can figure out what memory offset of your program correspond with the address and monitor it externally.

To test Youki's theory, it should be easy to compile MAME to save a series of joystick moves and button presses to predict what character is selected, then log it.

[Buddabing]

Testing Youki's theory:

I added two lines of code to the joystick handling routine to log joystick presses. The problem is not detecting when a joystick or button is pressed. The problem is when the player holds down the joystick. For some games, including Mortal Kombat, the joystick can be held down during the character selection screen and the joystick move will repeat after a certain period of time. This doesn't happen in all games. Sf2 does not have this behavior.

So, not only will joystick sequences have to be calculated, but the delay between moves generated by holding down the joystick will have to be considered.

You can calculate the exact amount of time between incremental joystick moves by using screenshots. If the joystick is pressed at frame X and the second joystick move happens at frame Y, then the delay is (Y-X)/framerate. This would require use of BuddaMAME's ability to generate screenshot each frame.

This is not a project I want to undertake.

[youki]

So, not only will joystick sequences have to be calculated, but the delay between moves generated by holding down the joystick will have to be considered.

It is why for this kind of game (where you can hold down the joystick) , you have to determine the charactere choosen using graphic recognition.  Just would have "just" to detect the characters selection validation.
At this time, you made a screenshot.

Then you compare the image generated with an imagine stored in your databank.  As Howard said, there is surely some problems with filter , resolution etc..Etc... but we could image a configuration tool that you will have to run once your mame is set up , that will generate image in your reference databank according to your current setting.

Or you use lot of more complex imagery algorithms.


So who starts?   

[nobbo]

I'm not sure where these "worms" you speak of are though.  Here's the thing, Youki isn't willing to do it, I'm not willing to do it, there might be 3 or 4 more people on the boards qualified to do it (that actually are willing to do software for this community) and none of them have volunteered, so even if youki argues to the contrary it seems pretty apparent to me that it is, indeed more trouble than it's worth. 

And I'm not being mean or negative, I'm just being practical. 

Sorry man. 

howard, what i meant was that i wasn't trying to start an argument about this whole thing. i also wasn;t expecting someone to go off and write an app to do it, it was as i said a crazy thought, and has pretty much been proven so, and i was interested in what more technical people, such as yourself, thought of it.

i always thought it would be a long shot, but you never know until you ask 

a big  goes out to Howard, youki, and budda for sharing their views on this

[Howard_Casto]

if youki argues to the contrary it seems pretty apparent to me that it is, indeed more trouble than it's worth.

I agree with that, i just say It is doable.   And i don't say it easy , just doable for somebody really motivated!!!

You can't validate anything with keypresses because you don't know if they pressed said keys in the character selection screen or not.

Yes, you can.  Because you work on Key sequences ,not on simple key press.   Insert Coin , following of a player start , following of joystick moves, folllowing of a player 1 button 1.   There is strong chance, for one given game, that you started the game, and select a player.   Of course there is surely tons of "exception" and special case to manage.... but it is just for fun, not a professionnal use, if you can make it works at 90% it could be enough.


Anyway as you said , i don't thing somebody will try that anyway.

I hate to beat a dead horse, but that won't work either.  I can insert coins and press start till the cows come home when a game is in boot sequence, but it wont take me to the select screen.  I can also insert coins and press start while playing the game (some fighters use start as a tuant button) but that won't get me to the select screen either. There are other issues like that, minor things specific to each game, like the holding of keys like budda metioned. 

I have a method in mind (not automatic but close) but I can't tell you how well it'll work till I get the physical hardware setup. 

[Howard_Casto]

Btw, I thought of a method of getting the memory addresses that Aaron *might* allow in the official build. 

Perhaps a "-list_outputs" command line switch that prints the port names and memory addresses at runtime. They are actually allocated into memory inside mame via offset values, so in theory it would be possible to determine the exact memory range.  Of course it'd work different from traditional list outputs in mame in that it couldn't print unless the game is loaded, so I dunno. 

[youki]

I hate to beat a dead horse, but that won't work either.  I can insert coins and press start till the cows come home when a game is in boot sequence, but it wont take me to the select screen.  I can also insert coins and press start while playing the game (some fighters use start as a tuant button) but that won't get me to the select screen either. There are other issues like that, minor things specific to each game, like the holding of keys like budda metioned. 

It is why i said :

Of course there is surely tons of "exception" and special case to manage.... but it is just for fun, not a professionnal use, if you can make it works at 90% it could be enough.

You do that thing for a personnal use. So if you explain in the document the sequence it will work that's enough.

If you take you car and drive directly to hit a wall your car won't work anymore. I suppose, you don't do that with your car? Why? Because you know it will break it!  But technically you could do that.  So in that case, it is the same thing. 

Btw, I thought of a method of getting the memory addresses that Aaron *might* allow in the official build. 

Perhaps a "-list_outputs" command line switch that prints the port names and memory addresses at runtime. They are actually allocated into memory inside mame via offset values, so in theory it would be possible to determine the exact memory range.  Of course it'd work different from traditional list outputs in mame in that it couldn't print unless the game is loaded, so I dunno. 

Yes, that could be , effectivly ,a very good solution!   (for memory staticly and globaly allocated of course).