Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Eszik wrote:
Masterjun wrote:
The glitch always jumps to open bus. The reason why the game can continue is just because it managed to get back to the normal code again, but the fact that it executed open bus makes it not different from the ACE run.
So you could say: "If you get the cloud you might as well get directly to the credits."
And you could say: "If you get the cloud you might decide not to use its ACE effect because the category you're TASing bans it."
Inane.
(I can't argue this shit. To do so would be pointless.)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Honestly that Kirby run may have been missing a second controller, so I'll try it again.
Edit: just tried, same result, so I probably was using both controllers.
Re: movie, yes there will eventually be a proper movie for Mega Man.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Re: 2 players, the first movie I verified was a 2 player run: [1556] NES Rush'n Attack "2 players" by Randil in 09:35.90 My old device could do that. Right now the only things this new device does that my old one doesn't do are play Genesis and support high-bitrate playback. Oh, and it doesn't require a computer to play back and is easier to set up, and the connectors don't break because you aren't soldering Nintendo's frail, unsolderable wire. I even made an adapter for the old device so I wouldn't have to deal with that (see ~3 posts back).
Re: Kirby, unlike most NES games which poll only when they can use input, Kirby polls every frame, even if it lags. Now this wouldn't be an issue except for a second property, which is that timing in console is different for Kirby than it is on emulator, so it desyncs. The emulator seems slightly fast compared to console. With other games this very well may be happening at times but it is masked by not asking for input unless it can use it.
For this specific run, had you read the thread, I already tried it. See here for details.
Basically emulation needs to improve to verify Kirby, and when that happens the runs will need to be re-run on the new emulator.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Dyshonest wrote:
let me act like you for a little bit
lalalaalalala can't hear you not listening lalalalalalala going to have my own flawed views and aint nobody gonna change 'em lalalaalalalalala hyperbole lalalalalalala
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I tried verifying this run with my old device which has proven to verify other runs and again it does not verify with the same results.
I spoke with Masterjun about this and he may or may not be working on a test program to verify the behavior of the bus when doing open bus reads. My guess at this point is that the bus is terminated, so reads are returning a fixed value, and this property is causing the verification issue. It also would mean that the emulator is inaccurate, which would mean what for this run? :)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
REV4 MultiReplay boards finally came in. Very busy but I will try to find time to assemble one and show it off. It's also able to verify non-multitap multiplayer SNES but a few roadblocks are in my way for working fast multitap support.
Conversion boards for the old NES/SNES replay device also came in so I can now use this with the same connectors as the MultiReplay to verify troublesome SNES runs until I get time to fix MultiReplay, or simply as a second device to confirm desyncs. It's really simple but I didn't want to have multiple connectors for multiple devices.
(If you have the old device and want one of these, let me know)
Shown with the beta REV2 device:
EDIT: New MR device soldered up. Have a schematic error that got transferred to the PCB but it can be corrected in firmware, but as long as someone gets my early dev model I'll have to have two firmwares :) But everything else seems to be working well on it. Maybe I'll make the video tomorrow...
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
There is no published "earlier version of this run."
If you mean previous runs exploiting the game or in this category, then yes, there have been previous published runs and runs otherwise posted online, and I have verified at least one of them with my new hardware to confirm the hardware works as expected. My old bot is the one that replayed the AGDQ demo at AGDQ.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
And when replaying this run, we get disappointed because it doesn't verify. Controller or not it won't verify, so don't cry harder than usual.
Just in case of an implementation error (which I doubt - only the first data frame plays, and plays correctly as verified by logic analyzer), I will test this on my old device when the conversion boards come in...should be sometime this week.
What happens after this is I get one more clock and the console controller polling is dead. Screen is black. Music plays. I am sad. Masterjun is probably happy.
Masterjun, would it be possible to make a movie with the old glitch, and have some open bus reads done with screen printout to see what's going on? Or is this too much work? :)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
xnamkcor wrote:
The Replay is not a controller, it is a device that sends electrical impulses to the SNES.
Congratulations, you just described a controller.
xnamkcor wrote:
No, that's a definition of a controller. The definition of an SNES controller is different.
No, you don't understand definitions. You are retarded.
xnamkcor wrote:
And if you were conveying controls that aren't possible via button press on stock hardware, then you are not console verifying.
No, that's not what I was saying. What I was saying is that of the runs I have verified, every single one could be verified with a stock controller. I'll happily make it work with my device if you can make the mechanical construct to press the buttons. But, honestly, it's wholly unnecessary. The result is exactly the same - the console plays back the video and we get the expected result. A brief look on an oscilloscope between an original controller and my device would prove this. A brief look at a fucking verification video actually playing through would prove this. How could you say at this point that the expected result is NOT possible on console? It clearly is. Emulators are good enough for this now. Whether the input is a membrane switch, an output pin to an SR, or an output directly emulating Q7 doesn't matter one bit.
xnamkcor wrote:
I'm fine with these runs existing
Congrats. Glad you're fine with it.
xnamkcor wrote:
and even saying they work on a real console with the device, but we're getting to the point where we need to specify and separate runs that cannot be achieved using the real buttons on stock hardware.
It's simple - those that currently can't be verified with my device also could not be verified with my device pressing buttons on a stock controller. There is no difference. And just because something can't be verified with my device, doesn't mean it's not an implementation flaw, or an emulator bug, or uninitialized memory (different starting conditions) or.... In other words, it may be possible still, so marking something as "unverifiable" would not be a good idea.
In short, you are ignorant of the details regarding verification. I know the information is scattered and sometimes hard to find, but communicate with us, search, read (not just verification stuff but technical documents about these consoles) and learn rather than posting pointless drivel. Or don't and I'll just ignore you from this point forward. Thanks.
xnamkcor wrote:
We're console verifying the run, we need to use the stock controller that that console uses.
You are and idiot ;-)
xnamkcor wrote:
Also, do we have any Gameboy console verifications? All you'd need to do is solder in the button leads, right?
Yeah. It'll just magically play by itself.
I can tell you for sure we don't need an input dumper script or firmware for the device to play back Gameboy. Don't try working on these two things, it's not needed.
Additionally this doesn't "press buttons" per your super secret specification. Your retardation can't even be consistent.
xnamkcor wrote:
Wire up leads to the button switches on the SNES controller and send signals that way if you aren't sure.
I seriously fucking LOL'd. This isn't what you have been arguing all this time. Also, this is exactly what GhostSonic's shit does except without a controller in the way. Do you know what a shift register is? I guess you don't.
You are not qualified to argue this issue. You don't know what you are talking about.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
xnamkcor wrote:
Are we at the point where we need to remake the replay specs to specify you must use a controller and have a specific category if you're just pumping polls into the controller port?
No.
Replay _is_ a controller. (It's just a shift register for NES/SNES, and straight lines and a mux for Genesis, so very easy to emulate). With my implementation, timings aren't as fast as the original chips, but they are fast enough that the console wouldn't know the difference anyway. You could argue perhaps that some SNES runs that use the 4 extra lines isn't being a controller but I still believe it is - it's either a controller with 16 buttons or a modified controller, and in this latter case verification isn't the task that should be questioned.
We'll be at this point when we start acting not like a controller and getting usable or different results.
Why is this not an issue? Because the run would verify exactly the same either way. Verification isn't an exercise in creativity. It's a very specific task with a specific end result. If the expected end result is reached, then it was a success, and it wouldn't matter if I used a controller or direct wire. Importantly, verified runs are not modified from the original replay data. If they were modified, this might be worth looking at - but then again, they wouldn't be verified against the videos hosted here, would they?
It would be possible to make an intermediary device to press buttons on an actual controller, but that is the mechanical engineering realm which is something I don't know about.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Get me a Gameboy and SML2 and I'll verify this and other runs.
Or someone determine timings for SGB, write a .vbm parser, and get me SML2 and I'll verify it with that.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Still been too busy to verify. I did confirm that the run 1) is different in some way and my dumpscript doesn't work with it and 2) my new replay platform doesn't play back anything correctly so I still need to debug this code.
Hope for verification video / confirmation in ~2 weeks. Maybe someone can beat me to it. Or not and I can be the first to confirm =)
(I don't see a reason this wouldn't work with my old replay device, but I converted my controllers to the new input connectors and haven't made conversion boards yet. maybe someone else with the old replay device could verify, but it would require fixing the dumpscript too...)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I posit it was rejected because of my disagreement with how the site handled runs at the time far more than any lack of optimization, but accept the rejection.
I _do_ plan to work on this. Other far more pressing things are on the table. If anyone else wants to work on it I can forward on notes and, if I can find them, scripts I used to work on this.
There should already be a thread for this game. I remember posting in it. Edit: it's in that thread now =)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Patashu wrote:
For the non assembly programmers out there: What's the explanation (discriminator) for this glitch not being ACE, despite looking identical to the ACE usage?
Because of a bug in the game, a bankswitch is (or is not) being performed so incorrect code is being executed. The code isn't arbitrary as it is ROM.
So unintentional by the programmer(s), yes, but not arbitrary.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
finalfighter wrote:
any%: worng ROM address($8000->$FFFF) executed by glitch of TAS (like old TAShttp://tasvideos.org/2921S.html)
ACE : worng RAM address($0000->$7FFF) executed and the code of the RAM was executed by glitch of TAS (like new TAShttp://tasvideos.org/4308S.html)
Something like this makes some sense, but it's too technical (NUMBERS) and too restricted (NES-only! Or definitions for other consoles, no way!), so the people of drama will shoot this down.
Then they'll argue about how to be more vague with very specific requirements to this vagueness and with fewer and fewer words.
TASVideos will eventually be in the most strict one-category cataloging system in existence.
About this specific run: I'll see if I can make time to create a video this week, but I have nearly no time for anything right now.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
NitroGenesis wrote:
True wrote:
Can this be verified on MM USA with adjusting input frames?
The regular input file syncs perfectly already on the U rom
Really? Even with the intro on the U rom? I should have tried that first then as I have the actual cart instead of ripping apart Double Dribble. Will try to make time, a few other projects have come up that are very time constrained...
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Why is there even any drama on this
What if you couldn't hit start to return to the screen, like many other games? There would be no crying about it. I thought movie end here was defined as "reaching credits," which this movie does, thus there is nothing to drama about.
Oh wait this is Tasvideos it wouldn't be home without unnecessary drama
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
One of the reasons this didn't work at first is because I had a solder bridge between an SPI pin and a bodge wire for P2's latch line. It was barely a little flake, so I fixed it and now it works. This means 3 things:
1. The device works and code wasn't at fault
2. I'm blind
3. Praise Double Dribble
Video sometime later. Can this be verified on MM USA with adjusting input frames?
EDIT: New MR device soldered up. Have a schematic error that got transferred to the PCB but it can be corrected in firmware, but as long as someone gets my early dev model I'll have to have two firmwares :) But everything else seems to be working well on it. Maybe I'll make the video tomorrow...
Masterjun, would it be possible to make a movie with the old glitch, and have some open bus reads done with screen printout to see what's going on? Or is this too much work? :)