Sega Model 2 Emulator Full Screen Shooter fix - RamjetM2Borderless - App

[Howard_Casto]

Man insomnia sucks.  Even when you know you have stuff to do the next day, when you can't sleep you just can't sleep!

Anyway, I did just a little more work on the troubleshooter.  I've added support for reading addresses off of a csv file.  I added this specific for model2 because suprisingly other games/emulators aren't nearly as difficult to work with.  What does this mean?   Well RamJet's excellent scripts for daytona can now be replaced with the troubleshooter.  I wrote a simple script that prints out all the needed dynamic addresses to a csv file when daytona starts.  It seems to work pretty well although I have to add a delay of a second or two before it starts up to give model 2 a change to write the file.  Unlike the current script the file only has to be read once, so it should be easier on the harddrive.  This should be useful for problem addresses with the guns as well.  I can print out an address if it's dynamic. 

On that note I've been wondering if we are going about the solution the wrong way in regards to the guns.  We've been messing with the RAM to insert a NOP command, but if cheat engine is modifying the assembly code doesn't that mean we could simply hack the exe?  I haven't looked into it but I think ramjet is more intune to the lower level programming languages so I thought I would mention it. 

[Endprodukt]

I'm suffering from insomania as well to a point were it controlled my life. Therapy, medication, sports can help as long as you're not relying on one solution. I'm still up way too long, like 2-3 am and have to get up at 7 to get to work. Another important thing is not to force you're sleep. Its way more important to have a few hours of good sleep rather than forcing sleep under pressure. Some kind of endurance sports are the best you can do in my opinion. Running fast  for 20 minutes in the evening helped me a lot. If you all ready know all that I'm sorry.

[Howard_Casto]

Yeah I've tried it all, but I still have trouble sleeping sometimes.  Thanks for you concern though. 

Well even though I said I was going to take a break I found myself with some free time today so I thought I would plug along some more.  Model 2 stuff was getting on my nerves because of it's complexity so I thought I would start working on adding support for all the pc games in the old troubleshooter app into this one.  That part is suprisingly easy!  I plugged in the values for House of the Dead 3 and troubleshooter immediately worked with the game, no issues whatsoever.  I was a little concerned because HOTD3 uses float values to store the gun positions and vb technically doesn't have a float variable type.  Luckily the single data type works just fine for this. 

One thing I need to add in that I just haven't messed with yet is key simulation.  The old troubleshooter simply simulates keypresses to press the fire and reload buttons in games.  Since this works and I don't want to have to search memory addresses to do it the "right way" I went ahead and pulled in my now 13+ year old code for keypress simulation from the first wrapper I ever released.  Still works great!  I wish I could do this for model 2, but alas it doesn't work with m2... it's just picky. 


So except for model 2 ironically, things are going pretty smoothly.  What I'm going to do is this:  I'll add in code for a NOP section in the ini files for the games.  If/When we ever figure out the regions to NOP in m2 to make it cooperate, we can just plug in the values. 

[RamjetR]

On that note I've been wondering if we are going about the solution the wrong way in regards to the guns.  We've been messing with the RAM to insert a NOP command, but if cheat engine is modifying the assembly code doesn't that mean we could simply hack the exe?  I haven't looked into it but I think ramjet is more intune to the lower level programming languages so I thought I would mention it.

On this Howard, this is exactly what I'm doing with cheat engine and it's trainer 'maker' for want of a better term. I have isolated the assembly structs for gathering inputs within the exe itself and should be able to inject this into anywhere I want in the running process. What I am looking at is gathering inputs from Joystick devices rather than RAW inputs. This means that a simple script from glovepie that lots of people use everyday and in the rest of their cabinets should be able to just map the gun to joystick inputs.

This means the exe will just grab inputs and copy the values into the correct locations as if it came from the Raw input code...

It's a different way of doing it, and I'm learning not only the assembly it was written in, but having to reverse engineer how Elsemi wrote the original code (without all the nice commentary by any of it). Come to think of it, I should also be able to read the output data directly in the process and call a dll from in the lua code external to the ROM but within the Cheat Engine code.

Look this it a lot hypothetical and I don't have much experience hacking games... (not normally been something I do). But it's the route I'm trying too

Ramjet

[Howard_Casto]

