Post subject: SNES autopoller timings
Emulator Coder, Skilled player (1140)
Joined: 5/1/2010
Posts: 1217
The failures in console-verifying Super Mario World glitched run[1] likely point to that the autopoller timings in bsnes core are incorrect. These timing errors are not severe enough to cause failures or even desyncs in any even remotely well-programmed game, but really mess up things when run probes these timings to extreme degree, like the SMW glitched run. I did an inspired guess[3] about how real SNES would do the polling, but alas it didn't result in the same kind of failure than on real console, so it is likely incorrect. Looks like one has to probe what the heck the real console does with those timings, which requires test ROMs and flashcarts to run those on. Unfortunately, I have none of: - SNES programming skills. - SNES flashcart. - SNES console. Some questions to resolve: - When does the SNES autopoll cycle start (it varies per frame)? - How long is the SNES autopoll cycle[4]? - When in autopoll cycle the buttons are read? - What kind of incorrect values autopoll output registers contain when autopoll is active? [1] The run syncs fine up to first executed frame, which is 4th last frame in the movie. The jump to controller registers does work[2]. [2] Simplified payload that is just one frame long does work. [3] Autopoller can't activate for first 128 cycles of VBlank, the first time autopoller is invoked, it doesn't read input and there are extra 128 cycles autopoller active flag is raised after autopoll ends. [4] One document I found says 4224 cycles (16.5*256 cycles).
Post subject: Re: SNES autopoller timings
Skilled player (1703)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Ilari wrote:
The failures in console-verifying Super Mario World glitched run[1] likely point to that the autopoller timings in bsnes core are incorrect.
Wait, when did that happen? Can you please link to the thread/post? 0_o
Post subject: Re: SNES autopoller timings
Masterjun
He/Him
Site Developer, Skilled player (1968)
Joined: 10/12/2010
Posts: 1179
Location: Germany
jlun2 wrote:
Ilari wrote:
The failures in console-verifying Super Mario World glitched run[1] likely point to that the autopoller timings in bsnes core are incorrect.
Wait, when did that happen? Can you please link to the thread/post? 0_o
GhostSonic tested it and it didn't work. Here is a thread that gives more information about it.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Post subject: Re: SNES autopoller timings
Patashu
He/Him
Joined: 10/2/2005
Posts: 3999
Masterjun wrote:
GhostSonic tested it and it didn't work. Here is a thread that gives more information about it.
That infinite loop, man
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Post subject: Re: SNES autopoller timings
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Ilari wrote:
The failures in console-verifying Super Mario World glitched run[1] likely point to that the autopoller timings in bsnes core are incorrect. These timing errors are not severe enough to cause failures or even desyncs in any even remotely well-programmed game, but really mess up things when run probes these timings to extreme degree, like the SMW glitched run. [...] Unfortunately, I have none of: - SNES programming skills. - SNES flashcart. - SNES console.
Well, byuu has all three.
Ilari wrote:
Some questions to resolve:
Have you checked anomie's docs on RHDN?
AUTO JOYPAD READ
----------------

When enabled, the SNES will read 16 bits from each of the 4 controller port
data lines into registers $4218-f. This begins between dots 32.5 and 95.5 of
the first V-Blank scanline, and ends 4224 master cycles later. Register $4212
bit 0 is set during this time. Specifically, it begins at dot 74.5 on the first
frame, and thereafter some multiple of 256 cycles after the start of the
previous read that falls within the observed range.

