Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I should stress that the different timing only solves the problem up to the end of the input frame. (I.E. the ram states match and the ball actually starts off going in the right direction.)
I still lose the game in Stella, even starting from what is now the exact same state.
But at least now it will be easier to find out what's gone wrong, can't get much simpler then watching 2 games play out with no input and spotting the difference.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So while I try to get visual studio working so I can try working with Bizhawk, I decided to work the other direction and see if I can make Stella match Bizhawk results.
Turns out, it is easy, and it resolves a lot of the mystery.
The key difference is that Stella assumes a 'Frame' is 262 scanlines+extra scanlines. So when you hold a button down and 'Frame Advance' in Stella, it holds the button until we are back at line 1 again. But, Bizhawk (apparently, I haven't found the code where it says so) counts a frame of input as 262 scanlines ONLY, so only holds the button down for that long. So I released the button in Stella after 262 scanlines and like magic I got the same results as in Bizhawk! Mystery solved!
EDIT: Actually, this seems like a glitch in the game code since way more scanlines are being used then 262. I'm still looking into it.
Well, part of the mystery. The movie starts the same but diverges shortly after. And this doesn't effect visual or audio glitches as far as I can tell.
So I guess the question is which is correct? The game is certainly checking whether a button is held down or not during VBlank, so that seems right to me.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
@FractalFusion: thanks for clarifying that, yeah I was wrong there as well, it does in fact go to the proper hard difficulty in both cases.
As for IRC, I tend to only be online for sporadic periods of time, but if it will help get this cleared up then I will make an effort to go there, I'm definitely at my limits of being able to follow what Bizhawk is doing in terms of the C# code, and a simple 1 frame movie is definitely the time to get these things sorted out, maybe even finally solve that old dragster problem!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^ I actually got the exact same result. 1 frame of input on the first frame, I'm not saying it would be possible on console, I don't know what hardware constraints there might be, but at least on Bizhawk you can do it.
Anyway, after doing still more research, I finally realized what was going on here. In it's initial startup, Flapping goes through this loop:
BNE $F006
DEX
TXS
PHA
X starts at FF and goes to zero.
Unfortunately RAM in atari 2600 only goes down to $80, so this routine quickly runs into TIA registers and it's mirrors.
In my post above, I didn't realize at the time that the TIA was mirrored into $40, but once I saw that it was, it was obvious that what is happening is WSYNC is being written to when X reaches 0x42 and is being called, oops!
So currently my guess is that Bizhawk isn't checking the mirrors of the TIA and missed what should be a WSYNC, (EDIT: or more accurately, not checking PHA's into TIA registers as memory writes nope not that) hence the timing differences. I tried looking at the code but I have no idea what I am looking at.
EDIT2: Well, it looks like BIzhawk is doing all the WSYNC's correctly, just not counting the cycles? Or, isn't stopping the CPU?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
jlun2 wrote:
Alyosha wrote:
text
Is there any method to determine which emulator is correct (or both wrong)? I'm not even sure if having an actual console would help unless there's a way to dump the memory during runtime.
Edit: Also, not sure what to think of the situation where "Hard Mode" is selected, but the game treats as Easy. Is there some precedent for this? What should it even be categorized if it turns out to be legit?
Well, its not the dip switch setting that is effected. What is being selected is the hard AI in Stella (the binary one) but the easy AI in Bizhawk (the kind of dog face looking one.) This is because hard AI happens to be 5 (mod 6) and Stella ends up with $A2=23. Easy AI is 3 (mod 6) and Bizhawk gives $A2=21.
Well I think I (maybe) found the source of the timing difference:
A2600 Specs wrote:
Horizontal Timing and Resolution
Horizontal sync and blanking are done automatically by hardware. The software may re-synchronize itself to begin of H-Blank by writing to WSYNC.
Blanking 22.6 machine clocks (68 color clocks)
Picture 53.3 machine clocks (160 color clocks) (160 pixels)
Total 76.0 machine clocks (228 color clocks)
Bizhawk seems to incrementally lose clock cycles, and I did a step by step trace through both Bizhawk and Stella to see where it happened. I didn't have to go far, it turns out. At cycle 1904, Stella takes a 70 cycle pause as the color clk and pixel pos reset. There is no such pause in Bizhawk. It looks like this happens every time one of these instances pops up, so the difference gets big pretty fast.
EDIT: It's not every scanline, this one happens to be 25, which seems to be a short version that only takes up a few cycles (?)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
A bit of an update here, I found out why the movies play so differently between the 2 emulators.
It turns out that pressing 3 buttons like that at frame zero causes a glitched start up state to occur in the game. The addresses of interest here are $A2 and $F5, which seem to control level selection and RNG (not entirely clear on $F5.)
During a normal startup , $A2 varies between 0 and 5 as you choose between the 6 game modes. In the glitched start up, it goes to 0x17 on Stella and 0X15 on Bizhawk. This seems to be a timing difference, as Stella apparently goes through 2 extra loops of ... something before a poll for input comes up ($0C=0x80) to get to 0x17.
So basically, in the Bizhawk movie you play against the easy computer, while in Stella you play against the hard one. If you put the Stella values into Bizhawk you will indeed lose in the same manner.
I don't know which is correct. Bizhawk seems to be doing a lot of things differently. For example in Stella if you let one frame of 'fire' happen after a normal load sequence, both paddles fall at the same time, however on Bizhawk the same input make the paddle go up slightly, a pretty obvious difference. (besides the graphical / audio glitches in Bizhawk)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Oh, thanks for posting this Patashu, I am really excited for this project, I hope whatever brilliant people are working on it keep making good progress.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
03B4-5 for enemy HP. Seems to hold for all levels.
I didn't get as far as frame rules, but yeah this isn't a game you can really do just by feel, it will likely require some serious research.
I'm happy to help too if you need help finding something specific.
Good Luck!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
With the publication of Wai Wai World this project has reached it's half way point! (well in terms of just number of runs anyway.) When I first started, this project looked pretty daunting but now it really seems doable! There aren't even that many unclaimed runs left which is nice to see too. Well, onward with Battletoads!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So like a lot of games I have looked at this one off and on for a while. After staring at it for long enough I realized that elevators have some properties that can be manipulated to improve the current run.
1. Elevators always spawn at the top of their shaft.
2. Elevators are on something like a global timer, and if you don't spawn them until a cycle of the timer goes by, they won't start their route until the next one starts.
3. An elevator will not go more then 2 stories below where the player is. If the bottom of the shaft is further down then this, the elevator will not go all the way down but instead turn around and come back up.
We can combine these facts to improve level 2 in Brush's run substantially. By chance, everything in level 1 seems to line up nicely so I couldn't improve it at all. This is still a test run, it can probably be improved a bit from here.
http://tasvideos.org/userfiles/info/28816139828924298
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^ oh yeah I forgot to mention that I unchecked the "randomize Ram when loading ROM" option in Stella, so everything started at 0 just like in Bizhawk. But the game plays out the same whether the option is checked or not, and I didn't see any uninitialized RAM use in the trace logs I looked at.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I realized that I never posted any progress on this as I was previously working on it, and as BrunoVisnadi has asked for any info I might have, I figured I'd post everything here in the thread.
Dave_dfwm did great work on the first few levels, I carried on from his WIP. I quickly got stuck however, as RNG was not in my favor, and I never completely figured out how to control enemy behavior.
However even worse, it seems that missing a few enemy kills and not having enough experience to do the jump kick severely impacted the latter half of level 3. It might be the case that some of Dave_dfwm's earlier improvements will have to be thrown out in order to keep good times later on.
But, I did include the knocking the 2 knuckles into the water trick in this WIP, so at least it's there on a current emulator, should save some hassle.
http://tasvideos.org/userfiles/info/28798667389354492
By the time I beat level 3 I had lost all the previous savings, so starting over on that level is probably best, at least you have something to compare too.
Game Mechanics:
Enemies in a wave spawn as soon as previous ones fade out. They spawn off screen however so you will have to manipulate their behavior so that they spawn in a pattern that has them walking toward you, unless you have something to throw at them.
RAM addresses:
player X: 005A
enemy 1X: 005B
enemy 1y: 005C
player y: 0072
enemy 1y: 0073
enemy 2y: 0074
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Thanks for the encode Samara.
I've been wanting to see a run of this game and here it is! I skipped around a bit but the parts I did watch looked well done. It's a shame the game, like many N64 games, isn't emulated quite right, but oh well.
I did laugh at how some of the game mechanics are abused, like walking over the piano notes and blatantly starting in front of the orange walrus during the race.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I realized you can put inputs into Stella through the debug screen.
I started at frame zero and used the exact same 1 frame input as in Bizhawk in both difficulty settings and I lost both times. So, my guess is that this game cannot actually be beaten in 1 frame on actual hardware.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'm pretty sure all my settings are correct, I even put in NTSC Top line = 34 so the bottom line would show up correctly.
Actually, I was able to recreate the run in Bizhawk in real time after a few tries, it just doesn't work in other emulators.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I have tried reproducing this in other emulators and I always lose. I'm pretty sure I'm getting the correct input, you can tell when the paddles both fall at the same time, but the game plays differently.
In particular, pterry starts in a different position on screen. You can see this quite clearly here:
The bird starts 1 pixel to the left in Bizhawk. I captured this using the Stella emulator, which has a frame advance feature in it's debug mode. The birds X position is at $61. In BizHawk on the frame the bird appears, the value is 0x4D, in Stella it is 0x4C. Other emulators agree with this position.
But you don't need frame advance to see the differences, here is a another screen shot of the countdown, the number '1' is pretty clearly one pixel to the left in Bizhawk:
It's not the ball that is positioned wrong either, it is at 0x55 at $5B in both.
I suspect there is an emulation issue in Bizhawk.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
There are a couple bugs in emulating the A2600 game Flapping in BizHawk.
1. On the title screen part of the 'p' in 'ping' is not properly outlined. It looks like the blocks are shifted upwards.
2. The sound effect that plays when you move your paddle is noticeably higher pitched then on other emulators and youtube game play I saw. That seems to be the only sound effect that is wrong though, the bird and the music sounded right to me.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
There is a graphical glitch in the title screen of this game on Bizhawk. You can see that part of the 'p' in 'ping' is not outlined properly. I tested 2 other A2600 emulators and the 'p' is outlined correctly.
Dragster for example also contains graphical glitches on Bizhawk and seems to suffer emulation errors as well. Is there a way to test if the behavior in this run, as well as TASeditor's, is correct and not the result of some error?
I have no idea what exactly is going on, but something seems to be up with A2600 emulation.
EDIT: I also noticed that the sound that plays when hitting B to move your paddle is also much lower pitch on other emulators (and youtube videos)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Nach wrote:
Returning to the problem at hand, in my opinion, we need a way to classify these total control and similar runs. They need to have their own rules regarding completion criteria, as well as overall criteria on what is allowed and disallowed. I find a key factor here that games which lack these exploits are finite. Baring loops, there are a (nearly incalculable) finite amount of ways to complete a game. However, in games that we can add our own code, once we do so, there are now an infinite amount of ways to proceed. These two groups are now objectively distinct, and we really do need to come up with a set of rules for each. These rules we develop should take into account how the different groups of these runs differ from each other as I entailed in my presentation of the previous problem, and allow for many runs per game, but limit the infinite.
An important point to consider in developing a tier and rules for it is how a run makes use of the existing game once its payload begins. This run to my knowledge is the first run to no longer make any use of the game whatsoever once the payload begins. Meaning that the final payload can be ran on any SNES game once controller input to RAM becomes possible. Since it's not tied to a game, do we accept different runs of Notepad attached to Super Mario World, Super Metroid, Kirby Super Star, and others? Not only do we have to categorize what kind of diversity we allow for any given game, we need to limit how we apply this diversity to many different games, as I do not wish to publish the same virtually identical payload over and over.
I already began work in trying to define a new tier for these kinds of runs in order to spark some discussion. However, I find this initial work to be lacking in that it does not make use of yet to be developed movie class/branch criteria, and it does not supply a series of rules on how to deal with the aforementioned sub-problems in this tier problem. If we can iron these issues out, I'd be happy to enable the site to support it, and then accept this run if it conforms to the new rules.
In closing I want to add that runs like this which include payloads and play them take tool-assistance to their epitome input-wise, and we should put the effort in to properly acknowledge them.
Since I do like tech demo stuff a lot (even if I'm not that technically knowledgeable enough to do anything of the sort) I guess I'll at least post some comments about this.
My feeling in reading over Nach's post is basically wondering why there is such an over abundance of caution. I don't see the harm in just declaring the Demo Tier into existence, using your (Nach's) existing rough draft of rules and such, putting some runs into it, and working out the kinks from there. It's no big deal if some problems are encountered or some mistakes are made along the way, gotta climb that learning curve somehow. At least there would be something real to look at and work with instead of just the hypothetical. Not everything needs to be crystal clear and set in stone for the tier to work, and it's not like we're stopping global warming or defeating ISIS here, give it a try! Something is better then nothing!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I definitely agree, which is why I asked for just that in the Umihara Kawase fun by Flagitious.
For Clue though I don't think any of the groundwork is in place to make that happen, so it will probably have to lie dormant for a while, even if a real improvement is found, oh well.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Ok, so given that in the Clue submission there seemed to be some support amongst staff for updating old submissions with new ones on current emulators, I thought this one would be an excellent test case.
1. It is short
2. It is incredibly well optimized so a significant improvement is unlikely
3. It has it's own frame timer, so you can easily check that the re-synced file completes the levels in the same manner with the exception of more accurate lag.
4. There is no RNG, so nothing to raise concerns there.
So, I wish to ask that the existing submission file be replaced with this one:
http://tasvideos.org/userfiles/info/21288338289808557
I'm glad I kept it around!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
There are a lot of repeat solutions in the List I posted, so there might be another aspect to the RNG that I haven't accounted for.
Also I tested quite a few different possible solutions, and so far Deign's run still wins.
The closest in Green accusing himself with the wrench in the ballroom, but the problem is that to get green to be the accuser, all 3 of the lower 3 characters on the selection screen have to be selected. Play in the game starts at Ms Scarlet and proceeds clockwise, so in order for green to be the accuser, he needs to be the first human player in the rotation. This takes 4 frames to set up, and just 2 frames too long to beat Deign's run.
I don't think I'll put too much more into this. But, the important point here is that RAM initialization makes Deign's solution optimal, and this cannot be achieved in Bizhawk or lsnes without it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Awesome! Good luck Bruno Visnadi!
Yeah Cobra Triangle is all luck manipulation and is a bit tedious so good luck.
I put a decent amount of work into Double Dragon so I can at least give you a head start once you get a round to that one.
Also I am Happy to announce that myself, Samsara, and ArandomgameTASer have teamed up to tackle both Battletoads runs, expect WIPs in the not too distant future : )
The bird starts 1 pixel to the left in Bizhawk. I captured this using the Stella emulator, which has a frame advance feature in it's debug mode. The birds X position is at $61. In BizHawk on the frame the bird appears, the value is 0x4D, in Stella it is 0x4C. Other emulators agree with this position.
But you don't need frame advance to see the differences, here is a another screen shot of the countdown, the number '1' is pretty clearly one pixel to the left in Bizhawk:
It's not the ball that is positioned wrong either, it is at 0x55 at $5B in both.
I suspect there is an emulation issue in Bizhawk.