If that is the case, then that's even better. But he did say "However I did have to modify the HELL out of the m64 to play it back right, but all frame and button data is the exact same (just some formatting)." So to me it somewhat sounds like he had to insert a bunch of blank frame here and there, but I am most likely wrong, and like your answer much better!
Like I said, just ask how I did things. I'd be glad to answer. Here is my process for modifying the m64 file:
1. I used this TASedit v1 tool to convert the m64 to a txt file. http://www.bluetoaster.net/emu/tools.htm
2. The txt file created has some data at the beginning of it (it says what game is being played, author name, frame count, etc). I just delete this stuff from the beginning of the file, leaving only the frame number and controller data.
3. I use a program called MATLAB to edit the file into 16byte chunks; every other 16byte chunk is button & joystick data.
The reason for doing this is because of the processor I am using, the MSP430F169; it only has 2kB of memory, and has no way to have a file system (i.e., I can't read .m64 or .txt files directly). It has an SD card on it (the txt file is put on the card), but you can only read in raw byte data. Making the MSP read the SD card data is a lot simpler my organizing it so every occurrence of the A,B,Z,etc buttons occur at every 16th,16th+1,16th+2,etc memory addresses of the SD card.
Here are examples of my modification process
1. m64->txt http://www.2shared.com/document/NBNMC6YM/fMario.html
2. txt->txt via MATLAB http://www.2shared.com/document/K81Uf-eH/MarioTest.html
And that's it; I didn't have to add or delete frames to get it to sync, it is straight up the same button and joystick data and frame numbers.
I don't think Warp was saying he thought you were cheating, just that right now it's just your word and video providing the proof. Just like we generally don't assume a given scientist is making data up for their publications, but we do verify their results, just in case...
Personally I think it's awesome. Thanks for making it! I do have to wonder if any other N64 games are as accurately emulated as SM64 is that this would work for them, though.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
If that is the case, then that's even better. But he did say "However I did have to modify the HELL out of the m64 to play it back right, but all frame and button data is the exact same (just some formatting)." So to me it somewhat sounds like he had to insert a bunch of blank frame here and there, but I am most likely wrong, and like your answer much better!
Like I said, just ask how I did things. I'd be glad to answer. Here is my process for modifying the m64 file:
1. I used this TASedit v1 tool to convert the m64 to a txt file. http://www.bluetoaster.net/emu/tools.htm
2. The txt file created has some data at the beginning of it (it says what game is being played, author name, frame count, etc). I just delete this stuff from the beginning of the file, leaving only the frame number and controller data.
3. I use a program called MATLAB to edit the file into 16byte chunks; every other 16byte chunk is button & joystick data.
The reason for doing this is because of the processor I am using, the MSP430F169; it only has 2kB of memory, and has no way to have a file system (i.e., I can't read .m64 or .txt files directly). It has an SD card on it (the txt file is put on the card), but you can only read in raw byte data. Making the MSP read the SD card data is a lot simpler my organizing it so every occurrence of the A,B,Z,etc buttons occur at every 16th,16th+1,16th+2,etc memory addresses of the SD card.
Here are examples of my modification process
1. m64->txt http://www.2shared.com/document/NBNMC6YM/fMario.html
2. txt->txt via MATLAB http://www.2shared.com/document/K81Uf-eH/MarioTest.html
And that's it; I didn't have to add or delete frames to get it to sync, it is straight up the same button and joystick data and frame numbers.
So, there is an MSP protoboard on sparkfun - http://www.sparkfun.com/products/584
I already have MATLAB. You obviously just soldered to an N64 controller... what else is needed?
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.
Due to nature of .m64 format, what wasn't validated here is correctness of lag on Mupen64.
However, we can time how long the console took to play the movie, and compare with the time Mupen64 thinks it took to play it, to (sort of) set an upper bound on how different the lag might be. Across the entire 1:39:02 TAS, it looks like the console took about 63 seconds longer than the emulator did, which makes the emulator's average timing 98.95% accurate in this case, if I did that right, although maybe most of the inaccuracy is concentrated in the few areas of the game that are prone to lagging. It's probably possible to compare (in more detail) the video produced by the emulator with the video produced by the console to determine which parts in particular took longer on console (for example, by playing them simultaneously, and noting at which points it's necessary to briefly pause the video from the emulator in order for them to visually sync up).
So, there is an MSP protoboard on sparkfun - http://www.sparkfun.com/products/584
I already have MATLAB. You obviously just soldered to an N64 controller... what else is needed?
I was given a license to a program called "Code Composer v4" by Texas Tech, which is what is used to program the MSP. The license can be expensive if you get the full version ($795), but maybe this will help. http://students.byu.edu/~cs124ta/references/downloads/CCS/ccstudio.htm
Another program called "IAR workbench" can also be used to program the MSP, but the free version of that has limits on how large your code can be (I think 4kB, which my code is larger than). Of course, with this being TASvideos, I will not mention the "other methods" to obtain the software, wink wink.
You also need a debug module (USB to JTAG) to even put code on the MSP. Some can be about $100. http://www.ruiva-fastproto.com/msp430-usb-debugging-interface-mspfet430uif-p-53.html
I would HIGHLY recommend getting this MSP, since it is the one I used, and it already has an SD card mounted on it. (Mounting one yourself will be a pain) http://www.olimex.com/dev/msp-169lcd.html This way you wouldn't have to change my code at all as to which connections I'm reading the SD card from. It is only $15 more.
For the smaller things: an SD card (a few $), a set of hex screwdrivers to open the N64 up ($7 eBay), and a N64 controller or two to break ($?).
I'm creating a project on Instructables.com of my process. I'll provide code and all that when I get around to it. I'm very bad at explaining things in a technical manner so bare with me.
I assume I shouldn't even bother trying doing this on my German (PAL) Nintendo 64, right? Even if I use a SCART connector I guess it still runs at 50Hz.
I assume I shouldn't even bother trying doing this on my German (PAL) Nintendo 64, right? Even if I use a SCART connector I guess it still runs at 50Hz.
In theory any N64 should work with how I programmed the MSP. If you can verify that the controller polls at 50Hz, then there shouldn't be a problem, but I could be wrong.
So, there is an MSP protoboard on sparkfun - http://www.sparkfun.com/products/584
I already have MATLAB. You obviously just soldered to an N64 controller... what else is needed?
I was given a license to a program called "Code Composer v4" by Texas Tech, which is what is used to program the MSP. The license can be expensive if you get the full version ($795), but maybe this will help. http://students.byu.edu/~cs124ta/references/downloads/CCS/ccstudio.htm
Another program called "IAR workbench" can also be used to program the MSP, but the free version of that has limits on how large your code can be (I think 4kB, which my code is larger than). Of course, with this being TASvideos, I will not mention the "other methods" to obtain the software, wink wink.
You also need a debug module (USB to JTAG) to even put code on the MSP. Some can be about $100. http://www.ruiva-fastproto.com/msp430-usb-debugging-interface-mspfet430uif-p-53.html
I would HIGHLY recommend getting this MSP, since it is the one I used, and it already has an SD card mounted on it. (Mounting one yourself will be a pain) http://www.olimex.com/dev/msp-169lcd.html This way you wouldn't have to change my code at all as to which connections I'm reading the SD card from. It is only $15 more.
For the smaller things: an SD card (a few $), a set of hex screwdrivers to open the N64 up ($7 eBay), and a N64 controller or two to break ($?).
I'm creating a project on Instructables.com of my process. I'll provide code and all that when I get around to it. I'm very bad at explaining things in a technical manner so bare with me.
Hmm, I can't seem to see any advantages of the MSP over say the Atmega (arduino) platform. Likewise, the overhead on getting the MSP going appears to be much higher. I'm assuming that your capstone lab already had all of these items available, which is why you went with that platform. This may be doable on the cheap by sticking with the arduino platform.
As a side note, the capstone that I took, and later TA'd for, used the PIC microprocessor. Thus, most of my early projects used PICs. Now, I stick to arduino, since the startup cost is low for every project.
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.
Hmm, I can't seem to see any advantages of the MSP over say the Atmega (arduino) platform. Likewise, the overhead on getting the MSP going appears to be much higher. I'm assuming that your capstone lab already had all of these items available, which is why you went with that platform. This may be doable on the cheap by sticking with the arduino platform.
As a side note, the capstone that I took, and later TA'd for, used the PIC microprocessor. Thus, most of my early projects used PICs. Now, I stick to arduino, since the startup cost is low for every project.
The arduino should be perfectly fine; I even thought of using one for this project since the NESbot used it, but at TTU, the engineers say it is bad practice to use them. As long as it can clock over 8MHz and has the ability to load large files onto it; the txt file for the Mario120star run is 5MBs. I can provide you my code in a zip: http://www.2shared.com/file/1BVi7BR-/MSP430SDcard2.html Good luck converting it!
Getting an MSP430 board is 4$ and 30cents away. Shipping is free.
This will give you a Launchpad. Now a Launchpad can be rigged to program some more advanced chips. Not that you need that...
The default chips that come with the launchpad don't have much ram, but you can use a 23K256 to store more data that is an SPI use away. You can get a 23K256 as a free sample from Microchip. Not much data space either, but larger chips that fit the socket are a free sample from TI.
You can probably breadboard/solder an SD card without an adapter too. An alternative is to run an UART from the computer. There is a 9600 UART on the Launchpad.
EDIT: In my limited experiments it will hold up fine at twice that speed.
The last issue might be the pin count, but a fix for that is a shift register away... Hard to get as a free sample, but not impossible. Or rig up a free sample MCU to act as one.
For software there is always mspgcc and friends. Not that nice, but will do the job.
The whole thing is probably doable under 50$, if you are resourceful about it.
EDIT: Also, MSP430 is a crap architecture, unless you want low power.
SoulCal, would it be possible to test other N64 games?
The only games I have are Ocarina of Time (v1.2), Majora's Mask (v1.00), Mischief Makers, and Smash Bros.
I can probably get Mischief Makers and Smash Bros to sync right, but Majora's Mask is causing me problems. MM does odd stuff with the controller, which screws up my code as to when to send new controller commands. MM makes the controller poll 2x during gameplay, but 6x during load and pause screens. I can tell that the 2nd poll is actually just rumble pak stuff. As for what the other pulses are... O_o
[URL=http://imageshack.us/photo/my-images/84/smaskd.png/][/URL]
All other games I've seen either poll once per frame, or two per frame if rumble pak or memory card is supported.
But seriously, I actually did this as my graduation project at Texas Tech University.
I wish I could have gotten my degree with such a cool project (rather than a boring programming project about a graph manipulation algorithm implementation, as I did). Now I'm jealous... :P
It looks like the N64 uses 3.3V for communication. Why not write all the stuff the MCU does in C and control the whole thing via parallel port? (http://en.wikipedia.org/wiki/Parallel_port#Pinouts)
There are 8 to 11 output pins, which can be used for data, and 4 to 7 input pins, which can be used for polling. Is that enough for this design?
Two problems: timing and availability of a computer with parallel port.
The timing is a programming issue because I think, that every modern computer is fast enough to handle N64 polls.
As far as availability goes, there are USB to parallel adapters, ranging at about 3,50€ or 4,80 $. All you have to do is put a socket on the parallel port side of the cable and use a ribbon cable to connect to whatever hardware you want to connect to, e.g. a N64 controller. That would take another 3 to 4 $.
If this works, you only need the USB to parallel cable (or an older computer with parallel port), the parallel to N64 adapter and the software. Furthermore you'd be independent of the filesize of the m64 file. File converting, if required, can also be done in C quite easily.
Of course it depends on the design, whether this could work or not, but it'd be an absolutely low cost and highly portable solution.
I tried running Mischief Makers. I couldn't get past the title screen. I added a 1 frame delay at the beginning and it synced until level 1-4 (Spike Land). I will try adding/deleting frames to see what happens, but I fear that in later stages it will affect boss AI and puzzle solutions.
It looks like the N64 uses 3.3V for communication. Why not write all the stuff the MCU does in C and control the whole thing via parallel port? (http://en.wikipedia.org/wiki/Parallel_port#Pinouts)
There are 8 to 11 output pins, which can be used for data, and 4 to 7 input pins, which can be used for polling. Is that enough for this design?
Two problems: timing and availability of a computer with parallel port.
The timing is a programming issue because I think, that every modern computer is fast enough to handle N64 polls.
As far as availability goes, there are USB to parallel adapters, ranging at about 3,50€ or 4,80 $. All you have to do is put a socket on the parallel port side of the cable and use a ribbon cable to connect to whatever hardware you want to connect to, e.g. a N64 controller. That would take another 3 to 4 $.
If this works, you only need the USB to parallel cable (or an older computer with parallel port), the parallel to N64 adapter and the software. Furthermore you'd be independent of the filesize of the m64 file. File converting, if required, can also be done in C quite easily.
Of course it depends on the design, whether this could work or not, but it'd be an absolutely low cost and highly portable solution.
Although all of you didn't seem to like the idea: I did some internet research. It is possible to replace the N64 controller entirely by a PC/Notebook with parallel port and feed the controller data directly to the N64. This can be done entirely with software. The only thing you need (as mentioned before) is a N64-to-parallel-adapter (and probably a parallel-to-usb-adapter).
That way SNES and NES controllers can be replaced as well. You only need to take the additional clk-pin into account.
I know you guys want to see results rather than talking but it's an idea to start with and once implemented, all that someone who wants to play a TAS on a real (Nintendo) console needs is
1. console
2. adapter console to PC (10 $ max.)
3. software that feeds the emulator movie file to the console
If I have time during christmas, I'll try to do some programming on this task.
In case somebody is interested heres a link to a really old site (beware of horrible colors).
http://cnt.at-ninja.jp/n64_dpp/N64%20controller.htm
The author describes how to attach the N64-controller to a parallel port and use it as gamepad. It would be just the other way around (or something like that) to use the pc as a controller.
To be honest, I believe the BEST method to control the N64 is to actually use a N64 controller like I did. This way, for games that use the memory card, rumble pak (unnecessary for TASes), or GameBoy adaptor we won't have to emulate those either with software.
EDIT: And megaFoetzli, this would be useful, but Parallel Port aren't supported in Windows7 (I think) and I bet a lot of people here use that OS.
And also, Majora's Mask and OoT will not play back. Period. I had to add ~150 blank frames just for it to create the save file in MM. Load times between emulator and console are just too different for these game. Please stop asking me to do it. :,( Mario64 is a completely different case, since it only polls during gameplay, thus load times don't exist according to my Droid64. Load times stop the controller for any game that does not support controller peripherals; only these TASes I can see working on console.
Unfortunately modern N64 emulators don't enforce the limitations of the console, so games load and run faster than they should. That does mean a lot of the runs aren't technically valid...
It's a problem with hacks too, since you get hacks that won't work on a real console because the GPU isn't fast enough or they aren't sending it some instructions that it needs but that emulators just ignore...
Anyway this is a really cool project. All you do is send back the next frame every time you're asked for it? I would have expected syncing to be a nightmare...
Unfortunately modern N64 emulators don't enforce the limitations of the console, so games load and run faster than they should. That does mean a lot of the runs aren't technically valid...
It's a problem with hacks too, since you get hacks that won't work on a real console because the GPU isn't fast enough or they aren't sending it some instructions that it needs but that emulators just ignore...
Anyway this is a really cool project. All you do is send back the next frame every time you're asked for it? I would have expected syncing to be a nightmare...
I would still say most of the N64 TASes are still valid, but with certain, like load times, syncing the run is next to impossible on console. I was able to get Majora's Mask to sync up until Link turns into a Deku, but it involves a bunch of adding/deleting frames until the load times differences between emulator/console are eliminated. However, I don't see this working in the long run, and hand editing the whole thing would be a chore. I would assume, however, that all non-load screen areas will still sync up with the movements. And yes, I just send a new command every time a new request is sent to the controller. In case you wonder, it's what the middle of the 3 holes on the controller port is.
Mightn't it be possible to get the emulator to calculate the lag differences, like is done with NESbot, and do the time shifting automatically? Or is Mupen not accurate enough for that?
Mightn't it be possible to get the emulator to calculate the lag differences, like is done with NESbot, and do the time shifting automatically? Or is Mupen not accurate enough for that?
I wouldn't even know how to begin such a task. Someone more knowledgeable about the emulator and programming would need to pick this up. Even if the lag counter can be interpreted in Mupen, I wouldn't have the slightest idea how the data would be used on the console.
Why would load times be an issue for N64 emulation, though? It's loading from cartridges, and other cartridge-based systems don't have such problems. I think the main problem is just that N64 emulators are inaccurate and hacky, adding lag here and skipping it there to try to make the game work mostly well. (Still most choke on e.g. Zelda's pause screen, Mario Kart's jumbotron...)
With disc-based systems load time becomes an issue since it's not really possible to accurately emulate the disc drive's physical motions, but load time from cartridges should only be limited by how fast the CPU can read them?
This is a great project, but I think the name Droid64 sounds too much like a N64 emulator for an Android phone.
Too much? It's exactly the same name :P That's exactly what I was thinking too when I saw the name.
Derakon wrote:
I do have to wonder if any other N64 games are as accurately emulated as SM64 is that this would work for them, though.
I'm sure there are others. Turok 1 would probably work as good as Mario 64, because it has the same framerate, but games with highly variable framerate like Goldeneye and many others will probably be impossible to get to sync, at least the way Mupen 64 emulates them now.
---
Nice work on the N64 bot, SoulCal. I was impressed that an N64 TAS would be verified now when people had only begun to verify NES TASes, so that seems like a major leap.
[/URL]
All other games I've seen either poll once per frame, or two per frame if rumble pak or memory card is supported.
