TASVideos

Posted: 1/22/2017 9:21 PM

Quote

Alyosha

He/Him

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

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

Thanks to True's testing I now have some real leads on things that need investigating. Mega Man 5 and 6 are the most promising to sync, I'll try to get longer runs of those maybe even beat the game. Mega Man 4 is pretty random but synced once, so maybe some potential there. Battletoads performed weirdly, I still think it should sync but will hold off on that one for now. Streemerz gave some very real data points to look at. Comparing the VODs of True's stream to BizHawk shows some visible differences that I hope will lead me to some new directions. This should be a much better approach then the random guessing I was doing with Kirby, so I'm optimistic.

Posted: 1/21/2017 3:23 PM

Quote

Alyosha

He/Him

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

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

that's crazy 8D Can't wait to see what people will do with this.

Posted: 1/21/2017 3:17 PM

Quote

Alyosha

He/Him

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

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

I'm not sure what you mean by several times in a row. I tried it on the first elevator but couldn't drive 00E4 to zero in that area so it didn't work.

Posted: 1/21/2017 2:31 AM

Quote

Alyosha

He/Him

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

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

This glitch is caused by a certain coincidence of events that cause a skip of the check that triggers the elevator. The check is $00FC==0, which seems to be related to the automatic screen scroll in that area. When the glitch happens, the trigger condition is not checked, but in an oversight the value is still incremented to its next value ($EF) So the game thinks your moving on to the next area even though it didn't trigger the elevator. Several things need to be in place for this to happen. $05B8 needs to be $84, I'm not sure what this is exactly but it seems to always have this value in this area. You need to shooting fire and have it collide with an enemy on the frame 00FC goes to zero. I'm not sure if this needs to be the turret or not. $00E4 needs to be 0. This seems to be the key to the 'randomness' of this glitch. I don't know what this value is tracking or why it changes, but if you can figure out what this value is you can understand how to trigger this glitch. So basically, the glitch occurs on only one frame, and that frame is consistent, it is when 00FC is 0. So for the sake of RTA there should be some kind of potential setup for for at least that much (since its related to screen scroll, maybe a visual queue.) However, this requires that 00E4 is also 0, and it is currently not known what it does.

Posted: 1/20/2017 12:58 PM

Quote

Alyosha

He/Him

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

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

Koh1fds wrote:

There is no hope of getting nes overclocking in NESHawk by extra scanlines?

Maybe sometime in the future, but it's not high on my priority list right now, sorry.

Posted: 1/19/2017 3:39 AM

Quote

Alyosha

He/Him

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

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

^for now I will not be considering runs that use reset or turn on the DMC channel, so everything will be from power on and number of controllers won't matter (except obviously for 2 player runs) But yeah for clarity I will add that info for each run I plan on starting with easy runs like Streemerz as kind of general tests that don't do anything too crazy, then move on to others as I become more confident in the basics of the emulator.

Posted: 1/19/2017 2:11 AM
(Edited: 1/31/2022 3:19 AM)

Quote

Alyosha

He/Him

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

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

I want to start focusing more heavily on console verification efforts for the NES. I want to do this in a more structured way, so I'll be using this thread and this first post to keep things organized. If anyone has anything they want to add or suggest, feel free to post. Status: Power up timing verified to a high degree of confidence, many timing sensitive games now sync to console. DMC timing verified with new tests. DMC sensitive games now work on console. Runs with resets are the biggest remaining open cases, but no way to test (for me.) Testing: Nothing. Current Test Runs: None presently. No runs are currently known to desync due to emulation errors, but also few runs sync on current builds. Testing can continue as new runs are made.

Posted: 1/18/2017 1:13 PM

Quote

Alyosha

He/Him

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

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

Yeah I think this discussion can be moved to the NESHawk thread, I'm not making any forward progress. This run requires too many things to be prefect that aren't even fully understood yet. It's like the last boss of NES console verifications. I need to come up with a more structured approach to this.

Posted: 1/18/2017 4:31 AM

Quote

Alyosha

He/Him

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

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

Pretty cool project, and not bad for only 12 hours of work. Enormous project for a single person to be undertaking, good luck!

Posted: 1/18/2017 4:28 AM

Quote

Alyosha

He/Him

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

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

This is looking very similar to that Contra level end glitch from a while ago. It could just be a very fortuitous hardware error. Might want to keep this in mind before dumping too many hours into trying to reproduce it.

Posted: 1/16/2017 2:24 PM

Quote

Alyosha

He/Him

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

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

^ oh cool thanks! @True: I can pretty easily get the desync at the slide now, it came down to resetting CPU cycles after the reset to fix the even/odd cycle timing. But then there is another desync at the 'A' press at frame 1428 that is still not resolved, so research continues. I might try making a run that does not have a reset in it just to minimize the number of variables for now.