Well I can save you the trouble on the lua route..... I thought of that one and tried to overwrite the functions that way, it didn't seem to have any effect.  I don't think lua can see the static parts of the code, in other words the exe loaded into memory. 

I've actually got a few of hte functions isolated in cheat engine myself, but the CE addresses look like gibberish to me.  I'm going to try to get them via art money so I can get the address relative to m2 so I can access it from within model 2's lua.  That should make things much easier as it can just print me an address to use with the troubleshooter. 

[Howard_Casto]

Good News! 

Instead of trying to follow the stupid pointers and baseaddresses and run-arounds and what not I opened up the exe in a hex editor and simply hacked the exe.  It disabled the Y-Value just fine.  So that problem at least is solved.  I have frozen these values in gunblade with nop's and my app can inject the values just fine after they are disabled.   

Memory hacking I'm not so great at, but file hacking I'm a little bit better at.  This just seems like an easier solution to me.  We can either supply hacked exes or I can make a patch at runtime. 

When you have time I'd appreciate it if you sent me any NOP-able addresses you've found thus far.... it'll just save me the trouble. 

[Howard_Casto]

Ok progress report. 

Spent all of 20 minutes this evening with the cheat engine to determine the lines of assembly code I need to NOP.  I've found all the code for the analog gun games.  I ran the troubleshooter 2 with the code disabled and my app no longer fights with m2, allowing my interface methods to work. 

Unfortunately the code to change the lightgun game values is in another location.  This actually makes sense because while the analog gun games use a single byte to store position (0-255) the lightgun games use two bytes for double that resolution (0-512).  Now RamJet already figured one of these out a few posts back, I think it was the x-value of p1 and all of the locations are generally in the same area, so I should be able to get that when I work on things again tonight.  Then I can make a patch, allowing you to have special "gun" versions of the exes for lightgun use. 

I haen't looked into hacking the address of the gun triggers yet.  This is actually a big deal for the lightgun games.  The reload button is hardcoded to the mouse's button 2, so without trigger hacking you wouldn't be able to reload! 

Anyway, more porgress as it comes in. 

[vandale]

looks promising, great work 

[Howard_Casto]

Ok more progress.....


I looked at the cheat engine file that ramjet sent me a while ago.  The good news is it DOES work universally, just for the lightgun games.  He's only gotten p1's addresses though so I'll poke around for player 2's addresses.  Looking at the assembly a little more I now know what to look for, so it's a bit easier for me to search for code generically. 


Ok on the analog gun front.... It turns out that I'll need to hack the exe in multiple places.  We've got three analog gun games right?  Gunblade, Rail Chase 2 and Behind Enemy Lines.  We'll I don't know if the hardware or software developers were sniffing glue or something, but even though all three games use the same hardware hookups and memory spaces, each one randomly inverts the values and/or port used. 

Gunblade NY:

The Y axis is inverted for both players

Rail Chase 2:

Both X and Y are inverted, player 1's gun is hooked up to player 2 and vice-versa

Behind Enemy Lines:

Mostly like Gunblade, but the calibration values are slightly different. 


So I'll have to patch the exe in multiple places.... not a huge deal, it just means a bit more work.  I haven't even looked into this yet aside from my initial hack because I want to get the rest of the lightgun data. 

In regards to triggers.... that is a bit of a tougher nut to crack.... doing a nop on the mouse buttons has become tedious to put it lightly.  Fortunately I was struck with a bit of common sense.  Elsemi hacked the lightgun functionality so that you couldn't move the cursor outside of the screen.  There is no reason that I need to do that.  I can allow the cursor to move outside the screen, just as it would in the arcades.  Not only does this solve my lack of a "reload button" problem, but it allows for original functionality.  In terms of a dedicated reload button, I can simply lock the gun position to outside of the screen and fire the game's trigger (I CAN do that at the game level) to simulate an outside screen shot whenver the user presses their reload button.  For dual mice-based lightguns of course I don't even have to do that, I can simply leave the original code as-is.... this is merely for joystick support. 

Anyway, I'm not sure if this is interesting to anyone... I'm just trying to keep everyone aprised of what I'm up to so we won't repeat each other's work. 

[retrorepair]

Wow an awful lots been happening while I was away!

