Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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.)
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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.
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I tried to get this run to sync in BizHawk and it made it all the way up to the glitch itself. But after that it crashed.
It crashed at a kill instruction ($72).
Execution here depends critically on values in PPU registers/memory and undocumented opcodes.
FCEUX seems to be having some serious trouble here. Here are the last few instructions where things depart seriously from NESHawk:
There are 2 TAY's here that aren't moving A to Y, a jump to $0029 that I can't tell where it's coming from, and execution jumping from 3C8C to 3C9E on the 87 instruciton (which is just supposed to AND X and A.)
I read in the original publication of this branch by MUGG that the glitch itself is console verified, but on a different level. Is the glitch console verified on this level?
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Wow that's crazy! 8D
The online version was just too slow to be very useful, but I can see this version being a valuable asset and test bed in the future with a bit more development.
Very Cool!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
jlun2 wrote:
Alyosha wrote:
So, did reverting the change fix the problem? feos, jlun2, nrg_zam?
Sorry for the late reply, but at the latest interim, the buttons are back for me.
How about the scroll bars?
@feos: In the latest dev build copying/cutting cells isn't working for me and when I do that it just leaves the clipboard empty and pasting doesn't do anything.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Wow this is a very unexpected improvement! I never considered death could ever be faster, great idea!
I do wish the run could have been done on an up to date emulator version due to how timing dependent RNG is on this game, but oh well.
Nice Work!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
For reliable syncing make sure you use NESHawk and not QucikNES.
QuickNES is default (look at the lower part of the BizHawk window after you load a ROM.)
To change to NESHawk, first load a NES Rom.
Next go to NES->Core in the meues and click on NESHawk.
Then Reboot the core under Emulation -> Reboot Core
Now it should say NESHawk at the bottom of the window.
Any movie you make in NESHawk should sync, and if it doesn't do post it and I can debug it.
This means you'll need to start from scratch though.
You can try posting your existing QuickNES movie to user files and maybe I can try to find the desync, but no promises there.
You can upload movie files here:
http://tasvideos.org/userfiles/my#uploadfile
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
jlun2 wrote:
Edition: Windows 10 Home
Version 1607
OS Build: 14393.576
How about you?
I have the exact same.
...weird 0_0
EDIT: Ok I reverted the changes I originally made to the designer, so hopefully this resolves issues with the buttons and scroll bars.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Everything works and looks correct to me.
What OS are you working with jlun2? You and nrg_zam seem to be having the same issue.
@feos: do you think my commit that fixed the original issue i was having should be reverted? It seems like it might be cause of problems here. Maybe then i can find a more surgical fix for windows 10, since I'll at least be able to see the problem, without messing things up for other users.