Posted: 1/15/2017 9:22 PM

Quote

Alyosha

He/Him

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

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

@True: the desyncs at the start menu are probably due to the reset, how does your bot handle that? Desyncing in the first room is interesting, I'll have to look into that. Is that desync consistent?

TASeditor wrote:

I got the run to sync but it had overall 9 frames of delay.

@TASeditor: do you have the file that syncs? Isn't 9 frames longer then the original run? 0_0 Strange. EDIT: Here's a straight resync of the most recent file on BizHawk, it does not get past the middle of the second screen. Should work with one controller and DMC glitches on (although glitches off resulted in the same behaviour.) If this run also desyncs in the first room that will at least be something to study. http://tasvideos.org/userfiles/info/36369751744442141

Posted: 1/15/2017 8:55 PM

Quote

Alyosha

He/Him

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

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

dwangoAC wrote:

arstechnica.com/gaming/2017/01/how-a-robot-got-super-mario-64-and-portal-running-on-an-snes/#p3 has full details. Please let me know what you think.

Good article with clear explanations. I also really liked the pictures they had of the TASBot set up. Really good summary of everything with background links to boot, nice! This reminds me, are the details of what was happening going to be published somewhere? It would be cool if all the programs and whatever used were preserved and documented so it isn't lost.

Posted: 1/15/2017 8:51 PM

Post subject: Re: Update to submission file

Quote

Alyosha

He/Him

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

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

True wrote:

If it is an FM2 it will surely desync. I'll run it as-is. I still need to know how many controllers should be connected for these runs. I'll also try running one you posted previously. Running in about an hour.

Yeah it will surely desync, but my hope is that it will be in the same way as on BizHawk. I just can't think of any ways to glean more information. Any ideas? Yeah the FCEUX run should be 1 player and preferrably DMC glitch disabled since that's how FCEUX works. The run I made was 2 players but coincidently I had DMC glitch disabled on player 2 at the time so that one can be run with 1 player DMC glitch on. I very much doubt it will sync but it's worth a try i guess.

Posted: 1/15/2017 2:15 AM

Quote

Alyosha

He/Him

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

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

Voting for Mario Kart, easily my favorite TAS and a real masterpiece!

Posted: 1/15/2017 2:12 AM

Post subject: Re: Update to submission file

Quote

Alyosha

He/Him

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

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

TASeditor wrote:

Please update the submission with this 8 frame faster run: User movie #36341054517440931 I couldn't get it to a glitched ending, so those who wanted a clean ending are lucky.

I couldn't get this version to sync on BizHawk. It makes it about half way through the second room. I also tried a build without glitch reads and got the same results. @True: Maybe this would be a good one for console testing? It might give more information then simply failing on the glitch like the other runs.

Posted: 1/15/2017 12:36 AM

Quote

Alyosha

He/Him

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

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

Nice work Dwango & Co! I liked the Gradius revenge on the mini nes, that was a really cool way to wrap up a loose end from before. Personally I think it would have been better to run the Portal TAS seperately so it had time for more exposition. The whole AV Skhype thing was a cool tech demo but didn't offer much entertainment value in my opinion. Also it seems like each AGDQ TASBlock relies more and more on behind the scenes computing and less focus on the consoles/games. It was even mentioned this time how latches in the NES were removed (somehow) to cram more data into it. Personally I prefer to see the consoles used as video game consoles and not so much as a data dump for whatever a behind the scenes computer is doing. Still though very impressive stuff as always!

Posted: 1/12/2017 4:14 PM

Quote

Alyosha

He/Him

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

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

One other interesting fact about Kirby's Adventure is that not only does it always poll controller 2, but it will also attempt to correct it for DMC gltich reads even though it's never used. This matters here because it means there will be cycle timing changes due to running the extra code. However this is only true if the controller is plugged in, since unplugged controller reads will just return zero even in glitched reads and thus will not result in an error. So in this particular instance you can get different results just by having player 2 controller plugged in, even if no buttons are ever pressed. Strange stuff! (You can test this in the most recent Dev Build of BizHawk, since I forgot to apply the glitch to player 2 previously.)

Posted: 1/11/2017 11:28 PM

Quote

Alyosha

He/Him

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

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

TASeditor wrote:

Room 1 is now 5 frames faster: User movie #36277810643532219

Cool nice find!

jlun2 wrote:

I have no idea what DMC timer means, but would it be possible to set this to some known, "legit" value to make things consistent on console?

