Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
pirate_sephiroth wrote:
you could try to do something stupid to make the passage of time less painful, like moving in some sort of pattern, making a step every second and completing the loop every 60 steps
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I made my nes / snes bot years ago. My newer robot is also getting pretty old. Others have made robots.
Yes, there is hardware. No, RPi won't work with a standard distro, it's been tried and analyzed, but it can operate said hardware.
I'm not aware of anyone selling any hardware. TASLink stuff is posted publicly but it is expensive and relies on obsolete hardware. total's bot is posted publicly but will require some work though not much. Not much for documentation though. My next robot will have public information, and hopefully finally some documentation in the bot space, but who knows when I'll get that done.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Yes, the IRC channel is best. We've been doing this for a while. Most is institutional knowledge though.
NESBot is not a recommended place to start. Many people have built all sorts of variants of bots on Arduino, but I wouldn't recommend that either. Doing so seems an exercise of dealing with limitations of a platform than learning how to control an NES.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I wrote my replies and then they were lost...let's try again...
Alyosha wrote:
For version I don't think emulation accuracy is at the point where we can reliably tell the difference, and loading times by themselves can always be discounted.
On the contrary. On Z80 the R register is 0 at reset. So on emulators now without BIOS, they start at 0. However with BIOS, this register will increment. So regardless of cycle accuracy, this register won't match based on BIOS or not. It has nothing to do with emulation accuracy. And many games use this register as part of randomness routine.
Alyosha wrote:
As for built in games, Vecna had the foresight to make it so that you can load BIOSes as you would ordinary ROMs as well, so any of the built in games should be accessible already.
Except this isn't how one would usually play these games...they'd use the original machine, not a copy of the BIOS of that machine on a different machine...
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
The issue of version will need to be decided. Because bootup times between versions vary, games using the R register in randomness calculations can result in very different outputs. Other than what could be copied into RAM with different BIOS versions, I'm not aware of any other impact BIOS will have. But these two are already very important.
v1.3 is the most "common" and the first / original retail version. These are arbitrary points for using it as a base. But what if the TAS is for a built-in game in a later BIOS? Should there be exceptions for this case? I would hope it isn't a "fastest BIOS" search... but who knows, maybe some game has an exploit that is more useful with a certain BIOS version?
I've done some testing on console with Alex Kidd in Miracle World on a v1.3 USA unit and found, if I remember, about 16 possible variations of randomness in powerups. None of these variations matched the emulator. I would need to test again to see if I delayed the emulator to match the frame count of the console...I don't have any notes about that written down.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Just so it is known, even today's emulators do not emulate SMS well enough. For one thing, the startup state is known to be wildly incorrect. And for BIOS / post boot state, which should be chosen?
Still it will be nice to move from old emulators and finally get some console verifications done with SMS runs.
What would it take to quickly determine if Z80 R register is read by a game, as the easiest indicator of a console verifiable run? Static analysis? Analysis during gameplay?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sorry, things have not been great for me lately... haven't been able to do tests.
Get together a test - the game (exact version), preferably the movie but a raw input dump works, the mode if a raw dump (per-frame, per-latch), and what exactly I should test for - and I will get to it soon.
For Donkey Kong Jr it looks like a small NROM128 game so I can burn and do this one, assuming I can find blank EPROMs. My eraser is missing or stolen...
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sour wrote:
On a north american NTSC NES, count_errors should technically only have a maximum of 4 different results (there are only 4 possible alignments CPU/PPU alignments) - but I could be wrong on this.
We tested PPU alignment on the frontloader I have. From either hard power or reset, I got something like 8 or 10 different alignments. Unless we didn't understand the test...
I can test what is needed on real hardware, but I am running low on EPROMs and my eraser may have been stolen.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
OmnipotentEntity wrote:
Some bits are correlated, some are anti-correlated. This might be true of groups as well. We don't know enough to demonstrate which power on states are valid and which are not.
In order to get sufficient statistical power, as much as a few hundred or few thousands cold power-ons can be be required.
In SNES case, different consoles will have different likely states, different correlations... it will not be universal. One console cannot give us the answers here.
While I don't have a solution to this problem, at a minimum I think it should be noted if a game is known to use uninitialized RAM for any routine that can change the outcome of the game.
Patashu wrote:
If all TASes were unpublished except console verified ones, the site would be very bare indeed!
Something else to note: console-verified inputs that cannot be played on emulator are also not allowed.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Patashu wrote:
Kles wrote:
How many games have that DPCM exploit?
AFAIK:
-Every NES game that uses DPCM has a high likelihood of having DPCM glitch ACE
I assume you are talking about controller read workaround, and if so, then no, this isn't the case. There have been a few tested routines so far and it turns out not as many as previously imagined are vulnerable.
MUGG wrote:
Maybe in that listing you can differentiate between total control type of ACE, and non-total control.
wat
If you can't load your own code, it isn't arbitrary. If you are limited in what you can enter (not length, but content), it isn't arbitrary. As I understand it, SML2 doesn't allow execution of arbitrary code / specific opcodes, only some subset.
The old MM1 glitch wasn't ACE even though it jumped to credits. The glitch demonstrated at AGDQ is ACE.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Overall this was an improvement. The setup was described, / there were lead-ins, people understood what was going on and the information provided generally was useful. What you could not provide directly was backed by resources and a name drop, a good way to handle it and promote at the same time.
Sticking points:
Asking a commentator "what do you think should happen" during a run, and having them try to cram some weird response in the span of a few seconds, doesn't really open up anything helpful with on-screen banter. Actually it's a big detractor. This ends up putting someone on the spot and the result is someone trying to explain two different things at once. The similar segment at AGDQ2017 was worse. No form of this works.
Speaking really fast to cram in as much detail as possible. Slow down a bit. Speedrun, slowtalk. Let the robot do the racing.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Is the next input polled at the start of the next vblank, or does this game poll at the end?
If so: the problem is the windowed mode causing that frame to be repeated. In this case, as the run otherwise syncs, I will need to dump the inputs per-latch which as I understand isn't supported yet in this emulator.
If not: it shouldn't be the bot.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Values seen in rough order of chance:
4 (when cold), 7 (reset or when hot), 8, 6, 11, 12, 0, 10, 1, 2
Need to test this against more consoles, test when cold, test when hot, and test with various cooldown times between power cycles or resets.
Need to test with Famicom.