Reading $4218-f during this time will read back incorrect values. The only
reliable value is that no buttons pressed will return 0 (however, if buttons
are pressed 0 could still be returned incorrectly). Presumably reading $4016/7
or writing $4016 during this time will also screw things up.
Emulator Coder, Skilled player (1140)
Joined: 5/1/2010
Posts: 1217
creaothceann wrote:
Have you checked anomie's docs on RHDN?
Yeah, I saw that document, and those guessed timings were heavily based on that (and one page giving oscillator outputs), but didn't seem to reproduce the same results (sprites visible on with oddly scrolled background) as seen on the console (black screen). Of course, there's a chance that those timings I intended were buggily implemented...
Post subject: Re: SNES autopoller timings
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
creaothceann wrote:
Ilari wrote:
Unfortunately, I have none of: - SNES programming skills. - SNES flashcart. - SNES console.
Well, byuu has all three.
It will be very kind if you bring this issue up on his forums. He can check that stuff in an evening I think :D
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Post subject: Re: SNES autopoller timings
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
feos wrote:
It will be very kind if you bring this issue up on his forums. He can check that stuff in an evening I think :D
Done.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Fixed.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
byuu answered, btw. Looks like somebody else is needed, maybe someone from here?
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Ilari wrote:
One simple test ROM: Around when autopoller is active, it records values from autopoll register as fast as it can and then shows those on screen. Then hold various button combos and see what appears on the screen. If bsnes has register updates correct, holding B it should show 8000 0001 0002 0004 0008 0010 0020 0040 0080 0100 0200 0400 0800 1000 2000 4000 8000. ... It is likely correct, given that kind of behaviour makes a lot of sense from hardware POV (it is SIPO). Then after how register updates is established, one could use carefully cycle-counted code (the bsnes CPU cycle counts are likely correct) to establish when the changes happen. By carefully choosing the ops, one should be able to get to 2 cycle accuracy.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Masterjun
He/Him
Site Developer, Skilled player (1968)
Joined: 10/12/2010
Posts: 1179
Location: Germany
So I made a testrom (edit: the first two word numbers are crap, the first real value starts at the third number) that simply reads $4218 as a word at the start of V-Blank a bunch of times and then prints to the screen. When for example pressing B (which results at the end in a 0x8000 at $4218 when read as a word) it looks like this in Bizhawk/lsnes and like this in Snes9x (this explains why it was much easier to do the glitched SMW run in Snes9x). However, I'm not good at making ROMs and this was the first one I've ever made. I only know that it reads $4218 as fast as possible and as early as possible. As far as I can tell
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Joined: 5/4/2005
Posts: 502
Location: Onett, Eagleland
60FPS video of the same rom on a SFC SNES: https://www.dropbox.com/s/t9oc9val6mjc9kr/SNES%20POLL.MKV I'm just pressing 'B'.
I think.....therefore I am not Barry Burton
Joined: 7/2/2007
Posts: 3960
I just want to say that all this research and your results are super cool. Thanks for sharing, everyone!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Emulator Coder, Skilled player (1140)
Joined: 5/1/2010
Posts: 1217
What is known and guessed so far: Based on the videos and other data, here is my guess on the timings (just a guess, confirming would require more detailed measurements): Cycle 0 (must be 128 mod 256): Detect VBlank Cycle 128: Set Autopoll busy, Raise latch, zero autopoll result registers. Cycle 384: Lower latch. Cycle 512: Shift the autopoll registers one place to left and read new LSB from controllers, Raise clock. Cycle 640: Lower clock. Cycle 768: Shift the autopoll registers one place to left and read new LSB from controllers, Raise clock. Cycle 896: Lower clock. ... Cycle 4096: Shift the autopoll registers one place to left and read new LSB from controllers, Raise clock. Cycle 4224: Lower clock. Cycle 4352: Shift the autopoll registers one place to left and read new LSB from controllers, clear autopoll busy. Might not be correct, but is likely way closer to reality than what bsnes currently uses: Cycle 0 (must be 0 mod 256): Detect VBlank, set autopoll busy. Shift autopoll registers one place to left and read new LSB from controllers. Cycle 256: Shift autopoll registers one place to left and read new LSB from controllers. Cycle 512: Shift autopoll registers one place to left and read new LSB from controllers. ... Cycle 3584: Shift autopoll registers one place to left and read new LSB from controllers. Cycle 3840: Shift autopoll registers one place to left and read new LSB from controllers. Clear autopoll busy. But additionally glitching is seen in the captured videos. The bits are not shifting at the same time, resulting values where some bits have been copied from proper places and some haven't. Following glitched update sequences have been seen: 0080->0180->0100 and 0100->0200->0201. There are probably others. In first, bit 8 copies its value from bit 7 before bit 7 copies its value from bit 6. In second, bit 1 copies its value from bit 0 before bit 0 copies its value from serial in. Additionally, 0 and 1 bits might get copied at different times (Digital circuits are usually not symmetric with regards to 0 and 1), but this hasn't really been probed yet. One thing that might be useful: Test ROM that functioned like Masterjun's test ROM, but only showed glitched values (those that aren't F >> x, for any x, where F is the final value and >> is right shift).
BigBoct
He/Him
Editor
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
Derakon wrote:
I just want to say that all this research and your results are super cool. Thanks for sharing, everyone!
Indeed, it's pretty fascinating even for me, a layperson at this kind of stuff.
Previous Name: boct1584