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).
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.
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.
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...
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
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.
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.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
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.
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 creditsI will finish this ACE soon as possible
(or will I?)
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).
