I'm hoping someone can eventually test the Blues Brothers TAS because of this issue:
This run desyncs with fceux-2.2.2-win32 at the very beginning due to loading 15 frames faster. If said amount of frames were removed, it then desyncs at 4th stage because it misses a pipe.
OK, I am trying what I can to get more NES games to sync and play, but I have a few problems:
* I still don't own my own NES (borrowing, still looking for one)
* I don't have many games
* Some games cannot sync for various reasons
I would like to try to make a RAM prepare cart to set WRAM in the console to the state it is in in emulators. This cart can run before the game to "prepare" the console. While not strictly verifying from-power-on with true randomness it will confirm that there are not other emulation glitches getting in the way of sync. (This will probably get at least Final Fantasy to sync.)
However, I need a cart to do this. I also need either games to verify or donor carts from shit games to convert into better games for verification (I already have parts like EPROMs for this, just no carts).
I am looking for these myself but not willing to spend much money, already dumped a lot of time and money into verification... if you have old games you don't care about and want to send over, or have games you want run/verified, or have extra funds and want to see this done let me know...
---
Apart from NES, I have some some SMS being sent to me, and I am still looking for a Genesis, various gameboys, N64, A2600 for even more for verification purposes. If you can help in any way let me know :)
Is there no such thing as a 'reprogrammable NES cart' that you can put any NES ROM on?
They don't use original mappers, and can't be expected to work like an original cart. Some have menus or init routines that interfere with power-on compatibility.
Whereas using an EPROM will have very similar characteristics to the mask ROMs originally used on the carts. In fact, some games from Nintendo (usually repairs) actually have EPROMs inside.
As I am trying to console verify; I want to be as close to original as possible. If I verify a game with a donor cart, it is sure to sync with the original cart.
Re: boards, I have donors for SGROM and AOROM.
I need carts for (at least):
NROM (also used for memory clearing cart)
UNROMTLROMSLROMSNROM (!!)
Is there no such thing as a 'reprogrammable NES cart' that you can put any NES ROM on?
They don't use original mappers, and can't be expected to work like an original cart. Some have menus or init routines that interfere with power-on compatibility.
Somebody should fix that. Granted, I know far from enough about electronics to do this myself, but it sounds easy enough to make.
While at AGDQ 2014 I was able to borrow Weatherton's Everdrive, and we gave #3555: SwordlessLink's N64 Wildwaters: Extreme Kayak in 01:30.93 a try. The results were interesting:
Link to video
I had to set the bot to activate the game from the Everdrive menu, but besides that I had little trouble getting it to play back. I ran it a few times, and each time the in-game time was significantly longer than the TAS length. It does seem like all the actions from the TAS played back correctly, just slower than the emulator. Someone who knows the game better than I can confirm or deny this. I'm not sure if this is emulator inaccuracy, if the Everdrive played a part in this, or if it was something else.
I'm inclined to call this a console verification, but I'd like to hear some input from other people before we call it that.
So I made a TASbot this week for fun and learning purposes and managed to get three of the runs mentioned earlier in the thread by Meshuggah to sync with it so far, there's more testing to be done.
I should mention that all of these were done using a Powerpak flashcart, even though that shouldn't matter much when it comes to games like these using relatively simple mappers.
These are the runs I managed to get going:
NES Chip 'n Dale Rescue Rangers 2 (USA) "1 player" in 15:13.79 by feos
NES Duck Tales 2 (USA) in 08:41.29 by feos & MESHUGGAH
NES Darkwing Duck (USA) in 10:59.5 by AnS & Randil
I've uploaded the raw deinterlaced video captured directly from the console, but no video filming the console since I don't really have a decent setup to do that with.
The videos can be downloaded here: http://tas.speedga.me/
Edit:
I also just managed to get "NES Mega Man (JPN/USA) in 15:29.27 by Deign" (using the JAP version) working and added a video of that as well :)
Which bot? My bot, the Arduino NESBot design or a custom bot?
It's a custom one I made for both NES and SNES, but I'd guess it's quite similar to already existing designs. I'm just using an Arduino Uno and CD4021 shift-registers and then sending the controller data over serial in realtime to it.
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.
It does seem like all the actions from the TAS played back correctly, just slower than the emulator. Someone who knows the game better than I can confirm or deny this.
micro500, first it was really cool to see you get an unreleased game to sync on my Everdrive64! Second, I just noticed this statement in Swordless Link's submission text:
Swordless Link wrote:
The YouTube video was created using screen capture software because Mupen's built-in capturer crashes every time you try to capture a video because it can't tell what framerate the game is supposed to run at.
Well, apparently Mupen didn't know what framerate the game is supposed to run at either. Seems maybe Mupen played the game at closer to 60fps while it actually ran on the hardware at closer to 30fps. Personally, I consider the input to be console verified, but the time reported on the console should be noted in the publication if it is going to be labeled as "console verified."
Which bot? My bot, the Arduino NESBot design or a custom bot?
It's a custom one I made for both NES and SNES, but I'd guess it's quite similar to already existing designs. I'm just using an Arduino Uno and CD4021 shift-registers and then sending the controller data over serial in realtime to it.
Probably one of the easier bots to make considering the simplicity of working with an Adruino. Same basic design for an SNES bot, just more pins and an extra 4021 needed. I actually went and tried to verify some NES runs on a friends NES once with my SNES Arduino design, but the games they had besides Super Mario Bros weren't syncing out of the get-go (including Tetris, which I'm not sure why that is, but I wasn't about to waste my time on it). Awesome job getting a few more games verified by the way!
Speaking of Arduinos, I've always wondered how these guys made an N64 bot with an Arduino Uno. The N64's controller protocol is much more complicated then the NES/SNES/Genesis', so I never really bothered trying myself.
Speaking of Arduinos, I've always wondered how these guys made an N64 bot with an Arduino Uno. The N64's controller protocol is much more complicated then the NES/SNES/Genesis', so I never really bothered trying myself.
I just recently completed this exact thing. As long as you use inline assembly, it's totally within reach. The protocol happens at 1 MHz (sub-bit are sent at 1us intervals), and the Uno has a 16 MHz processor, so you get 16 cycles between sub-bits.
Since most instructions take 1 cycle (except for some branching or larger arithmetic instructions), you have "plenty" of time to do any work you need. Most of the assembly consists of wait loops to make sure the timing is okay.
(Doing it with interrupts is out of the question, the latency from receiving an external interrupts to actually running code is too great.)
Speaking of Arduinos, I've always wondered how these guys made an N64 bot with an Arduino Uno. The N64's controller protocol is much more complicated then the NES/SNES/Genesis', so I never really bothered trying myself.
I just recently completed this exact thing. As long as you use inline assembly, it's totally within reach. The protocol happens at 1 MHz (sub-bit are sent at 1us intervals), and the Uno has a 16 MHz processor, so you get 16 cycles between sub-bits.
Since most instructions take 1 cycle (except for some branching or larger arithmetic instructions), you have "plenty" of time to do any work you need. Most of the assembly consists of wait loops to make sure the timing is okay.
(Doing it with interrupts is out of the question, the latency from receiving an external interrupts to actually running code is too great.)
Oh, neat. I've only dealt with a tiny bit of inline assembly with arduino myself. Do you mind sharing the code?
(This is still the same person behind GManNickG; I've been meaning to swap accounts for some time now, and now is a fine time I suppose. I likely won't be using that account any longer.)
Sure, at least the core of it. Someday this will end up on GitHub properly, but as the beginning of a very large project sharing all of it would be pointless and broken. This is the hardest part anyway. :)
https://github.com/NicholasGorski/Scratch/tree/master/n64_arduino
Please read NOTES.md and view the pictures to see the circuit, I haven't diagrammed it yet. The black controller cord is a controller extension cord that I cut in half and spliced with breadboard cables. The tags are just notes on what each wire does (they don't match the usual color schemes).
Getting the data to the Arduino for playback is left as an exercise for the reader. You can stream the data from the computer (note that the Arduino Uno supports up to 1 Mbps on the serial line), but for some games the latency of the communication is too low to keep up. I'm preloading the data to an SD card now.
(As you can see there are various things that may not make sense out of the box, like the DEBUG_PRINT methods; engineering that to work is also an exercise for the reader.)
The assembly is well-commented (IMO), so you should have no trouble following the code itself. Make sure you have your Arduino datasheets handy:
http://www.atmel.com/Images/doc0856.pdfhttp://www.atmel.com/Images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet.pdf
So I made an interesting discovery on the Genesis side of thing. There's an updated Genesis core in one of the recent Bizhawk Betas, using GenesisPlusGX, that's apparently more accurate than Gens, so I decided to test things out by trying to sync the Sonic 2 run I tried to console-sync a while back. I used a lua script that can play the lag-frame stripped files I used on the verifier bot on Bizhawk. The result is that it basically syncs until the same general point in de-syncs on console, just not the same exact way.
http://i.imgur.com/gkN7OFZ.pngIt's those stupid panels on the floor again. There's also a few more lag frames in Bizhawk, one of them originating from before the title screen. I noted that I thought the console was lagging a lot more at a certain point in Chemical plant than Gens was, and that's the same place where it lagged additionally in Bizhawk. (Screenshot of around where that was).
My PCBs for the next generation replay device should have been in by now; hopefully I will have them this week. Still don't have the parts for a complete assembly but I should be able to get started developing.
I just ordered a TKROM board and some SLROM boards.
edit: maybe this gives you an idea of what I am trying to do
Have TKROM and SLROM donor boards; have verified Double Dragon and have been working with Kirby's Adventure.
Parts for the board come in next week so maybe I should start on firmware development...
edit: new page, board I am referencing is here
edit 2: Major problem with boards. I have had the boards for over a week now I think and I should have noticed it. I should have noticed it before I even sent them out for fab. Anyway these PCBs are useless and I wasted 5 hours soldering a lot of expensive parts to a board so I am not very happy nor motivated.
Have TKROM and SLROM donor boards; have verified Double Dragon and have been working with Kirby's Adventure.
Are you having to modify the kirby file to run on your device? Is there anything about your design that improves on previous iterations with accuracy or playback issues?
The whole point of donor boards is that I do _not_ need to modify anything; I run the exact ROMs that match the inputfile. As Kirby has two PRG versions I don't need to hunt for PRG0. I'd still like to verify against actual copies of the games.
To see what a donor board looks like with EPROMs populated, look at the Double Dragon verification video (in the description for [485] NES Double Dragon by Phil in 08:57.47.
This also allows me to verify against ROM hacks.
Re: Kirby specifically, it doesn't sync...looks like an emulation timing problem.
Re: my device, Kirby doesn't run on it. Kirby is on the NES. My device is just a glorified controller. There are numerous improvements to playback vs other designs (look at SMW total control for example). My new device will bring even more improvements.
