Here are 4 more videos to enjoy. The walkathon video completes the game, but the rest show how that particular game desyncs.
SMB1 WalkathonAdventures of LoloSMB2SMB3 (more details below)
And by request, here is a playlist of all videos I've made with this bot so far. I'll keep this up to date as I upload more videos.
qubical wrote:
Try using the hardware timers (Timer0, Timer1, Timer2) that are part of the microcontroller; I'd be stunned if they stop on an interrupt. Once you've set one up, it should increment itself automatically (at an interval you choose) no matter what's going on elsewhere in the processor, and you can check and change its value whenever you like.
Thanks for the idea! I started using one of the hardware timers, but it was very picky about the length I chose for the timer. It might be the way I designed my code, or me not completely understanding the timer library I'm using. I'm going to mess with it some more and hopefully get it fully working.
With some tinkering I did manage to get SMB3 to play through the first level, after which it desynced. The hammer bro on the overworld didn't move in the same way as in the emulator version, causing the button timing to desync and mario never correctly starts the second level.
When you mentioned timer 0, timer1, and timer2 I ended up finding a code library for timer1 and tried to get that to work. After messing with it for a couple hours I had no luck. Then I remembered I've used a different timing library in the past, MsTimer2. I modified my code to fit it in, changed the delay, and it worked first try. The video is of the second time I tried running it. I should really get my new code online somewhere, but the basic idea is this:
preset first input
add interrupt for latch pulse (input request)
wait forever
InputRequestInterruptRoutine() {
restart 14ms timer, run update_buttons when done
}
update_buttons() {
stop timer
change buttons
update frame number
}
On every latch pulse the timer is restarted, that way the buttons are only changed after the last input request in that frame, and each input request gets the same input no matter how many times the console polls the controller.
I next tried SMB2, and it worked too! My camera died immediately after shooting the SMB3 video so I don't have a video for SMB2 yet. I'll try to shoot one and get that up tomorrow.
The code (as expected) still works with SMB1, but now Adventures of Lolo doesn't work. It seems like the start button is pressed too early and the game never gets into the levels. I tried adding an extra blank input before the start button, which caused the game to sync to a little past where it stopped working before. The character now walks far enough down to pass the block, shoots, walks up a bit, then playback desyncs and he walks aimlessly around the area. I'll try and get a video of that too.
1. Create a console game that can be watched in TV.
2. Dump it for an emulator.
3. Record a TAS.
4. Develope a device sending input to console.
5. Record a movie of that recorded movie, played back on TV
6. Upload to YouTube.
7. Watch it on computer display
8. Drive mad
9. ?????
10. Profit!
Also I'd love to see the best TAS of 2010 played back like that.
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.
... restart 14ms timer, run update_buttons when done ...
Why 14ms? That produces a framerate of approximately 71.43.
It should be around 16ms plus some decimals that I am uncertain of.
(50/3 ms ~ 16.667 ms for exact 60fps, 655171/39375 ms ~ 16.369 ms for exact FCEU's framerate, etc.)
Bisqwit is right, however it's interesting that it's really working. I'm also interested in your full code. Here are some pages where you could upload it (if we can kindly ask you in order to support you)
http://kpaste.net/http://codepad.org/pastebin.cahttp://notepub.com/
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
A suggestion for the timer, you could try to capture the delay between the first few controller interrupts and base the timing on that?
I suppose most games wouldn't introduce many lag frames that early in the game.
Why 14ms? That produces a framerate of approximately 71.43.
It should be around 16ms plus some decimals that I am uncertain of.
My goal was to avoid having to do any precise timing, since it likely would not work (it is unlikely I could get any timing on my bot to exactly match the clock in the NES). With the way my code is, the timer only needs to be longer than the time it takes the console to do all of its input requests. When this timer runs out, the input is changed and the frame count in my bot is increased. Then the bot waits for a latch pulse and restarts the timer. Here's a timing diagram if that helps. It shows two frames of input, then a lag frame, and another frame of input. You can see that the "frames" my bot counts, and the frames the console draws don't line up.
MESHUGGAH wrote:
I'm also interested in your full code.
Enjoy. It's kind of a mess and some of the text comments may not actually be talking about the code they are near, but that's the code I'm working with right now. If you'd like a copy of the MMC library I can share that too, but it just setups the SD card, and reads and writes data from it.
Patashu wrote:
How many games does this make NESbot capable of playing back?
This new code should allow games that do multiple input requests in a video frame to work, assuming they are emulated well enough. I still have no idea how many games fit that description yet though. I hope I can get this bot out to more people with bigger collections so we can test even more games.
Thank you for explaining the timing issue and also for sharing the code.
edit: for the "lack of sending the reset input": Thread #10783: Legitimacy of using resetmicro500 wrote:
You'd probably want to start with the first Mega Man TASes and work your way up, since they get more and more dependent on lag frames and other emulator wackiness.
OK watching the gradius run on a real NES brought me an inappropriate amount of happiness.
I support the creation of the console verified checkmark, great addition.
Thanks again micro500 for all your work on this project.
Our community continues to amaze me.
There's one practical problem with this checking: Since you need the physical game cartridge, the person(s) who owns the bot needs to get hold of it, and they can be pretty hard to come by in some cases, and often not free. Who is going to pay for all this checking?
Would it be cheaper to produce several bot-enabled Arduinos to distribute them among people who have access to lots of games? I think that could be cheaper in the long run.
And yes, this would be entirely a volunteer project, just like ROM dumping.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
This is crazy. The computer plays the game for us.
First we get a computer to win a game show, now we have another computer playing our old games and beating them. What's next?
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
Would it be cheaper to produce several bot-enabled Arduinos to distribute them among people who have access to lots of games? I think that could be cheaper in the long run.
And yes, this would be entirely a volunteer project, just like ROM dumping.
I was looking into this. I'd want to make it integrated into an NES controller. Not so much for fraud, as for portability/design coolness. Additionally, I'd want it to still function as an original controller, adding to the coolnes factor.
An Atmega 328 chip is $6.00
The 4021 Shift register is $0.52
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=296-2040-5-ND
The SD slot is $2.14
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=1903572-1-ND
An NES controller is $5-10 dollars on Ebay
The PCB is the expensive part, and can range from $10 to $150, depending on supplier.
Add approximately 5 dollars for capacitors, resistors, solder, etc.
The thing I don't know, is how the NES pads work, and don't know where to find information on that.
Anyway, that is my estimate on price. Pretty much on the line, except for the PCB.
Sparkfun offers a service for PCB manufacture, but each order takes 15-20 days (or more!) to make/ship/etc.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
I have a PCB design that I've been working on. I've thought about trying to get it into the controller, but the board needs an external power supply (usb, batteries, etc). It may be possible to work on the NES power, but I haven't tested it, and it would require programming the chip directly (not using the Arduino bootloader) which creates more headaches, but is doable (you need another micro controller to program it in that case). There may also be problems try to get it to be the right size and shape to fit in the controller.
I figured I would start with a simpler version before trying to figure out all those problems. My PCB has the FTDI chip needed to program the atmega chip using the bootloader, along with a USB port. I'd be glad to share the design when its all finished. I was planning on using that site you mentioned (BatchPCB) to get it printed. I do agree though that implementing this into a controller would be awesome, and I'm definitely going to work on that after I get this PCB all finished.
I especially like your Stratford boardwalk stroll video on youtube. If you actually live near here and are looking for other games to test, I might have some you could borrow or whatever.
Joined: 10/27/2004
Posts: 1977
Location: Making an escape
Random thought: How feasible would it be to transfer this over to handheld systems? It would obviously require some invasive surgery, but it should be simple enough, correct?
(why yes, I do want to see my Metroid 2 run played on a Gameboy, why do you ask?)
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
Anyway, that is my estimate on price. Pretty much on the line, except for the PCB.
Sparkfun offers a service for PCB manufacture, but each order takes 15-20 days (or more!) to make/ship/etc.
