Watched this after being referred from AGDQ2014 Tasbot block 2. It would be interesting to go for an 'entertainment' obsoletion of this run.
Is that demo part of the payload or part of the input sent in the movie file? If the former, great. If the latter, then it should be as optimal or entertaining as possible.
Will there be voice acting for the NESBot now that he has a personifiable avatar?
I originally tried putting the Raspberry Pi up around his neck, but it didn't quite look right to me.
I'm using zipties at the moment which don't look too bad but I might try to find a better solution. I admit that I really like the impression that this gives that ROB is playing the game in question. My next step is to hook up the GPIO pins on the Pi to the LED on the top of ROB's head to make it flash every time a button is pressed. This could be a bit more of a challenge than normal as from here on out I don't have home-field advantage; we're leaving to visit family for Christmas and won't be back home until after AGDQ, so I'll have to do the rest of this "in the field".
Thanks again for everyone's support!
A.C.
******
How about SM64?
I at least have an excuse for why the SNES wires are a bit messy at this prototype stage, but even then, I had to get extremely creative to get the second controller DATA1 wire to stay in place by using a small screwdriver crammed in to keep the wire from slipping out.
The biggest problem I have is lack of proper jumper wires.
This is a good example of how not having enough equipment makes everything take so much longer to wire up. Between the Pi and the PCB, I have two old fan connectors hooked up to serial TX, RX, and ground, and the power is connected using two blue jumpers on a breadboard wire. The wire nuts prevent TX and RX from shorting to ground. Suboptimal is probably not a strong enough word. I'll be ordering a lot of parts later this week (after the US Thanksgiving holiday tomorrow) so I can make this a whole lot cleaner. Everything has to be portable enough to make it through the airport in carry-on luggage come January so I plan on putting together a proper wiring harness for the two SNES controllers with a pigtail at the SNES end similar to how USB powered DVD drives are designed.
Having said all of that, I am very happy to say that I was able to get the SNES glitched run to complete on my setup, which makes me exceedingly happy. As long as wires are in the right places it's very reproducible, which along with getting Gradius to sync is exactly what I was hoping for at the beginning of the project.
I'll be doing a dry run of what I plan on presenting at AGDQ 2014 on December 10th when I'll be giving a presentation at the North Bay Linux User's Group. Linux was a key aspect of this process as I used FCEUX and lsnes Linux ports to convert the emulator-specific movie files to the correct format for the replay script which itself is running on Linux on a Raspberry Pi. With true's permission I plan on releasing the gerber files for the PCB as well as the PIC code and replay scripts as open source (likely with a simple attribution license) as soon as everything is cleaned up.
Again, thanks to everyone for the support!
A.C.
******
It's a bit tight with the scope probes connected, and I'm not entirely certain I haven't crossed a wire here.
At the moment I'm not seeing sane controller input but as soon as I can sort out my wiring problems (hopefully by taking apart a third controller and using its connectors) I'll be able to get SMW going myself. Again, huge thanks go to true for his work on scripts, and for Ilari for his work on lsnes and assistance understanding how to work with its lua scripts. Back with more soon,
A.C.
******
Is there an encode for this run?
There were some tricky bits, such as needing to solder a jumper wire to short a populated resistor that was causing problems. I did this soldering myself at home with solder with lead in it and I haven't thoroughly cleaned the board yet but it still looks pretty good.
I was able to solder the NES cable onto a header (more specifically, this part was actually done by the same co-worker who helped me with the bulk of the soldering) and I used some glue to keep everything in place. After flashing the latest firmware I hooked everything up.
Linux (in my case, Linux Mint XFCE edition) immediately detected a "USB Abstract Control Model driver for USB modems and ISDN adapters" device so I crossed my fingers and attempted to run Super Mario Bros.
I'm happy to report that SMB synced to the end. This looks far cleaner than my earlier breadboard setup and is the first result that I'd be comfortable taking to the marathon. Next up, I need to figure out what the SNES controller pinout is and give that a shot, but that might have to wait until true can get an SNES of his own.
A.C.
******
One thing I've discovered is that true has a lot of parts and I don't. This is something I need to fix, but in the meantime the consequence of my lack of parts is I end up devising some creative hacks (case in point, I had to build my own SD card holder using jumper wires when I worked on the NESBot, but I digress). I had to come up with a pretty messy setup to go between the PCB and the Raspberry Pi (which is acting as a UART serial data source containing movie files and a script to send them across said UART serial interface). I finally resorted to using pinheaders off of old fans from a neglected Pentium II, but this only got me three of the four wires I needed (+3.3 volts, ground, RX, and TX). For the final wire I ended up using a jumper and jammed a wire into it - it worked well enough. :)
I moved the NES connector over and re-used the same method of connecting it to the breadboard. I didn't bother depopulating everything from the NESBot, so it's still on the breadboard for the moment. I'm happy with how the blue wires fanned out, but I'll have to tighten everything up when I get to two players.
I'm very happy to report that this crazy contraption was able to sync SMB1. Next step - obtain a copy of Gradius and work on getting another broken SNES controller (I have one, but I need one more).
Again, thanks goes to true for the amount of time and effort he's put in to the PCB. Thanks for everyone's interest and support!
A.C.
******
Seemingly busted SNES controller for sale here if you still need one: https://forum.speeddemosarchive.com/post/wts_a_lot_of_video_games_nessnesn64_ntscu.html
...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.
Would it be possible to maybe do some Genesis verification there?
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.
******
Does the Pi even support slave mode?
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.
******
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 |
+----------+------+------+--------+------+----------------------------+
Is the rPi a realtime device?