1 2
16 17 18
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
How much can a TAS differ from a version of the same TAS that fully syncs in the actual console, for it to be considered "console-verified"? 1) None at all. If any modification at all needs to be done to the keypress data (amount, timing...) to make it sync, it's not "console-verified". Also even if no modification is needed, but the number of frames to completion differs (in cases where the console "polls" the input, rather than the input being fed to it on a regular basis), it's also not "console-verified". 2) If the input syncs fully in the console without any modification, even if the completion times differ (in cases where the console "polls" for input, thus allowing leeway in the timings.) 3) If the only modifications needed are adding or removing a few extra lag frames or empty input due to differences between the emulator and the console, then it's still ok. (It would be great if the emulator matched the console perfectly, but until we get there, this ought to do.) 4) Something else?
Senior Moderator
Joined: 8/4/2005
Posts: 5769
Location: Away
I would say that ideally option #2 is where we should start with any respective system, gradually moving on to #1 as emulation quality improves. Some movies will probably stay permanently unverifiable due to non-deterministic routines, voltage sag incurring random lag frames, or something else that is impossible to control via input alone. However, because of the sluggish pace of emulation development and the purposes of publicity, it is reasonable that option #3 remain allowed for the reason both of us have already stated. This, as I understand, is pretty much where we're at with Sonic Advance (and probably some other movies? I don't have enough data on that). The wait for proper RNG seed at the start of that movie is indeed contentious (even if unavoidable), but seems to fall under the "inserting empty input" condition and could be seen as a delayed start... which it technically is. It boils down to whether we, at this point, want to be extremely pedantic with regards to run start point, or treat the start/finish timing as a sliding interval, closer to what realtime runners do (i.e. from pressing Start at title screen to movement stop, regardless of system uptime or the actual last input). The important part is that literally everything in that movie that demonstrates precision which separates TAS from non-TAS is, thankfully, deterministic and syncs perfectly, which is why the extra frames were inserted only during downtimes. The character does all the exact same things on the TV screen as what you can see in the emulator... good enough for virtually everyone aside of a few of us here. Modifications we're making are compensating for the emulator's deficiency, not for the author nor the TAS itself. At the same time, anything that would make the gameplay look differently or arrive at different in-game conclusions/timer results (when applicable) should definitely be unacceptable in my opinion, because at that point we would be tampering with the relevant content of the TAS, i.e. not actually verifying it at all (adaptation would be the right word for that). "Console-adapted", how's that for a new flag, eh? :)
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Perhaps we should indeed talk about two "sub-categories" of console verification of TASes: Those that work as-is on the console, without the need of any modifications, and those that require minor modifications to sync on the console (but such modifications make it desync on the emulator, because the emulator is not yet 100% accurate).
Active player (303)
Joined: 8/21/2012
Posts: 429
Location: France
Just to play on words, I consider the Sonic Advance run itself console-verified, using a console-adapted movie file.
endrift
Any
Emulator Coder
Joined: 12/14/2014
Posts: 161
Well, hopefully this verification of [1958] GBA Sonic Advance 2 by Mukki in 18:01.78 will be less controversial. There were no large changes I had to make, only inserting lag frames (about 3 per level), removing one lag frame in one of the levels (I forget which), and inserting frames at the beginning to compensate for the boot screen that's not in the emulator. The RNG was more cooperative in this game, so nothing fancy was needed. I'll post a cam vid sometime soon-ish. Note that I was not easily able to clear the entirety of the save data (the name input screen at the beginning is notably absent), so I'd need to do a bit more work to get the very beginning working, but the data is otherwise completely cleared. I hope to do that additional other work soon, but it requires toying with the cartridge between runs, so I haven't done it yet. Link to video
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Private.
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.
endrift
Any
Emulator Coder
Joined: 12/14/2014
Posts: 161
Strange. It was set to unlisted when I uploaded it. Should be fixed now.
Editor, Player (68)
Joined: 1/18/2008
Posts: 663
Just to note here since discussions have primarily been on IRC, I have been working on Super Metroid sync. dwangoAC sent me a broken SNES and I have modified it to use clocks injected from my signal generator. We're getting close to syncability (can get about ~10 minutes in) but I think my sig gen, though a good unit, has two major issues preventing sync. I also need to confirm how the clock dividers work on the CPU, PPU and SPU and perhaps even try a different SNES board rev.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
True wrote:
We're getting close to syncability (can get about ~10 minutes in)
WOW! Could you please remind what breaks sync originally?
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.
Editor, Player (68)
Joined: 1/18/2008
Posts: 663
There are a few issues right now. 1) I don't know the state of the clockdividers in the CPU/PPU/SPU at power-on. Each chip has its own dividers built in, and I don't know if they power-up reset or if they reset when reset is asserted. Most divider implementations do not reset... 2) I cannot start both clocks at the same time, and I have no control of phase. This can be solved with a better clock generator or an external circuit. This circuit design would depend on how the dividers work and if they will reset if reset is asserted. Why I desync now? I don't know, but my theory is a combination of: source clock jitter, SPU clock and CPU clock divider offset, initial start phase mismatch. It could also be emulation inaccuracy or emulation board rev mismatch (I have been doing this on a rev1 board) but I need to rule out these other things first. I don't have equipment to test all of them but I can test some things still, like divided clocks to know the reset state of the on-clip clock dividers. But what's really interesting is that I moved the CPU clock injection from the crystal (where it goes through buffers) to directly at the CPU/PPU with a 10k pulldown (to have a known start state and to possibly dissipate reflections) it had a drastic affect. Before the move, we were deterministically getting to a point in the runs, and after we were getting to a different point. Since phase and dividers don't match, why would this one change do anything? It's baffling. My guess right now is that the pulldown alone is responsible for this - but phase doesn't match at start anyway, and the SPU is clocking before CPU, so why would it matter? Lots of work left, this is only the beginning. I need time, motivation, and probably money for better tools, in that order. I'll try to get the first two because that's affordable :)
true on twitch - lsnes windows builds 20230425 - the date this site is buried
endrift
Any
Emulator Coder
Joined: 12/14/2014
Posts: 161
And here I was assuming the game was unsyncable due to variance in how the hardware starts and runs. I guess if you modify the clocks you can do it, but at what point does it start being too intrusive into a hardware mod? Perhaps I'm getting to philosophical though.
Senior Moderator
Joined: 8/4/2005
Posts: 5769
Location: Away
As long as the mod amounts to forcing the hardware to comply with its specification (i.e. making the system deterministic without changing its timing or performance) it shouldn't be considered too intrusive. Though I agree, the setup is getting... quite elaborate, to say the least. Frighteningly so.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Editor, Player (68)
Joined: 1/18/2008
Posts: 663
endrift wrote:
And here I was assuming the game was unsyncable due to variance in how the hardware starts and runs. I guess if you modify the clocks you can do it, but at what point does it start being too intrusive into a hardware mod? Perhaps I'm getting to philosophical though.
For verification purpose, clock injection isn't too severe - emulators have precise clock timings and sources and those of the console aren't anywhere close to accurate. The emulator clocks are (close to - see below) the specified frequencies of the oscillators they replace. I am basically accurizing the console to induce determinism. I don't change any characteristics of how it runs or of user input. If I had to, say, snoop the bus to inject or modify instructions, change how controller polling worked by forcing polling to take place, run my own software on the console etc. then that's a bit far, but making the console more accurate isn't. Obviously I would like NOT to need to need to do this, but for many games on SNES there will be no way around this. The end product of this modification isn't as severe as it seems - the console contains clocked devices and I am simply clocking them at near-nominal specs. Note: I have concerns over frequencies chosen by byuu. The cpu frequency is not nominal specified frequency, but it is at least well within spec. The chosen frequency is 2hz higher, well within a high specced 10ppm crystal's accuracy tolerance; this selection is only out about ~93ppb out. I can't find a datasheet for this product but his frequency _could_ be the most common standard deviation of accuracy at a specified temperature...though I am guessing not. The APU is even farther out though. On the console it is clocked by a cermamic resonator (at least in rev1 SNES) and is a comparatively inaccurate and drifty clock; that said, it probably won't be the ~1250ppm out that the emulator's clock is. The nominal frequency of the resonator is 24.576MHz but byuu has chosen 24.607104MHz. This is WAY out of spec, and should be fixed in the emulator, but as long as I sync the console to this frequency, game sync should occur. I would suggest that the clocks by set to main:21477270 apu:24576000 or some similar values with a shorter phase sync period. (unless someone has better information as to why these values were chosen for accuracy?) These values are in line with the actual oscillators used and specified for use in the SNES. Ilari has modified lsnes to support changing APU but I don't know if the main oscillator can be changed with how the emulator is designed, or if it can, if it will have serious performance consequences...
true on twitch - lsnes windows builds 20230425 - the date this site is buried
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
You could ask at byuu's forum...
Joined: 2/21/2008
Posts: 255
Are there specific rules against soldering a device directly to the controller electronics? Would that work for GameBoy games?
"The guy was fatally injured and wants to be covered by God's tears (rain) before he dies. God is too busy to bother because it wastes frames." Frames 16:26
Joined: 8/4/2011
Posts: 26
Location: Sweden
Anyone here that has experience in the Nicohood Nintendo Library? I'm trying to find a way to synch frames using controller polls from a GC/Wii console but I'm not sure how to proceed.
Skilled player (1703)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
This was posted on the discord chat: https://pastebin.com/DXiDT9ZT
Game Boy/ Game Boy Color Console Verification Pipeline with new halt bug accuracy Needed - A Game Boy Player, Game Boy Interface, and an SD Media Launcher to use to load GBI and the input movie Build BizHawk from source code, tested working as of this commit: https://github.com/TASVideos/BizHawk/commit/e8145af463500d8886f1a0369e7b13a2c7c8933b Write your TAS using the GBHawk core and then restart the core and leave it paused on the first frame Run this lua script and then play back the TAS in the emulator to generate timestamps.txt https://pastebin.com/aEmMY4cm rename your timestamp output to yourmoviename.txt and optionally gzip it put the movie file on an SD card with GBI or GBI-HF, both inside a folder named GBI (for example E:\GBI\gbihf.dol and E:\GBI\yourmoviename.txt.gz) create a CLI file in the same directory name gbi.cli or gbihf.cli respectively to pass your input movie to GBI, the cli should contain an argument --movie=yourmoviename.txt.gz along with any other arguments that you use to tune GBI. Run GBI or GBI-HF from the SD card. I do this using Swiss, which I rename to autoexec.dol and place on the root of the FAT16 formatted SDHC SD card. From swiss it's easy to choose which version of GBI to load to load other homebrew. Watch as GBI plays back your console-accurate TAS! Credit to Extrems, AlyoshaTAS, and Gifvex for their help with getting console verification to where it is.
Also:
Go ahead but with a caveat about double speed mode and trying anything longer than 52 minutes We're running into more issues in the Yellow TAS
Edit: Lua code in case link dies:
local inputlabels = {"P1 A", "P1 B", "P1 Select", "P1 Start", "P1 Right", "P1 Left", "P1 Up", "P1 Down"}
 
