TASVideos

Posted: 1/12/2017 4:14 PM

Quote

Alyosha

He/Him

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

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

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

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

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

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

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

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

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

Posted: 1/8/2017 11:21 PM

Quote

Alyosha

He/Him

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

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

c64248952    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C78:A8        TAY
c64248954    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C7A:10 00     BPL $3C7C
c64248957    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C8C:87        UNDEFINED
c64248960    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C9E:23        UNDEFINED
c64248963    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3CA0:A8        TAY
c64248970    A:7E X:FF Y:62 S:F9 P:nvUBdIzc       $0029:48        PHA

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?

Posted: 1/8/2017 2:22 AM

Quote

Alyosha

He/Him

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

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

sounds fun please sign me up!

Posted: 1/7/2017 5:28 PM

Quote

Alyosha

He/Him

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

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

Posted: 1/4/2017 3:56 PM

Quote

Alyosha

He/Him

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

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

Posted: 1/4/2017 3:45 PM

Quote

Alyosha

He/Him

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

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

So, did reverting the change fix the problem? feos, jlun2, nrg_zam?

Posted: 1/4/2017 3:43 PM

Quote

Alyosha

He/Him

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

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

Posted: 1/4/2017 12:45 AM

Quote

Alyosha

He/Him

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

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

An error in what? You can't have a movie/TAS loaded when changing cores.

Posted: 1/3/2017 11:18 PM

Quote

Alyosha

He/Him

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

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

Posted: 1/3/2017 5:38 PM

Quote

Alyosha

He/Him

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

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

Cool TAS! I played this game a lot as a kid and its nice seeing a TAS of it, voting yes!

Posted: 1/2/2017 4:58 PM

Quote

Alyosha

He/Him

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

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

Posted: 1/2/2017 4:34 PM

Quote

Alyosha

He/Him

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

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

Posted: 1/2/2017 4:09 AM

Quote

Alyosha

He/Him

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

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

This looks pretty cool. I hope there are some interesting strategies to let the players split up bit more.

Posted: 1/2/2017 4:07 AM

Quote

Alyosha

He/Him

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

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

Woah cool stuff here, keep it up!

Posted: 1/2/2017 4:02 AM

Quote

Alyosha

He/Him

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

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

This page might help as well. It looks like changing the select pin pulls some other pins low from the multiplexer output. If you are only changing one pin (9) then it might be messing up the read routine in whatever game/rom you are testing with.

Posted: 12/27/2016 5:50 PM

Quote

Alyosha

He/Him

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

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

Alright! After some debugging and code cleanup, I added the border and I managed to pass the intellivision MTE test cart! With this I am not aware of any bugs in the intellivision core and am pretty confident in declaring it ready for TASing. As always I'll be available to fix bugs as they pop up, but I'm not sure I'll put too much more effort into this core. So, things like intellivoice, Intellivision II, ECS, keyboard, system changer will not be actively worked on (at least not by me, anyone else is welcome to try!)

Posted: 12/25/2016 3:46 AM

Quote

Alyosha

He/Him

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

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

Nice work! Glad a better optimized run with that new zip is done.

Posted: 12/25/2016 3:42 AM

Quote

Alyosha

He/Him

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

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

Ok! After a lot of debugging I finally fixed Pac Man! As a bonus I also managed to get the homebrew Ms. PacMan working as well. On top of that I made a lot of accuracy improvements that really make the emulator a lot closer to the hardware. It's not quite cycle accurate but close enough that only edge cases (like timing code to change background tiles midframe) would reveal any errors. The only remaining challenge is the MTE201 test cart, which I htink should be pretty easy to pass with a few more tweaks.