Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
After my last post I took everything I had to the office to use the oscilloscope.
The breadboard came up fine, even with lots of probes attached.
We started with just the clock connected.
A few things surprised me - for one thing, the scope showed that the Game Genie ran the CPU at around 112 kHz, but Dr. Mario ran at 43 (I think) and Mario ran at 78 as tested with a single controller connected. The scope had a USB port and a print ability, so I saved off a few screenshots. Here's the state while running the Game Genie.
This shows the clock in yellow, the data in purple or blue, and the latch in green (although apparently we'd bumped that when we saved the images from the unit itself). In the above image, the latch only hit once, but when I plugged in a second controller while playing SMB3, the clock went to 16.1 kHz and the latch triggered twice in a row.
While the scope was attached I was able to get everything working with the dip switches so flipping an appropriate switch caused the correct button press to be sent to the NES. I even managed to stomp the first Goomba in SMB3 using just the dip switches.
Now that I'm completely confident that I have reimplemented an NES controller on a breadboard, my next step is to tear this down and further investigate WiringPi and get cracking on getting level shifting going for the CPU and latch lines into the Raspberry Pi. I need to get the +5 volts headed from the NES to the Pi down to a safe level of between 2.5 and 3.3 volts as well as boost the 3.3 volts the Pi will send down the serial data out line up to 5 volts. I have limited parts on hand but I'm going to try to get something working with what I already have and then plot my next parts order.
I am still actively looking at the option of making a common connector from the Pi to a common plug type and converting each console's controller type to act as the wiring harness and console-specific circuitry holder, but the one problem with this plan is this may complicate working with multiple controllers. The other option would be to create a single PCB that could support NES, SNES, N64, and perhaps Sega, but that's a bit ambitious so I'll worry about those decisions later.
Thanks for the feedback and keep it coming!
A.C.
******
Extra bonus if it could be used as a regular gamepad as well (perhaps there could be a switch to select which mode it is in.)
Indeed, it would be a great feature which could make the device look more credible in the eyes of casual gamers.
Actually, it would be even more awesome if the gamepad could also log the buttons while in the "normal gamepad" mode, and then replay these while in the "TAS replay" mode (mode 3?). This would introduce even the most ignorant people to the concept of logging and replaying input (without needlessly bringing the next, complicated step: tools like savestates, etc). And no problem if these replays are going to be desync-prone - even a single successfull public attempt to replay World 1-1 of SMB should be enough to get the idea.
Extra bonus if it could be used as a regular gamepad as well (perhaps there could be a switch to select which mode it is in.)
Indeed, it would be a great feature which could make the device look more credible in the eyes of casual gamers.
Actually, it would be even more awesome if the gamepad could also log the buttons while in the "normal gamepad" mode, and then replay these while in the "TAS replay" mode (mode 3?). This would introduce even the most ignorant people to the concept of logging and replaying input (without needlessly bringing the next, complicated step: tools like savestates, etc). And no problem if these replays are going to be desync-prone - even a single successfull public attempt to replay World 1-1 of SMB should be enough to get the idea.
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
OMG, I insanely second the idea of recording real-time presses!
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.
should be easy enough to implement. I'll consider it as another project... my 4mbit NOR flashes come in next week, which should offer lots of recording time.
A controller that can replay the button presses you previously entered? Sounds cool. But I doubt it's the right tool to explain to others what a TAS is. Unless that controller can do savestates, slowdown, memory watch and LUA scripting. ;)
Thanks for the detailed descriptions, dwangoAC. I'm purely a software guy and can't claim to understand half of it, but it's interesting to read.
A controller that can replay the button presses you previously entered? Sounds cool. But I doubt it's the right tool to explain to others what a TAS is.
Explaining or demonstrating a subset of what a TAS is goes a long way in explaining what it is. True, savestates, etc are tools used, but they are just that--tools. They do not explain the concept behind a TAS.
The replay controller sounds like an excellent idea for conveying that TASes are not "cheated", i.e. they play within the game's logic. It'd be totally useless for conveying what making a TAS is like, but that's fine.
Another possible idea might be some way of having an input display. Just an array of LEDs hooked up to the buttons or something so people can see the input that the controller is sending.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
Derakon wrote:
Another possible idea might be some way of having an input display. Just an array of LEDs hooked up to the buttons or something so people can see the input that the controller is sending.
That's an interesting idea as well. My plan was to only modify the original controller with an extra port to connect to the Raspberry Pi and require that to be present to do any playback, but the idea of putting everything in the controller is very interesting and is likely a better fit for your idea. I wish True the best of luck with that.
Thanks for the ideas,
A.C.
******
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Input display may be some additional panel. Building it right into controller sounds like an overload. As for the panel, if it has a point-based display of one color, it could be drawn at like we draw with lua (snes9x does it perfectly as well):
P1: ABsSLRUD
P2: ABsSLRUD
etc
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.
But I doubt it's the right tool to explain to others what a TAS is. Unless that controller can do savestates, slowdown, memory watch and LUA scripting. ;)
The things you mentioned (savestates, etc) are only representing the current phase of TASVideos history. They don't tell us what a TAS is, because they are not inherent to TASing:
1) they are often used for other purposes outside TASing
2) TASes can be created without them, for example, this TAS was made entirely in a text editor, and this one was solved by a bot without using emulator.
But what is actually inherent to TASing? I say, only the fact of editing the replay data. That is essentially what a "rerecording" is - a rerecord happens not when you load a savestate, but when you overwrite old logged buttonpresses with new buttonpresses.
Of course, savestates help to quickly navigate backwards in the movie (in order to edit previous buttonpresses), but they are not necessary (if you don't have savestates, you can just replay the movie from the beginning - sure it's time consuming, but then, if we're talking about comfort, even our conventional savestate slots aren't the best way to navigate the movie, and everyone still uses them, so I guess it's just a matter of habit, and not something truly fundamental).
So yes, this kind of gamepad functionality is the right tool to explain what a TAS is. Unless you also want to explain which emulators and tools are popular at TASVideos today.
Derakon wrote:
It'd be totally useless for conveying what making a TAS is like, but that's fine.
What do you mean useless? It does convey the idea how you can make a TAS without an emulator: first you record an imperfect playthrough, then you transfer the input log to an editing environment (e.g. Notepad), there you change some buttons and then upload the file back into the gamepad, replay it and see the changes, then make some conclusions and repeat the process until you're satisfied.
Of course, this process would take hundreds of years to produce a publish-worthy TAS, but the supposed "gods" have infinite time, so the workflow is perfectly legitimate.
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
BTW, if such tool gets widely available, the SDA's mark "verified, no cheating" would finally lose its sense :P
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.
But what is actually inherent to TASing? I say, only the fact of editing the replay data.
Indeed. The fact that the input is not generated by holding a controller and playing the game, but by artificially constructing the best possible input one can imagine using any tools available.
Which is why I dislike the idea of a replay-controller for the AGDQ presentation: it limits the input generation to holding a controller and playing the game.
Sure, none of the tools I mentioned are required to make a good TAS. There are other tools I didn't list. But holding a controller is probably the worst tool we have, it's absolutely insufficient in terms of precision and efficiency when aiming for perfection, and I disagree that there should be much focus on this way of TASing.
AnS wrote:
Of course, this process would take hundreds of years to produce a publish-worthy TAS
Remember that the timeslot during AGDQ is somewhat limited, so it's important to bring the point across as quickly as possible. That leaves more time to show off our best TASes :)
feos wrote:
BTW, if such tool gets widely available, the SDA's mark "verified, no cheating" would finally lose its sense :P
<ot>That mark is no more than a marketing gag. There have been cheated runs officially sanctioned with that mark. Many runs are encoded by the players themselves, so you have the situation of runs being submitted for verification that already contain the mark.</ot>
Input display may be some additional panel. Building it right into controller sounds like an overload. As for the panel, if it has a point-based display of one color, it could be drawn at like we draw with lua (snes9x does it perfectly as well):
P1: ABsSLRUD
P2: ABsSLRUD
etc
I was going to do this with a 16x2 on the pi - show controller input, lag detect and frame count. But that comes after everything works. :)
Re: all this controller stuff, there's nothing to cry about, it's just a neat toy gimmick idea and doesn't really apply to TAS. It could be useful to realtime speedrunners, to perhaps see in slow motion where they could improve after the fact, or just to post the runs so others could emulate them. Or maybe it won't be, who knows, it just sounds like a cool idea.
Waiting to get some controllers...
But what is actually inherent to TASing? I say, only the fact of editing the replay data.
Indeed. The fact that the input is not generated by holding a controller and playing the game, but by artificially constructing the best possible input one can imagine using any tools available.
I was stressing the fact that the data is being modified (instead of live performance, which also generates/constructs the data, but does it on the fly).
The point is that in TASing the input is being constructed incrementally, by polishing previous attempts and being able to compare/revert to old progress (unlike in live speedruns where, if you managed to pull off a trick, you can't be sure you'll repeat it in another situation). The gamepad with replays reflects this point very clearly, so I think it would be immensely useful.
Tub wrote:
Which is why I dislike the idea of a replay-controller for the AGDQ presentation: it limits the input generation to holding a controller and playing the game.
I don't think anyone is going to assume this is how TASes are actually made, since emulation is well-known concept, while the gamepad will be presented as a novel concept. So no need to worry about the possible misconception. Conceptually.
Tub wrote:
Sure, none of the tools I mentioned are required to make a good TAS. There are other tools I didn't list. But holding a controller is probably the worst tool we have, it's absolutely insufficient in terms of precision and efficiency when aiming for perfection, and I disagree that there should be much focus on this way of TASing.
The focus should be put on replays, not on tools. Tools come up as a natural step towards comfort and efficiency.
Tub wrote:
Remember that the timeslot during AGDQ is somewhat limited, so it's important to bring the point across as quickly as possible. That leaves more time to show off our best TASes :)
But it's very important to show the inherent legitimacy and naturalness of TASing, since a lot of people still consider it somewhat farfetched (if not plain cheating).
What they don't realize, is that any recorded data (both input and output/AVI) may have been edited after it was created and before it was seen. The only way to be sure of the "live performance" is to actually be somehow involved in the process of generating the input (e.g. to make a random request to the player and receive certain feedback). Whenever the probing is impossible, you can only believe that the recorded replay wasn't edited. Probably. Most likely.
Well, there's always some probability of cheating involved in regular speedrunning, but it is neglected because it's rather small. While in TASing there's basically zero cheating, since the title says clearly: the replay data was edited. And provides an insight on how exactly it was edited, how many times, etc. Basically, in the whole world of gaming, TASing is the closest analogy to Open Source paradigm. It's literally the opposite of cheating.
Tried interfacing with pi.
Latency is just too high, and jitter is pretty bad too. This will probably only work if input is buffered or parallel out is used (which eats up pins).
EDIT: Latency was my bug. Jitter is fairly high but not high enough to really affect things, about .5uS, except I think it spikes sometimes... The other problem I think is unreliable detection of the clock pulse and latch, each is about 1uS, which may be fixed by stretching the period but I'm not so sure.
Right now the Pi is holding down A and Right. This is what it should look like.
It screws up regularly.
Sometimes it doesn't even bother. I think it didn't see the latch so it didn't get set up correctly though.
Sometimes it misses a pulse, which is what I think the problem really is. Here it misses one somewhere in the middle.
And one right at the beginning, pressing both A and B...
Ultimately with how it is acting I do not think the Pi is a reasonable platform as a playback device. It can probably feed a buffer but it can't respond directly to the NES. I will have to try stretching the clock low and latch high (looks like about 1us right now) to see if it picks up better, but with it sometimes completely missing, I don't know if it could ever work right.
Is the rPi a realtime device? I'm not familiar with it, but if it's meant to be a computer-on-a-chip running a "normal" OS then it's going to have much less reliability when it comes to timing than you'd like. Unfortunate.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
Derakon wrote:
Is the rPi a realtime device?
Sort of. There are things like http://www.xenomai.org/ that has a realtime kernel which runs on the Pi, and we might have to play with that. It's more likely that we will need to buffer the output with another chip so the timing (latency and jitter) are improved; the data rate of the Pi is definitely high enough based on the performance data from this report:
http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/
In other words, the problem is still solvable but will likely require more work.
A.C.
******
Is the rPi a realtime device? I'm not familiar with it, but if it's meant to be a computer-on-a-chip running a "normal" OS then it's going to have much less reliability when it comes to timing than you'd like. Unfortunate.
not realtime, and there are problems even with realtime patched kernels. realtime just means guaranteed service time, it doesn't mean immediate, so we may still have the same problems...
If the thing needs buffered, why not just use an mcu and be done though? I guess it could be cheaper with a buffer but that's if you don't consider the pi price...
EDIT: I guess logic is cheap enough. I'll work on a pulse stretcher sometime soon with the parts I have and see if that fixes it. If it doesn't the only way it'll work reliably is serial out to the formats desired by the controllers. I'll get some various logic ICs on order.
Doesn't look like I have much to do this passively; passively extending 1us can be tough as it is.
I'll probably program an attiny13 as a temporary trigger / stretcher. But ultimately I don't think we can rely on the pi for suitable output, the timings are probably just too tough to match reliably. I mean, I can probably get them to match but then something might come along and hold the CPU for 1ms in the middle of the data output and now we're out of sync. :(
If pulse stretching works and I can reliably play back without interruptions then I'll design a circuit using monostable multivibrators to stretch the output. If not I'll design one as mostly 74xx and 4xxx logic. That is, IF we don't have >10ms delays holding us back...
Regardless, my goal is probably going above and beyond dwangoAC's initial requirements - my final circuit will probably use 4 GPIOs to run outputs for one of 2 NES, 2 Genesis or 2 SNES at a time, and probably have generic outputs for other consoles. Hopefully that will be enough for anybody.
Well, good luck! And keep us posted as to progress, please. This stuff is fascinating to me even though I've never tried to build anything like it myself.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
A co-worker of mine pointed out the following kernel-level ISR project:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=72&t=33880https://sites.google.com/site/hamlinhomeprojects/projects/raspberry-pi-isr
It looks like this gets interrupts down to 2.5us to 7us and could be worth looking at. In the meantime, a different co-worker loaned me an Arduino Duemilanove which I can keep through January so I can build the original NESBot based on micro500's design as well, although I'm still dedicated to getting the Pi working.
Thanks to everyone who has provided help thus far - there is no way I could do this without the assistance.
A.C.
******
Random question - Can a NESBot be made to be compatible with a Powerpak and thus allow console verification of any NES game? Or is there a technical reason making this impossible?
Possibly, but that is yet another dependency, and is still pretty high considering what the NES is expecting. I am getting similar response by directly polling I think. I won't know the limits until I stretch the pulses out a bit.
dwangoAC wrote:
In the meantime, a different co-worker loaned me an Arduino Duemilanove which I can keep through January so I can build the original NESBot based on micro500's design as well, although I'm still dedicated to getting the Pi working.
You know you can just order some samples from Atmel and have your own for free...use the one you are borrowing as an ISP loader for the chips. You can even put on something like usbasploader so you can program it with avrdude. Just need some 3v6 zeners, a few resistors and a 5v psu :)
Random question - Can a NESBot be made to be compatible with a Powerpak and thus allow console verification of any NES game? Or is there a technical reason making this impossible?
It looks like the Powerpak has a built-in file browser. Movie playback typically starts from power-on of the console, so that browser would cause desyncs. It would probably be easy to fix by just inserting the necessary browser-navigation input at the beginning of the movie, though.
I don't know how the Powerpak actually works, but assuming that everything after that point is like playing the game normally, it should be fine otherwise.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The breadboard came up fine, even with lots of probes attached.
We started with just the clock connected.
A few things surprised me - for one thing, the scope showed that the Game Genie ran the CPU at around 112 kHz, but Dr. Mario ran at 43 (I think) and Mario ran at 78 as tested with a single controller connected. The scope had a USB port and a print ability, so I saved off a few screenshots. Here's the state while running the Game Genie.
This shows the clock in yellow, the data in purple or blue, and the latch in green (although apparently we'd bumped that when we saved the images from the unit itself). In the above image, the latch only hit once, but when I plugged in a second controller while playing SMB3, the clock went to 16.1 kHz and the latch triggered twice in a row.
While the scope was attached I was able to get everything working with the dip switches so flipping an appropriate switch caused the correct button press to be sent to the NES. I even managed to stomp the first Goomba in SMB3 using just the dip switches.
Now that I'm completely confident that I have reimplemented an NES controller on a breadboard, my next step is to tear this down and further investigate WiringPi and get cracking on getting level shifting going for the CPU and latch lines into the Raspberry Pi. I need to get the +5 volts headed from the NES to the Pi down to a safe level of between 2.5 and 3.3 volts as well as boost the 3.3 volts the Pi will send down the serial data out line up to 5 volts. I have limited parts on hand but I'm going to try to get something working with what I already have and then plot my next parts order.
I am still actively looking at the option of making a common connector from the Pi to a common plug type and converting each console's controller type to act as the wiring harness and console-specific circuitry holder, but the one problem with this plan is this may complicate working with multiple controllers. The other option would be to create a single PCB that could support NES, SNES, N64, and perhaps Sega, but that's a bit ambitious so I'll worry about those decisions later.
Thanks for the feedback and keep it coming!
A.C.
******
It screws up regularly.
Sometimes it doesn't even bother. I think it didn't see the latch so it didn't get set up correctly though.
Sometimes it misses a pulse, which is what I think the problem really is. Here it misses one somewhere in the middle.
And one right at the beginning, pressing both A and B...
Ultimately with how it is acting I do not think the Pi is a reasonable platform as a playback device. It can probably feed a buffer but it can't respond directly to the NES. I will have to try stretching the clock low and latch high (looks like about 1us right now) to see if it picks up better, but with it sometimes completely missing, I don't know if it could ever work right.
