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?
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.
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).
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
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
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.
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.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
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.
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 :)
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.
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.
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...
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
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.
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()
Ambassador, Moderator, Site Developer, Player
(155)
Joined: 3/17/2018
Posts: 358
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.
[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
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.
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.)
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.