Firstly I hope everyone's ok what with the crazy weather of late.

As for the progress that's some mighty impressive stuff

If the exe can be patched at runtime I feel that might be a better approach unless you were willing to host the hacked exes but at this point I'll be happy with the darn thing just working Can this be done with output data too? It'd be great to do away with lua once and for all. I wonder if the exe can be patched for stereo sound again too..

BTW I would say Rail Chase had the x and y inverted due to the different controller on that game. I believe it was an actualy joystick rather than a large gun so it mechanically needed to be different. Not sure on behind enemy lines.

I'd be interested to know how you are hacking the exe using cheat engine btw, I understand memory locations (more than I used to anyway) but not sure how you can use that to find where to patch the exe.

Shaping up nicely!

[RamjetR]

Howard

The exe can have code injection enabled and disabled with a hotkey when needed. So it's quite easy to enable and disable all manner of code at will. It could probably even be triggered by the M2 LUA script on launch of the game.

The P1 code I sent you is from about 3 weeks ago (seemingly the last time I had a moment spare)... P2 data is a replica of that and can be found by scanning what access' the P2 XY 0x5xxxx addressing in games virtual RAM. Give me a couple days to gather this and make sure it's universally like P1. It requires me setting up a second mouse and configuring it and some monitoring... and some beer....

I haven't touched any actual code in the last week or so with the cyclone and floods. Working 18 hour days for 8 days in a row and I'm just looking forward to some game time this weekend.

On a side note, I found 20mins at work today to get kaillera to work. I'm oh so excited to get the guys into some 4 player TMNT/Sunset Riders/Simpsons. I was very impressed to see 4 players on a LAN playing the same MAME game without having to smell the guy beside me lol!

[Howard_Casto]

***NOTE:  It seems like we all are posting at the same time anymore... RamJet's reply wasn't there when I started typing this****


Yeah it's currently 5 am here.  I had to go out at 3am and unplug my trickle charger for my car because I woke up in the middle of the night and it was snowing sideways!  Even though the thing is under a carport it was under a few inches of snow.  Which wouldn't be all that abnormal in terms of weather for my area this time of year if it hadn't have been 75 degrees (F) only two days ago.


I can patch it at runtime, but it doesn't make a lot of sense to do so.  It would have to copy the original exe and make a new one each time the game is launched.  So why not just copy the original exe, patch it, and leave it on the users computer permenantly?  The idea was the m2 portion of the troubleshooter would come with a setup program... it would generate new exes from your original ones as well as setup a few m2-oriented do-dads not required for other games and emulators. 

Lua isn't going away completely, it just won't actually do anything anymore.  The LUA scripts I am currently using do only two things.  They launch the troubleshooter (more of a matter of convienance than anything else) and they generate a csv file upon startup containing any dynamic addresses I might need.  After that the whole thing becomes dormant.  If somebody more versed in memory hacking can give me some sample code of how to get the dynamic addresses or is willing to go through the painstaking process of finding the re-direct pointers in m2 we can eliminate lua completely. 

Outputs are detected by the troubleshooter and passed along to mamehooker.  I don't mention that part a lot because it's basically done.  It works perfectly and the ts will be used for nearly all of the games in m2 because of it.  I've got the basic output data from most of them.  The only thing that eludes me are the outputs in desert tank, daytona and the vs billboard system for the fighting games. I'm talking about official outputs of course, we can easily (and I already have) use the memory locations that you and ramjet found for daytona as well.  My only request is that any output that isn't official have the flag "fake_"  tacked on to it for use in mamehooker.  I'm all about the documentation afterall. 

In regards to the cheat engine, there is a function called "find out what writes to this address" where it literally searches the assembly code of the running exe to see if there are any lines of code that make reference to the memory location you've currently selected.  There is also a "go to this section in assembly" option where you can see the actual code both in readable form and in raw hex.

So basically you

1.  Find the location in memory where the x/y/whatever position is stored

2.  Run the find out what writes to this value function on that position.

3.  Look at the hex of the code in question and write it down. 

4.  Open the exe in a hex editor, search for the hex code from #3, and replace it all with 0x90's (do nothings or NOPs). 

[Howard_Casto]

Howard

