Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Mr_Sweed wrote:
I'm not a insane person IRL. I'm a helpful and curious of me. Like to help people. Not letting them to be angry on me.
Please, WST. Bring this submission up again. :'(
I begging you. This hurts alot. To hurt a nice guy with not mutch friends IRL to communicate with? I was really glad when you asked me in to join this train. Just when good things turns to greatness goes to sadness. Is it this you are treating your friends? Just putting dirt in there eyes?
Get a grip, child. This isn't about you.
Besides, it's a fucking inputfile for a videogame. Why is there so much drama over who holds the controller? Holy shit.
Mr_Sweed wrote:
I'm sad now.
You've been sad for as long as you've been on the internet.
WST wrote:
I am ashame to see my name where the name of DMTM is present.
As anyone should be.feos wrote:
What I see now is that WST is pissed by Mr_Sweed/DMTM's actions. What's so disturbing about them, he just asked for credits?
He begs for them. He says he invents everything. He wants attribution for pressing buttons on someone else's controller. Just a typical internet 13 year old, really.
Sorry for contributing to drama.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
WST wrote:
DMTM’s praying for co-authorship (even through other people) makes me so tired that I will sooner quit the TAS world than listen to him :(
Seriously, may I decide on my own who is in my team? May I TAS just to spend spare time and when I’m feeling lonely?
I don't even do this shit and I completely agree with you. The guy is an attention whore loser.
WST, don't apologize. The kid claims far more credit than he has ever deserved.
I've been working on SNES support and just under an hour ago got this to sync with my hardware and a late model mini SNES. :)
EDIT: tested and synced Masterjun's latest version, which presses different buttons on the extra two controllers that GhostSonic's bot couldn't do. Saves one frame! :)
EDIT 2: Masterjun posted this total control demo to IRC, which _also_ syncs. Best part is if you plug in a normal controller afterwards and try to play where the hack leaves off :) (tip: if you do this, and after messing with p1 want to play, make sure only p2 is plugged in)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sonny_Jim wrote:
Hi there, I do pop my nose in every now and again to see if there has been any advancements as I'd really like to run something other than the SMAS run on my hardware.
working on it
Sonny_Jim wrote:
So it was both a failure of an established member to realise when he was being a jerk
there was no failure
it's what you wanted after all
but this is the first I've heard of such chatter, I lol'd
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
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.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I am console verifying SMB3 warpless. Right now it desyncs on world 6-castle because the runners treat Mario like a jump-happy buffoon and send him into flames. (How he escapes all the other flames up until this point is beyond me...)
It could have just been a one-off desync. If this script will eventually work for SMB3 though, and if the run desyncs again on console at this point and I can determine it isn't an implementation bug, then you might have a valid use of your script :)
(That said, this level is an autoscroller, so maybe I can fix this part manually...)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
AnS wrote:
adelikat wrote:
Not true. The point is that you would have to attempt to run the bot many times before it finally worked.
Doesn't NESBot require starting from console power on? At least the movie does.
Youtube videos make it look like you have to first let the game run for some (small) time and then reset at a very specific moment - perhaps exactly while the game is writing data into mapper port.
So, simply switching NESBot+console on at random occasions won't do the trick.
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.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
jlun2 wrote:
AnS wrote:
Allowing TASes to start from an arbitrary state (instead of a universally accepted state) is a huge change of the site rules. It's funny that such an unentertaining TAS would be a ground for changing rules so much.
Uh....
Well, we did have this movie that ended up making the dsm contain the firmware settings. Infact, does the firmware settings for NDS movies count as an arbitrary state? There are some games like animal crossing, pokemon, rubik's world, etc that has different luck depending on when the time, name, color, etc is at power on.
The setup for the NDS case can (possibly, I don't know clock details) be deterministic. For this case, it isn't certain.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
AnS wrote:
Also, I'm questioning the technical side of the original assertion.
Where is the proof that NES can start with any uninitialized RAM values? This page states that "all internal memory ($0000-$07FF) was consistently set to $ff except for a few bytes". Same goes for mapper registers - you don't know for sure if they can have those values at poweron.
To quote your own source, verbatim, "Please note that you should NOT rely on the state of any registers after Power-UP and especially not the stack register and RAM ($0000-$07FF)."
Why? It is how this hardware works. Do you want to learn?
For a practical example, try replaying the fighter FF TAS on NES, and notice the first battle is almost always different. For why this is, refer to disassembly and the quoted note above.
AnS wrote:
The video above only proves it can be reset to a similar state.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Warp wrote:
True wrote:
Why post this thread here?
I didn't know there was a limitation on what should be posted here and what shouldn't.
I've already replied "fair enough." He can post whatever he wants. But since you won't drop it, I'll elaborate. If he wants good information about electronics, this isn't the place for it. It's like going to a bakery to get the best advice on how to do car repair. That was my point.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Warp wrote:
And I really mean simple tasks. For example, how large of a resistor do I need not to burn out a LED? I have no idea.
Ohm's law.
But seriously, this is a site for TAS and very little electronics happens here. There are a LOT of wonderful resources on the internet for what you seek. I can send you a huge list of beginners electronics resources if you desire. Why post this thread here?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sonny_Jim wrote:
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.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Derakon wrote:
You should drop in on this thread; dwangoAC and True are both trying to do similar things. It's great to hear you were successful!
Oh, and welcome to the forums. :)
Not trying, I have succeeded ;)
Well, OK, haven't tested on SNES because I don't have one, just NES, but it should work fine..
I designed the device with 2 player, multitap on both ports playback. See the above linked thread for details.
Sonny_Jim, too bad you weren't in IRC earlier, you could have followed the progress or participated. I have a working PIC32 implementation with direct serial out (no other parts except level shifters), an fm2 parser and replay script. Because of the way NES controllers work fm2 playback isn't the greatest, but raw polled works well (I have verified 5 new games including a 2-player game). It should be better on SNES though. Will work on snes9x movie format parser once I get an SNES.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Ilari wrote:
Detecting the vsync from video output signal?
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
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
jlun2 wrote:
True wrote:
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.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
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.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I figure Genesis will be a pain.
The first version of my board will be for 2P+ NES and SNES (including multitap). Next board should work with any modern controller with up to 8 I/O lines per port, 2 ports, and with supporting code...aiming for NES/SNES/Genesis/N64. Should also be plug-and-play. But I'm not going to worry about it until the NES/SNES code is tested on the current board.
I can't do Genesis on the current board because I don't have enough IO, and N64 would be rough because of speed. Next board should be able to do more (SD card mode option, for example) so I'll save it for then.
----
As for parts I need to test bots, I still need an SNES and a couple of controllers (been looking at thrift stores, haven't got lucky yet, though a friend has but he won't give it up...). Can't test SNES stuff without this. Also need games to test with...I can borrow some from a friend but his collection isn't very large.
For Genesis I will need a console. I have a small collection of games for this.
If you are in the US and want to work something out, contact me.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
xPi wrote:
What if the Pi's video output (or a small portion of it) would be added to the AGDQ stream to present information to the audience?
you could use it to show button presses, playing status, and a stopwatch that automatically starts when playback starts.
I basically have this now (frames total (normal / lagged), time per frame, button presses, will be adding elapsed movie time later, simple little command line thing, just blow it up I guess :)
Will have a lot to show in a week or less.
[/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.