Tux

Well I didn't understand everything here, with this script you start it on the title screen, it works like the on script, normal, then f1 to reset, which stops all the scripts including this one, when you return to the title script it's normal which confirms this script is indeed stopped. But apparently it's not a problem for you anyway so everything is good. And that's right, this loop is quite fast, it's probably because the 3 1st instructions of the for are specially evaluated, no function parsing for these 3, the function parsing is used only from the 4th argument. Anyway it works well, so it's good.

When you reset all the scripts are stopped, if you start it again then it should work. Once again : the initialization part of the loop is always executed, so whatever value there is in the loop variable when the loop starts is not relevant.

Nope at the exit of the loop the variable has the last value which made it to exit and keeps it even if there is a reset, but if you execute a loop again, the 1st instruction of the loop is always executed so the old value doesn't matter.

Ok, finally understood so there is indeed a bug, actually 2 bugs in the for loop, here is what happens when you do many things at the same time... ! Anyway it's fixed, your test2 now clears the whole screen keeping only the stars.

Tsss, your original script did that exact same thing with the gauntlet alone in the middle of the screen ! Ok then I leave you to that then !

Just to be perfectly sure I did that in windows, in msys 32 bits git pull then make on a makefile for the debug version then copied the mshud.txt file from the attachment above. Then ran the game inserted a coin, ran the script took this picture. If you get something else then we really don't live in the same world !

It's probably something stupid but since I can't guess what it is, here is my mshud.txt file. To be started on the title screen of course. mshud.txt

Well it works here so you probably made a mistake somewhere. Of course not you can do whatever you want with it, but be careful if the loop never ends then raine will freeze and the only way to stop it will be to kill it (from the task manager). You can open the console and do a help for to check if for is really inside. And of course if you run a loop such as the one in your example in every frame in a run: script, it will probably be very very slow !

Just pushed this simple for loop to git, your script becomes : script "test 2" on: poke $FF4BE1 $F3 poke $FF26AD $71 for counter=0 counter<=$2ac counter=counter+4 dpoke $90c090+counter $6000 it's now a on: script, not a run: because everything executes in just 1 frame.

There are 2 parts here : 1) it's not a crash, it's the effect of the recent optimization to make the ifs faster, if you run raine from a console (which is always the case for me in linux, curse windows to make running programs from a console so difficult !), you'll see it prints an error message before exiting without crashing, the message says : no command for counter=dpeek($FF1020) It's not an error from you, it's because the optimization expects to have real commands inside an if, that is a function name and then some parameters, which is not the case here, something I forgot but I thought we would have found this kind of case earlier. Anyway its really easy to fix, I just pushed the fix in git. The script doesn't remove the gauntlet, it keeps the gauntlet alone on the title screen 2) what you really need here is a loop, simply. Well the fact is that these scripts were never meant to be that complex so the notion of block is not really defined for them for now except for the if..elsif|else...endif case. What I could do is a simplified loop without block, like the c for loop, but without block which would look like : for init test increment instruction where init would be the initalization of the loop variable, like i=0 test would be the test to run for each turn like i<=12 increment would be what is executed at the end of the loop, like i=i+4 (the i+=4 from C is not supported by the console !) and finally instruction the optional instruction to run inside the loop, which would replace a whole block, like dpoke adr+i value This would be a good compromise, not too hard to do, and it would simplify quite a lot this kind of problem, plus the loop would execute in 1 frame, here your script runs a lot of frames for its loop. What do you think ?