The exe can have code injection enabled and disabled with a hotkey when needed. So it's quite easy to enable and disable all manner of code at will. It could probably even be triggered by the M2 LUA script on launch of the game.

The P1 code I sent you is from about 3 weeks ago (seemingly the last time I had a moment spare)... P2 data is a replica of that and can be found by scanning what access' the P2 XY 0x5xxxx addressing in games virtual RAM. Give me a couple days to gather this and make sure it's universally like P1. It requires me setting up a second mouse and configuring it and some monitoring... and some beer....

I haven't touched any actual code in the last week or so with the cyclone and floods. Working 18 hour days for 8 days in a row and I'm just looking forward to some game time this weekend.

On a side note, I found 20mins at work today to get kaillera to work. I'm oh so excited to get the guys into some 4 player TMNT/Sunset Riders/Simpsons. I was very impressed to see 4 players on a LAN playing the same MAME game without having to smell the guy beside me lol!

That's actually one of the reasons why I don't like trainers ramjet... hotkeys and mame cabs don't mix.    As I stated in this last reply, the way I was going to go about it was to just have different exes.  It's simple enough to just have the user launch the original exe if they ever want to retain original functionality.  Why they'd want to do that though is beyond me considering I'll be supporting dual mice in my app as well. 

I need to find the memory locations of the drawn on cursors as well.  People with IR guns might like some crosshairs on the lightgun games.

Kaillera is fun... used to do that with mame back in college... damn I'm getting old. 

[BadMouth]

Anyway, I'm not sure if this is interesting to anyone... I'm just trying to keep everyone aprised of what I'm up to so we won't repeat each other's work.

Progress is being made.  It's interesting to everyone with two guns!

[Wade007]

Anyway, I'm not sure if this is interesting to anyone... I'm just trying to keep everyone aprised of what I'm up to so we won't repeat each other's work.

I agree with BadMouth. +1 here who is VERY interested in the progress made here on this thread. I'd LOVE to see two lightguns working. Thanks for your hard work. Keep it up. I'll be watching from the sidelines. 

http://www.cheapskategamer.com/pc_game_stories_and_news/true-light-gun-support-for-pc-gaming-the-arcade-guns%E2%84%A2-product-review/

[Howard_Casto]

Ok, did some memory snooping tonight.  I couldn't find the real outputs for desert tank as apparently they are borked (confirmed this in mame) but I did find a dynamic value that stores the current view, similar to what ramjet found in daytona.  So I made a file for that. 

I dunno about the motor data, I think because all the limit switches and what not are improperly hooked up it isn't going to work right. 

One step at a time I guess. 

[Howard_Casto]

Fantastic news!

I finally figured out how to read dynamic addresses from an art money table programatically. 

Because artmoney isn't exactly clear about it I thought it would document it here. 

On the user/searching side:


1.  When searching in artmoney make sure you select the model 2 emulator from the emulator group so that it'll get you the relative addresses.

2.  After you've found what you are looking for, copy one of the values and change the address to 50,000 which is the start of RAM in m2... this give us a reference point.

3.  Subtract the 50,000 from all the addresses you found, this will give you a relative offset and THIS is the value that the troubleshooter needs. 


On the programmer side:

1.  Use a convoluted api like CreateToolhelp32Snapshot to help you find the base address of model 2, it's always 0x400000 - this step takes a bit of elfin magic, but I found some example code. 

2.  In a art money table, there's a section for all the relative spaces, the first one, which is the 50000 we added to our table looks like this:

"WorkRAM 1Mb","00500000","emulator_multicpu.exe+P0018F930,100h,

Ignore the workram bit, that's just a label.  The 500000 will be our reference point as I said before, emulator_multcpu.exe means the base address of the exe (again 40000), the P00.... is a POINTER to an address that contains yet another pointer to our value.  The 100h means once we find that address add 0x100 and that's the address to the final pointer.

3. Knowing all of that above we now use a get memory function to read 8 bytes (long) from the address 40000+0x18F930, that'll get us our first pointer

4.  Now we read a long at the address we just found +0x100, this is the  physical address  to 50000, or the work ram for model 2.

5.  Remember all of those offsets that you were supposed to determine on the user end?  You can now get the actual value of any of those addresses by reading with teh address found in #4 + the offset. 

Yeah that's about as simple as riding a unicycle. 



