Hello everyone,
I've been a long time follower of tasvideos but first time poster. You guys have done some incredible works and I want to thanks you for that !
But I've been asking myself a question for a long time and even when searching on the forum I didn't see anything related to that. Do you guys think it is possible to output some movie (I said NES in the title, but could also be SNES, Genesis/Megadrive, etc) via the computer serial port to the controller port of a real console.
It will probably difficult to do since it will need some custom cable, program to output the key sequence. Beside, i'm not even sure that the emulator are close enought to the real hardware to be able to do that without desync.
Anybody ever tried to do that ?
It's not that the emulator itself isn't close enough, but the timing of movie startup. Many (probably most) games either run on an universal timer or otherwise change randomness since the moment of power-on. Delaying movie start by as much as one frame can throw off the randomness completely.
Also, frames themselves are divisible units (which is not very important for making movies on an emulator but very prominent if you try to do so on the actual hardware), so there will need to be a way to synchronize the keypresses to particular times within a frame when they produce the needed result.
Wow, thanks for the fast reply :)
I must admit that I'm maybe not familiar enough with either the emulator nor the real hardware. But when you start up the console, is there any check done by the console to see if there is at least one controller connected or something, maybe it will be possible to use that to signal that it is time to start the output of keypress.
But it will be a bigger problem to actually sync the key press within the frame. I was pretty sure you could only do a key press in the frame and whenever you did it had actually no importance. It's good to know, I will know one more thing when I will go to bed this night :)
Actually, the NES (and SNES) would make this conversion pretty simple. The controller is just an 8-bit shift register. The NES sends out a latch signal, and all controller buttons are registered, then sent on the clock pulse.
Thus, the inputs could be sync'd with the frames. The NES only sends this latch once per frame.
However, I doubt it sends the latch pulse on lag frames, and seriously doubt any emulator perfectly emulates lag, which means, (in an RNG-less world), the video will still desync... quickly.
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.
Emulator Coder, Site Developer, Site Owner, Expert player
(3576)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
The input files could be redone and only non lag frames could be recorded.
Then input could be fed only when the nes polls for input.
Also, SMB has no randomness, if someone were to actually try this insanity.
EDIT:
Even better, SMB's 21 frame rule even applies to the intro screen so you would even have to worry about power-on sync.
Also if someone were able to get something like this working, I wonder what kind of impact that would have on the speedrunning community. Say if someone were to do a TAS that replicates andrewg's speedrun but adds in 1 more time saving wall jump and pass it off as a speedrun.
How feasible is an idea of actively reading memory and playing the game with a script designed to do actions at certain points in the game? This may have better results than trying to sync the entire keypress file.
Far more difficult. You'd have to either - change the ROM and add display RAM features - or tap into the memory bus...
http://www.freeinfosociety.com/electronics/schemview.php?id=2405
(page 3)
This could be done in two ways.
1st, you could hijack the address and data lines, and add an additional circuit that can send addresses for reading. The problem is - you don't want to interfere with the running code on the NES. I don't know if there would be a way to do additional reads when the NES isn't doing anything. I doubt that there are enough NOP (no operations) in any game that would let you do this.
2nd, you could build a circuit that passively listens to the address and data lines, and essentially mirrors the on board ram. I'm pretty sure you could easily find a RAM chip these days that would allow you to do reads and writes in parallel, allowing you to read memory values without interrupting the mirror.
However, both of these are far more difficult to build than a controller that sends input.
I've actually had this idea for some time now. However, I'm... lazy.
This could make the project much simpler now. If you had a microcontroller and that, the code would be about 10 lines long.
Get frame data, put new values across the 8 bit register. wait for latch. wait 10 ms. (or whatever the controller clock is). Repeat. [/url]
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.
If the game has an RNG and does not initialize the variable first, you will likely have sync problems.
How accurate is the NES clock? I'm not familiar with the physical hardware; will it execute a fixed number of instructions per frame? I would imagine not...
If you guys think this will work, I'll try to get my hands on an NES and Mario cart. I have plenty of PICs (company ordered too many PIC18F2550s) and some free time at work to write an inputfile-fed controller. Re: startup sync, I could probably just pull reset high/low to sync, you think?
First step would be to figure out how the latch signal works on the controller.
I.E. is the controller polled by some external frame counter, and a consistent ~60 Hz, or is it per frame where input is requested? (I'm pretty sure it is the latter).
Thus, you just need input data on your PIC (over serial maybe?) and then, the Latch for the controller is the input signal. You can easily sync on that alone.
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.
Do not forget that NES RAM is not initialized by default. A randomization system that relied on uninitialized RAM as a seed could be particularly devious.
I was searching on the net for some technical information on the way the real NES controller is working and I found a PDF file that contain some useful stuff.
If that could be of some help to anyone. Here's the link : http://www.parallax.com/dl/docs/prod/prop/Hydra-Ch6All-v1.0.pdf
If the latch signal is sent to the controller then it shouldn't be too hard to devise a simple circuit with a ROM containing the registers, with a counter to determine the frame.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Fortunately, most games clear all RAM on start. But there are probably games that update the RNG during idle time, and those will desync right away because of timing differences between the emulator and the NES.
First step would be to figure out how the latch signal works on the controller.
Actually, that step comes far after all the other things I asked. It's likely just some form of shift register.
EDIT: that's exactly what it is. I don't know if it's up to the game to read it or if the console does that (likely the former), but if it is the former, it can't be used as a reliable clock source and the console clock will have to be tapped.
First step would be to figure out how the latch signal works on the controller.
Actually, that step comes far after all the other things I asked.
Um, its the only part that matters for synchornization. Mario has zero randomization. It's possibly one of the most deterministic games on the site. Thus, all you need to care about to sync is the controller latch output. That is it. No need to tie in reset, at all. The console will send you latch signals.
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.
First step would be to figure out how the latch signal works on the controller.
Actually, that step comes far after all the other things I asked.
Um, its the only part that matters for synchornization. Mario has zero randomization. It's possibly one of the most deterministic games on the site. Thus, all you need to care about to sync is the controller latch output. That is it. No need to tie in reset, at all. The console will send you latch signals.
I'd rather write an NES playback device than a Mario playback device.
I can synchronize directly from the clock, if necessary, especially if controller input isn't polled for a number of frames after power on.
Alright. I've been talking about doing this for a couple of months. I'm starting it this weekend... we'll see if I can get Super Mario Bros going. Wish me luck :)
First prototype will be an arduino reading a movie file converted to raw controller bytes off an SD card.
I'd be working concurrently with a PIC, but I don't have an NES, a controller or a kart. I can get this working in a night if someone can provide a resource to pick this stuff up in Vegas...
PS - I am flat broke for a while - I have all the parts to make this other than the stuff described above :( So good luck RyanC, hopefully I can hack one of these eventually...
Edit: _might_ have a real NES this weekend... no kart though. I also have no spare EEPROMs so I'll go the easy route and make this host-based - the PIC will basically be a USB-powered smart shift register :)
I managed to blow up a brand new arduino, a usb hub, and my usb ports on my computer (thanks static) trying to build this.
Better luck to you.
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.