This submission beats "Dragon Quest (J)" in about 6:20, using "Stone of Sunlight glitch". I used the Famicom version because the NES version doesn't have this glitch.
NOTE: I'm not sure if this movie syncs on a real console. For example, in this movie, the game reads PPU write-only registers as data.
At first, I made a movie on FCEUX, but we replaced it with this SubNesHawk movie for accuracy. I believe we have to use SubNesHawk to make a verifiable movie of this game, because this game sometimes polls multiple inputs in a frame.

Game objectives

  • Emulator used: BizHawk 2.9 (SubNesHawk core)
  • Aims for fastest time
  • Major skip glitch

About the glitch

"Stone of Sunlight glitch" is originally found by cheap. I will describe it as possible as I can.
First, you can take chests unlimitedly if you fill up the "open-chest" array (address $2A-$39). To do so, take some chests in a dungeon and die before exiting. Then the array is not re-initialized, so you can fill up the array before you take all chests in Tantegel Castle. (Note that the capacity of the array is 8 elements, and the array always has 3 elements for the chests in the throne room in Tantegel Castle)
In this situation, if you take the chest containing "Stones of Sunlight", a glitch occurs and the game displays a string "12345". This is harmless by itself. But if your inventory is full, the game corrupts the window buffer ($0400-$07BF). And, the window buffer is corrupted a bit more if you open and close the inventory window.
After corrupting the window buffer as above, scrolling the message window (dropping an item, using a cursed item, talking, etc.) causes a significant glitch and the game reads the beginning of zeropage memory as text script commands. Furthermore, the game treats zeropage memory as window buffer and corrupts it by message scrolling process.
By the way, the "beat Dragonlord" flag exists at bit2 of $E4. So, if you can manipulate this address, you can beat the game just by going to the front of the king. But sometimes the game is softlocked by the glitch. Moreover, the address $E5 (message speed) is also often corrupted. If the message speed value is too large, conversations take so long time.
As I said, the game reads zeropage memory as text script commands. So, you can write some script commands at some addresses (e.g. $47 (input), $4F (nmi counter), $50 (sprite animation counter)...).
When the game corrupts zeropage memory by message scrolling, it writes via the pointer $42. And this pointer is also corrupted by the glitch. I found that the game writes 0 to $42 in many cases. In such cases, the game corrupts only the beginning of zeropage, so you cannot change $E4. To corrupt memory over $42, you need to write a large value to $42. To do so, write some script commands which emits multiple characters. For script commands, see Data Crystal.
Unfortunately, I haven't yet found a method to control this glitch precisely. It is difficult to analyze since it works like self-modifying code.
rat926 uploads some examples of this glitch (movie files are available from the description texts):
Sometimes the hero name is corrupted by the glitch, and this tends to freeze the game when you talk to the king. But, you can sometimes avoid the freeze by opening and closing the menu beforehand (it partially fixed the corrupted hero name). This technique is found by pirohiko.

About the run

The hero's stats depend on his name. I named him "は" for the reasons below:
  • He has 15 HP, so he can walk through poisonous marsh with only one herb.
  • He has 3 agility, so enemies can easily surprise him (useful for deathwarp).
  • You can minimize cursor movements in the name screen.
I go to Rimuldar and buy a key. And I return to Tantegel by deathwarp.
I go to Rock Mountain Cave, open 5 chests, and fill up the inventory. And I deathwarp back to Tantegel. Note that the "open-chest" array is filled up.
I go to the basement of Tantegel, and execute Stone of Sunlight glitch. I set $47 (input) to 0xAF (word "にじのしずく"), and set $50 to 0x70 (word "ラダトーム").
The game enables the "beat Dragonlord" flag. The message speed value is still 0. And I go to the front of the king and beat the game.
Note: In the first FCEUX movie, I mistaked the path in the bottom floor of Rock Mountain Cave, but this issue is fixed in the submission movie. (Thanks to juef for pointing out this.)

Possible improvements

This movie is just a resync of a NesHawk movie. In theory, you will be able to manipulate the RNG more efficiently taking advantage of subframe inputs. (For reference, I put a Lua script to resync a NesHawk movie for SubNesHawk.)

Samsara: I've tentatively added the "game end glitch" branch (EDIT: I actually did this time! I certainly didn't forget to do so on my first edit!!!), but I'm also dropping my judgement claim in order to let someone with more technical prowess judge the run more accurately. My fondness for TASes of this game remains the same, however.

feos: Claiming for judging.
feos: It's not often that a submission triggers improvements in emulation, but I've reached out to the nesdev people and got a test ROM that will allow us to see how consoles work with reading write-only PPU registers (which this movie relies on). While we're waiting for more console tests of it, I'm delaying this submission.
Note that it doesn't mean that we will require emulation to be so good that this run will start syncing on console. Due to how console behavior on this front seems to be non-deterministic, and different from device to device, I want to accept this run (its SubNESHawk resync) if it's determined that this movie will work in principle if things align correctly, even if we can't find a console it will sync on.
feos: Replacing with a SubNESHawk resync and accepting as a new branch.
We've done due research, and based on the available info, nobody (not even NESDev gurus) claimed that this movie relies on an emulator glitch, even if it doesn't sync on the consoles we were able to try it on. We can't keep scrutinizing it further hoping to find a reason to reject, because reject reasons need to be way more apparent.

despoa: Processing...


