TASVideos

Posted: 3/13/2016 11:17 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Awww, I was really hoping that 5.51 would work too, back to the drawing board I guess. Yeah the exploding car fix should work perfectly. Just change the 3-2-1 in that bit of code to be zeroes, oh and remember to do it for both players.

Posted: 3/13/2016 1:36 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

So far neither the 6532 timing bug nor the RESP bug have solved the sync problem with this game. I am at least fairly confident that I am recreating the run correctly in Stella, simply by running each input for 262 scanlines and letting it go from there. The run desyncs around frame 956, where the collision with Pterry happens 1 frame earlier in BizHawk then in Stella. I thought the 6532 timing bug fix would resolve this but it happens the same way. The RESP bug has no effect since no collisions occur in that region of the screen between Pterry and the ball (close to the left edge.) I do end up losing in Stella, so just like for the last run this is a rather consequential desync. I'm still looking into it though.

Posted: 3/13/2016 1:15 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

I believe ptrerry's random pixel shifts are caused by a bug in RESP. I followed the game code and it turns out Pterry's buggy movements happen right when the RESP function changes from happening 'on screen' to happening in the HBlank region. Looking over BizHawk, it seems the variable at play is:

if (_hsyncCnt < 69)
				{
					_player1.HPosCnt = 0;
					_player1.ResetCnt = 0;
					_player1.Reset = true;
				}

Setting _player1.ResetCnt = 2 instead fixes the problem. (needs to happen for player 0 too of course)

Writing any value to these addresses sets the associated objects horizontal position equal to the current position of the cathode ray beam, if the write takes place anywhere within horizontal blanking then the position is set to the left edge of the screen (plus a few pixels towards right: 3 pixels for P0/P1...

So when it started at 0 the loop in the TIA that reset the player put it 2 pixels too high, since it counts from 0 to 4. I'm not 100% sure this fix is correct, but it makes the game behave as it does in Stella, so I'm at least somewhat confident it is.

Posted: 3/11/2016 3:58 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

micro500 wrote:

After looking over the 6532 datasheet it looks like you are correct that there is an off by one bug in that code. Your change looks like the right way to fix it, so I went ahead and committed it.

Great! Any ideas on the other bug with Pterry? I have no leads and no ideas. But on the up side, I just tested the timing fix in Dragster and it with it you can change gears earlier! You can start at frame 164 instead of 167, and from my previous testing this should be enough to improve the time. Maybe that riddle might be close to being solved! EDIT: Oh yeah, the timer is also set at the top of the interval at initialization too. In Stella it is set at the bottom. I am not sure if there is a correct setting or if this is undefined, just thought I'd mention it.

Posted: 3/11/2016 3:31 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

So I think I found where the timing bug is that causes random lag frames. From this document we get:

Normal Timer Decrement The timer is decremented once immediately after writing (ie. value 00h does immediately underflow). It is then decremented once every N clock cycle interval (depending on the port address used).

This is what Stella does as well, but in BizHawk's 6532 we have:

// Write to Timer/64
Timer.PrescalerShift = 6;
Timer.Value = value;
Timer.PrescalerCount = 1 << Timer.PrescalerShift;
Timer.InterruptFlag = false;

So what it does is write the new value but sets the interval timer already at the top of the interval. So basically this gives 1 extra Tick every time there is a write to the clock. This happens once per frame, and this interval is one scanline, so naturally after every 262 of those we see the timing error. I am pretty sure the fix is to just put: Timer.PrescalerCount = 0, which will immediately decrement it as spec'd. I did so, and indeed the random lag frames vanished, hurray! But, this STILL didn't fix Pterry's buggy behavior, and I am at a loss as to how to fix it or where the bug is.

Posted: 3/10/2016 11:30 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

http://tasvideos.org/userfiles/info/29465684669371662 Somehow the rest of the run syncs pretty smoothly so I thought I'd resync it as far as I could, which right now is about 1/3 of the way through the last level. This is great luck since I had trouble even syncing level 2 when I first started working on this. So as earlier levels are finalized this head start should make the remainder a lot quicker.

Posted: 3/10/2016 8:52 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Sometimes the best test is simply to do nothing! I loaded up FlapPing and just let it run. Then I noticed there were some strange lag frames every so often on the title screen. They occur at frame: 64, 327, 590, 853, 1116, .... The important point is that they are all separated by 263. This is an important clue since the number of scanlines in a nominal frame is 262. So my theory here is that there must be an off-by-one error happening somewhere in the code. I don't know where or why, but this seems like a pretty solid lead.

Posted: 3/10/2016 3:24 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

SaxxonPike wrote:

Excellent work :)

Thanks! Okay, so Pterry's strange behavior in Flapping is being caused by some type of strange timing bug. The short version of what's happening is that the address tracking Pterry's position that should be changing every frame is being paused occasionally. On Pterry's first loop going left, it pauses at 0x25. So Pterry takes 259 frames to make a complete loop in bizhawk but only 258 frames to make a complete loop in Stella. It doesn't consistently pause at this point, it seems to shift with each loop, but always happens once per loop. I tried looking at a trace log to find out what was going on but nothing shows up in the trace log that indicates a pause. I did see some strange trace log behavior though:

F902  85 STA $02           A:0A X:16 Y:FF P:94 SP:1D Cy:4444707 NBI
F903  02 ---               A:0A X:16 Y:FF P:94 SP:1D Cy:4444708 NBI
F904  A5 ---               A:0A X:16 Y:FF P:94 SP:1D Cy:4444709 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444710 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F904  A5 LDA $E1           A:0A X:16 Y:FF P:94 SP:1D Cy:4444711 NBI
F926  24 BIT $00           A:E0 X:16 Y:02 P:94 SP:1D Cy:4411201 NBI
F927  00 ---               A:E0 X:16 Y:02 P:94 SP:1D Cy:4411201 NBI
F928  EA ---               A:E0 X:16 Y:02 P:94 SP:1D Cy:4411202 NBI
F928  EA NOP               A:E0 X:16 Y:02 P:16 SP:1D Cy:4411203 BIZ
F929  EA ---               A:E0 X:16 Y:02 P:16 SP:1D Cy:4411204 BIZ

STA $02 is a WSYNC, so as expected the cpu gets paused at the LDA $E1. But then at the end of the WSYNC, the instruction address suddenly jumps to F926 and the cycle counter DECREASES by 33510 cycles. 4411204 is actually where the trace originally started. I think this is a new bug introduced into trace logger in this version since it doesn't happen on previous versions. At any rate it looks like it's just a trace logger bug not related to other core bugs. Previous versions (I tested on 1.11.1) still exhibit this timing bug so it wasn't a result of any of the recent patches. But I don't know what the origin of it is, quite a strange bug indeed. The only hint I have is that even though Pterry's position is paused in RAM, his position on screen is still changing.

Posted: 3/10/2016 3:50 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

So I made a build of atariHawk that removes the 3-2-1 code from AtariHawk. Curiously, this fixes the problems in Smurfs, Halo2600 and Dragster, but Pterry still exhibits the exact same buggy behavior. So there must be something else at work that is causing problems that I have not found yet. Another thing I noticed is that the ball's initial motion is different in Bizhawk previous versions of bihawk compared to 1.11.6 for this movie. 1.11.6 agrees with Stella, while older versions do not. However, older versions agree with the build I just made removing the bug. Very strange. My guess is that all of these are ultimately interconnected but I haven't tracked down how yet.

Posted: 3/9/2016 4:03 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Wow what a neat mystery! I'm always amazed by all the little quirks and riddles I've never heard of before. I hope you somehow get this figured out micro500, would be cool to see it emulated properly, even if the result is more complicated then the rest of the core!

Posted: 3/9/2016 2:55 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Well I don't know how I didn't notice this before while meticulously studying pterry's movement, but he quite clearly also suffers from the 3-2-1 bug. This bug is a piece of code originally borrowed form the Atari 7800 emulator which was meant to model some curious behavior in a couple 2600 games. However it seems the code itself was just a hack, it has no discernible benefit and breaks several games (i.e. Smurfs and Halo 2600) and has bad effects in others (Dragster.) In this case what it does is push pterry towards the right one pixel when he reaches the left edge of the screen. You can see this happen around frame 290 in this movie. This changes the timing of when pterry reaches which side of the screen. Since it happens every time pterry hits the left side of the screen, the effect is cumulative over the the course of the movie. It causes the run to desync with Stella around Pterry's third loop. This bug also effects the published runs of Airlock and Bobby is Going Home. I think emulation still needs to be improved a bit more before this run will be a realistic representation of what would happen on console.

Posted: 3/8/2016 2:11 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

So far I am unable to reproduce this result in Stella. It is difficult to reconcile the different frames timings between the two emulators, so it may not be possible. I suspect very strongly that BizHawk is incorrectly managing frames that are shorter then normal, although I can't follow the code well enough to point out where. But, at least now it isn't (aside from the title screen) blatantly wrong so maybe it's close enough, although my personal opinion would be that it isn't. As a side note, I have never won a game in Stella with no input, despite numerous attempts. Obviously this isn't proof of anything, just an observation.

Posted: 3/7/2016 11:43 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

@feos: what do you know about how the snakes work? It seems I am able to slightly change their length depending on how I scroll the screen. I saved 4 frames so far in this manner but am not entirely sure what mechanism is at work. See the second section here: ~~http://tasvideos.org/userfiles/info/29399306582151235~~ Oh good timing with more level 4 improvements too! EDIT: saved another 17 frames on level 4 with a better ice block throw. EDIT2: Here is a current file with all improvements and yet another 10 frames saved on snakes. http://tasvideos.org/userfiles/info/29401103848403536