Anyway, this means that we no longer have to rely on the lua scripting to print out relative values, I can do it internally.  Unfortuantely that means I have to re-write a few sections of code, so the release might take a bit longer.  At least now I can do things the right way, including inserting NOP's into the running exe. 

[Howard_Casto]

*update*

Actually this wasn't nearly as hard to implement as I initially thought.  I've already modified the output functions, I'll add code for the input functions and NOPs later. 

[vandale]

Hi, good progress, I check this thread daily.

Just out of interest, will all this hard work benefit all types of guns used on M2, ie Aimtracks, wiimotes and the old school CRT based light guns? I think most have IR aimtracks these days, and then theres the minorty like me who have wiimotes.

Thanks

[Howard_Casto]

I'm supporting mice, lightguns and joysticks, so unless you want to play with the keyboard (why? dear god why?)  It should cover everything. 

[Endprodukt]

Awesome news! You're the man!

[Howard_Casto]

Thanks for the support guys. 

Ok, I implemented the NOP functions.  Gunblade is 100% playable with joysticks now.  At least for the multicpu version, I'll have to find the addresses for the other exe, but that doesn't take long.  I'm assuming that I can get rail chase to work 100% as well. 

But.... it seems like every time that I do a major leap forward with this thing, I find another annoying setback.  NOPs work just fine for the x/y axis on any of the games.... this is probably because the mice values have to be translated to the game values first, and I'm adjusting the game values.  When I try to NOP the triggers...  well it crashes.  This won't effect the analog gun games, you can remap the triggers (for joysticks) in m2 and it doesn't effect mice/trackballs/lightguns at all because you can use the mice buttons as-is.  BUT for people using joysticks on the lightgun games (which includes wiimotes) they won't have an easy way to reload. 

I'm sure it's something I can fix, but it's annoying to have to deal with this stuff every step of the way. 

[Howard_Casto]

Ok still making progress. 

Rail Chase 2 is now working 100%  again just for multicpus

Instead of using artmoney or the CE, I just looked for any bytes via a hex editor holding the memory address to NOP and sure enough, rail chase, although allocated in a different area, uses the same one.  It actually makes searching a bit easier.... if you find what you want in the actual exe file, you can add 0xC00 to it and that's the offest when in memory. 

So what's left is HOTD, VCOP, VCOP2 and BEL..... I think BEL and HOTD use the same interface and the two virtual cops use the same interface, so it's really only two games to find. 

Then I'll tackle that trigger issue. 

[vandale]

woop woop

[Howard_Casto]

A little bit of bad news.  I looked at the CE table that RamJet sent me for VCop and unless I am missing something the code in it doesn't work.  It does indeed freeze the values, but it does so persistantly.  In other words m2 constantly re-writes the last address.  So I'm going to have to look elsewhere unfortunately. 

[Howard_Casto]

More strangeness... BEL is actually a analog gun game... it uses the same inputs as rail chase BUT there is some wierdness going on with it. 

First off you can't remap the triggers.... for whatever reason they have been hardcoded to the mouse like the true lightgun games.  Also the NOPs I have for p2Y don't work even though the other three NOPs (taken from rail chase) do.  I think it's because bel is kind of cludged in there and he's written special code for it.  I'll have to find the stupid thing. 

Also the outputs appear to be in a different location as well.... this is extremely odd as all the gun games have used the same address thus far. 

[Howard_Casto]

Found something fun.  The Rail Chase 2 data for the motion cabinet is just a few bytes over from where you would normally find the lamp outputs!  I initially thought it was just some random data because in RC2's test menu the data goes nuts.  It turns out this is due to a cludge in the code to get the driver board working.  In the game it becomes apparent that this is the byte for motion data. 

Unfortuantely because the test mode is borked, I can't fully figure out the bitmasking to split it out into individual outputs.  I Know that 7 is the mask for the rear piston but that's about as far as I got. 

[Endprodukt]

Just for my interest: is it easier to implement the code for the analog or the light gun controls? Just wondering because your focus seems to be on analog games.

[Howard_Casto]

The controls (my end) are equally easy to implement.  I use a joystick for my testing because it's a lot eaiser to test with than a lightgun. 

In terms of the games themselves, the analog gun games are the first I've found the memory addresses to, it's as simple as that. 

