TASVideos

Posted: 4/5/2016 2:37 AM

Quote

Alyosha

He/Him

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

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

wow great work feos! I honestly didn't think that level was improvable, good to be proven wrong.

Posted: 4/5/2016 2:28 AM

Quote

Alyosha

He/Him

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

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

Well I have a possible solution that correctly displays cosmic Ark stars. The problem was that the TIA code was looping the _Hmove counter instead of just resetting it after it reached 15. The effect of this is that the latch that normally would never would be cleared would just be cleared on the next pass of the counter. This prevented the stars from forming. This 'fix' breaks DK JR though (well, in a different way) so I'll be consulting with micro500 to work out what's happening. I'm pretty sure the overall idea is correct though. Here is a brief video though: Link to video Perhaps we are close to getting the star effect in a real non-hackish way! EDIT: found the bug the messes up DK JR

if (_hmove.HMoveDelayCnt < 6)
				{
					_hmove.HMoveDelayCnt++;
				}

				if (_hmove.HMoveDelayCnt == 6)
				{
					_hmove.HMoveDelayCnt++;
					_hmove.HMoveCnt = 0;
					_hmove.DecCntEnabled = true;

Those 6's should be 5's. This 1 extra clock delay is what's breaking DK JR. The stars still don't display exactly as expected so more research is needed there, but things seem to be shaping up. EDIT2: I forked all my changes into github here: https://github.com/alyosha-tas/BizHawk This contains the fixes for pterry, the ENAM fix, the starfield, DK jr fix, 3-2-1 fix.

Posted: 4/3/2016 10:05 PM

Quote

Alyosha

He/Him

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

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

So I happened across an emulator bug that might hopefully also shed light on Cosmic Arc stars and properly emulating quirky HMove instructions. I was browsing other Atari 2600 games that were known to behave badly in BizHawk looking at the list here. I looked at Donkey Kong Jr since it had some weird gameplay bug listed as the error. The picture below is 4 consecutive movement frames. On frame 3 you can see quite clearly that DK gets pushed to the left rather far before snapping back to the right the next time.

What's happening here is (I think) related to the warning not to change HMove registers until 24 CPU cycles after HMove is executed, here is the relevant code:

D2F1  8D STA $0010         A:71     4 
D2F4  85 STA $20           A:71     3     HMP0 
D2F6  85 STA $02           A:71     3     WSYNC 
D2F8  85 STA $2A           A:71     3     HMOVE 
D2FA  A5 LDA $E4           A:71     3 
D2FC  18 CLC               A:00     2 
D2FD  65 ADC $AF           A:00     3 
D2FF  85 STA $DC           A:90     3 
D301  A5 LDA $C5           A:90     3 
D303  85 STA $DE           A:18     3 
D305  A9 LDA #$00          A:18     2 
D307  85 STA $20           A:00     3     HMP0 
D309  A5 LDA $BF           A:00     3
D30B  85 STA $02           A:44     3

So what we have is an HMove immediately following a WSYNC, this is the expected behavior, but then we have only 22 cycles in between that and the following HMP0 instead of the expected 24. Quoting hardware notes we have:

In theory then the side effects of modifying the HMxx registers during HMOVE should be quite straight-forward. If the internal counter has not yet reached the value in HMxx, a new value greater than this (in 0-15 terms) will work normally. Conversely, if the counter has already reached the value in HMxx, new values will have no effect because the latch will have been cleared. Much more interesting is this: if the counter has not yet reached the value in HMxx (or has reached it but not yet commited the comparison) and a value with at least one bit in common with all remaining internal counter states is written (zeros or ones), the stopping condition will never be reached and the object will be moved a full 15 pixels left. In addition to this, the HMOVE will complete without clearing the "more movement required" latch, and so will continue to send an additional clock signal every 4 CLK (during visible and non-visible parts of the scanline) until another HMOVE operation clears the latch. The HMCLR command does not reset these latches.

This shove to the left only happens here when HMP0 is 7, the same code is obviously running constantly but only this value makes the big shove to the left happen. Stella seems to cheat in this case and instantly applies the HMOVE and ignores how long actual execution should take. This shove to the left doesn't happen on console (and makes the game unwinnable in BizHawk) so sorting this out seems like a good step in understanding this HMove stuff. Either that or it's a simple bug that I just can't see yet.

Posted: 4/3/2016 2:55 PM

Quote

Alyosha

He/Him

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

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

CoolKirby wrote:

I can confirm that the double sized player bug did not affect the sync of the published E.T.: The Extra-Terrestrial run. (The run does not sync on BizHawk 1.7.0 or later as it is though.) I want to say thank you for fixing all those tough bugs - I was thinking of running Halo 2600 several months ago and now it should finally be possible. Will your fixes be implemented into the next BizHawk?

Not sure, once micro500 or some other knowledgeable person confirms these findings are correct, it's easy to fix a few of the bugs just by changing some constants. The latch delay type bugs are more difficult though will probably take some time to sort everything out. Halo 2600 should work with the easy fixes though. Yeah any run like E.T. made before the switch to fixed length frames / inputs will be difficult to reconcile with any new runs made. I thought about making some test runs but currently don't have the time.

Posted: 4/1/2016 7:36 PM

Quote

Alyosha

He/Him

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

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

Looking good feos, you're almost there now!

Posted: 4/1/2016 7:34 PM

Quote

Alyosha

He/Him

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

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

While I'm not an expert, I don't think Mari/o is strong enough to do anything serious like that. It's fine for a sandbox model but you won't get anything particularly impressive out of it for complex games like SMW. If I were to offer a suggestion that would both seem doable and be impressive, I would suggest SNES Star Fox. The existing run is woefully obsolete just by nature of the emulator used, and the gameplay lends itself more to the Mari/o methodology. However this would require a great deal of research, I guess it depends how much effort you want to put into it.

Posted: 4/1/2016 7:28 PM

Quote

Alyosha

He/Him

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

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

Wow nice work Tompa! I hope this gets a console verification, that would be very exciting!

Posted: 3/17/2016 12:44 AM

Quote

Alyosha

He/Him

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

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

feos wrote:

http://tasvideos.org/userfiles/info/29595151998473782 Are you sure you're leaving?

Yeah sorry but I won't be able to commit to finishing this for at least the next several months. Normally I hate leaving things open ended so I at least wanted to have that complete WIP out, but beyond that it's up to you! (and possibly Samsara!) Good Luck!

Posted: 3/16/2016 3:30 PM

Quote

Alyosha

He/Him

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

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

http://tasvideos.org/userfiles/info/29591466236789461 Well it seems I've run a bit short on time so won't be able to commit much more to this. I've created this run that goes to the end of the game (and saves 30 frames on the boss.) Level 10 and 11 were pretty trivial from TAS perspective so nothing really changed there. Terra Tubes seems pretty well optimized since I couldn't do anything about checkpoints in my testing. The final level seemed really well optimized too so I just synced it up. @feos: if you plan on working with that trick you found feel free to use this file. If you think it will take too long I might just submit this one by week's end and leave it for future improvements (perhaps including it on the next iteration of the run with a goal to sync on console.)

Posted: 3/15/2016 8:05 PM

Quote

Alyosha

He/Him

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

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

Wow you're right! Definitely something that needs further investigation. EDIT: so far level 3 and 4 have easy improvements related to this trick. Looks like some back tracking needs to be done. This is quite a strange and random trick, I might try putting this in BizHawk and confirming it works the same.

Posted: 3/14/2016 10:05 PM

Quote

Alyosha

He/Him

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

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

http://tasvideos.org/userfiles/info/29553178600016834 Alright, so I saved another ~20 frames on the snakes, cleaned up the jets level, and implemented the jump through the current improvements in the tower (as well as fixed the boss fight.) Overall saved about another second. I think we're ready to start investigating Terra Tubes! For starters I looked at the fish knocking you into the exit thing, and it seems the exit won't spawn until after the helicopters have already spawned. After that the fish would need to hit you into the spikes to get you through the wall and down into the exit, but this would require scrolling back down a significant ways and probably wouldn't save time since you just fall down anyway.

Posted: 3/14/2016 4:39 PM

Quote

Alyosha

He/Him

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

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

Nice run. I played this when I was little and remember being tricked by those cats that hide behind the items, but it was pretty fun for a simple and kind of silly game. Oh one interesting thing I found out while looking at the code of this one is that the score is actually stored in Decimal and goes up to 99 milliom before rolling over, so anyone wanting to make a max score run would be playing for quite a while!

Posted: 3/13/2016 11:18 PM

Quote

Alyosha

He/Him

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

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

No worries : ) TAS is just a hobby after all so shouldn't be all consuming. Looks like Combatribes escapes yet again! That is a tough one to capture!

Posted: 3/13/2016 11:15 PM

Quote

Alyosha

He/Him

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

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

I have finally found where the desync happens. Turns out it is very similar in nature to the title screen bug. What is happening is that the write to Enable Missile for Player 1 (ENAM1) is happening on the same pixel as it is supposed to be drawn. In BizHawk, we get an immediate draw, but in Stella we get a one pixel delay in registering the write. In this case the one pixel delay causes the collision with Pterry 1 frame earlier (since the effect is shifting the missile down one scanline) and this is where the desync happens. I implemented the delay and indeed lost in BizHawk in exactly the same manner as in Stella, 8-10 For this case I couldn't find any documentation I could quote, so micro500 will need to weigh in here, but this is the cause and effect anyway.

Posted: 3/13/2016 11:17 AM

Quote

Alyosha

He/Him

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

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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 (3536)

Joined: 11/30/2014
Posts: 2733
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.

Posts for Alyosha