User Files from dwangoAC

This is the configuration file that goes with the Windows 95 verification movie at UserFiles/Info/638587329764509858 - see EmulatorResources/PCem/Windows/Configurations#Windows95 for more information. You will need to replace the paths to point to the correct files.

This is the configuration file for the Diablo installation verification movie

I've shamelessly adapted the instructions below to match what Feos did in UserFiles/Info/638595506638587861

Note: /full/path/to/file.ext is always meant to be substituted with whatever your actual full path to a given file is.

Follow these instructions up through the NVR section:

UNCHECK Runtime -> Prevent writing to disk OR THIS MOVIE WILL NOT WORK!

Set Game executable to your pcem path (probably /usr/bin/pcem).

Set Command-line options to

--config /full/path/to/windows95b.cfg

- The configuration file can be found at UserFiles/Info/638595502390206468

Run the movie.

On the last frame of the movie, PCem will close by itself.

This should leave you with these four files:

~/.pcem/configs/windows95b.cfg - Hashes for this will vary because file paths/names will be different for everyone.

~/.pcem/nvr/windows95b.ga686bx.nvr - MD5: ecbf896579341959544fd5e87c3b9e34

~/.pcem/roms/ga686bx/flash.bin - MD5: 09fa443e777f9bbc7e9af976d43e67a9

Hard disk windows95b.img file wherever you originally saved it - MD5 db6dd6a1e541287eac9ef9d214633b1b / SHA-1 1312b0c12287092aa930cb2437ad599722162b38

This file is the culmination of the input from all three of us.

Like userfile http://tasvideos.org/userfiles/info/46055922858869420 this file completes roughly the first level of each game but represents a resync attempt.

In 2016 at a time when GDQ prep was not insane and before my life was as chaotic as it is now, I started a silent project I told no one about. This file works in both 3-D Battles of WorldRunner 1 as well as 3-D Battles of WorldRunner 2 (ignore the checksum error on the second game). This aims to complete the game as fast as possible with an emphasis on entertainment. I'm posting this WIP now now to show what else is possible. This WIP stops around the end of the first level(s).

This is a script from quite some time ago that seems to now be broken.

This file shows the SMB3 battle mode in memory order.

octfac51.zip is still around courtesy of http://www.doomworld.com/mellow/bots.shtml on his https://www.doomworld.com/3ddownloads/mellow/ page.

Run with doombot using the following arguments:

-deathmatch -warp 1 -skill 5 -ctf -file ikbastex.wad octf.wad -nodes octf.nod +teamplay 1 -playdemo octfac51 +exec ctfteam.cfg %1 %2 %3 %4 %5 %6 %7

Now, this is so archaic that it would be a miracle if anyone managed to get it to work and it probably isn't worth it but I didn't want to lose this. Enjoy, if you dare!

This script requires a custom build of jpc-rr to properly connect the controller to mouse input and also shows important information on the screen.

This is pretty evil; I'm uploading with the wrong gametype to get past the not-yet-complete lsmv file check. To play this movie in an appropriate lsnes emulator with an SGB core, open the .lsmv file, edit gametype, and add the word gambatte_ at the front, to change "sgb_ntsc" to "gambatte_sgb_ntsc".

This is the final Pokemon Red movie file that was presented at AGDQ 2015. This version includes the full Twitch chat payload as well as other content that is accessible when specific buttons are sent after the payload has completed.

Or rather, this *would* be that movie, but it's in such a strange format because of the use of SGB that it can't be uploaded here, so I've uploaded the actual movie file to:

http://acbit.net/static/tas/p4test31.lsmv

