[gauveldt]

TAS - Tool-assisted something-or-other (script???)

I don't know much about what TAS is or what programs are used but it looks like a way to script controller inputs to the SNES.  The youtube's I've watched that use TAS are basically game play-throughs to get the shortest possible time and can do frame-synced controller inputs to do things like rig the RNG (to get critical hits when you want them, etc).

Sounds like a great way to unit test stuff in ROM hacks and homebrew ROMs.
If you find a particular controller input sequence crashes your game at a particular point you make the script replicate that sequence on all future tests to check for regression (once again making the game crash after some future code iteration, having fixed it initially).

It's not a perfect system (if you change game event delays earlier in the game you may need to offset everything in the scripts to accommodate the change so the test inputs still occur at the right master frame count) but any means of doing automated tests is a definite plus.

A less trivial process may be actually detecting a crash (sometimes it's easy to see with garbage display or whatever but just like poor Relm's sketch bug it might not be immediately visible what happened) and it might be easier to do such a check in emulators via state saving and checking the savestate after running the test to verify the CPU (or more if you use SPC and/or SA-1) is in places it should be with sane register values.

Any thoughts on this?

[FAST6191]

It seems like we are using the higher level TAS definition rather than the more general one where TAS = anything that is not pure player skill/could be done on hardware -- you could otherwise play stock game but using savestates would make it a TAS.

I am not sure how useful this would be. Most issues in ROM hacking that I see are more memory management (though this is less an issue on the SNES and more on filesystem/unmapped cartridge/CD things, until you play with graphics anyway) or combination logic (see things like Final Fantasy and how many hack patches fix say issues with reflect) as safe coding practices and bounds checking were not exactly the norm in SNES era, to say nothing of assembly coding making such things a bit harder.

TAS grade/oriented emulators do make nice toys and if you are waiting on a proper hacking grade thing to be made then they often provide a means to get some things done.

Unit testing is great for minimal input and minimal state things (like a lot of electronics), as well as things like medical devices that have to function perfectly, but for games the paths taken are near infinite after the first second of play, you seemed to appreciate this though and already narrowed it down.

You might have something for a game like megaman where you want to fire a weapon, swap before the frame is done and fire another (testing graphics mainly, logic secondarily), you also have the "what is humanly possible?" thing to contend with.

Probably the biggest hacking type use for it would be those ripping assets via emulation that do not so much want to get their hands dirty fiddling with cheats (though TAS stuff does conditional things so much better than cheats).

That said emulators are now often seen to include general scripting options, typically using lua, for various reasons which can include this.

Crash detection probably falls under the same problem as infinite loop detection aka the halting problem.

If you wanted to do this as a learning exercise I could see you learning a lot from it.

[gauveldt]

Crash detection probably falls under the same problem as infinite loop detection aka the halting problem.

I was not thinking of an fully automatic crash detection since there is no way a script could just out of the blue know where the CPU should be and where it shouldn't.  It's more a case of where the project expects the flow to be and scripting the test to detect the CPU having moved outside those boundaries.  So you might catch a bad poointer issue that comes up only if you have the combination L+R+X on frame divisble by 3 causes an unknown bad pointer sending the CPU way out of bounds to expected routines.

Your test catches the execution bounds breach then you could backtrace and set watchpoints to hopefully find the bad pointer.
It needs some domain knowledge to work for example that you expect routine A to only call B,C,D (or enter the designated interrupt handling code)  if the test finds the CPU in some other routine or interrupt code other than the ones specified in the test then the test fails.  You cannot expect these kinds of tests to be able to guess.  They load a save state, play the input from script, and when the script completes, pull the current processor status after and check against the test's parameters.

Some really old badly coded Amiga games had issue if you did stray mouse movement or keyboard presses (a classroom teacher hit these often because you know that's exactly what impatient kids like to do while waiting for lengthy floppy disk load times of their favorite programs).  The screen would come up "you did something we didn't think of" and proceed to crash into the Amiga's flashing red guru meditation screen of death.