Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Hard drives don't have an expected "lifespan" per se, other than a warranty and the MTBF listed in the datasheet. For modern drives the MTBF may be quoted as 2 million hours, but only have a 3 year warranty. They will fail when they fail.
A good model- and vendor-neutral rule of thumb is after 3 years of use, expect significantly increased chance of failure for every continuing year of operation. (I get this from experience, anecdote, and from information like this, though see the next paragraph.)
Hard drive quality has improved in the last couple of years; we are seeing less failure rates in the field than we have in the past. (Others are too - see this for example.)
Some drive models have more problems than others. Historically HGST (even under WD ownership) have been the most all-around reliable brand, and Seagate the least. Reliability depends heavily on model and technology shifts and drive handling more than the brand though. WD has models that fail more than Seagate's average, and Seagate has some models that are industry leaders in reliability. They have also had models that are the worst the industry has seen.
External drives are also the most likely to die, mostly from user handling that an internal drive does not experience.
Most people with heavy brand preferences have them based on a small number of drives and their past experiences. If they had good luck, they don't want to feel they could be wrong, so their brand choice is the only correct one. Others could have completely opposing experiences. I've posted Backblaze information in the links above, and while they primarily use desktop class drives, it isn't suitable information to draw a conclusion on drive lifetime in home use scenarios. Keep these points in mind if asking for drive recommendations. Look at the specific model and its failure rate if you can find it, keep the brand secondary.
A hard drive sitting idle and unpowered, undisturbed externally, should work and retain data for a long time - between a decade and a century or so. The most likely fault when powering up a well-used or long-sitting drive is the spindle seizing. Very old drives (which were simple) and new drives (with modern bearings and lubricants) should have no problems for a long time.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Nice thread necro. It's OK here, but there are newer threads about this, or this could have went in your own since it has to do with your specific bot.
SMB isn't really affected by weird startup states. It is a good starting point for testing basic sanity of NES robots.
Why Arduino? I only ask because there's like 15 Arduino implementations of NES bots now. Why not leave the comfort zone and use hardware better suited to task?
Re: your problem specifically, there are a number of questions:
- Have you looked at it with an oscilloscope?
- How are you exporting frames from the emulator?
- Is the game an original cart?
- How are you managing timing? SMB is one-input-per-frame safe on polled frames, with no DPCM. But once you move to other games, you'll need to use either a window, or a more accurate emulator for per-latch input playback. Vsync or other external methods are doomed to fail until emulation is very good, and at that point you might as well use the controller for clocking anyway.
- Have you measured interrupt latency? Particularly with Arduino there may be additional overhead because of context switches, pinout abstractions, etc.
- Are you pre-calculating frame data so you don't need to do it right at interrupt time?
- Depending on your implementation, initial power on will set latch high for a long time, before going idle low again. My first robots had a "latch skip" feature for this reason, to skip this first latch high pulse.
- Is data loaded on the bot or streamed from PC? If from PC keep in mind there is added latency with USB comms; I assume you have a buffer in this case. Also CDC is probably the slowest way to do this but is the way just about everyone uses right now. If your buffer is too small, make sure your streaming code is not preempted by other things on your computer.
- Several other things haven't thought of yet
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
OmnipotentEntity wrote:
I was given an unfair percentage of the credit for work that was done by a large team of talented members.
Honestly, that comes with the territory of being the "face" of an operation. If you're not going out of your way to take credit then I don't see a foul.
That isn't and hasn't been the problem, and we who have made the events possible (from hardware to code to other planning) know this. We understand and accept that.
However, some of us (I can speak for myself at least and others have said things about it) don't care much for how these opportunities had built up ego and led to selfishness. Not necessarily with intent, mind, but that's what it had become. Hopefully that won't be an issue anymore.
I'm surprised it was considered as much of a problem at the most recent event but then again I was kept completely out of the loop so I wouldn't know. Wasn't the first time names were completely left out.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Patashu wrote:
Is it a quirk of the real SNES console that is being faithfully reproduced? Or is it an lsnes-specific quirk and not really related to a real SNES?
How hard would it be in theory to reproduce this TAS on a real SNES?
SNES uses PSRAM, so values are random (with possibly some per-console bit pattern probabilities). Runs should not rely on starting state unless they have a sufficiently high probability of success. The community hasn't defined what this probability should be, though.
Cart swapping doesn't work on SNES because of CIC, and physical interlock on the original release console. Holding the console in reset doesn't work either, as the CIC will not release reset until power cycled. This is unlike NES which will renegotiate after reset.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
micro500 wrote:
And then at the end of this event I felt like the team was largely uncredited for all of the hard work we put in.
Hey, at least you were mentioned at all, had credits in the actual event, ...
micro500 wrote:
Looking back at the time I spent over the past year doing all of this, it wasn't worth it.
I felt the same about it for the first AGDQ. A lot of time burned into it, the satisfaction of getting things working well near right up until go time... then being ignored about certain specifics, being kept out of the loop, having the event displayed so poorly, needing to explain to people live what is going on because even the basics weren't explained, ...and my name isn't even said once. This continued on into further events.
Not the same but some similarities and shared root causes, surely.
There is far more going into this event than what there was three years ago. You described the last minute efforts taken. Many of us who have had impossibly large projects with looming deadlines can relate. I understand the feelings you hold now, particularly if you were doing this solely or primarily for the sake of the TASBot project.
For what it's worth, I wanted to contribute / help out this year, and hopefully, possibly reduce some of this burden, but I was snubbed. I know many were involved but from what I've heard things seemed pretty compartmentalized. So while some of the burden was spread around, the secrecy and your silence helped to self-impose some of that burden. I say this not to blame, but to clarify some other failings I saw as an outsider this year.
As for TASBot, was this project your primary goal? I continued work on robots never just for TASBot's sake. My goals were personal improvement and console preservation. If your goal is more than TASBot then I'd still like to talk with you about some of these in the future.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
MrWint wrote:
DrJones wrote:
Is it possible to hardware verify TASes in the Game Boy Color?
Hardware verification at least for this TAS is very unlikely, the precision required to sync the inputs it up is likely to great.
They said the same thing about Rockman 2.
They said the same thing about SMW.
They said the same thing about Battletoads.
Yeah, this is different. No, I don't think this run will sync, because the emulator isn't cycle accurate. When we gain that accuracy, I can verify runs like it.
Matriks404 wrote:
Hardware verification? lol
If it wasn't for that, we'd in all likelihood still be TASing against crap, inaccurate emulators.
Doing a run like this is possible. Even on an unpolled console like Gameboy. I just need the emulation to be cycle accurate with correct timings and I will make a bot to do it.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Do you have ffmpeg headers installed?
I've always had this issue when cross compiling but sorry to say, I can't remember what workarounds I have used to get past it. This is the best hint I can give.
You might want to speak with Ilari on IRC.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I will test Streemerz and any other games I have this weekend.
If any other runs for games I do not have are posted but I have donor carts for them, I will test them if my EPROM eraser was not stolen.
EDIT:
Alyosha should have some info to help track down problems now.
- Streemerz had somewhat deterministic desyncs
- Battletoads acted strangely, with nondeterministic desync, though the most common desync point was at the stage 1 boss. I can't remember this game desyncing nondeterministically with other runs.
- MM4 was extremely nondetermistic but had a finite amount of desync modes. If we can find the culprit then maybe we can take a guess as to what the "perfect" NES has. If it is console SRAM (doubtful), then I can clear the console on run attempts.
- MM5 desynced once, but could have been the bot. Synced two other times just fine
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
It will be important to note, based on experience and your testing list:
* How many controllers should be connected, and/or if count is known to matter
* What specific issue is being targeted in the run, for example DMC timing, so the bot can be set appropriately
* If the robot should, on the console, react to every poll exactly as the emulator does (DMC timing test) or if we should use a frame window mode
* If a run starts from reset
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
TASeditor wrote:
True: You did use the latest BizHawk release? And set it up to NESHawk, 1 controller connected? After importing you need to delete one frame before reset.
I used latest autobuild. Which release should I be doing this with? Also it wasn't mentioned about deleting a frame...I'll run whatever input I am given directly. Core and settings were set properly.
Alyosha wrote:
I might try making a run that does not have a reset in it just to minimize the number of variables for now.
I don't think that affects anything right now, but it does simplify testing, so not a bad idea. Should this work go to the general Kirby thread, or the NESHawk development thread now?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sappharad wrote:
Is modifying a CD-based console to make it deterministic going to far to be considered valid console verification?
It's hard to say.
I have a dream of eventually making a hardware-based ODD emulator and software plugin for some console, with matching timings and emulation matching an ideal "perfect" disc (yes, ultimately culminating in an emulation of the rotation of media and head seeks...), or at least an emulator and plugin with matching consistent performance.
Ultimately, if emulation is so accurate all we have left is the ODD, I think that in and of itself is the biggest part of victory. It's up to the community to accept something like this though.
----
Re: payloads and exploits, I understand secrecy of the payload and the argument can go either way. I'd like to think that a resolution isn't necessarily binary.
Re: work for this event, practically everything was kept very secret. Things were discussed in isolation, privately only amongst the rockstars. Previous years didn't have the level of secrecy and isolation that the TAS demoscene did this year. Before my real life issues started I offered to help and was snubbed with no real substantive response. What I offered help for wasn't figured out, so who knows, maybe things could have been different? Still, a solid "yes" or "no" would have been nice.
edit: didn't finish writing
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Alyosha wrote:
@True: the desyncs at the start menu are probably due to the reset, how does your bot handle that?
My bot doesn't. Kirby will sync when reset manually though, so my input starts past the reset point and I manually release reset to start play.
Alyosha wrote:
Desyncing in the first room is interesting, I'll have to look into that. Is that desync consistent?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
1) The FM2 you linked, exported from FCEUX, desyncs on first screen. Does not get the slide before the mix.
2) Your k2 file performs well until the glitch, and it fails. Both of my robots do different things but I think one of them is handling it correctly. Changing the amount of frames before starting doesn't affect the outcome from 0-3 frames extra.
3) TASeditor said the fm2 desyncs in bizhawk at second screen. Trying to import it, it desyncs at start menu. I need a file to test.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Alyosha wrote:
TASeditor wrote:
Please update the submission with this 8 frame faster run: User movie #36341054517440931
I couldn't get it to a glitched ending, so those who wanted a clean ending are lucky.
I couldn't get this version to sync on BizHawk. It makes it about half way through the second room. I also tried a build without glitch reads and got the same results.
@True: Maybe this would be a good one for console testing? It might give more information then simply failing on the glitch like the other runs.
If it is an FM2 it will surely desync. I'll run it as-is. I still need to know how many controllers should be connected for these runs. I'll also try running one you posted previously. Running in about an hour.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
jdaster64 wrote:
Yeah, I must have tuned out right before the SM64/Portal streaming stuff was explained. Really impressive from a tech standpoint, but I feel it might have had a better reception if it were explained more beforehand.
Welcome to GDQ TAS Blocks. This is how they all have gone.
I'll keep my other opinions away from here as they won't be any more constructive.
The block pulls in the dollars though.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sour wrote:
I guess I could make it so Mesen only polls input once per frame, at the moment the game first requests it, then returns the same input subsequently until the next frame starts - it would allow per-frame input to stay in sync, wouldn't really increase input lag, and should have relatively minimal impact on players.
Please don't do this. This results in more problems than it solves and is not accurate.
Either store inputs on every latch, or have an option to do this or per-frame input.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Dwedit wrote:
I don't think DMC channel state at bootup is consistent. Try playing Blades of Steel, and see how the demo changes every time you play it.
Yes, this game shows this off. In testing though for some reason many other games are consistent - SMB3 for example will always have glitched reads of the same length at the same spots. The variation here is if the console is powered from cold power or reset though, and in this case I would have a different but _consistent_ pattern coming out of reset.
---
I don't know what hardware I have left that wasn't stolen or destroyed, but I am pretty sure I saw my Kirby cart and I think I have enough to put something together and test this run after work.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Having very serious personal life issues, it will be a bit before I can pick up tests again. Starting over, over and over again, year after year, is taking its toll. And I'm forced to do it again now. Sorry.
If you have any tests feel free to accumulate them and if nobody else does them, I will try to get to them done within 1 to 3 months.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Alyosha wrote:
Actually half the RAM is explicitly cleared (0-0x400) at startup, and most of the rest is properly initialized by loading values from ROM, so it's not 3 out of 16384, more like 3 out 16-20 (for whatever RNG bits that I haven't had time to track down.)
That is the game doing that though. Do we track the possible entropy on a per-game basis then, based solely on RAM access? And what if something is missed, like the initial submission? This gets us back to odds. Do we play odds, or just run against an ideal console, considering that the more bits are set, the less probability of the state being correct?
Personman wrote:
The default branch always begins from zeroed out RAM. On a case-by-case basis, "arbitrary starting RAM state" submissions can be accepted to Moons, much as we do with "game end glitch" runs. We never draw a distinction between runs based on the number of bits they flip, unless that number is 0.
Alyosha wrote:
Personally I don't like framing anything in terms of moons-vault since I would hope to see that distinction removed someday, so I hope whatever decision is made can avoid that, but that being said, doing things on a case by case basis seems fine to me, not much point trying to frame a sweeping policy on what might amount to a small handful of runs overall.
Somewhat agree, but if we go this route, _what the case must be_ and why it is a valid exception is what needs to be determined now.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
andypanther wrote:
I don't understand enough of this stuff, can anyone explain the difference between this TAS and the published Cheetahmen II TAS by adelikat?
Thanks.
I thought I replied to this, but I guess I fell asleep before posting.
In Cheetahmen II, a single mapper register is being set to an arbitrary value.
In this run, NES RAM is being set to an arbitrary value.
In the former, I don't particularly agree with the submission, and had anyone else posted it, it may not have been accepted. But still, this mapper is not as well understood at the physical level, and it has been demonstrated to have this effect on console.
In the latter, NES RAM can also have arbitrary state, but there are 2^16384 possible startup states. Some are far more likely than others, with the most likely on average being that of zero bits set.
The difference is that of one settable register on hardware that is on the cart (8-bit register?), to three specific bits set and all others cleared out of 16384.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
feos wrote:
I mean an emulator feature to switch ROMs isn't required.
But if the end effect is that this is required anyway, why would this specific method get a pass, when actual console input is not submittable until an accepted emulator supports the format "natively?" (because, as I understand it, the input in an interpreted code format, versus a file->open format, is currently not allowed)
feos wrote:
But what could be the differences introduced by any ROM we previously run other than just memory state?
- Bus errors during swap causing a freeze, or worse, other undefined behavior, such as but not limited to:
- Register states possibly being different
- Mapper registers or states possibly being glitched by hot insertion
- Different DMA cycle alignment
The console was not designed for swapping carts while powered on. Just because it can, doesn't mean it works every time or is deterministic. My Final Fantasy verification YouTube video took about three dozen takes before I got the two swaps to work successfully.
feos wrote:
Second, if it is reproduce on console without (the traditional meaning of) cheating, we could allow it.
What is the "traditional" meaning? And why do traditions matter for "cheating," but not for the arbitrary execution of code before the game even starts or tainting of memory?
In fact, traditions have given us things like the completely wrong FCEUX startup memory state.
But would running arbitrary code at startup entail "cheating?"
grassini wrote:
how would the initial ram be created in a reproduction on console?
feos wrote:
A cart with a ROM on it that just sets those values and is then replaced with the actual game cart.
And yes, this is what it comes down to - arbitrary code needs to run to set the bits necessary to make this run sync.
----
Certain given states may be as statistically likely as the all-zero state, but only one state has the most statistically significant chance of sync in games that read and utilize before write, and that is of all bits cleared.
The NES is not designed with hot-swap carts. As much as we say "super human inputs" even for 30hz mashing, it isn't a physical impossibility of the input hardware. Swapping the cart however IS something that can't be deterministically performed, as the console was not designed for it, and in fact cannot be performed on the original version of this hardware without modification. And should we introduce a cart-swap delay? Because it can't be physically cleared and replaced in one frame or less time.
---
feos, So you are saying, cart swapping on NES is valid input now? Even though emulators don't support it, and the games and consoles were never designed nor exploited by commercial titles to do this?
Should this submission have such an arbitrary code ROM attached to set RAM, or is having the finger of God poking some bits high acceptable?
If the former, why are we allowing arbitrary code to run before the title in question? If the latter, is it not "cheating" because God does it?
As stated before, these consoles were NOT designed to hot-swap carts. To get runs with arbitrary memory values to sync on an ideal NES, either a modified game needs to be used, or a setter cart runs arbitrary code before the game is swapped in on a modified or specific version of the console. This unsafe, unsupported and non-deterministic swap is one of only two methods a human (or superhuman) can use to guarantee the specified startup state. We already know that a modified game is not allowed per site rules and "tradition."
I think you don't care about an "ideal" NES, which is a fair viewpoint. But having some arbitrary, impossible to achieve NES is not fine, either. And to have anything but the ideal would imply we must also have the impossible based on current discussion.
To go another way - if we ignore the cart swaps, then are we truly TASing the game anymore? If the discussion were to go this way, then I would heavily argue in that case that we are in fact running a particular emulation's view. The work is now a combined work of emulator and binary, rather than using the emulator as a means to an end. We know and accept that emulators are a means to an end now by porting of movies between emulators, console verification of inputs and attempts to improve emulation. But, if this swapless view is the accepted view, then the listed console when the game is submitted or published (in this case, NES) should be replaced with the emulator or core (in this case, NESHawk), because it isn't an NES run anymore at that point. Anything else in this case would be deceit.
Somewhat in jest, but also somewhat seriously: If we want perfect play, we should at least play on the perfect console, lest we play the console and not the game.
or another way: Perfection isn't omnipresent. It is but one state of multitudes.
