Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
adelikat wrote:
The judging hold up here is primarily the lack of an actual console verification. I think given the category, that would be needed.
It has been verified, and live streamed.
For an evidence video though, I will have it done in 2 weeks or hopefully less. The visual display boards have shipped, and it should take little time to solder parts to them and write the code to make them work and record a video.
adelikat wrote:
Also, I haven't heard of any feasible way to incorporate hard resets into a bot. I'm under the impression soft resets is in the realm of feasibility even if they don't yet exist, but hard reset isn't going to happen. So regardless, a console verified ff1 movie will differ significantly from the published movie.
To replay power cycle with an unmodified console, basically the movie is split on power button presses, and a robot (or a human if timing isn't important) powers the console off. The problem is the NES case where this turns into a multi-step process of power off, remove cart, run RAM clear cart, while powered (and in reset for a frontloader) swap to original cart, then press (release) reset, and while doing this configure the replay bot, and hope it all works. Doing this will add some time to the replay procedure, and thus the actual replay time shown on site will not be an accurate display of time as done with real hardware and on the real console. Not to mention the need for third-party tools to actually prep the console to match the emulator on every power cycle.
So it _can_ theoretically be done, but not as expected with a name like "power cycle": to do this on NES will require either multiple prepared consoles sitting on and ready or preparation software to be run on the console with at least two cart swaps. But as described earlier in this thread, even if that is done, replay time for Final Fantasy with power cycles will be longer than this movie.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
cak wrote:
Hello there...I was wondering if anyone has advice on what to change in a Metroid ROM to achieve the same Kraid position on Powerpak as on console. On Powerpak, whether from poweron or reset, Kraid is further away from door. Thanks.
Read above re: what was necessary to console verify this game. This game is sensitive to uninitialized RAM. Furthermore, FCEUX does not set power-on RAM to a possible power-on state on the NES, it instead sets it to some pattern for historic compatibility reasons.
Since you are running on Powerpak, maybe you can write a RAM clearing patch or something?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
spweasel wrote:
I'm keen on having a "No Resets" run in the Vault, but "Any SRAM" seems like a pretty arbitrary goal when a means to clear a physical cart's SRAM exists.
I would like to argue this as how we do it now is with external, non-official software on a hacked up cart but an empty battery would also reproduce what we need for this run to sync, so yeah, maybe.
What I would really like to know is what factory fresh carts unpackaged by kids with mullets and awfully colored clothing looked like in terms of SRAM. Were they tested? Were they cleared? Was it whatever state the SRAM took when installed?
Time difference between zeroed-SRAM vs arbitrary SRAM is something like .004% of the overall run length (out of my ass guessing calculation)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I'm so gald you enjoyed the run, ericjsepulveda! Your enthusiastic feedback is welcomed and very much appreciated; thank you!
Just so you know, I am redoubling my efforts to complete a Somari TAS. Additionally, I think I can save a few more frames in Sonic Jam 6, so look forward to an update in the near future!
If you have any further suggestions or know of any top-quality games I have not yet TASed, please let me know!
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Maxim wrote:
Games use it as a random seed because its value is not deterministic, as the CPU clock runs for a while before the power stabilisation components allow it to start executing code.
Then would this be as simple as an RC circuit on the reset line to delay Z80 startup? The docs I see say when Z80 is reset, R is set to 0 - but I can't see if it is level or edge triggered? (does it increment while in reset?) Some docs say you can load R, some don't, so I'll assume not. Obviously I am not too familiar programming the Z80 =)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
1. Yes I understand Dega is inaccurate. Most runs here are using Dega so for the only game I had for a while (Alex Kidd MW) I used Dega input. And it works, up until the second level, because of the RNG... The other games I tried were with the other emulator, with similar failures.
2. I think I am updating immediately on vsync, so I need to add a changable delay so that I don't update during a read (probably not happening, but...). My point was that I need to put in a wide variation of blank frames during the BIOS routine before the game runs to get any kind of sync.
3. From register, ok. Nothing in the BIOS, this will be game dependent?
4. Vsync detect is probably OK with SMS, unless I can't really get input to sync up and input lag is involved and not emulated properly.
But you mention controlling registers this way...are you thinking an expansion ROM that sets the register to what the emulator expects, then sets the cart slot to active? (But this would require a delay to insert the cart since cart slot is checked before expansion?) This cart could even be used to signal to the replay device when it is OK to start sending inputs - when the !OE goes high after going low then the cart is selected and running...
Or maybe even a replacement BIOS although this is getting into HW mod territory? I have three original SMS and could always hack one up but an external removable mod used for determinism / verification is preferred over modding the console. Is the connector pitch 2.5mm or 2.54mm?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Worked on SMS tonight. Wrote a dumper for BH. The way sync works is with vsync detection as I don't have any other kind of polling to work with. Unlike dega, I need to give the run ~627 frames lead time (dega with Alex Kidd in Miracle World was ~489 frames lead time) for the bios to complete.
Aladdin did not sync - it always trips on the barrel after the rock/thing on the floor and gets caught.
Wonder Boy ML did not sync - never goes through the second door. But like AKMW, the RNG for drops is different every time the game is run.
Can someone look at how SMS BIOS (specifically v1.3, I have 3 of them) works to see what it does to RAM and if it is responsible for weird RNG? Then take a look at the game to see what it is responsible for? Is RAM not initialized? Or is it and some hardware facility is being used to seed RNG? Is some hardware facility being used directly?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
derula wrote:
Hmm, which makes me wonder if it would be possible to make a specially crafted cartridge that you plug the real game cartridge into. This cart would take care of initializing memory, and then just re-routing the original game. It could have a separate input from the bot, upon which it would halt the game, initialize memory again, and restart the game. Kind of like one of those cheat modules that used to be all the rage.
Of course, there are multiple concerns about this:
- Is it even possible?
- Would this be recognized by the TAS community as a valid console verification aid?
- Would it make non-TAS scene people make more suspicious of what it does / think we're just cheating?
This was my initial plan before doing cart swaps - repurpose a Game Genie for this but with some custom hardware or software.
My plans were not going to have separate input for reset on this board; it wouldn't be necessary. If you are talking about power/reset inputs that pulls the reset line and chooses what to do at startup (init WRAM or not), yes that could make things easier to verify, but is not actual "input" or comparable to the motions of input we did when we played the games on real hardware. (This is even less true on consoles like SMS or Genesis that do not tie the Reset line directly to the Reset button.) While it is a prep phase, the console is not usually "power cycled" in this fashion. In NES case it's almost but not quite equivalent to the power button, but would suffice for verification purpose - if it synced this way it also would with a power button. Basically, my thoughts are that a verification that did not use this kind of device would trump one that did.
Responses to your dash points:
- It should be possible, yes
- If the code and interaction of with hardware is known, at least in the case of NES, probably.
- My decision for not doing it this way is primarily for this reason. The secondary reason is that the swap cart and WRAM erase cart were way easier.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Catastrophe wrote:
Sometimes we accept runs which are technical improvements, but slower, due to correctly emulated lag.
I think TheAxeMan is making an academic case that this run is similar to a "slower improvement". Except instead of lag frames, he's blaming the cold RAM and inaccurately emulated resets for the time difference.
I agree. The author says that this run should be a new category and that it isn't meant to obsolete the current run. He's being modest. We wouldn't make new categories for "Takes advantage of emulator inaccuracies" or "Breaks the rule and starts from a save state", right?
We don't yet know what is possible with the hardware; what we do know is that cold power cycles take time and the NES cold state is different from the FCEUX cold state. What we are pretty sure of is that for most games, reset playback would likely work. Power cycling is the real problem / concern. (Reset could have problems too but I believe they won't be; this could probably be tested with a specially crafted FF test run before my bot supports resets)
It could very well be possible, with console clearouts in between or an array of prepared toploaders, to verify the existing site run. To verify against one console would likely take longer than this run. The emulator masks the power cycle time, and the inaccurate starting state makes it impossible to naturally achieve a compatible RAM state*.
Awhile ago a rule was made to require all runs to start from power on, not a save state. I think we should also require special games like FF to start from zero RAM too. At least for the NES.
This FF run, as does the prior run, does start with cleared cart SRAM and FCEUX-style console WRAM. SRAM isn't the problem, the emulator is the problem. But this game is unique in that for console verification, a typical cart is going to be used and have an unknown RNG. This run is unique in that it can be run to gain information used to calculate the RNG, and can also be regenerated to play against any possible RNG.
For the purposes of my verification videos though, I reset cartridge SRAM to all 0x00 as an empty SRAM would also have.
* again if we only make sure the RNG byte is set appropriately (according to TheAxeMan) it may sync. I think this byte falls on a 0xFF value in FCEUX which is why cold consoles won't sync this game.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Demon Lord wrote:
If the other runs don't sync on real hardware and this one does, they should be considered as if they were made using a buggy emulator*. There were precedents where that was enough to accept a slower movie, if I remember correctly...
We don't know if they won't sync yet. We are currently in the gray area. What is fairly certain (but also needs to be tested) is that the other runs, should they sync, would no longer be controller-only input and not even just power/reset buttons - there is the cart ejection mechanic and console prep stage as well between every power cycle. And further, these take time, so the real time elapsed from start to final input would likely be longer than this run.
I however don't think that this movie should obsolete these other runs, but it should be linked in the description of the current run as a reference.
FYI this run wasn't ever meant to obsolete anything.
I'd like a white mage "universal" run too, by the way...
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
My actual name is "true," but the forums have had it as "True" for a while. It doesn't bother me that they're different.
This shows the forum account "True" as an applicable account to the player profile "true"
Maybe it is because it doesn't show up in Latest Publications yet. Doesn't really matter, I am not concerned, the runs I do are not the ones many look forward to.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
FriendChckn wrote:
Someone else mentioned it but I think the best thing to do is provide a link to a video of the machine performing the emulation
What emulation?
SmashManiac wrote:
In my opinion, to approve this type of submission, it needs to be tested against all possible dirty RAM and SRAM states. Simply impossible. Not to mention that True already mentioned that this test would fail.
Why must this test be run? Why don't other verifications have this requirement? It makes no practical or statistical sense. Can you elaborate?
If we were to plug the cart SRAM into an emulator or run either run on hardware, neither this run nor the power/resets run will sync somewhere around 1/256th of the time because the RNG value in cart SRAM will typically be unknown to the runner. A neat property of this run is that it can be modified to sync and run in similar time to this original run (if you don't count this setup phase) after running the first couple of minutes and performing an offline calculation. This is true for any cart SRAM value and true for emulator or console.
However the cart can be erased to match what the technology used in the SRAM does for "empty" (thus acting like a typical dead battery situation; it also happens to be the default for FCEUX) and it WILL sync as-is. This is acceptable for verification because this is practically possible on real hardware on its own, and also possible to force it with an unmodified console and custom code as a separate setup event. (See accepted dirty SRAM runs with verification videos for prior art.) I do the latter for these runs.
Unless the emulator zeroes WRAM, all console runs of this game will require setting up the console WRAM to match the emulator's WRAM pattern which, for FCEUX's pattern, is a statistical impossibility to ever happen naturally on any NES console*. (Don't give me "theory" shit about that; if you have a rebuttal, bring content.) I'm not great with statistics but I'm sure I could get some help to run some practical tests put the numbers together to substantiate this theory, rather than "DO THIS BECAUSE I SAID SO" theory.
Please remember, the emulator assumes a specific cold console state which is important to playback of this game. One can tweak the emulator to match possible values in hardware (a previously mentioned Cheetahmen 2) but we aren't doing this. We are instead making the console match the emulator as best we can, and using the same setup state as almost every other NES run on this site, just so we can run this run properly on a real console. What we have to do to make this sync isn't "natural" and for syncing purposes it wouldn't matter if it was the power/resets run or this one. What could be done instead is the WRAM in the emulator could better emulate a typical cold power NES, in which case the console RAM erase wouldn't be necessary. But without this step, unless using multiple consoles, it is highly likely any run using power cycles would not sync, and a certain amount of time may need to pass between power cycles, thus making a power/resets run longer. (Unlike what you wrote, this is a valid and testable theory)
This game is not like other commercial NES games. The RNG in WRAM and the battle RNG in SRAM is a unique combination that currently warrant a run of this type.
But even if that was possible and the test passed, I still wouldn't approve it because it foregoes using Reset and Power, even though this is definitely possible for a bot to perform.
No, it isn't possible for the bot to perform, yet. You are welcome to make one that does to prove your point. But even when (if) my bot or another bot can, the runtime as executed on console from first power-up (you decide if setup time counts) to final input will likely be longer than this run, unless very fast theoretical NES hardware cart manipulator robots did it or multiple consoles were used, in which case it would at least still be slower than the posted time. (And it wouldn't any longer be a bot just playing a game...it would be a meta-playback of sorts.) Unless the clock has drifted. Theery.
I like what the author is trying to do here, but it's a tech demo designed to work around technological constraints that can theoretically be bypassed. It only has value until a realistic solution to bypass those technological constraints is found.
For the first sentence, I'm still not understanding why unsubstantiated theory trumps repeatable, proven facts and practicality when nothing stops said theory from obsoleting this when (or if) it isn't theory anymore. But for the second sentence you basically finally state what the point of this run is about, and simultaneously invalidate your main argument. Congratulations.
As for entertainment, I'm voting No as it is slower than the current publication (thus not as entertaining for me),
If power cycles and SRAM setting takes 0 time, OK. But I guess the illusion of speed gives you "theoretical entertainment."
and because it's not the input that I would find entertaining in this case, but a successful recording on an actual NES.
Again, this is coming, and for your "entertainment" I am waiting to do this for when I have visual input aids. These are currently in production and I should get them in 2-3 weeks.
I'm sorry, I just don't understand why you say this run needs to pass arbitrary practical tests, but still you "wouldn't approve" because of theory. Runs have been accepted here that could be "theoretically" as well as practically improved. If we waited for practicality to meet theory we might just be finally accepting the first run of SMB in another 5-150 years (FMA theoretical calculation).
On another note, I swear people don't read discussion threads on TASVideos, as shown by the repeat posts under different names.
(*) For specific write-before-read address values, see what RAM is accessed without init. Maybe someone can post these, and determine which are important.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sirmola wrote:
...was the fact that the theoretical tas superhuman could configure the external enviornment so that the system ram started in the right way. This also applies to decay on poweroff as far as i can tell, so the current run could be done on a console by said superman.
I take it you didn't read my post.
Therefore, the fault lies in the setup for not being able to do things that are theoreticaly possible but practically impossible.
This is incorrect. It is not theoretically possible for the NES to have the same starting state as FCEUX unless directly outwardly manipulated. Time will not give you this state, ever.
If you have some factual basis on the topic for which you have written, please provide it. Otherwise you have contributed nothing but opinion to a factual conversation.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sirmola wrote:
oh. i see. Is it theoretically possible for the ram to clear itself after a short amount of time given the right environmental conditions,
Clear to mostly 0x00, yes,
because if so, we can follow the same logic used in the acceptance of the "chetahmen two" tas, which used a bug that meant that a certain uninitialized ram state skipped half the game.
FCEUX does not initialize to all 0x00; there is a 4bytes 0x00, 4bytes 0xFF pattern in console RAM.
Sirmola wrote:
As such, this sounds like a case where the bot simply does not have the environmental manipulation skills required to pull off the tas.
It is an emulator problem. Without this emulator problem then only an initial cart clear would be required, and some time....but that also means that without multiple consoles that replay would 1) not be deterministic and 2) would take longer than this run does.
My general point is that a console verifiable run does not deserve its own catagory it no other distinguishing characteristics are preasent.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sirmola wrote:
I honestly don't think that this is a good branch idea. Although i like console verification of runs as well as the next person, having a slower branch with a different route just to get it to verify correctly seems rather arbitrary to me, especially because the issue is not an emulator bug and it is the verification process that is buggy
The verification process is not buggy. Right now we have to compensate for the emulator that is buggy in that it does not behave as a console does in order for the run to sync. Every power cycle in-game will require an erase pass on the console to make it match the incorrect emulator. I also thought we strive to TAS games, not the emulators they run on (well, usually anyway)?
Also, when playing back, this run will likely be faster, as the erase process and cart swapping for power cycling takes time - it isn't an instant process like shown in the emulator.
Antronach wrote:
I'm gonna have to vote no on this, since it's a somewhat arbitraty goal
How so? Isn't the goal to TAS games? Isn't having a run that is confirmed to also work on console an extension of that - again, TASing the game, not the emulator? The goal choice seems very clear, concise and well-defined to me. For most games, this branch simply wouldn't exist as either the fastest run would verify, or no runs would verify. Final Fantasy is currently a technical and possibly also a practical exception.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Console verification video will come in when I get my input display boards, which will probably be mid to late October. If there is high demand for recording this without input display I can do it but I think the wait will be worth it.
EDIT: Actually, I could run this with my old bot and old display board if people want to see this run on console with input display.
To clarify on the console erasing: erasing console RAM is REQUIRED. I haven't ever been able to sync FF without first erasing the console RAM to match FCEUX's empty RAM pattern (which isn't empty by the way). I wrote the RAM eraser ROM which is really very simple.
To get this input file to sync as-is, without scripts, code written by scrimpy can be burned and put on a cart. This code runs in RAM and it will erase the cart SRAM for MMC1 or MMC3 carts with 00, FF, or FCEUX pattern (why? don't know) depending on button input. So for this run the eraser cart is then removed and the Final Fantasy cart put in, P1 button A is hit, and if the screen turns blue the cart is erased and ready to go. A toploader or modified frontloader (10NES disabled) is required to hotswap the cart. This was all tested late last night; TheAxeMan and I watched the run verify in its entirety. One or two others people even saw the whole erasure setup.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
IIRC they actually looked nearly as wrong on a TV as they do in the emulator. I'll be doing heavy SMS stuff in the next couple of weeks and can test the games and show photos.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Somari also has some shit controls but there is a lot more global stuff that could be optimized so I really need to tear that one apart to re-do it.
Yeah, the plan is to do it at some point, but I work full time and when I don't work I am working :( I preferred Somari too having played it when I was young...nostalgia and all that. Would also like someone to show progress to or to work with and that seems to be hard to get for these pirates.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
It isn't Mario physics, in any way at all. The game engine is an original engine even if some of the content isn't.
Has the inputfile been updated yet? It is in this post.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Been very busy with non-TAS projects. Here is the status of TAS projects.
MultiReplay: The first three recipients got theirs, and two have used it to verify games. The last finally got back to me and should be doing it soon. Will be making more when I get my oven controller board in and modify my oven. I also need to order more parts.
Verification videos: I have a large backlog. I will get to them when my visualization boards come in. These are boards that look like controllers and have LEDs to show input being pressed. They connect to my MultiReplay device, but the output pinout has been kept the same as console for NES and SNES so could technically be wired up to the controller output directly in parallel. Maybe speedrunners who run live on console would like this to visualize the buttons they are pushing on camera?
SMS: not much progress; this is the next thing to be completed before other major progress. Lots of stuff to do here. I will have time for this soon.
NES: Thanks for scrimpy's help, he wrote a PRG RAM eraser that can be booted from a cart, removed, the target game hot-inserted and a button press (or a few) later, erased. Has options for erasing MMC1 and MMC3-enabled carts and has been tested so far with MMC1.
My bot now has an option to slow down clock detection to work around emulator / console inconsistencies (generally fixes A Boy and His Blob playback).
SNES: Nothing interesting
Lynx: I have one, it doesn't boot
Game Gear: I have one, it boots but has a fucked up screen. I wish I had a dev board for this or more games.
