TASVideos

Posted: 1/30/2017 7:32 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Ok, I tracked down the bug to right after the dialog box:

'This is a regular movie, a new project must be created from it, in order to use TAStudio. Proceed?'

After you click 'ok' this function is called (line 604 of TAStudio.cs):

ConvertCurrentMovieToTasproj();

here is that code:

private void ConvertCurrentMovieToTasproj()
		{
			Global.MovieSession.Movie.Save();
			Global.MovieSession.Movie = Global.MovieSession.Movie.ToTasMovie();
			Global.MovieSession.Movie.Save();
			Global.MovieSession.Movie.SwitchToRecord();
			Settings.RecentTas.Add(Global.MovieSession.Movie.Filename);
		}

Notice the 'SwitchToRecord' there. This is where the recording bug comes from I think. The exception comes from ToTasMovie(), from right here:

...
tas.TasStateManager.MountWriteAccess();
...

which contains:

States = new SortedList<int>(limit);

Thie erases state 0, which was already created at this point, and thereafter state 0 does not get reinitiialized, so the key 0 in the list will never exist. So when you hit '<<' and it tries to find States[0].state it doesn't exist (it doesn't show up as darker colored in the piano roll indicating a state is there) so naturally there is an error. This should definitely result in an error. @feos: can you see if you are ending up in the same code path? Or if you are somehow getting state 0 re-made somewhere after this point? EDIT: If I change 'SwitchToRecord()' to 'SwitchToPlay()' in the above then that is clears up the recording bug. Not sure what to run to fix the savestate bug.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/30/2017 4:41 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

oh, I forgot that deleting the config file defaults NES back to QuickNES. So that movie was converted with the QuickNES core. That movie is only compatible with QuickNES then. I guess TAStudio should also pick the correct nes core as well? Either way I get the same errors opening it in QuickNES.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/30/2017 3:33 AM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

http://tasvideos.org/userfiles/info/36685975026438434 feos I narrowed down what was causing the apparent 'recording mode' bug. I made this movie conversion from the original fm2 (after just deleting the config.ini) When I open the bk2 in TAStudio and hit play it overwrites the inputs as though its in recording mode. When I click the check box, it does not make a check mark appear, but after a second click a check mark does appear. Can you open that bk2 file and see if you get the same results? I also get the same exception as I mentioned before if I let this movie play a bit then hit the '<<' button.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/28/2017 11:23 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Really cool to see this run! Another long expected N64 game finally on the workbench, even if it's not quite emulated perfectly that's still progress at least. Voting yes! Are there techincal details about the Intro Story Glitch? I'd be interested in seeing exactly what went wrong.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/27/2017 11:36 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Koh1fds wrote:

I try everything (reloading the core, rebooting emulator). It doesn't work. I try old version (first one after you fix sound of fds). It doesn't work too.

This was an interesting bug. Should be fixed now. Please try Dev Build.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/27/2017 12:16 AM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Nach wrote:

What's going on with this run? Is there a particular file it should be replaced with? Are you guys still working on an improvement? Do you want to cancel this for now and come back in a couple of weeks when you figure it out?

I'm not actively working on it, other things need to be sorted out first. A correctly emulated run that works on console is not on the horizon. I think TASEditor wanted to use this file:

Please update the submission with this 8 frame faster run: User movie #36341054517440931

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/27/2017 12:01 AM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

^ seems to work with a clean config. My computer just seems to not play nicely with TAStudio.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/26/2017 11:58 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Koh1fds wrote:

"Allow more than 8 sprites per scanline" doesn't work in NesHawk

