I think I have asked about this earlier, but nevertheless I'm still curious to know how feasible it would be that rather than building a dedicated electronics board to send the console controller input, instead have just a game controller cable -> PC port adapter. (I'm assuming that the RS-232 port would be by far the easiest for this, although using the PC's USB port is probably also possible, but requires a more complex adapter.)
The advantage of this would be quite clear: Not only would the adapter be (most probably) a lot cheaper and easier to build, but programming the "bot" would become much easier and versatile because you can do it with whichever language you like (as long as it has some way of reading and writing that port).
(It also opens other possibilities, such as playing the console using your PC, eg. with your keyboard or whichever game controller you have.)
Since I'm not an electronics expert, I was hoping that the people here who have much more knowledge about these things could share their opinion on this.
I think I have asked about this earlier, but nevertheless I'm still curious to know how feasible it would be that rather than building a dedicated electronics board to send the console controller input, instead have just a game controller cable -> PC port adapter. (I'm assuming that the RS-232 port would be by far the easiest for this, although using the PC's USB port is probably also possible, but requires a more complex adapter.)
Problem is response times. PCs with general purpose OSes are not good for hard realtime work with very short response times.
Ilari has it. If I recall correctly your average PC can't guarantee you better than ~10 milliseconds' accuracy when trying to do something at a specific time. If you need to respond to polling events at 60Hz, then you need accuracy down to 16.7 milliseconds -- and if you screw up for even one frame then your playback will desync. You need reliable response times from your controller.
The Arduino used for the NESBot can be plugged into a computer for ease of use (loading new programs onto the card, etc.), but it also has its own onboard clock for realtime (i.e. very low reaction time) activity. I assume it would be possible to write a program that would let you send controller input with your keyboard, through the Arduino, and on to the console, allowing you to play a "real" console game with your keyboard. I couldn't guess what kind of additional input latency that extra translation layer would impose though.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Problem is response times. PCs with general purpose OSes are not good for hard realtime work with very short response times.
How fast does the PC have to respond to a poll by the console? If it has to be within the 60 Hz timeframe, I don't think it should be that problematic.
(I suppose that if it becomes a problem, then the adapter would need some kind of buffer which the PC can fill up, and which the adapter then sends to the console as needed. This buffer probably doesn't need to be very large if its only purpose is to guard against the PC missing one or a couple of frames of polling. It does make the adapter much more complicated, though.)
Couldn't you use something like a realtime kernel, that's designed to be able to guarantee response times for specially flagged processes? (I know those are available for Linux; not sure about Windows.)
If you did anything requiring quick response times on a PC, I would suggest a real time operating system. QNX is one example (it's a Unix-like, POSIX compliant RTOS with special extensions), but there are several out there.
You would still need to be able to have digital inputs and outputs though, which could be achieved if the machine has parallel or serial ports. There are PCI cards that you can get that are designed for dedicated digital I/O though (and they often have analog I/O too).
<ccfreak2k> There is no 'ctrl' button on DeHackEd's computer. DeHackEd is always in control.
Btw, isn't the RS-232 port on a PC connected to an IRQ (at least if configured so in BIOS)? That means that the adapter could send an IRQ to communicate to the PC that the console is polling for input. On the PC side you could have, at least in theory, a kernel module that responds to said IRQ immediately. (Basically this kernel module could be used as the software buffer for the input data to the console so that the buffer doesn't have to be built in hardware into the adapter.) I think this would be as close to real-time as you could get.
Of course the only question is: Would you install a kernel module from a random website? Any security-savvy user would shiver to the idea.
The Arduino used for the NESBot can be plugged into a computer for ease of use (loading new programs onto the card, etc.), but it also has its own onboard clock for realtime (i.e. very low reaction time) activity. I assume it would be possible to write a program that would let you send controller input with your keyboard, through the Arduino, and on to the console, allowing you to play a "real" console game with your keyboard. I couldn't guess what kind of additional input latency that extra translation layer would impose though.
Yeah - this is what microcontrollers are meant for. A PC for this application is trying to use a sledge hammer to squash a fly. Use the best tool for the job.
Warp wrote:
The advantage of this would be quite clear: Not only would the adapter be (most probably) a lot cheaper and easier to build, but programming the "bot" would become much easier and versatile because you can do it with whichever language you like (as long as it has some way of reading and writing that port).
Since I'm not an electronics expert, I was hoping that the people here who have much more knowledge about these things could share their opinion on this.
Even at your cheapest option, you'd still need some way to convert an RS232 signal into something the console could understand. This would require an RS232 chip, a 4021 shift register, and probably some logic handling for buffers. In short, what the microcontroller already does.
The reason for the cost of a project like this really isn't in the chips though. It is in the PCB manufacture. Now, you could solder everything on a protoboard, but that is a massive time consumption. Now, if we were talking about making 50,000 NESbots, we could get the price down to around $10 per unit, total. Small run PCBs are expensive. The chips are cheap.
Finally, the language option really isn't a barrier - Arudino's C is extremely simple to understand and do. If you look at the NESbot code, it is trivially simple. So multi-lingual doesn't really translate into a value.
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.
Is there any way I can get one for NES without making it? I'm not too good at making things, and I don't really like the idea of having to get a bunch of random stuff anyway. Something like buying a pre-made one, if possible...
Does anyone have a NESBot along with the game "Journey to Silius"? I noticed that the previous run is console verified, but the current run isn't. I'm curious would all the lag-reduction in the run actually occurs on the real console. :)
Is there any information available for making a SNES bot for verifying console runs? I've seen the NES and N64, but no word on SNES.
http://www.gamesx.com/controldata/snesdat.htm
With a bsnes-derived core, you can easily dump tracelogs of 4016\4017 activity and then use it to tell you what results your snesbot should return.
The SNES controller is pretty much just an NES controller with more buttons. The electronics are almost identical (except there is an additional chip to account for the 4 extra buttons). I just never spent time on getting a SNES bot working since at the time we didn't have a very accurate SNES, but now with lsnes and Bizhawk this is definitely something worth looking into. I should hopefully have a workspace set up again soon where I can play with these bots, probably in a few weeks.
With a bsnes-derived core, you can easily dump tracelogs of 4016\4017 activity and then use it to tell you what results your snesbot should return.
I don't think monitoring writes to controller stuff is the correct way...
With lsnes, there's easier (and correct) way: on_snoop Lua callback.
The parameters are:
1st: Port number (always 0 if there is just a single controller).
2nd: Controller number in port (always 0 unless there is multitap or paired justifiers on that port)
3rd: Control index within controller (always counting from 0 for each poll)
4th: The value to be returned.
Simple script (only supports one gamepad):
Download polldump.lua
Language: lua
dumpfile = nil;
start_dump = function(filename)
file, err = io.open(filename, "wb");
if not file then
error("Can't open output file: " .. err);
end
dumpfile = file;
dumped = false;
current = false;
iframes = 0;
end
end_dump = function()
dumpfile:close();
dumpfile = nil;
end
current = false;
iframes = 0;
on_snoop = function(x, y, z, w)
if z == 0 then
if current and dumpfile then
byte1 = math.floor(current / 256);
byte2 = current % 256;
dumpfile:write(string.char(byte1, byte2));
iframes = iframes + 1;
end
current = (w ~= 0) and 1 or 0;
dumped = true;
else
if w ~= 0 then
current = bit.any(current, bit.value(z));
end
end
end
on_paint = function()
if dumpfile then
gui.text(0, 0, iframes, 0x00FF00, 0);
end
end
I thought I'd share my attempt at creating a Genesis Bot here. Tried testing it using Aglar's Sonic 2 run, but unfortunately it desyncs at the end of Chemical Plant Act 2,
and I can't see any way to fix that. There is some slowdown that doesn't occur on gens, it's hard to notice but it occurs at 2:52-2:54, though it's not until the boss that it actually desyncs.
http://www.youtube.com/watch?v=Dnt0-CAui2Y
This was made using a Genesis Model 1 VA6, two controller extenders, two DB9 gender changers, a breadboard, an Arduino Mega 2560, an adafruit MicroSD breakout board, two 74HC157 multiplexers, and many jumper wires. The Arduino sketch I wrote myself, but for stripping lag frames I just slightly modified the Lua script made for the NesBot to work for the second controller. Here's the files in case anyone wants to look at them. Hopefully someone who has more of an idea of what they're doing than I do can help. I haven't tested it very much with any other games since my Genesis library isn't very big.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
It's not guaranteed to be a problem with your bot but a problem with the Gens emulation of the Genesis being slightly inaccurate. Do you have any other games for which there are TASes?
The only other game I have is Jurassic Park, but it seems to be polling for input in an erratic manner, it can't even get through the menu screen!
I might borrow a couple games from a friend. Sonic 1 is out of the question unless I can import the second revision.
I thought I'd share my attempt at creating a Genesis Bot here. Tried testing it using Aglar's Sonic 2 run, but unfortunately it desyncs at the end of Chemical Plant Act 2,
and I can't see any way to fix that. There is some slowdown that doesn't occur on gens, it's hard to notice but it occurs at 2:52-2:54, though it's not until the boss that it actually desyncs.
I would check to see if the Genesis has a constant poll rate, or if it varies based on slowdown. I only got Mario64 running (and some of Mischief Makers) only because those 2 games slow down the poll rate when the console lags, while other games don't. Also check if you're using the correct version number (like V1.0 vs V1.1 or whatever Genesis uses). Also try some of the obsolete runs too, to see if those sync better.
Another idea is to check the input file itself at that spot in the run. I could get more and more of Mischief Makers played back by deleting or adding frames here and there. The reason is because sometimes the game didn't poll on some frames, and sometimes it polled twice (which I didn't write code to compensate for). Try deleting or adding an input around the boss section before Sonic dies to see if you can recreate the console playback on the emulator. If you can recreate it, then you found the input you need to edit.
Welcome to the verification club! :)
I thought I'd share my attempt at creating a Genesis Bot here. Tried testing it using Aglar's Sonic 2 run, but unfortunately it desyncs at the end of Chemical Plant Act 2,
and I can't see any way to fix that. There is some slowdown that doesn't occur on gens, it's hard to notice but it occurs at 2:52-2:54, though it's not until the boss that it actually desyncs.
I would check to see if the Genesis has a constant poll rate, or if it varies based on slowdown. I only got Mario64 running (and some of Mischief Makers) only because those 2 games slow down the poll rate when the console lags, while other games don't. Also check if you're using the correct version number (like V1.0 vs V1.1 or whatever Genesis uses). Also try some of the obsolete runs too, to see if those sync better.
Another idea is to check the input file itself at that spot in the run. I could get more and more of Mischief Makers played back by deleting or adding frames here and there. The reason is because sometimes the game didn't poll on some frames, and sometimes it polled twice (which I didn't write code to compensate for). Try deleting or adding an input around the boss section before Sonic dies to see if you can recreate the console playback on the emulator. If you can recreate it, then you found the input you need to edit.
Welcome to the verification club! :)
I'm almost positive that the polling rate varies based on slowdown, but I'm gonna have to check that again. I did make sure that the version on the cartridge matched the rom the TAS used.
I also did test with obsoleted runs, with the most success coming out of the oldest wherein I actually had it synced all the way until the second to last level (Wing Fortress), and the only way I managed to pull that off was by deleting and adding frames in certain areas until it just started doing what I wanted it to. This run has completely stumped me though, because I tried adding and deleting frames in a couple different areas I thought were troublesome, but only caused it to desync sooner.
I might try to take on the SNES as well by seeing if I can get an lsnes movie to playback on a real SNES. Has anyone actually tried that yet?
edit: Literally just tested it by spawning a ton of objects in debug mode until the game slowed down and then measuring it, so yes, the polling rate (at least in Sonic 2) does vary based on slow down.
I think that if the problem is in gens not being 100% accurate with lag frames, then it would be quite unfortunate. Even if gens were to be made more accurate, it would obviously desync the existing runs, so either those runs would need to be fixed somehow, or someone would have to make completely new versions of those runs for the fixed emulator.
If the only difference between the two emulators would be a few lag frames more here and there, then in theory it would be possible to auto-convert the runs (by simply automatically adding extra frames in the run where the new emulator lags while the old one doesn't.) However, if the different timings affect things like RNGs, then there's little that could be done to autoconvert the runs.
I might try to take on the SNES as well by seeing if I can get an lsnes movie to playback on a real SNES. Has anyone actually tried that yet?
Note: the on_snoop (and on_snoop2, which just differs in port numbers it passes) Lua callbacks are explicitly meant for dumping data for console verification.
There should be an example script earlier in this thread.
As for runs on bsnes core:
- 2055M (Actraiser 2): Might be a good candidate.
- 2047M (Chrono Trigger): Requires resets, not verifiable.
- 2073M (Speedy Gonzales): Rare version[*], hair trigger with timings.
- 2000M (Speedy Gonzales): Rare version[*], hair trigger with timings.
- 2296M (Lost Levels): Very good candidate to attempt verification on.
- 2280M (Congo's Caper): ???
- 2250M (Timecop): ???
- 2277M (Metal Max Returns): ???
- 2337M (Super Mario World 2): ???
- 3517S (Yoshi's Cookie): Needs two controllers.
- 3779S (Super Star Wars): Extreme hair trigger with timings.
[*] The version that does NOT have the Acclaim logo. I haven't found any gameplay-relevant differences between the two versions (all glitches and tricks I know work in both versions). Still timings are different enough to cause movies to desync fast.
Thanks for the script! Since I already have the 4021 Shift Registers on me, I decided to just change my sketch to work with my SNES, and I've actually had some success. Literally the only game I own is DKC 2 (1.0), so I just made some test movies and they seem to sync. I should probaly buy Super Mario World since I know Masterjun has already made a movie proving the "credits-glitch" works on lsnes.
Is it possible to have the lost levels run sync on the normal Mario All-Stars rom? And would it still be a valid verification if done on the normal version of All-Stars rom?