The DMC timer ticks whenver the APU ticks, regardless of the state of the CPU or PPU or anyhting else (basically whenever power is supplied to the console.) There is no way to access the timer, it just reloads from the rate table whenever it hits zero. So assuming it isn't reset when powering on the console, there really isn't a way to manipulate it. Conceivably, you could contrive a ROM to output glitched controller reads at a fixed rate, and make a bot recognize the glitch read and kill power to the console, thereby leaving the timer at a known value and hope it doesn't decay the next time you power on the console. This is all speculative though and needs a lot of research.

Posted: 1/10/2017 8:30 PM

Post subject: Non-Standard Controllers and Console Verification (NES)

Quote

Alyosha

He/Him

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

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

As pointed out by Dwedit, DMC start up state for NES seems inconsistent, assuming this is true, it has serious impact for console verification of games using DMC channel. Basically games would be split into 3 categories: 1. Games that don't use DMC channel, seems like they should in principal be console verifiable, Battletoads for example needs subcycle accuracy and a two player run was recently verified by True. 2. Games that use the DMC channel but don't need cycle accuracy to verify, assuming glitched controller reads are ignored. Ninja Gaiden falls into this category as well as cretain runs of SMB3. 3. Games that use the DMC channel and do require cycle accurate timing. Kirby's Adventure glitched is in this category. Category 3 games probably are not verifiable, but my question here is about games of Category 2. Ninja Gaiden was verified assuming no glitched controller reads, this implies a non-standard controller, one that essentially ignores latches that are too close together. FCEUX does this implicitly, but NESHawk currently does not. This is more accuracte, but assumes a fixed DMC start up state, which would certainly kill any attempts at console verification assuming it is inconsistent. So I am wondering, for the sake of getting as close as practical to console verifications, should an option be added in NESHawk to turn off DMC glitched controller reads for submitted TASes? I'm interested what people's opinions are on this. It's basically a trade off between having more console verifiability but using non-authentic controllers.

Posted: 1/10/2017 8:11 PM

Quote

Alyosha

He/Him

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

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

Dwedit wrote:

I don't think DMC channel state at bootup is consistent. Try playing Blades of Steel, and see how the demo changes every time you play it.

I tested it for a bit using different DMC timer start states, and it looks like you are probably correct. That sucks :( I thought we had a good chance of console verifying this run, but if that is true it seems unlikely.

Posted: 1/10/2017 3:47 PM

Quote

Alyosha

He/Him

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

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

Since things here are dependent on true cycle accuracy, you might want to wait until some console testing can be done to finalize DCM timer startup before trying to make a final run. Right now I found 2 places in the run where a DCM read occurs that would effect the final cycle timing at the glitch. Unfortunately these instances may change with more accurate knowledge of DCM startup state (a process which was started with Ninja Gaiden but never finished.) You might also be able to use this to your advantage if you can purposely trigger a DCM glitch and cause a re-read to eat up some cycles. Unfortunately there just isn't a way to nail down DCM startup state without some more testing.

Posted: 1/9/2017 8:09 PM

Quote

Alyosha

He/Him

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

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

I notice sometimes I get differences in TAStudio as well, but they always seem to go away and I can't recreate them with any consistency. One frame away now: http://tasvideos.org/userfiles/info/36235074406613720

Posted: 1/9/2017 2:41 PM

Quote

Alyosha

He/Him

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

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

http://tasvideos.org/userfiles/info/36229935354105129 Here's a version that is only 2 frames too long but has correct credits and only 1 player input. maybe it's possible to get those 2 frames back with enough guess and check.

Masterjun wrote:

This seems like the usual case of not logging what actually happens. ... The location being executed seems to be the huge chunk of mirrors of the 8 bytes PPU registers. And reading PPU registers not meant to be read results in open bus behavior, which would explain the strange logging (and execution, for that matter).

A bug in the logging makes sense, but also makes it very hard to tell what's going wrong. There are other spots where only one instruction is read from PPU registers and those spots differ as well I noticed, so there are too many discrepencies to sort out unfortunately. I think console testing is required.

Posted: 1/9/2017 12:09 AM

Quote

Alyosha

He/Him

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

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

feos wrote:

Alyosha, there were posts by true back when some of the recent glitched Kirbys was published, look those up.

Yeah I'm getting the same thing he describes, frozen grey screen with different sprites and a constant tone.

Fog wrote:

The current any% WR: https://www.speedrun.com/run/pydwx4vm

Hmmm that looks quite a bit different then the exeution in the TAS, I will try to reproduce it in BizHawk. EDIT: Here is a test run in NESHawk that executes the credits. I didn't in any way try to optimize it all I did was recreate what I saw in the video Fog posted. http://tasvideos.org/userfiles/info/36216983802179878 I am pretty confident in saying that FCEUX is not emulating this correctly. I looked through the 6502 source code for it and undocumented ops are not well emulated to say the least. This combined with True's console tests before and I would say that this run should really be done on BizHawk.

Posts for Alyosha