Editor, Player (69)
Joined: 1/18/2008
Posts: 663
I have the working PIC, just need to finish the PC side of the code. I have a USB bootloader on this thing so I shouldn't need ICSP anymore...I hope. I had no free debug boards, but dozens of spare PIC18LF2550s and no breadboard and no $$$ so I had to do what nobody should ever replicate: I didn't find out that I had extra PDIP sockets until after I was about 3/4 of the way done. Just need to hook up an NES connector to it :) Edit: whoops, forgot to attach my decoupling cap...it's there now :)
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
I've run into some extremely serious real life issues... I won't have time for this for another week or two. I have an NES (my pick between a top loader and a front loader) and a controller to tear apart, but still no standard SMB cart. Any ideas? Edit: video will obviously be made of the unit running, working or not. Would you rather see the classic front loader or is the top loader ok? I am also going to try some videogame stores since some of them have an oldass games pile. They'll probably want $5 for the game but meh.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
If I had the money, I'd ship you my copy of Super Mario Bros. (Assuming it isn't region locked, and that it isn't PAL optimised). So yeah, someone ship your Super Mario Bros. cart to True already. =P
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
I got an SMB cart. $15, sigh. Still dealing with a lot of issues...such as sabotage to my motorcycle. Almost killed me today. I am dealing with a lot of things like this recently. Once I get some time between work and sorting out stuff from moving and fixing my bike, I'll get a prototype going.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
Update: Got a prototype working... sort of. Non-ideal conditions, but meh. I am trying to just see all the latch pulses right now and I only get about one every 3-5 frames back to the PIC. Until I hook up my scope, I can't really see what is going on... Mario himself is jumping and pausing and stuff, likely due to noise on the data line. Anyone know if this should be pulled up / down? I've only been able to interpret either leave it alone or pull up, but until I get latch / clock reading properly, I'm not overly concerned about data. I'm probably missing something really easy - stress in my life is affecting my work. I mean, the main code part on the PIC is ~30 lines... if there are mistakes, I should have found them by now... Shorting clock and latch does fun stuff :) Edit: Might know what is wrong... hopefully I'll have time to work on it tonight.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Player (150)
Joined: 11/27/2004
Posts: 688
Location: WA State, USA
Maybe the fine folks at NESDev can help you out. http://nesdev.parodius.com/
Nach wrote:
I also used to wake up every morning, open my curtains, and see the twin towers. And then one day, wasn't able to anymore, I'll never forget that.
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
I think it's just my real life stress taking its toll on me. I don't have my scope handy while working on this project, so I can't quite see / compare what is going on...but it looked like I was getting at most half of the clock pulses. Anyway, re-wrote stuff to be very bare and have Mario jump every X frames and run forward. He beat the first level a few times :) but I can't seem to get it to do the same run after powering off cold for a few minutes. I think I am not seeing every latch pulse, but without a scope and the ability to see response time, I can't really know why. Running the PIC at 12 MIPS shouldn't have this happen. It's likely just the major stress right now in my life - just after I started this major things happened. I haven't even worked on the firmware I am supposed to be working on at work. The TAS input part is easy... getting it to play reliable, reproducible games is the hard part. :(
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
Wow! This sounds really cool. Keep us posted. If you finally makes one that works, I'd want one! :) Imagine actual TAS-hardware eh? =)
Experienced player (702)
Joined: 2/19/2006
Posts: 742
Location: Quincy, MA
Highness wrote:
Wow! This sounds really cool. Keep us posted. If you finally makes one that works, I'd want one! :) Imagine actual TAS-hardware eh? =)
But You're gonna put me outta business! :(
Super Mario Bros. console speedrunner - Andrew Gardikis
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
This project is on hold for at least a couple weeks. I'm going to make up a proper board... I'll be using the original NES shift register that I removed from my otherwise useless controller :) By then, hopefully stress will be reduced and I'll bring my scope home from work for testing. This is such a simple project, it really should be done in less than an hour, and I already spent a good part of a weekend with barely any good results.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Joined: 10/4/2009
Posts: 3
I did a bunch of work on this a few weeks ago, but I'm also having some reliability issues with control. Jumping and running and whatnot works okay, but I think my wiring was kinda fucked up. I am *NOT* using a shift register in my design, just emulating one. That may be not the best idea, but it *SHOULD* work fine. True, maybe we could collaborate on this?
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
Perhaps. I was also emulating a shift register but as I said, I wasn't seeing all the clock pulses so I just let the real shift register handle the load. I have a proper board made up now. Might need one or two more parts but otherwise it's ready for me to write code. I brought home my scope this weekend, but I forgot my programmer...
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Joined: 11/29/2005
Posts: 317
Location: Sao Paulo - Brazil
Wouldn't this be a threat to SDA?
Joined: 9/17/2009
Posts: 18
Location: Hungary
SpiDeY wrote:
Wouldn't this be a threat to SDA?
SDA doesn't allow hardware modification in submitted runs.
Senior Moderator
Joined: 8/4/2005
Posts: 5777
Location: Away
I think SpiDeY means it in the context of playing TASes back on the original hardware making verification more-or-less impossible. Well, what can I say? As I have verified several runs for SDA, I can say that realistically, unless there are noticeable differences between the recording and normal console output (such as lag or sound pitch), the verification process puts emphasis on the gameplay, analyzing things that can give clues on tool-assistance: button tapping speed and patterns, speed of reaction to on-screen events, accuracy, etc. So, if somebody goes through all the hurdles of creating a TAS that consistently looks like realtime play throughout, modifies the hardware, records on it and plays innocent forever after, maybe it doesn't really make any difference to the end viewer.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Player (121)
Joined: 2/11/2007
Posts: 1522
moozooh wrote:
So, if somebody goes through all the hurdles of creating a TAS that consistently looks like realtime play throughout, modifies the hardware, records on it and plays innocent forever after, maybe it doesn't really make any difference to the end viewer.
Kind of like fake "authentic" antiquities or whatnot... as long as the forger is good enough to fool everyone, it's inherent value is no different than a genuine article. Just another example of how perception is reality, not the other way around :)
I make a comic with no image files and you should read it. While there is a lower class, I am in it, and while there is a criminal element I am of it, and while there is a soul in prison, I am not free. -Eugene Debs
Joined: 2/22/2017
Posts: 6
Location: Eau Claire, WI
I know this is an older topic, I'm wondering if anybody can help me with this? I'm interested in TAS running on real hardware and I've had quite a bit of success so far. I have an Arduino board running at 64MHz and I'm using the interrupt pins to capture the pulse and latch signals and sending out controller output to the data line. My goal is to TAS run Super Mario Bros. on real hardware, and I'm a little disappointed right now that it's not consistent. I often get through the first couple levels, but that's not a guarantee. The farthest I have ever gotten is about half way through World 8-1, eventually some frame trigger fails and I have no idea where the randomness is coming from. Does anyone know of what may be causing my frames to be captured incorrectly? I understand lag frames, but is there anything that may cause like a random lag frame?
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3807)
Joined: 11/30/2014
Posts: 2828
Location: US
BryGuy wrote:
I know this is an older topic, I'm wondering if anybody can help me with this? I'm interested in TAS running on real hardware and I've had quite a bit of success so far. I have an Arduino board running at 64MHz and I'm using the interrupt pins to capture the pulse and latch signals and sending out controller output to the data line. My goal is to TAS run Super Mario Bros. on real hardware, and I'm a little disappointed right now that it's not consistent. I often get through the first couple levels, but that's not a guarantee. The farthest I have ever gotten is about half way through World 8-1, eventually some frame trigger fails and I have no idea where the randomness is coming from. Does anyone know of what may be causing my frames to be captured incorrectly? I understand lag frames, but is there anything that may cause like a random lag frame?
Unfortunately, there are quite a few things that can go wrong on a NES for console verifications. The problem with trying to TAS directly on hardware is that initial state has several variables that you can't control. And it is quite possible that differences can go unnoticed until later levels. The benefit of TASing on emulator is that you at least have an exact state to work with, then when you go to run it on a console you just hope it starts up in the state you want. Hope this helps, if you want more info check out ppu/cpiu alignment and cpu/ppu power up state on NESDEV wiki, there is a lot of valuable info there. EDIT: Oops just saw your post in NES thread, guess you got it sorted out, ok!
Joined: 2/22/2017
Posts: 6
Location: Eau Claire, WI
I did sort out the issue I was struggling with, but didn't really understand the "why," so thanks for the response! I'm checking out the NESDEV wiki, and some of the things I see with chip initial states is making sense, things like "if the NES has been off for less than 20 seconds." A lot of times when I was debugging I ran into strange behavior, and I would unplug the power connector and press power to drain any stored capacitance, which *seemed* like *maybe* it helped, and that seems in line with what I'm reading on the wiki. I know that an emulator will be more ideal conditions, I just really like interacting with the physical hardware and seeing what I can get it to do.
Editor, Player (69)
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
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Joined: 2/22/2017
Posts: 6
Location: Eau Claire, WI
I have a board, NES, and cartridge and had done a project a few years ago communicating with NES controller to control a pong game. I didn't have any grand reason, just had the hardware available and got curious if I could get a working setup that could play SMB. I saw some other projects using shift register chips, but thought I could get it to play without any other extra hardware. I started off writing some FPGA code to burn into the Arduino to handle the controller protocol but found that I didn't need that since I could run the board at 64MHz which is plenty fast for the NES. It is fully functioning now and completes the game, though I am trying to add some features. - I have used a borrowed Saleae logic analyzer to look at my signals, I notice that when I send button data my latch signal fluctuates and I've had to compensate for that by disabling the latch handler until my writes are done - I create my TAS video, get the raw text version of it, and use a perl script to turn it into button state instructions for the Arduino - I'm using the original SMB/Duck Hunt cart that was shipped with the system - I've attached an interrupt for both latch and pulse signals, so I initiate a transaction when the latch signal is seen and send each button's state per pulse - I haven't measured my latency, though I have disabled Arduino's standard timer interrupt and I try to keep my interrupt tasks very tight. I'm writing to the port registers directly instead of Arduino's "digitalWrite" to avoid pin overhead as best I can - I load my frame data before the interrupt so when the signal comes in I can write my data asap - That's interesting, I haven't run into any trouble with the latch signal at power on, but I'll keep that in mind if I see any issue - The bot is loading everything on its own, it isn't connected to the PC at all and even gets its power from the NES controller 5V line. I'm trying to add an SD card for arbitrary loads and it seems like the NES is not able to stably power the board as well as the SD card so it seems like I'll have to change that. Right now my setup is very specific to running SMB and changing the playback is difficult, which is why I'm trying to get the load from SD card working. If things go well, I'd like to try other games and maybe move to a SNES.
Joined: 2/22/2017
Posts: 6
Location: Eau Claire, WI
I did get the SD card load working, I'm using a simple microSD breakout board for it using the SPI pins on the Arduino. I do indeed have to use external power now, a USB battery pack works well enough for that. I was able to modify the HappyLee world record to play on a dual cart, it looks very stable to me now.