Posted: 3/7/2016 7:06 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Wow you are on a roll feos! At this rate this run will come together really fast! http://tasvideos.org/userfiles/info/29394998935083011 Here is a first pass at level 7 (with all previous improvements included.) It is a bit faster then the original. It syncs up to the fireballs. Since they are RNG I guess it would make sense to finalize everything up to that point before having to redo them over and over as improvements are found. I'll also go back to snakes and try to throw in some attempt at entertainment. I guess there isn't that much to do but I'll give it a try.

Posted: 3/7/2016 3:37 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

apparently you can exit the surfboard without jumping after the first part of level 5. Saved about a dozen frames this way. http://tasvideos.org/userfiles/info/29391811010828289

Posted: 3/6/2016 7:36 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Oh, no worries these are all rough drafts, I always do things iteratively. I never try, or expect to have, anything optimized until after quite a few tries. Thanks for speeding up the process though : )

Posted: 3/6/2016 4:31 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Thanks feos! Yeah I couldn't boot blarg either, I tried for a while with those helmet things on the ground too. Not sure what you mean about the resource page, am I missing something? I use lots of different files and cut and paste between them all the time. I don't really care about rerecord count so I don't pay attention to it. So that is most likely why there is a discrepancy. Feel free to suggest whatever number you feel is appropriate though. http://tasvideos.org/userfiles/info/29370504072808374 Here is a file with all current improvements. I also did a rough draft of snakes. I also appended the inputs of the original run at the end. I usually have them there but at some point along the way they got removed. I like to have them to keep track of improvements easier. It also makes progress on rough drafts much much faster.

Posted: 3/3/2016 5:58 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

wow nice find! I had actually tried something similar but failed, glad you got it working. EDIT: seems like if you are on the left side of the wall you go down and when you are on the right side you go up. I haven't found a real use for the downward scrolling yet, but maybe it could come in handy who knows, this trick might have some more potential. http://tasvideos.org/userfiles/info/29332821195644672 Here is my most up to date file. It contains feos' new trick as well as other level 4 improvements. It also completes the first half of level 5, but so far there is nothing really new there.

Posted: 3/3/2016 3:42 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Thanks for your research efforts feos, it seems like the difficulty then is keeping going to the left while the scrolling is pushing you to the right, which I guess is why it seems so much easier in 2 player. For the time being I am doing a rough draft of level 5 assuming the clip will not be possible, but I do hope it will be!

Posted: 3/2/2016 12:42 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

^ oh, good question. There are 4 addresses associated with 'level' in this game. That is, they increment every time the next level is loaded. 058E 0689 068D 06E0 They seem to be interconnected to determine score, enemy behavior, and level layout, but basically you can set any or all to FF at the end of a level and they will roll over and the next level will start without issue. So while I don't know the exact behaviour of what happens if the game is legitimately played up to that point, there doesn't seem to be a kill screen.

Posted: 3/1/2016 10:30 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

oh, thanks for the feedback Brushy : ) I put your name in mainly because I didn't really change level 1 or 3, but if you want it removed that is fine too. Oh so prone enemies must just be rarer in earlier levels then. I remember seeing them while hacking around to different levels but didn't know what made them appear.

Posted: 2/29/2016 6:52 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

http://tasvideos.org/userfiles/info/29239365814639538 here it is, it is also my most optimized level 4 at this moment. Videos I see seem to be pretty easy to do with 2 players, but I haven't seen a one player version and I wonder if it is possible since the screen scrolls a bit differently with only 1 player.

Posted: 2/29/2016 1:12 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

@feos: do you know if the surf city skip is possible for one player? I am testing it out but can't seem to clip down and die.

Posted: 2/27/2016 2:40 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

^it wasn't hard to do so I just quickly TASed the route, it's easier to show: http://tasvideos.org/userfiles/info/29191056658029890 You can see that not only is it too slow but it also doesn't spawn the ice block or checkpoint. I think this is because we also need to pass through the hidden clear points in order too. The game spawns the snowmen from one level above. To pass that point I would need to go backwards which would make it even slower, so looks like this idea is a bust for now. But that second clip should be faster then that snowball clip in your GIF, so might still be a time saver in that one part.

Posted: 2/27/2016 1:35 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Well the easiest checkpoints to respawn are 2 and 6. 2 doesn't help that much since skipping 1 doesn't save enough time. But, Respawning 6 multiple times may be a time saver. My thought is that instead of doing checkpoints 1-2-3-4-5-6, we might be able to do 1-2-6-6-6-6. It takes ~400 frames to loop around repeatedly to respawn-reactivate. Currently it takes 1850 frames to go the current route to the point of the first loop. Skipping 3 checkpoints means we would use 1200 frames multi spawning checkpoint 6, leaving us only 650 frames to do all the clipping, which doesn't seem possible at the moment. But the loop can still be improved, in my testing so far I have gotten around 380 frames instead of 400, giving a whole extra second for the clipping. 6-6-6-6-6-6 may even be possible, it all depends how easy it is to clip down there. All of this needs testing.

Posts for Alyosha