I know it uses hard reset, but I think it was mentioned somewhere that it could be resynched to work with an ingame soft reset.
All it takes to replace the hard reset with a soft one is 13 extra frames and some different input at the very beginning. Hopefully it's not a problem that the input time would have to be changed like that.
I would love to see our movie played back at the marathon though.
dwangoAC ordered some of my early rev boards to be sent to me because he didn't want to wait until I placed my order (I have a lot of boards I still need to finish before I order). They came in on Thursday.
I'm still sleep deprived, but I thought I'd show them here.
[URL=http://imgur.com/YzAVD0d][/URL]
Here are the boards....
[URL=http://imgur.com/y44hJb7][/URL]
Another view.
Sorry for the shit photos, I make a poor photographer when I'm this tired.
Went ahead and soldered up the first board. A design goal of this board was to have it all through-hole so it could be assembled by soldering noobs or by people with spare prototyping parts. The next version supporting Genesis and N64 will be mostly SMD though :)
[URL=http://imgur.com/fJt39pD][/URL]
Here's some progress showing a bunch of resistor leads :)
[URL=http://imgur.com/XQ3Naq7][/URL]
And the finished soldering (minus USB parts like the crystal and LDO vreg).
I've got a really messy shot of it connected to the Pi, waiting for the NES to turn on...
[URL=http://imgur.com/qv9OJkq][/URL]
Sorry about the cable mess :)
It's working, the board functionality has been verified (already have a lot of changes simplifying the board and making it easier to solder for REV4). Still struggling with USB firmware and bootloader, and the only games it will run are SMB (verified complete with SMB+DuckHunt) and Duck Tales. DT goes farther than NESbot but still has problems, I've been able to manually edit about 5 inserted frames total to get it halfway through stage 2 though. But the hardware does work =)
So the hardware seems to work, USB works (just not with my firmware), now I just need to fix the firmware and implementation bugs :)
Once I'm satisfied with the FW and board layout I'll order a bunch of boards.
GhostSonic's previous attempts have shown that the Genesis emulator used for TASing is not very accurate, so genesis verifications will be difficult to do (about equal in difficulty to verifying a SNES TAS not made with Bizhawk/bsnes)
http://tasvideos.org/795M.htmlhttp://tasvideos.org/1713M.html
These two are the only "complete" runs I've ever sucessfully verified and the first one required modifications to resync. I don't have much faith in many other Genesis games until a much more accurate emulator is suddenly created and adapted.
http://tasvideos.org/795M.htmlhttp://tasvideos.org/1713M.html
These two are the only "complete" runs I've ever sucessfully verified and the first one required modifications to resync. I don't have much faith in many other Genesis games until a much more accurate emulator is suddenly created and adapted.
Out of idle curiosity: when you tried to verify the Genesis movies, did you try passing the movies through a script of one sort of another to remove lag frames from the input file? I ask because the GMV keeps input in lag frames, and this could cause additional problems when trying to verify the run.
Something tells me you were already aware of this and had already dealt with it, but it doesn't hurt to ask to be sure...
It's working, the board functionality has been verified (already have a lot of changes simplifying the board and making it easier to solder for REV4). Still struggling with USB firmware and bootloader, and the only games it will run are SMB (verified complete with SMB+DuckHunt) and Duck Tales. DT goes farther than NESbot but still has problems, I've been able to manually edit about 5 inserted frames total to get it halfway through stage 2 though. But the hardware does work =)
So the hardware seems to work, USB works (just not with my firmware), now I just need to fix the firmware and implementation bugs :)
Once I'm satisfied with the FW and board layout I'll order a bunch of boards.
I wonder if you tried adding a very specific input to the movie file that would have otherwise no effect on the run if it syncs, but can be easily spotted if the run desycned. For example, opening the menu with "Start" on a laggy frame. This can help narrow down the points where the run starts to desynch.
It's working, the board functionality has been verified (already have a lot of changes simplifying the board and making it easier to solder for REV4). Still struggling with USB firmware and bootloader, and the only games it will run are SMB (verified complete with SMB+DuckHunt) and Duck Tales. DT goes farther than NESbot but still has problems, I've been able to manually edit about 5 inserted frames total to get it halfway through stage 2 though. But the hardware does work =)
So the hardware seems to work, USB works (just not with my firmware), now I just need to fix the firmware and implementation bugs :)
Once I'm satisfied with the FW and board layout I'll order a bunch of boards.
I wonder if you tried adding a very specific input to the movie file that would have otherwise no effect on the run if it syncs, but can be easily spotted if the run desycned. For example, opening the menu with "Start" on a laggy frame. This can help narrow down the points where the run starts to desynch.
No idea. Too sleep deprived to think about it anyway. I made a ton of changes tonight and got a 2-player run to sync all the way to the end (need to fix the bug that prevents the ending now), maybe after all of that I'll think about this.
I was thinking of making a vsync detector circuit so I don't have to care about any of this frame bullshit, I just read out the input file. A human can see the screen, so is it cheating if the replay device does too? Doesn't guarantee sync of course, and wouldn't even be a big help for Duck Tales, more for other problematic games ;) There was also a bug I found in the original NESbot strip_lag_frames or whatever lua that wrote buggy output (may have been fixed? not in the version I had) and I ripped that off for the non-fm2 raw mode, so I'll try Duck Tales again re-exported in case that bug is affecting the output.
I was thinking of making a vsync detector circuit so I don't have to care about any of this frame bullshit, I just read out the input file. A human can see the screen, so is it cheating if the replay device does too?
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Comparing screen hashes? >_>
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.
Yes. There are even chips to do this, like the LM1881.
FM2 (and many emulators) store per-frame input information, including lag frames, so if I detect each frame then perhaps sync would be easier.
feos wrote:
Comparing screen hashes? >_>
No. Not much understanding of video here I take it :( See above.
WST wrote:
It does not look a more elegant solution than the mentioned «frame bullshit»…
Why not?
1. Some games are fine, always 1 latch-per-frame (SMB,). Easy to sync.
2. Some games are fine, always 2 latch-per-frame (Tetris, other games using PCM). Easy to sync.
3. Most games have some weird lag shit at startup, wherein one frame is polled then a bunch of lag, sometimes a few times over. This throws off my lag detector. This can be worked around with raw input but any change in lag during playback will throw the playback off (Duck Tales). I can improve this in firmware and software.
4. Some games poll like crazy at certain points., like menus (looks like Legend of Zelda does this). This won't work unless the latch count on current frame is known, and if the system clock is off at all, the latch count may be off. NESbot and my bot can't play these back right now.
5. Some games poll like crazy all the time. Like above but worse.
Detecting vsync may or may not solve 4 or 5, depending on how the game is programmed and how dependent on the core clock they are, but if it doesn't work it can at least offer insight as to if a game could ever be synced on hardware. And in the first through third cases, it should make playback really simple and reliable.
Doing this in code requires a supporting code in FW and a script you need to run on the emulator to capture the output. Doing this with a vsync detector means just updating with the next frame's contents when vsync is detected (or just before, but you get the idea). A bunch of code and scripts seems complicated, not elegant.
Ideally, a movie format that stores the input per latch cycle rather than per frame would work better for playback and eliminate all of these issues as well as allow intraframe input changes. I can wish... :)
edit: clarifications
FM2 (and many emulators) store per-frame input information, including lag frames, so if I detect each frame then perhaps sync would be easier.
IIRC, all accepted do, except M64, DTM (input frame based), JRSR and OMR (time-based).
True wrote:
1. Some games are fine, always 1 latch-per-frame (SMB,). Easy to sync.
2. Some games are fine, always 2 latch-per-frame (Tetris, other games using PCM). Easy to sync.
I think some might also have deterministic 3 latches per frame.
True wrote:
Ideally, a movie format that stores the input per latch cycle rather than per frame would work better for playback and eliminate all of these issues as well as allow intraframe input changes.
That would only work on games that poll a fixed number of times per ingame frame and don't have anything depending on number of video frames (this is why SM64 was verifiable!). Otherwise clocking still matters.
http://tasvideos.org/795M.htmlhttp://tasvideos.org/1713M.html
These two are the only "complete" runs I've ever sucessfully verified and the first one required modifications to resync. I don't have much faith in many other Genesis games until a much more accurate emulator is suddenly created and adapted.
Out of idle curiosity: when you tried to verify the Genesis movies, did you try passing the movies through a script of one sort of another to remove lag frames from the input file? I ask because the GMV keeps input in lag frames, and this could cause additional problems when trying to verify the run.
Something tells me you were already aware of this and had already dealt with it, but it doesn't hurt to ask to be sure...
Yes, they were passed through a lua script to create a new input file sans lag frames.
Thanks for the tip. I got in contact with the seller and sent some bitcoins and the controller should be here sometime soon. If anyone has a copy of Gradius they could sell me I'm still on the lookout for that although I'll snag it from Amazon if I don't hear of anyone here with a copy.
I have the PCB now and I hope to populate it very soon, but my schedule has been packed this week. I'll update when I can. Thanks for everyone's support!
A.C.
******
dwangoAC, I'd thought I'd pipe up on this thread seeing as you are trying to do the same thing as me (namely a Pi controlled SNESBot) and two minds a better than one and all that.
WRT to bitbanging the clock and data straight out the GPIO, unless you get very low level (ie straight on the sillicon with no OS) then I don't think it's going to be possible. But you don't need to do it like that, it just requires a few more GPIO pins, although you might have a fun time trying to get multitap support working without bitbanging....
TRUE: Could you post the code you used during your scope reads so I can see what software methods you were using?
Ideally, a movie format that stores the input per latch cycle rather than per frame would work better for playback
This is exactly how I did it and it seems to work fine for 95% of the games I tried, in fact the only game I've found so far that didn't work was Super Puyo Puyo.
I look forward to seeing what you come up with!
EDIT: Also, nice TZ. I have one as well, plus a Lethal Weapon 3 :-)
TRUE: Could you post the code you used during your scope reads so I can see what software methods you were using?
I probably don't have it. Besides, I edited it quite a bit trying to find a sweet spot. I could clock out plenty fast and latency was OK, but input detect speed and reliability just wasn't there.
I tried using a pulse stretcher to stretch the latch and clock, but that still did nothing. Input triggers or polling was just unreliable.
Moderator, Senior Ambassador, Experienced player
(908)
Joined: 9/14/2008
Posts: 1014
So the PCB that true designed arrived this week and I got everything soldered up with some assistance from a co-worker. We have an awesome soldering station at work which made things much easier.
One thing I've discovered is that true has a lot of parts and I don't. This is something I need to fix, but in the meantime the consequence of my lack of parts is I end up devising some creative hacks (case in point, I had to build my own SD card holder using jumper wires when I worked on the NESBot, but I digress). I had to come up with a pretty messy setup to go between the PCB and the Raspberry Pi (which is acting as a UART serial data source containing movie files and a script to send them across said UART serial interface). I finally resorted to using pinheaders off of old fans from a neglected Pentium II, but this only got me three of the four wires I needed (+3.3 volts, ground, RX, and TX). For the final wire I ended up using a jumper and jammed a wire into it - it worked well enough. :)
I moved the NES connector over and re-used the same method of connecting it to the breadboard. I didn't bother depopulating everything from the NESBot, so it's still on the breadboard for the moment. I'm happy with how the blue wires fanned out, but I'll have to tighten everything up when I get to two players.
I'm very happy to report that this crazy contraption was able to sync SMB1. Next step - obtain a copy of Gradius and work on getting another broken SNES controller (I have one, but I need one more).
Again, thanks goes to true for the amount of time and effort he's put in to the PCB. Thanks for everyone's interest and support!
A.C.
******
Moderator, Senior Ambassador, Experienced player
(908)
Joined: 9/14/2008
Posts: 1014
Great news - true was able to get the USB firmware working on his setup and I was able to populate the rest of the components. There's an extra diode soldered in an usual place that you might be able to spot.
There were some tricky bits, such as needing to solder a jumper wire to short a populated resistor that was causing problems. I did this soldering myself at home with solder with lead in it and I haven't thoroughly cleaned the board yet but it still looks pretty good.
I was able to solder the NES cable onto a header (more specifically, this part was actually done by the same co-worker who helped me with the bulk of the soldering) and I used some glue to keep everything in place. After flashing the latest firmware I hooked everything up.
Linux (in my case, Linux Mint XFCE edition) immediately detected a "USB Abstract Control Model driver for USB modems and ISDN adapters" device so I crossed my fingers and attempted to run Super Mario Bros.
I'm happy to report that SMB synced to the end. This looks far cleaner than my earlier breadboard setup and is the first result that I'd be comfortable taking to the marathon. Next up, I need to figure out what the SNES controller pinout is and give that a shot, but that might have to wait until true can get an SNES of his own.
A.C.
******
Next up, I need to figure out what the SNES controller pinout is and give that a shot, but that might have to wait until true can get an SNES of his own.
The pinout is (From straight side to curved side):
1) +5V
2) Clock
3) Latch
4) Data1
(the small separator plate is here)
5) Data2 (often marked as NC)
6) Select (often marked as NC)
7) Ground
I'm posting here because I don't want to derail adelikat's submission thread so:
True wrote:
My bot allows starting from reset - it doesn't care about cold power or reset. But it doesn't itself control the reset line (though with a 1p TAS, I suppose I could include this support in the firmware using the 2p port - automatic resetting ;d)
I could also support turning the power on and off pretty easily.
Some games do act differently from reset and hard power (example: FF1)
If I had this game (ha) I could test this.
Dr. Mario doesn't require reset, just 2 player. I have confirmed it syncs.
I don't have Kirby (wish I did).
Zelda 2 doesn't sync worth crap but I haven't tested with my latest firmware changes. It might sync now.
dwangoAC has Dr Mario I think and it is a short run, up to him.
[/URL]
Here are the boards....
[URL=http://imgur.com/y44hJb7]
[/URL]
Another view.
Sorry for the shit photos, I make a poor photographer when I'm this tired.
Went ahead and soldered up the first board. A design goal of this board was to have it all through-hole so it could be assembled by soldering noobs or by people with spare prototyping parts. The next version supporting Genesis and N64 will be mostly SMD though :)
[URL=http://imgur.com/fJt39pD]
[/URL]
Here's some progress showing a bunch of resistor leads :)
[URL=http://imgur.com/XQ3Naq7]
[/URL]
And the finished soldering (minus USB parts like the crystal and LDO vreg).
I've got a really messy shot of it connected to the Pi, waiting for the NES to turn on...
[URL=http://imgur.com/qv9OJkq]
[/URL]
Sorry about the cable mess :)
It's working, the board functionality has been verified (already have a lot of changes simplifying the board and making it easier to solder for REV4). Still struggling with USB firmware and bootloader, and the only games it will run are SMB (verified complete with SMB+DuckHunt) and Duck Tales. DT goes farther than NESbot but still has problems, I've been able to manually edit about 5 inserted frames total to get it halfway through stage 2 though. But the hardware does work =)
So the hardware seems to work, USB works (just not with my firmware), now I just need to fix the firmware and implementation bugs :)
Once I'm satisfied with the FW and board layout I'll order a bunch of boards.
One thing I've discovered is that true has a lot of parts and I don't. This is something I need to fix, but in the meantime the consequence of my lack of parts is I end up devising some creative hacks (case in point, I had to build my own SD card holder using jumper wires when I worked on the NESBot, but I digress). I had to come up with a pretty messy setup to go between the PCB and the Raspberry Pi (which is acting as a UART serial data source containing movie files and a script to send them across said UART serial interface). I finally resorted to using pinheaders off of old fans from a neglected Pentium II, but this only got me three of the four wires I needed (+3.3 volts, ground, RX, and TX). For the final wire I ended up using a jumper and jammed a wire into it - it worked well enough. :)
I moved the NES connector over and re-used the same method of connecting it to the breadboard. I didn't bother depopulating everything from the NESBot, so it's still on the breadboard for the moment. I'm happy with how the blue wires fanned out, but I'll have to tighten everything up when I get to two players.
I'm very happy to report that this crazy contraption was able to sync SMB1. Next step - obtain a copy of Gradius and work on getting another broken SNES controller (I have one, but I need one more).
Again, thanks goes to true for the amount of time and effort he's put in to the PCB. Thanks for everyone's interest and support!
A.C.
******
There were some tricky bits, such as needing to solder a jumper wire to short a populated resistor that was causing problems. I did this soldering myself at home with solder with lead in it and I haven't thoroughly cleaned the board yet but it still looks pretty good.
I was able to solder the NES cable onto a header (more specifically, this part was actually done by the same co-worker who helped me with the bulk of the soldering) and I used some glue to keep everything in place. After flashing the latest firmware I hooked everything up.
Linux (in my case, Linux Mint XFCE edition) immediately detected a "USB Abstract Control Model driver for USB modems and ISDN adapters" device so I crossed my fingers and attempted to run Super Mario Bros.
I'm happy to report that SMB synced to the end. This looks far cleaner than my earlier breadboard setup and is the first result that I'd be comfortable taking to the marathon. Next up, I need to figure out what the SNES controller pinout is and give that a shot, but that might have to wait until true can get an SNES of his own.
A.C.
******