function getinputbyte()
  if not movie.isloaded() then
    return 0
  end
 
  local t = movie.getinput(emu.framecount())
  local b = 0
 
  for i = 0, 7 do
    if t[inputlabels[i + 1]] then
      b = b + bit.lshift(1, i)
    end
  end
 
  return b
end
 
function tryinput(file)
  local input = getinputbyte()
 
  if input ~= lastinput then
    local cycles = emu.totalexecutedcycles();
    
    cycles = (cycles + 70224 * 14 - 456 * 90 - 1024) / 1024;
    
    file:write(string.format("%08X %04X", cycles, input))
    file:write("\n")
    lastinput = input
  end
end
 
local timestamps = io.open("timestamps.txt", "w")
local lastinput = -1
 
tryinput(timestamps)
 
while emu.framecount() <= movie.length() do
 
  tryinput(timestamps)
 
  emu.frameadvance()
end
 
tryinput(timestamps)
timestamps:close()
 
client.pause()
TiKevin83
He/Him
Ambassador, Moderator, Player, Site Developer (119)
Joined: 3/17/2018
Posts: 348
Location: Holland, MI
Check the paste for updated LUA scripts for both GBHawk and Gambatte, you should probably use Gambatte right now because it appears to be a tad bit more accurate.
Editor, Player (68)
Joined: 1/18/2008
Posts: 663
Maybe it's time to make the interface for an actual GBC now, since that would probably be considered impressive.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
EZGames69
He/They
Expert player, Publisher, Reviewer (3941)
Joined: 5/29/2017
Posts: 2701
Location: Michigan
There seems to be a slightly large list of movies that are listed as Console Verified (only for NES it seems) but have no video proof to back it up, not even posted in the movies' discussion thread. I honestly have no idea if the verification videos were posted in a different thread or were just never posted at all, but it seems that most of them were verified via live stream which was just never re uploaded. If anyone can provide some of these videos for the following movies that would be very helpful: [1049] NES Batman by Aglar in 09:21.93 [1128] NES Chip 'n Dale: Rescue Rangers "2 players" by dragonxyk in 09:25.73 [1816] NES Chip 'n Dale: Rescue Rangers "1 player" by Aglar in 09:54.37 [2044] NES Chip 'n Dale: Rescue Rangers 2 "1 player" by feos in 15:13.80 [2859] NES Darkwing Duck "pacifist" by feos in 12:35.66 [3211] NES Double Dragon by Alyosha in 08:50.28 [3223] NES Ninja Gaiden by Scumtron, MESHUGGAH, feos, Xipo, Marx in 10:50.36
[14:15] <feos> WinDOES what DOSn't 12:33:44 PM <Mothrayas> "I got an oof with my game!" Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish [Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
arflech
He/Him
Joined: 5/3/2008
Posts: 1120
Has there been recent work toward a robust method of verifying TASes on Sega 8-bit consoles, the Genesis, and the 32X? I know that the latter two do have console-verified runs, but it looks like all of the verifications were done in 2014 with a setup that doesn't look as well put-together as TASBot for some reason. Also, has any attempt at all been made to verify TASes on other non-disc-based consoles? The only thing I've seen was a first effort for verifying the TAS of Dragster for Atari 2600 in 2017, but it doesn't seem like that board was used to verify any other A2600 TASes. From how I understand runs on the Game Boy line are verified, it doesn't look like this sort of thing would work for Lynx, Game Gear, Neo Geo Pocket, or WonderSwan.
i imgur com/QiCaaH8 png
TiKevin83
He/Him
Ambassador, Moderator, Player, Site Developer (119)
Joined: 3/17/2018
Posts: 348
Location: Holland, MI
A lot of work has been going on in the console verification scene. I went over all published runs to verify whether they had video proof of a console verification and could not find it for the following runs (which was confirmed separately by Stovent): http://tasvideos.org/562M.html http://tasvideos.org/1114M.html http://tasvideos.org/1128M.html http://tasvideos.org/1267M.html http://tasvideos.org/1621M.html http://tasvideos.org/1665M.html http://tasvideos.org/1816M.html http://tasvideos.org/2652M.html http://tasvideos.org/2859M.html http://tasvideos.org/3179M.html http://tasvideos.org/3211M.html http://tasvideos.org/3223M.html http://tasvideos.org/3225M.html Please provide video if you know of any for the previous runs. Our procedures for console verification and archives of past verifications are now being documented here: https://runs.tas.bot https://runs.tas.bot/runs We have now verified TASes of the following GB games to match the Game Boy Player using pipelines documented on the above site: Super Mario Land, every Gen 1-2 Pokemon, Pokemon TCG 1 and 2, Dr Mario, Mickey's Chase, Link's Awakening DX, and the notoriously difficult to emulate "Pinball Fantasies" We have identified issues verifying some TASes of Wario Land II that use out of bounds (though some TASes also work correctly), and separately identified that TASes of Donkey Kong '94 may be impossible to sync due to the RNG being started from uninitialized wRAM.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
That page is cool! I'm glad to see console verification advancing so rapidly! I would add a note of caution about NES verification though. Some bots do not respond to DMC glitch like a real controller does. So, runs made on FCEUX which does not emulate DMC glitch reads at all, will appear to verify on a bot that also does not implement them. I remember working through this issue with True on Ninja Gaiden a while back, here is the relevant post: http://tasvideos.org/forum/viewtopic.php?p=442241#442241 Whether or not runs should count as verified with non-standard controller behaviour I think is something that should be detailed more carefully, at least in my opinion. (This is specifically important for Ninja Gaiden, which uses DMC a lot.)
TiKevin83
He/Him
Ambassador, Moderator, Player, Site Developer (119)
Joined: 3/17/2018
Posts: 348
Location: Holland, MI
https://youtu.be/G8IonKUea7o A bit of a follow up to the work on runs.tas.bot
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
TiKevin83 wrote:
https://youtu.be/G8IonKUea7o A bit of a follow up to the work on runs.tas.bot
Thanks for this tutorial, I followed all the steps but it failed to load the files from the SD card. I think my SD card has too high a capacity, the website says 4 GB limit, but mine has 64 GB. Probably good to mention that somewhere for the tutorial.
1 2
16 17 18