[Endprodukt]

Ah okay, thanks for explaining. Wish I would understand more on the technical side of things. Wondering how to find the right numbers in the hex code?

[Howard_Casto]

Good news.  I figured out what was going on with the lightgun games.  There are actually a couple of addresses for each value that need to be NOPed, unlike the analog gun games where only one is necessary.  Not a huge deal to fix, I'll just have to do some more memory searching.  I can probably get bel fixed using this method as well. 

[Trnzaddict]

I check this thread a couple times a day.

 I so appreciate you trying to get dual mice to work in Model 2.

It's crazy though to have to go through all this hacking . If the source for model 2 was made freely available by El Semi this issue with having 2 mice work could of been alot easier to accomplish.

If I was an emu author, I would freely make my works source code available so the day I throw in the towel fans could improve/work on it. But to each their own.

[Howard_Casto]

Well the rumor is he got a job with SEGA, so I can certainly understand why he can't release the code now. 


Anyway, with the breakthrough last night in regards to the lightgun games, I managed to get p1's axis for all the lightguns to repond.  I'll search for p2's junk later. 

So all that remains for the m2 stuff are those pesky triggers.... I've really hit a stumbling block with those... any code I try either freezes the game or crashes it. 

[RamjetR]

Hi Howard,

I've been working on the triggers (along with the axis) and found the dynamic location where the multicpu is grabbing the mouse inputs and converting them ready to be written into the emulation. I haven't posted anything on it yet as I really haven't nailed down the assembly source variables as it calls a few subroutines whilst doing it (looks like it does a compare to the last reading and does a relative movement within the exe?). My idea was to grab the source bytes of data right before it's sent to the emulation and thus requiring only a single area to be modified rather than RAM injection and NOP'ing all the other hook code points (for which there appears quite a few).

I have printed out the assembly structure and currently mapping the stack and registries as it steps through the code to nail the actual variable it assigns dynamically. Like I say it's dynamic which points quite clearly that it's happening outside of the emulation space but within the M2 exe.

[Howard_Casto]

Yeah if we are talking about the same thing, what it's actually doing is calling a dll.  The problem there is the dll crashes the program.  We might be able to get it that way but I dunno.  It would probably involve NOPing where the dll is called to begin with and then you'd have to NOP any instance of a function that accesses the dll.  But keep at it man.  The NOP functions I added to the app allow for infinate NOPs and they support pointers and offsets as well.  It's one of those things to whre if we find a better solution later on, all we need to do is edit the ini file for the game. 

I've got the axis working for every game now except p2 y axis for bel and p2 x axis for vcop2.  Pretty sure these games just do a special case and I need to find some redundant code to NOP.  The games are actually playable at this point... you just can't reload.    It would be nice to find the code for the cursors.  I can probably draw our own, but it'd be a pain in the butt.

It's starting the grate on me a little... been working on this too long.  At the same time I would feel defeated if a solution isn't found at this point, so I HAVE to finish. 

[BadMouth]

I had some ideas and did 10 minutes of hurried testing before leaving for work this morning.