Bigbass
He/Him
Moderator
Joined: 2/2/2021
Posts: 194
Location: Midwest
feos wrote:
This version too please, it records slowest/fastest now: https://cdn.discordapp.com/attachments/450038053159960577/1098779612433108992/ppudecay.nes
Link to video Wasn't sure how long was sufficient. After around 10 minutes the results were:
Fastest:
7F-025B 3F-025A 7F-0259 7F-0255
3F-0253 7F-0267 7F-0266 FF-0262

Slowest:
01-065E 10-0736 40-0B0D 40-0B2B
40-0B31 40-0B37
TAS Verifications | Mastodon | Github | Discord: @bigbass
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3824)
Joined: 11/30/2014
Posts: 2832
Location: US
Link to video V2 test. Same basic results as V1. Seems to be a couple orders of magnitude faster than what NESHawk has now (but shouldn't really matter since in this case the reads seem to be happening during rendering, so even quicker decay should still be ok.)
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11486
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
SBDWolf kindly provided entire 20 minutes of footage, on 2 consoles each! Link to video Link to video
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: 8/24/2012
Posts: 28
Location: Russia
The "slowest" line may have a different line length (number of values) depending on reset. The "fastest" line changes it's values depending on the duration of the test (PPU warm-up) !! The freezes at the beginning of the some videos was caused by the late activation of virtualdub recording !! Chip type: Ricoh RP2C02G-0 (PPU) PCB type: Custom Timing: NTSC Link to video Chip type: Ricoh RP2C02H-0 (PPU) PCB type: Famicom AV Timing: NTSC Link to video Chip type: Ricoh RP2C07-0 (PPU) PCB type: NES PAL Timing: PAL Link to video Chip type: UMC UA6538 (PPU) PCB type: Custom Timing: Dendy Link to video Chip type: TA-02NP 6538 (PPU) PCB type: Custom Timing: Dendy Link to video Chip type: T1818P (NoAC) with external UM6516 RAM PCB type: Custom Timing: Dendy Link to video Chip type: T1818P (NoAC) with external IDT6116SA 15ns RAM PCB type: Custom Timing: Dendy Link to video Chip type: UMC UM6561F-2 (complete NoAC) PCB type: Custom Timing: Dendy Link to video Chip type: UMC UM6561F-2 (complete NoAC) PCB type: Dendy Junior MG-02 Timing: Dendy Link to video
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11486
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
lidnariq wrote:
My recollection is that for this specific TAS, the contents of PPU open bus need to stay stable for 5ms, and your tests here show that's liminal
Fiskbit wrote:
Alyosha wrote:
https://www.youtube.com/watch?v=kd50wwM0mBQ V2 test. Same basic results as V1. Seems to be a couple orders of magnitude faster than what NESHawk has now (but shouldn't really matter since in this case the reads seem to be happening during rendering, so even quicker decay should still be ok.)
Rendering shouldn't matter at all in this case. The PPU open bus we're talking about here is open bus for the PPU's CPU interface and is only affected by register access - that is, values driven onto this specific bus when the CPU writes or when bits are driven to respond to a CPU read. This is separate from the PPU bus used for CHR and nametables, which is what is used for rendering. Indeed, consider lidnariq's test ROM above that is measuring this decay. It has rendering enabled at all times and would not function properly if rendering affected it.
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.
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11486
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Bigbass wrote:
Wasn't sure how long was sufficient. After around 10 minutes the results were:
Fastest:
7F-025B 3F-025A 7F-0259 7F-0255
3F-0253 7F-0267 7F-0266 FF-0262

Slowest:
01-065E 10-0736 40-0B0D 40-0B2B
40-0B31 40-0B37
I have a theory that the movie should sync on your device if the run is resynced on a core that replicates your ppu decay. But if we all agree that it should sync in theory after an accuracy tweak, then it's possible to do on console in principle. In which case we should just accept it without resyncing.
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.
Bigbass
He/Him
Moderator
Joined: 2/2/2021
Posts: 194
Location: Midwest
feos wrote:
I have a theory that the movie should sync on your device if the run is resynced on a core that replicates your ppu decay. But if we all agree that it should sync in theory after an accuracy tweak, then it's possible to do on console in principle. In which case we should just accept it without resyncing.
Could be. I'm not too knowledgeable when it comes to open bus or really anything to do with the PPU. In regards to acceptance though: While I would definitely like to see this verified, I do feel that it should be acceptable, as long as the glitch appears plausible, according to the knowledge the community currently has. Unless the author explicitly wants to hold off until verification? As I'm sure the judges know, there's always a chance that TASes could rely on emulated behavior that does not match the real console. While a successful verification proves the TAS is possible, a failed verification does not prove the TAS is impossible.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Experienced player (942)
Joined: 9/18/2008
Posts: 154
Location: Japan
I have no objection to the acceptance, if all the people agree on the theoretical reproducibility as feos mentioned. I appreciate the people who put effort into console testings.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3824)
Joined: 11/30/2014
Posts: 2832
Location: US
I recompiled NESHawk with much faster decay rate (by a couple orders of magnitude) and the run still syncs. This decay rate is faster than I saw on my own NES, so presumably the run would work there, except I don't have the hardware to do so. In fact this rate is even faster than Bigbass' console, so seems like it has a chance of working there too if it was done from power on and the power on states match. So seems plausible.
Experienced player (942)
Joined: 9/18/2008
Posts: 154
Location: Japan
I edited some submission texts to reflect the movie replacement.
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15601
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [5273] NES Dragon Warrior "game end glitch" by TaoTao in 06:19.51