(Yes, it took 31 tests before we reached the final payload, but that's 31 tests *after* we got the exploit working.)

This is the result of work from scahfy and Weregoose to create the game using a much more efficient method followed by my attempts to TAS it. My biggest concern is that this may not be enough of a difference to be publishable. This version of Snake does not place food pieces inside of the snake which means the position of the snake's body can be used to somewhat manipulate where food will appear (although much less so in the early game). This version also re-seeds the RNG at the segment drawing edge if a direction is pressed (other than back in the direction the snake is coming from). The effect is that you can press a button once per segment redraw and re-seed the RNG, but this makes things go slower because it takes more frames to re-seed the RNG.

Ultimately, if there's no piece nearby you can reposition yourself (very ineffective in the early game it would appear) or you can make yourself go slower in the hopes that you can make food appear closer to you. The catch is this method effectively has as many opportunities to manipulate the RNG as there are segments left to draw. This leads to an annoying catch-22 - you can manipulate a new piece of food next to you but if you do that, say, two spaces away from you you now only have two opportunities to manipulate a good position on the next apple that appears.

At any rate, I'd like feedback on whether this is worth continuing. My best estimate is that this will clock in at a good 12 minutes or longer.

This movie file demonstrates a hardest-possible scenario in the game Blockout and demonstrates clearing a 5x5x5 pit on the highest difficulty.

There were requests to do some taunting, so I did a taunt at the end of the Akuma battle and figured out a way to save a couple of frames in the process.

Is there any value in continuing? Despite the low rerecord count this has been about 6 hours of work, mostly deducing how evil the RNG in this game is. It turns out that the colors you will get next can only be affected by two things - the frame on which the level is started (either the frame you press start on the beginning menu or the frame on which the previous level was completed) and "missed" shot colors during the level, i.e. ones that don't touch the correct color. No other waiting or button mashing will have any impact on the RNG. This results in odd pauses prior to starting the level and intentionally firing at the wrong color, not to mention the very tedious process of testing entire levels with multiple starting states to see if future luck will be worth early bad looking results.

I've completed two levels but I'm not sure if it's worth continuing as I suspect this would be quite tedious for very little benefit. Thoughts?

The file I used in my Crazy Climber submission was unintentionally longer; I apparently botched it when I saved the movie, even though I thought I had truncated the movie to the last frame. This file now ends as soon as the arm is extended *just* far enough to reach the helicopter.

This lsnes + Gambatte movie starts Pokemon Red with an existing (corrupted) GB SRAM state that contains the player character RED, the rival name xAxA(Pk), and FF in *just* the right place to allow further exploitation. This movie file uses input suggested by Masterjun based on FractalFusion's work to execute arbitrary code, which it does very well. One minor caveat: I've discovered with help from Ilari and padz that D+U and L+R (representing bit values 128, 64, 32, and 16 respectively) are canceled out by the SGB BIOS meaning FractalFusion's payload can't be written as it contains the value 0xD3. This movie file contains a bunch of input at the end that softlocks the game in an interesting way but doesn't yet do exactly what we want it to. Still, it shows arbitrary code execution on Pokemon Red, which is good.

Because support for this filetype hasn't been added yet I've used a dummy file in this WIP (and, um, I'd ignore it if I were you, but that's just me. :) I've uploaded the real movie file to:

This lsnes + Gambatte movie starts Pokemon Red, names the player character RED, and names the rival xAxA(Pk). After getting into the game, it resets and should be truncated on the frame the reset occurs. This will allow for later hardware reset testing at movie end. I do not know if support for this filetype has been added yet so I've used a dummy file in this WIP (and, um, I'd ignore it if I were you, but that's just me. :) I've uploaded the real movie file to:

IMPORTANT NOTE: the file that is uploaded here is the wrong file and is simply a placeholder (because the parser does not understand the as-of-yet unreleased Gambatte core). The correct file can be found at:

http://acbit.net/static/tas/PokemonRedSGBdwangoACnewGambatteCore.lsmv

This is a comparison movie that completes Pokemon Red up to identifying the trainer ID using the new Gambatte SGB core in lsnes. I tried to always do everything on the very first frame possible. As was somewhat expected, this move does not synchronize on real hardware without some twiddling because the core or the process of handoff from SNES to SGB is somewhat inaccurate (by about 1 frame). Raw data dump from my testing sequence:

There's exactly 1 frame off at the beginning of the movie (i.e. I had to add 1 frame in order to allow the start button press to be recognized when playing back the dumped run on real hardware). The base movie trainer ID is 25143 per emulator; adding 1 frame before first button press causes the emulator to desync, manually playing through anyway changes trainer ID to 40964. I got it to sync further on real console by adding one frame at the very start and adding another immediately after acknowledging the grandson's name; that allowed the real console to sync until meeting Prof. Oak, late enough that the Trainer ID should have already been decided. I played through the rest manually and got trainer ID 18765.

Late in my testing, I replayed the exact same file I had tested before and for whatever reason the timing is was wrong at the very beginning. I'm not sure if I mangled the .r16m replay file somehow or if there is other saved data impacting the real hardware startup - if it's the latter it is far more concerning. Additional testing is required.

(Again, the file in this upload is the wrong one, please download the correct file from http://acbit.net/static/tas/PokemonRedSGBdwangoACnewGambatteCore.lsmv instead.)

This is a comparison movie that completes Pokemon Red up to identifying the trainer ID using the original SGB core in lsnes. I tried to always do everything on the very first frame possible. As expected, this move does not synchronize on real hardware because the core is not very accurate (likely 14 lag frames would be needed at the beginning based on past experience). I'll be doing this again on the new Gambatte core implemented by Ilari to compare the differences (loosely - I didn't actually intend to make this movie, all of this work was supposed to have happened on the new core).

This is an instance of Pokemon Yellow for SGB for use with lsnes for console verification. This is supposed to get to the point of asking if you want to save the game (but doesn't hit yes). Initial console verification tests show that this is not console sync-stable, likely due to emulator inaccuracies in lsnes.

Commodore 64 submissions are not yet accepted, so I'm uploading the actual submission to movie storage.

I'm very pleased with how this is turning out - this is a far better port than I initially gave it credit for. It's a bit odd working with this because the player sprite is drawn on one frame and then all of the enemies are drawn on the other. On a CRT I imagine the flickering wouldn't be as bad but it's a bit disconcerting trying to TAS this when you can't see yourself literally half the time. Having said that, I am extremely impressed what they accomplished on such a limited platform.

Addresses for this game (should be up shortly): https://tasvideos.org/UserFiles/Info/637936906484319946

I admit, this was surprisingly more entertaining than I expected. Very short WIP, just for the heck of it.

A.C.
******