For the crash it was a stupid mistake, it happened only if the empty dir was not the 1st of the list ! And in my test it was, of course... ! Anyway fixed in git and for next time ! (it's a 1 line fix... !). And by the way, I didn't know some people still had some windows8 around, one of the most hated windows version ever, with windows me (millenium but it's rather old now). The part about spying the user to get ad money was added in win8, but is more and more present now, luckily there are tools to block all of this... !

Yeah I was not totally sure it would be worth it for the speed, at least it's good news for my peek function, it's not so slow after all ! And yes it's clearer with the mode variable. Thanks for the fixes, updated in git.

It's actually rather long... ! I don't have the crash here, maybe some craziness from windows which escaped me ? I'll test this again to be sure. edit : don't have the crash at all, even in wine : empty ips directory -> messagebox to tell the dir is empty, empty dir inside ips directory -> just displays the .. dir to return 1 level higher, tested in wine, same thing. Very good diagnosis indeed, it's related to the recent optimization of the scanline counter for aodk and some other games, apparently there can't be any optimization here because this unibios just uses it to count the frames !!! (it's a very unefficient way to count frames, the best way is just to add a counter in the vbl irq, if they had done that there would be no bug). Anyway, I'll revert to some more classical code here then, there was a game which produced a black screen because of this recently, do you remember which one it was, I didn't write which one it was and since I change this again, it would be better to double check. (aodk already checked and ok) Yeah you can't use game options here since it's not available until a game is loaded, but I don't like the idea to add lines in the header of the game selection dialog, there are already quite a few and I don't want a crowd here. Maybe simply as a line on top of the "preload ips dat file", a kind of "ips patches enabled globally" with a checkbox. I'll think about it. edit : done, not with a checkbox finally because they are not really convenient in the gui right now, so a classical menu with enabled/disabled displayed in text, it's easier. Setting saved in config file so it stays if you quit the emu, and is taken into account if you load a game from the command line. You're in luck because I have a similar problem here, I have a pad which tries to be clever and to autodetect what it's plugged to and then change its layout based on what it detects. It worked well until recently and was detected as an xbox pad on pc, but with linux kernel 6 it started to detect it as a nintendo console ! There are ways around that : stick to a 5.x kernel, that's what I did 1st for about 1 year, but now the old kernel is not available anymore in arch and so I can't do that anymore. So I can experiment this button swap 1st hand ! I'd suggest using the controller mapping function instead, there is only a catch there : it doesn't change anything for the gui, you still have A & B inverted there, I'll change the gui to use the normal mapping then... ! edit : actually I had a weird problem here, normally raine creates a userdb2.txt file in the config directory and then renames it in the end to userdb.txt but mine was not renamed for some reason, so actually the new mapping didn't work at all. I added an error message in case the renaming fails, but when I redid the mapping, it worked flawlessly, no error message, and the new mapping works everywhere, gui and games, so the buttons are once again in the "right" order. Oh well... at least it works, once the right userdb.txt file is created you don't need to touch this ever again anyway.

Test 1st, maybe the improvement will be almost nothing, in this case don't bother.

Ok, some little optimizations again, get them from git this time, I didn't review the whole script, stopped at the beginning of the menu (Menu Screen), but there is a big one here ! You might eventually want to try : ff0=peek($FF0000) if ff0==0 ... elsif ff0==1 ... instead of having the if peek($FF0000)==0 elsif peek($FF0000)==?? etc, the reason is that the variable version gets the peek result only once, the peek version might get it a lot of times, and functions are a lot slower to evaluate than simple variables. But you need to check if it really makes a difference by checking the misc counter when changing this, and I was too lazy to do it tonight, so it's just an idea !

The reason why your values are changed is because it's a shared ram which is mapped directly to the z80, it serves as a way of communication between the 68k & the z80. They were pretty in advance for multi cpus architecture considering it was in the 90s, but this way to communicate was probably already used in the 80s in the arcades too. For the z80 it's some normal ram. You can access it by using the z80 instead, but it obliges to do cpu z80a (to switch to the z80) poke $c000-$cfff for this shared ram, this time it's some normal ram for the z80, which means the sound command is in the word $c000-$c001. But I advise to keep the way it works now since almost all your work is for the 68k, it's just an explanation of why this ram is so weird ! So as soon as the z80 executes during a frame it reads what is there, and eventually changes the values. For the other games, well maybe, you'll see, maybe I was to careful with the whole area, but it's not a big problem anyway, if something fails you'll know where it comes from !

Pushed to git, since you didn't explain in detail the changes I have put "mainly sound effects, fixes & improvements". Tested quickly, works perfectly, the shortcut to the service mode without reseting the game when you leave is quite impressive too ! Congratulations !

Yeah I know accessing this area is counterintuitive, you can keep $618001 it would be correct for normal ram, here it's the same as a poke to $618000, and poke to $618003 is the same as $618002. To remind you these are high byte of the word code for the music or sound effect to be played ($618000) and low byte in $618002 (or $618003 as you prefer). For $61801f if it's enough for you with sfad that's good, the song associations clears the whole area, but it works anywhere with any game. Good I'll test it a little later and update it to git...

writes to $618003 are strictly equivalent to writes to $618002, there is a handler at this address, it takes the offset and divides it by 2, the use it as an index in the qsound shared ram. Anyway glad it worked for you, I'll take a look later.

Actually it's rather very tricky for cps2 because it's qsound, this chip doesn't take a single sound command, it has some shared ram which can be accessed directly by the 68k. I tracked how songs are played for the sound associations function, so I can explain this, but I didn't try to find how sound effects are played, but apparently it's something different, probably another offset... Anyway for a song, 1st init the game until you reach at least the copyright screen then go to sound commands / Associations and test one of the proposed sound commands until you find something you like. Here we'll take song number 1, the 1st one. So you need to 1st zero out the 16 1st addresses of the qsound ram ! And to make things worse this ram is not contiguous so you must access it this way poke $618000 0 for offset 0 poke $618002 0 for offset 1 ... poke $61801e 0 for offset $f If you want to experiment with that try that in the console, for a script you would need something like a memset command to clear the whole area in 1 line. Anyway once the whole 16 1st offsets have been cleared : poke $618000 commnad here the command would be 1 then poke $61800e 0 (from the console I am not sure this last poke is necessary since you just cleared it, the game always finish any qsound command by writing something to this offset). If you did things right you can close the console with the ESC key and you should hear something ! Rather complicated, I'd advise to start with neogeo which is much easier than that because there are true sound commands in neogeo ! edit : after testing quickly for the sound effects : they are simply after the musics, but it's on a word, high byte goes to offset 0, low byte goes to offset 1, so I guess in my example you should rather put 1 in $618002 even if putting it in $618000 seems to work. To experiment with this go to the service mode, sound test and browse the sounds... If you go backwards it goes to sound $2ff (which is nothing), but there are soon real sound effects to be heard close to this value. When you find 1 you like you can check the values in the qsound shared ram using peek($618000) for example. If you really want to try that, I'll add a memset function to clear the area in 1 line.

... and pushed this script to git too... I didn't test everything, but it can always be updated later, and it's already quite impressive !

I accept patches... ! on my side I just pushed the fix for alt-c

I don't think so, because A is used for normal input, so if you start pressing it then the corresponding control is enabled... ! There was also the grouping under if ((peek($FF8051)==$04)or(peek($FF8055)==$04)) instead of all these if which had this very same test in a and Well you can't win all the time with this kind of optimization, it came obvious to me when reading the script so I did it while looking for the cause of my problem...

Much better with some documentation ! So that's because I use alt-c as a keyboard shortcut to call the cheats dialog, I think that's the default shortcut, and since C is also the key for heavy kick, it's seen as always down when you return from the cheats dialog ! At least we found a rare bug here. I'll fix it in git... !

Ok, so here is a slightly improved version of the script, basically less tests in each frame by grouping the tests and the result of all that is that for me I have peek($ff8050) == $40 as soon as I start the 1st script, well almost, on the phoenix screen it's still ff8050 == 0 but after that something puts $40 in it during all the frames. Since your test to exit your menu is #Start game# if (peek($FF8050)>$00) #P1 start game# poke $FF8058 $01 poke $FF817B $01 endif it exits as soon as it reaches this point (I don't know what this ff8050 address is supposed to contain, I just know it's in ram). Actually it occurs all the time now with all the versions, 32 or 64 bits, I even wonder how I could have this menu to stay on screen before, now I can't, it's gone as soon as it appears. edit : and I finally understood how to get your menu to stay : you must start your script before starting the game ! That is, load the game with the option not to auto start it in the background, then enable the 1st script, then start the game. Then the peek stays at 0 all the time. If you start the script even during the phoenix screen, it's too late, the memory address will get $40 all the time. sfad.txt