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.
I asked this before, and it seems ok as long as its for testing purposes*.
*Probably refers to glitches like memory corruption, where accuracy plays a large role, but....
Also, for NES, there are so many dodgy mappers that support in anything except original cart is questionable.
SNES is much more regular. Unless game uses expansion chips, pretty much the only source of variability is memory mapping (which can be expressed as a few memory address ranges and some properties of those).
I asked this before, and it seems ok as long as its for testing purposes.
Yeah, this of course would not be sufficient for putting the console-verified checkmark next to a run. But it would make it a lot easier to demonstrate playback of lots of games at an event like AGDQ. You could theoretically even have a kiosk setup where visitors could request a run and watch it play back.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
I find that when I'm working on projects like this I tend to go in sprints of research followed by sprints of experimentation. At this point, I think I've wrapped up a good bit of experimentation and I'm back into research mode, at least as far as the Pi is concerned. Here's where I'm at, with a grainy shot of the Pi in the distance.
There's a lot going on there. Here's just the breadboard.
The stuff on the right is left over from when I still had the dip switches connected. On the left, there are connections from the NES to the Pi with voltage potential divider resistors to knock down the voltage so the 5 volts on the latch and clock from the NES doesn't hurt the Pi. There's also an NPN transistor to bump up the voltage from the Pi to the NES on the serial data line. A few things are connected back for monitoring purposes. Here's some ASCII art of the connections with all of the various pin and GPIO mapping notations, drawn by reusing (abusing?) wiringPi's gpio readall command.
+----------+-Rev1-+------+--------+------+----------------------------+
| wiringPi | GPIO | Phys | Name | Mode | To/From |
+----------+------+------+--------+------+----------------------------+
| 0 | 17 | 11 | GPIO 0 | IN | N/C |
| 1 | 18 | 12 | GPIO 1 | IN | Read serial (Phys 8) |
| 2 | 21 | 13 | GPIO 2 | IN | N/C |
| 3 | 22 | 15 | GPIO 3 | OUT | N/C |
| 4 | 23 | 16 | GPIO 4 | IN | N/C |
| 5 | 24 | 18 | GPIO 5 | IN | NES latch, ~? kHz |
| 6 | 25 | 22 | GPIO 6 | OUT | Out to Phys 7 |
| 7 | 4 | 7 | GPIO 7 | In | In from Phys 22 |
| 8 | 0 | 3 | SDA | IN | N/C |
| 9 | 1 | 5 | SCL | IN | N/C |
| 10 | 8 | 24 | CE0 | IN | N/C |
| 11 | 7 | 26 | CE1 | IN | N/C |
| 12 | 10 | 19 | MOSI | IN | N/C |
| 13 | 9 | 21 | MISO | IN | N/C |
| 14 | 11 | 23 | SCLK | IN | N/C |
| 15 | 14 | 8 | TxD | ALT0 | Serial to NES and Phys 12 |
| 16 | 15 | 10 | RxD | ALT0 | NES clock, ~117 kHz |
+----------+------+------+--------+------+----------------------------+
In this state it's possible to send random garbage down the serial line toward the NES and occasionally get the A button to be triggered (as observed by viewing the Game Genie screen) but not much else works. Yet. This is where the research phase starts. It might be that I need to order parts to create a buffer between the NES and the Pi or try various software methods to reduce latency and jitter. I'm not sure yet. There have been a lot of ideas thrown around in this thread already, but I'm going to set the Pi aside for a day or two and see if I can get the loaned Arduino up and running using micro500's original design, as I believe I have everything I need to at least test the original NESBot with my copy of Tetris. I might even try Dragon Warrior and see if I can Console Verify a new game. :)
Thanks for all of the support and ideas from everyone both here in this thread and on IRC in #TASVideos,
A.C.
******
The code I sent you will press whatever button you want, most of the time; it will also jitter around and press other stuff too or nothing at all as well from I believe lack of detecting the 1us pulses. I don't think it's a code problem, but a pi problem for it doing this as I've described.
Also my code doesn't send garbage; it looks at latch to set up the output and clock to clock out the output. You define output - can be from input file, the code I sent you currently just tries to hold whatever buttons you define. Should work with the parts you have even.
I am ordering buffer parts because I think that will be the route to go. But no longer will it be just connect-to-Pi-and-go (with level shifting)...isn't a quick hack-it-together thing anymore. Still, if this works I will design PCB and circuit and provide infos.
EDIT: Using attiny13 pulse stretcher, the Pi was still unable to reliably detect pulses. Really, an MCU is probably the best way to go with this, especially considering the multitap SNES support that the end device needs.
'm going to set the Pi aside for a day or two and see if I can get the loaned Arduino up and running using micro500's original design, as I believe I have everything I need to at least test the original NESBot with my copy of Tetris. I might even try Dragon Warrior and see if I can Console Verify a new game. :)
Will you ever expand on the original design and support multiple controllers?
'm going to set the Pi aside for a day or two and see if I can get the loaned Arduino up and running using micro500's original design, as I believe I have everything I need to at least test the original NESBot with my copy of Tetris. I might even try Dragon Warrior and see if I can Console Verify a new game. :)
Will you ever expand on the original design and support multiple controllers?
The original NESbot (and my prior unfinished PIC-based bot) feed the 4021, which is the chip the original controllers use. It's barely possible to get a an Arduino working with two controllers I think using only two 4021, maybe not with the default Arduino peripherals (maybe so? don't know) and certainly so with another chip or two, but with a raw ATMEGA328P this can be done.
But that said, I am working to get straight serial output working to the console, eliminating the need for the 4021. The project will not only support multiple controllers, but should be able to supoort multitap and Genesis as well. This will reduce chip count and price should others want to implement it. As I understand it multitap SNES is ultimately dwangoAC's intention. Ultimately the Pi won't work without buffering, and with the chip counts required for SNES multitap with even a parallel out from the Pi it makes going back to a microcontroller pretty appealing.
That doesn't mean software or even the GPIO on the Pi can't be used, it just doesn't need to be used. But maybe a nice LCD front-end with a browser could be donw using Pi GPIO... I'll think about that...
Right now I'm working with a 328P trying to get instruction count down and will probably need to write some careful asm during latch and clock to get the response times I need. If clocks are still too slow I can move on to PIC32MX or something faster and still attainable in DIP for easy soldering. (I don't care about the chips; if people want to solder TQFP or things like that I'll go with anything. I just happen to have 50MHz PIC32MX in DIP in my parts box.) Faster MCUs typically run at 3v3 and will need level shifting but I've already made up a board for that for the Pi, and some (like aforementioned PIC) have 5v tolerant pins already =)
+----------+-Rev1-+------+--------+------+----------------------------+
| wiringPi | GPIO | Phys | Name | Mode | To/From |
+----------+------+------+--------+------+----------------------------+
| 0 | 17 | 11 | GPIO 0 | IN | N/C |
| 1 | 18 | 12 | GPIO 1 | IN | Read serial (Phys 8) |
| 2 | 21 | 13 | GPIO 2 | IN | N/C |
| 3 | 22 | 15 | GPIO 3 | OUT | N/C |
| 4 | 23 | 16 | GPIO 4 | IN | N/C |
| 5 | 24 | 18 | GPIO 5 | IN | NES latch, ~? kHz |
| 6 | 25 | 22 | GPIO 6 | OUT | Out to Phys 7 |
| 7 | 4 | 7 | GPIO 7 | In | In from Phys 22 |
| 8 | 0 | 3 | SDA | IN | N/C |
| 9 | 1 | 5 | SCL | IN | N/C |
| 10 | 8 | 24 | CE0 | IN | N/C |
| 11 | 7 | 26 | CE1 | IN | N/C |
| 12 | 10 | 19 | MOSI | IN | N/C |
| 13 | 9 | 21 | MISO | IN | N/C |
| 14 | 11 | 23 | SCLK | IN | N/C |
| 15 | 14 | 8 | TxD | ALT0 | Serial to NES and Phys 12 |
| 16 | 15 | 10 | RxD | ALT0 | NES clock, ~117 kHz |
+----------+------+------+--------+------+----------------------------+
In this state it's possible to send random garbage down the serial line toward the NES and occasionally get the A button to be triggered (as observed by viewing the Game Genie screen) but not much else works. Yet. This is where the research phase starts. It might be that I need to order parts to create a buffer between the NES and the Pi or try various software methods to reduce latency and jitter. I'm not sure yet. There have been a lot of ideas thrown around in this thread already, but I'm going to set the Pi aside for a day or two and see if I can get the loaned Arduino up and running using micro500's original design, as I believe I have everything I need to at least test the original NESBot with my copy of Tetris. I might even try Dragon Warrior and see if I can Console Verify a new game. :)
Thanks for all of the support and ideas from everyone both here in this thread and on IRC in #TASVideos,
A.C.
******
(I'm agill in IRC) You know that clock/latch data scheme is quite amenable to the SPI standard (or I2C with post processing). Is it at all possible to use the SPI interface (MISO/CS/SCLK) to reliably latch the data? Or will the SPI interface still be choked by other kernel activity? CS might be a bit tricky - maybe you can fiddle it by doing burst transfers and keeping CS low for long periods of time?
Edit: Does the Pi even support slave mode? I saw your IO port list, and they all said input... It probably requires some research on if a driver is available.
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
DK64_MASTER wrote:
Does the Pi even support slave mode?
Apparently the Pi only supports being the master for both SPI and I2C. This is unfortunate, but I suspect this is for the same reason as why I've had to abandon the Pi being directly connected to the NES - the Pi isn't reliable about listening for short pulses on the GPIO pins. So far, this is the best that my setup can do (with help from zid').
This shows a Raspberry Pi holding the left button as measured next to the Pi's GPIO. The Pi often misses these latch and clock signals and leaves the line high which presses every button. Yellow = Clock from NES, Purple = Serial data to NES, Pink = 5V from NES, Green = Latch from NES. The end result of this is if you play Dr. Mario the pill will get shoved to the left but will "bounce" one spot to the right for a fraction of a second every once in a while, and may even get rotated. This means that in order to use the Pi some kind of buffering method is needed which means I will need to order parts.
Until I figure out which parts to order and get parts shipped, I've started working on creating the original NESBot design micro500 created using the Arduino a co-worker lent to me (thanks, twm!). So far I've only laid out the breadboard connections, but they do look pretty to me.
One thing I'm still missing for the original NESBot design is an SD card holder, but I might try to modify the design to fetch the movie data from the Pi. That will require software changes, which will require a better understanding of the Arduino and AVR programming so we'll see if that's still my plan after I do some more research. :)
Thanks for the helpful comments and the interest,
A.C.
******
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.
Ohh, so roots of TASing are once again found in Japan. Great finding, feos.
It seems the device already allowed to save input log to audio tape (like Excitebike and Family Basic did), so at least in theory someone in mid-80s could load the data from the tape, edit it in a hexeditor and record back, then load to the Game Repeater. Man, this is exciting to know.
lol, pretty neat. Basically what I will do except not so huge and with non-volatile storage and review. But it is 25 years later...
---
Re: Pi replay, I have a PIC32-based pseudocontroller working with two players having dual serial out (to support multitap). I tried using an ATMEGA328P but a combination of architecture and really shit compiler made it infeasable, I could have did some asm hackery at it but why? With the PIC32 it works really well - 2.6us of latency for data0, 3.2us for data1, without even optimizing it yet. It already should be plenty fast enough even for SNES and can get faster. And this chip comes in DIP so it's easy to breadboard and experiement with. (That said, it's running at >40MHz, so results may vary running it on a breadboard)
Going to work on frame counter and lag frame detector (direct replay of TAS files without an intermediate emulator step may be possible) and the UART interface. It shouldn't be long before this works.
edit: lag frame detector done, geeky LED added and reset detect implemented - so if reset is held down for 5 seconds, the MCU can signal to the computer to restart playback.
---
Re: the NES or SNES replay controller, haven't even started, will start when the above project is done.
What if the Pi's video output (or a small portion of it) would be added to the AGDQ stream to present information to the audience?
you could use it to show button presses, playing status, and a stopwatch that automatically starts when playback starts.
Joined: 4/17/2010
Posts: 11476
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Neat.
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.
What if the Pi's video output (or a small portion of it) would be added to the AGDQ stream to present information to the audience?
you could use it to show button presses, playing status, and a stopwatch that automatically starts when playback starts.
I basically have this now (frames total (normal / lagged), time per frame, button presses, will be adding elapsed movie time later, simple little command line thing, just blow it up I guess :)
Will have a lot to show in a week or less.
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
It's been a busy couple of weeks. After giving up on connecting directly from the Pi (despite zid` spending hours experimenting), I tried to go back to make the original NESBot design based on the files included in the Instructible. Unfortunately, I ran into a lot of problems, mostly with the processing script (i.e. the movie to SD card transfer script written in the programming language named "processing"). It also took me a fair bit of time to populate the breadboard - there were a lot more jumper wires than I thought there would be.
I borrowed an analog scope that I could keep a bit more long-term, and the family cat decided to supervise.
Eventually with some help from DarkKobold pointing me in the right direction I got the code in the console-tas code repository to function correctly after finding the Arduino library dependencies. The newer code relies on a tas.txt file on a FAT filesystem on the root of the SD card as opposed to the processing script, which saves having to populate a load switch and makes switching files a bit easier (mostly - it can be a bit tricky getting the SD card off the breadboard, but the jumper wire SD harness I hacked together held up surprisingly well).
One thing that really plagued me with testing this is that on my setup I see low resistance between the latch and clock lines, perhaps because of something interesting going on inside the 4021. The long and short of it is that when I turn on the Arduino, voltage flows toward the NES on the latch line with the result that the NES either doesn't turn on or goes to a white screen. Sometimes I could get past that problem and get into a game but I could never get HappyLee's SMB1 run to sync even after what felt like hours of attempts with both the old and the new code. I *was* able to get Baxter's Tetris Mode B to sync after only a couple of attempts, however, and that made me very happy. I've been at this project for weeks now in my spare time and this is the first time I've actually seen a TAS movie sync to the end on my desk. I dabbled at getting other games to work, but the setup is so finicky that I think it's best to wait for a newer solution.
There's a lot to say about said newer solution which involves a board that true designed and I ordered from OSH Park but because the PCB hasn't arrived yet I don't want to go into too many details just yet. I'll make a follow-up post once the board is in and we can do some testing. As always, please feel free to ask questions and let me know if you have any broken SNES controllers as I still need some of those. :) Thanks!
A.C.
******
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
arkiandruski wrote:
Would it be possible to maybe do some Genesis verification there?
That's definitely the idea. If someone has a Genesis that they would be willing to donate to the cause I would be most appreciative, and I can pay for shipping. I'm also on the lookout for broken SNES controllers.
Thanks for your interest,
A.C.
******
GhostSonic's previous attempts have shown that the Genesis emulator used for TASing is not very accurate, so genesis verifications will be difficult to do (about equal in difficulty to verifying a SNES TAS not made with Bizhawk/bsnes)
I figure Genesis will be a pain.
The first version of my board will be for 2P+ NES and SNES (including multitap). Next board should work with any modern controller with up to 8 I/O lines per port, 2 ports, and with supporting code...aiming for NES/SNES/Genesis/N64. Should also be plug-and-play. But I'm not going to worry about it until the NES/SNES code is tested on the current board.
I can't do Genesis on the current board because I don't have enough IO, and N64 would be rough because of speed. Next board should be able to do more (SD card mode option, for example) so I'll save it for then.
----
As for parts I need to test bots, I still need an SNES and a couple of controllers (been looking at thrift stores, haven't got lucky yet, though a friend has but he won't give it up...). Can't test SNES stuff without this. Also need games to test with...I can borrow some from a friend but his collection isn't very large.
For Genesis I will need a console. I have a small collection of games for this.
If you are in the US and want to work something out, contact me.
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
dwangoAC wrote:
arkiandruski wrote:
Would it be possible to maybe do some Genesis verification there?
That's definitely the idea. If someone has a Genesis that they would be willing to donate to the cause I would be most appreciative, and I can pay for shipping. I'm also on the lookout for broken SNES controllers.
Thanks for your interest,
A.C.
******
I sent my old genesis to micro500 about 2 years ago to do just that, make a gensbot. He kept me posted for about a year but then I didn't hear anything else about it. I sent him a couple messages to check on things and see if I could get it back if he wasn't actively working on making the bot, but he read my messages and never responded. If anyone has a more useful way of getting a hold of him, please let me know. I'd still be happy to donate it (and the 10 or so games I sent to him) to the same cause, if anyone else is interested in actually working on it.
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
mmbossman wrote:
...If anyone has a more useful way of getting a hold of him, please let me know. I'd still be happy to donate it (and the 10 or so games I sent to him) to the same cause, if anyone else is interested in actually working on it.
I will attempt to contact him by E-Mail; I also sent a TASVideos forum private message to him and did not receive a response which Adelikat said is not uncommon for him, so it's not just you. :) I probably won't worry about games until we've had a chance to test out the Genesis code, and as noted the emulators are not yet very accurate so I'm preparing for the reality that some games will not sync correctly.
Thanks for your offer and support of this project! I'll be sure to keep in touch.
A.C.
******
Uh...kinda late, but can I suggest Kirby's Adventure as one of the TAS's to showcase? It's nice, short, and breaks the game into pieces.
I know it uses hard reset, but I think it was mentioned somewhere that it could be resynched to work with an ingame soft reset.
There's a lot going on there. Here's just the breadboard.
The stuff on the right is left over from when I still had the dip switches connected. On the left, there are connections from the NES to the Pi with voltage potential divider resistors to knock down the voltage so the 5 volts on the latch and clock from the NES doesn't hurt the Pi. There's also an NPN transistor to bump up the voltage from the Pi to the NES on the serial data line. A few things are connected back for monitoring purposes. Here's some ASCII art of the connections with all of the various pin and GPIO mapping notations, drawn by reusing (abusing?) wiringPi's gpio readall command.
This shows a Raspberry Pi holding the left button as measured next to the Pi's GPIO. The Pi often misses these latch and clock signals and leaves the line high which presses every button. Yellow = Clock from NES, Purple = Serial data to NES, Pink = 5V from NES, Green = Latch from NES. The end result of this is if you play Dr. Mario the pill will get shoved to the left but will "bounce" one spot to the right for a fraction of a second every once in a while, and may even get rotated. This means that in order to use the Pi some kind of buffering method is needed which means I will need to order parts.
Until I figure out which parts to order and get parts shipped, I've started working on creating the original NESBot design micro500 created using the Arduino a co-worker lent to me (thanks, twm!). So far I've only laid out the breadboard connections, but they do look pretty to me.
One thing I'm still missing for the original NESBot design is an SD card holder, but I might try to modify the design to fetch the movie data from the Pi. That will require software changes, which will require a better understanding of the Arduino and AVR programming so we'll see if that's still my plan after I do some more research. :)
Thanks for the helpful comments and the interest,
A.C.
******
I borrowed an analog scope that I could keep a bit more long-term, and the family cat decided to supervise.
Eventually with some help from DarkKobold pointing me in the right direction I got the code in the console-tas code repository to function correctly after finding the Arduino library dependencies. The newer code relies on a tas.txt file on a FAT filesystem on the root of the SD card as opposed to the processing script, which saves having to populate a load switch and makes switching files a bit easier (mostly - it can be a bit tricky getting the SD card off the breadboard, but the jumper wire SD harness I hacked together held up surprisingly well).
One thing that really plagued me with testing this is that on my setup I see low resistance between the latch and clock lines, perhaps because of something interesting going on inside the 4021. The long and short of it is that when I turn on the Arduino, voltage flows toward the NES on the latch line with the result that the NES either doesn't turn on or goes to a white screen. Sometimes I could get past that problem and get into a game but I could never get HappyLee's SMB1 run to sync even after what felt like hours of attempts with both the old and the new code. I *was* able to get Baxter's Tetris Mode B to sync after only a couple of attempts, however, and that made me very happy. I've been at this project for weeks now in my spare time and this is the first time I've actually seen a TAS movie sync to the end on my desk. I dabbled at getting other games to work, but the setup is so finicky that I think it's best to wait for a newer solution.
There's a lot to say about said newer solution which involves a board that true designed and I ordered from OSH Park but because the PCB hasn't arrived yet I don't want to go into too many details just yet. I'll make a follow-up post once the board is in and we can do some testing. As always, please feel free to ask questions and let me know if you have any broken SNES controllers as I still need some of those. :) Thanks!
A.C.
******