The trigger and reload buttons on the Act Labs guns work correctly for both players if raw input is enabled and their device #s are set correctly.
(all the bullets just go to the lower right corner because I'm testing with the plain m2emulator)
I imagine Aim-Traks would work this way also.  I will test this evening with the single one I have.

So if your troubleshooter program can function with raw input enabled, the trigger and reload buttons on the Act Labs and Aim-Traks would work fine without being interfered with by troubleshooter.

That leaves joystick input (and by extension, wii controllers).
I know if rawinput mode is not enabled, autohotkey can post fake mouse button presses for P1 and it works fine.
I don't know if it still works while in raw input mode.  I doubt Autohotkey can fake more than one mouse anyway, but maybe something else can trigger P2 reload.
I'll play around with reload this evening and try to find something useful.
Who knows, maybe El Semi left something in there for the old Act Labs guns that report mouse buttons 3 and 4 for player 2.

[Howard_Casto]

I'll tell you what I need, but we would have to find somebody with one of the real lightgun games. 

In the gun mark check screen I need somebody to do an offscreen reload and see what the gun position comes up as.  I'm fairly confident that I can hack the inputs at the game level, but I checked the HOTD arcade manual and there isn't an input for reload, meaning that something else, like a specific gun value or something is telling the game to reload.  If the values don't change, then that means that the actual sensor inputis doing something (like maybe never giving a response) which causes the guns to reload. 

I honestly think trying to do things at the mouse level is going to open up a whole new can of worms.  Any functions or dlls that use rawinput crash like crazy whenever you try to halt them.... I think this is the crashing I get when I try to alter the mouse inputs. 

[Howard_Casto]

Well I actually found the reload address for p1 on vcop.  I had actually had it in there for a while, but I didn't understand what was going on. 

It's a simple integer value... 0 when off, 1 when on.  What threw me is in the assembly code, instead of just setting the value to 0 or 1, a byte is allocated or either 0 or 1 and then copied to the address space when the reload data is stored.  So instead of NOPing the functions that write these bytes (which crashes or freezes the emulator) I can simply NOP the two functions that copy the bytes to the area of code that actually does something with them.    Now that I understand what is going on, I should be able to get the trigger as well.  Regardless, if I map the trigger to joystick b#1 and the new reload bit to joystick b#2 I can reload when I press both buttons at the same time.  So it's a start anyway.

I'm off to check if it works in the other lightgun games as well. 

[RamjetR]

Actually the reload still has it's off screen functionality, have you tried reloading with the fullscreen app running? Take a look at/for a memory address which toggles 1 - 17 with mouse left and Right clicked for Player 1

It binary equates to 00010001<- P1 Fire
                                       ^
                                        P1 Reload

This also becomes    00100010 when P2 Fire's and reloads

There are 5 entries of this with some lag between them. The primary state change looks like the initial read where the rest look like some bit wise operations are being added to provide a singe byte to send into the emulator.

They are happening up in the 900000 range with no 50000 RAM equivalent which suggests to me it's a EMU IO read which is sent direct to the virtual CPU.

So, to find this... fire up CE or ART... load the game and open process as per normal.

Do a first search for "1" , single byte... now before you click search... tab the "cursor" highlight the search button (in order to hit space bar to activate) and Press and hold the left mouse button somewhere on the CE or ART program. Hit search and you'll find all addresses with a 1 in it.

Then Filter or continue the search but this time look for "17" decimal, single byte and like before tab to the next search or filter search ready for the spacebar to look. Click and HOLD the right mouse button for the entire duration of the search.

This should reduce the results significantly... now, scan the list of results and look for a 0 after releasing the Right Click.... once you've found them, left click and right click away to see it toggle.... They are the ones you want. ART money for me on my work laptop has a repeatable location for this, but I'm at home today so I'll send that to you tomorrow (getting a TV picked up for return... faulty backlight).

Now because RAW input will capture both mouse cursors to the game screen, it's harder to do this search in that mode... go single player and it will be much easier. This Trigger capture does respond to the mouse outside of the game window, and again suggests to me it's not in game but the EXE capturing the mouse inputs. These same locations also apply to P2.

I'm getting pretty deep into the assembly code and although not directly helpful to your troubleshooter Howard, it's atleast applicable to enabling it's functionality.

Ramjet

[RamjetR]

Bloomin heck, we're all posting at the same time hahaha

The offscreen reloading that appears to be happening in Elsemi's code looks to me to search for a trigger value and then checks the X-Y coordinates. If I'm reading it right, it looks like it puts a threshold window around the game and if it see's the a trigger at the edges then does the reload.

What I've found useful is to do a break and trace in CE to step through the code as it's executed with the registers intact... that was I can see if a compare/test comparision passed or failed and where it would then jump to in the code. You end up with pages of opcodes being executed and it's time consuming as you know.

***edit***

There doesn't appear to be an actual reload input to look for. As I mentioned above. The reload function looks like a state hack Elsemi did to create a Reload button because mice could not shoot off screen. The Trigger inputs toggle just fine as a 0/1 like you say where I go to service mode and check the input trigger. Toggles just fine, but there isn't a reload button. To find that, it's actually in a different location as "17" decimal (see post above this one)

With CE and ART, I can see all 9 or so memory locations toggle 0/1 with a Left click... but 4 of them will toggle to 17 on a right click where the rest continue to toggle 0/1 with a right click.