Seems to be working to me (ex. Soltice intro.) Can you give an example?

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/26/2017 12:44 AM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.SortedList`2.get_Item(TKey key) at BizHawk.Client.Common.TasStateManager.get_InitialState() at BizHawk.Client.Common.TasStateManager.get_Item(Int32 frame) at BizHawk.Client.Common.TasStateManager.GetStateClosestToFrame(Int32 frame) at BizHawk.Client.EmuHawk.TAStudio.StartAtNearestFrameAndEmulate(Int32 frame) at BizHawk.Client.EmuHawk.TAStudio.GoToFrame(Int32 frame) at BizHawk.Client.EmuHawk.TAStudio.TasView_MouseDown(Object sender, MouseEventArgs e) at System.Windows.Forms.Control.OnMouseDown(MouseEventArgs e) at BizHawk.Client.EmuHawk.InputRoll.OnMouseDown(MouseEventArgs e) at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) Getting this error in NESHawk when trying to use TAStudio. It happens when I hit the '<<' button. Also it seems like 'recording mode' is defaulting to on even though the check box is not checked (if I just open TAStudio and play a movie it deletes all the inputs.)

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/25/2017 11:05 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

It's also possible that the probability of success for runs like these is just very low. MM4 only synced once. I'm able to get almost every desync observed in the console testing with only slight variations in start up timing. The only one I have still never seen is the second pie hit in streemerz mode. That one really is a mystery. Anyway I'll be putting some time into MM5 now and hopefully have a complete run soon if RNG is friendly. I am curious about the top loader tests though True, good luck! EDIT: @True: I also added a mega man 6 run, made from Shinryu's obsolete movie (the published run desyncs much earler.) Shinryu's run desynced in the same spot you mentioned in the verification thread. I resynced it and beat that stages boss so that should be a good test. The run seems to desync pretty badly thereafter, so I didn't go any further, but if it gets through the lag and RNG nightmare in that section a complete run would probably finish.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/25/2017 4:29 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Patashu wrote:

If it's essentially random whether VBlank starts on or off, and other such things related to startup state, should a NESHawk TAS be able to specify the starting states of such things (similar to how you can specify the starting state of RAM)?

Probably not. All games should clear the first before testing anything. And actually this is what Streemerz and Battletoads are both doing. It turns out I had made an error in my original testing, so it's not the initial condition of the VBlank flag that is the problem here, it seems to be purely a start up timing issue. I cleaned up the code a bit but as far I can tell there are no further errors. Both games will desync if start up is different by a single PPU tick. It could be that something is just not quite deterministic here (besides the known case of PPU-CPU alignment.) I wonder if the NES10 chip is throwing off the start up timing slightly?

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/24/2017 4:26 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

It's not related to the RAM at all. It's related to where in the frame the CPU starts relative to the PPU and the exact cycle alignment between the two. I've tried different RAM states for these runs and it is irrelevent. And the only reason that even matters is because OAM DMA takes one cycle longer depending on whether it starts on an even or odd cycle, and because VBlank can be delayed by a bit depending on exactly when it is triggered.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/24/2017 3:09 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

^ Yeah sorry it's not a very good explanation. Here's the order of events that lead to this point: 1. Pass test ROM's. These make sure the emulator is working right but don't offer any insight into start up behaviour. 2. Make a 2player run of Battletoads sync. With everything else being correct, this game syncs entirely based on an accurate start up state. At the time, this state was borrowed from FCEUX, which has one extra dead frame in the PPU and slgihtly different initial conditions. 3. Match the run that syncs to the start up state here: https://wiki.nesdev.com/w/index.php/PPU_power_up_state Surprisingly, this worked out quite well. 4. Make other test runs, they failed to sync in what should be the accurate start up state, the one in the current NESHawk release. 5. I checked against the old start up state and the behaviour matched the console tests. So, something is wrong somewhere. I'm not sure if it's in the NESDev link, my implementation, or something else. True's tests are pretty definitive that if I change the Vlbank flag at power on I should get one of the 2 desyncs he got. The goal now is to make that happen with a consistent start up state.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/24/2017 1:28 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

I'm making progress in understanding True's console tests. Several of the runs experienced 2 unique desync modes. As it turns out, I can recreate most of these modes by changing whether or not the Vblank flag is set at power on. This is known to be basically random. I also reverted BizHawk's start up state back to a previous one similar to FCEUX, this combined with the random VBLank flag and I got precisely the same desyncs as true got on MM4, and Streemerz superb Joe. I also got the same battletoads desyncs, but it required a few more tweeks then just that. The only desync I have never seen is the second one from Streemerz, Streemerz mode, so that is what I am currently investigating. The search now is basically for a valid startup state that matches all the desyncs when changes vblank flag.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/24/2017 1:19 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Challenger wrote:

@feos @Alyosha Any new progress of 2p warpless?

For me at least, on hold pending console tests of NESHawk. I don't plan on working on anything that won't be console verifiable. NESHawk's current state does represent a valid startup state of the NES, as evidenced by a 2 player warps run syncing, but current testing seems to indicate that this might just be a lucky coincidence (it correctly mimics a valid startup state but isn't the exact same.) Once I am 100% confident of sync I will be continuing the run, which is currently at stage 4. That being said, anyone can feel free to make an updated run, as re-syncing it afterwards isn't that hard.

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/22/2017 9:21 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/21/2017 3:23 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/21/2017 3:17 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/21/2017 2:31 AM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/20/2017 12:58 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/19/2017 3:39 AM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

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

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/18/2017 1:13 PM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/18/2017 4:31 AM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

Joined: 11/30/2014
Posts: 2884
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!

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posted: 1/18/2017 4:28 AM

Alyosha

He/Him

Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4082)

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

Accepting hardware donations for console verification! See my homepage for details: https://tasvideos.org/HomePages/Alyosha Monetary donations also accepted via gofundme: https://gofund.me/82aabaee

Posts for Alyosha