Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
^not sure if it helps, but when I release the barrel on frame 6530 it successfully opens the bonus, though I am still a good distance away from it.
When I release the barrel the sound of a kremling being killed plays, not sure if this is expected or perhaps related to the reason it doesn't work on the frame you want it to.
I've also reached the bonus area with different values of 000D4D while hitting the midway barrel at slower speeds, could be related to how it gets scrolled off screen
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Hmmm updated in what way? I'm not sure what the question is (or if it's directed to me)
If you mean by adding in the runs jlun2 found, then no I didn't plan on it. Maybe I will add it as an addendum after the initial list is complete. It would be nice to have those runs improved also, but I certainly have no plans for any of them. I also have no interest in a 'First 1000' or other equivalent.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
So even though I found the bug that makes the car break apart and start in the wrong place in BizHawk, I am no closer to being able to reach a time of 5:51.
Stella has the same behavior as BizHawk for the actual race, and there is just nothing new to test at a per frame level that could possibly bring the time down.
Only a reduction of one of the speed pauses could bring down the time, but nothing (at the frame level at least) that I have found can make this happen.
This one is still a mystery. My only thought is something at the snanline or even cycle level, but I don't know what it could be.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
else if (maskedAddr == 0x11) // RESP1
{
// Borrowed from EMU7800. Apparently resetting between 68 and 76 has strange results.
// This fixes some graphic glitches with Frostbite
if (_hsyncCnt < 69)
{
_player1.HPosCnt = 0;
_player1.ResetCnt = 0;
_player1.Reset = true;
}
else if (_hsyncCnt == 69)
{
_player1.ResetCnt = 3;
}
else if (_hsyncCnt == 72)
{
_player1.ResetCnt = 2;
}
else if (_hsyncCnt == 75)
{
_player1.ResetCnt = 1;
}
else
This piece of code is responsible for both the exploding car in Dragster and the fact that Halo 2600 cannot be completed in BizHawk.
When I change the 3-2-1 to zeros, everything works fine. So whatever the 7800 is doing with the TIA seems to be specific to the 7800 and does not extend to the 2600.
I also have found no reason to believe these values are true from looking at any of the 2600 documentation.
So looks like another quick fix and another annoying bug is busted!
EDIT: Update on this, it also fixes Smurfs in that the game can now be beaten. I also looked at the moving houses in River Raid and I think the double sized player bug fix and/or the player register write delay will solve that problem, and likely the graphical glitch in Grand Prix as well.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/28953286712756335I tired to make a youtube upload but it just wasn't working out, sorry.
Alright! Finally we can present WIP 1 of Battletoads one player warpless. This run plays up through the turbo tunnel skip. The skip itself can probbly be improved a bit, but I wanted to make sure to give time for people to comment on everything up to that point before I finalize it, just in case some funny sync stuff happens.
Anyway the main improvements over the current published run are:
-Reduce lag as much as possible in level 1 by using the sword. The boss in this level fires when a time at $0B rolls over from FF to 00. So basically, you can play the level slower using the sword to save on super move lag while still beating the boss at the same time.
-Remove super move lag from killing first 4 chompers in stage 2. I found this trick by accident, somehow it removes the animation of actually hitting the enemy since you hit the wall simultaneously.
- Turbo Tunnel Skip: As demonstrated by feos in the GIF above as well as by real time runners.
A lot of optimization work has already gone into this so far and i am happy with the results the team has achieved so far, I do expect level 4 to take a while and we are simultaneously working on the 2 player warpless as well, so there is lot's of time if anyone has any input, do post it!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I have also found out why your paddle always rises after pressing start in FlapPing (after an otherwise normal startup)
The game actually only does a very short (9 scanline) frame after the end of the previous frame when it determines the button is pressed and it's time to start.
The problem is that BizHawk is detecting this frame exists as a seperate frame, (giving it it's own frame in TASstudio piano role as well giving a blank screen i.e. no video input) but at the same time is carrying over the input from the previous frame into it. This is easily demonstrated in Stella by just doing the same thing and carrying the button press through those 9 scanlines.
I don't know where this matmatch is happening in the code, I'm having a hard time following the C#, but this is the effect anyway.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Not sure about river raid, but Atari's memory has lots and lots of mirrors so that could be it.
Dragster probably has something else going on that I haven't gotten to yet, possibly related to how the paddles act a little differently here in BizHawk then Stella.
But, the reason 'O' in POWER in the game H.E.R.O. isn't properly drawn is probably the same reason the title screen here isn't correctly drawn. In that case writing to the GRP0 register is happening at the same time it's being drawn, when there should be a one cycle delay.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Well, this has been quite a treasure hunt!
After a lot of time staring at code and Atari documents and looking at many frames and scanlines, I think I understand what went wrong here.
All of this comes down to a color clock delay in drawing double sized players. Bizhawk misses this delay and thus double sized objects, such as Pterry and the countdown numbers in Flapping, are drawn one pixel too far to the left compared to real hardware. Those interested can download the neat test ROM from this thread and compare BizHawk and Stella, pretty neat demonstration!
http://atariage.com/forums/topic/239890-respx-nusizx-and-player-positioning/
Anyway, this is not simply a graphical glitch, for the TIA also does hardware level collision detection, and in a literal case of threading the needle, this is where things go wrong.
After I understood the difference between inputs in Stella and Bizhawk, I was able to compare frames and see where things went wrong, and it all comes down to that one pixel shift. Illustrated below is the frames right where the game diverges between Stella and BizHawk:
Stella:
BizHawk:
So in Stella we see that, in an amazing coincidence, the ball moves directly into the birds eye! So the TIA does not count this as a video collision, and the ball carries on for one more frame. But, this isn't the case in BizHawk, that one pixel shift means that the ball and the player collide 1 frame earlier, and everything diverges from there.
In the end, the Stella game goes on to lose, while the BizHawk one goes on to win, all because of 1 pixel of shift due to an obscure hardware level delay.
there is still more to research and AtariHawk is doing several other things differently from Stella, but for this game this is the deciding factor.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Alright! Turns out the number positioning bug is actually a pretty simple bug and was relatively easy to track down.
The problem is that there is an extra color clock needed to position double and quad size players. Pterry and the countdown numbers are double sized, and BizHawk isn't giving them that one pixel shift to the right.
See this thread for discussion and even test ROM results that show this:
http://atariage.com/forums/topic/239890-respx-nusizx-and-player-positioning/
Looks like a simple fix, hopefully this also fixes the car positioning bug in Dragster.
EDIT: I should clarify that it's not their position that changes, it just takes one extra clock to start drawing them. BizHawk looks like it already has the one pixel delay built in for normal sized players, it just needs one more for double/triple sized ones.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Ok first off let's start with the title screen drawing bug:
So I stared at BizHawk's code for a long time trying to find the reason that the 'P' in 'Ping' is not being outlined properly, but in the end, it just seems like it's doing everything properly. This is strange, as other emulator's draw the screen as intended with no problems. So I looked at the game code:
F19D 85 STA $02
F19F BD LDA $FE9E,X *
F1A2 85 STA $0D
F1A4 BD LDA $FEC1,X *
F1A7 85 STA $0E
F1A9 BD LDA $FEE4,X *
F1AC 85 STA $0F
F1AE EA NOP
F1AF EA NOP
F1B0 EA NOP
F1B1 BD LDA $FF07,X *
F1B4 85 STA $0D
F1B6 BD LDA $FF2A,X *
F1B9 85 STA $0E
F1BB BD LDA $FF4D,X *
F1BE 85 STA $0F
The first instruction, STA $02 calls a WSYNC which halts the CPU until a scanline is finished drawing. So the next LDA instruction happens only once horizontal blanking starts. This loop loads one line of the title screen. (The addresses $0D-F are the playfield registers that tell the TIA what to draw.)
The above code (minus the WSYNC) takes 48 cycles to execute. There are 3 color clocks (i.e. pixels) per cycle, which means we have 144 color clocks worth of code there. Horiztontal blanking takes 68 of those clocks, meaning we end at pixel 76 on the screen. The point here is that F1BE has stored a new value to the playfield register before the TIA has had time to draw the first half (80 pxels) of the screen. So the expected behavior is that the last block of 4 pixels will be drawn with the new values (the second half of the screen.) And this is what we see here, As that vertical bar is clearly a copy of the one on the right edge of the title.
So I can only conclude that BizHawk is correct, and this is what should actually be displayed. It's not even hard to test, the next instruction after STA $0F is DEY, and if you just swap the order of these instructions, you give the TIA 6 extra clocks and it gets safely past the half way mark.
Stella seems to be cheating a bit here, as in Debug mode you can see that the TIA has drawn past the half way mark despite the hsync counter and the cycle counter both agreeing that they haven't made it that far. I can't explain this behavior.
This is all very strange, but if anyone has any reason to believe that Stella is doing things correctly, or has pictures of this game being played on a real console to prove things one way or another, please let me know. I will also post asking this on AtariAge (once they let me post.) I also tried e-mailing Kirk Israel, but the address (flapping@alienbill.com) returns a 'no such user' error.
well a helpful poster at AtariAge gave a helpful answer!
Nukey Shay wrote:
Stella is correct. The midline PF2 store needs to happen @ cycle 48 or above (up to cycle 60 IIRC) so the left portion is not affected. The original code hits exactly at cycle 48.
So it looks like a quick patch to BizHawk to prevent midscanline updates to the playfield registers before this point is all that is needed.
It pays to ask the experts!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
So I am making this thread as sorting things out in FlapPing is proving far more difficult then I thought. So I'll use this to sort out my thoughts/findings and if anyone with any sort of knowledge or can offer any insights please do so.
I will be using this opening post as a Tracker for things I find.
FIXED!
Midscanline playfield register updates are not immediately latched by TIA. This is why FlapPing intro screen doesn't draw correctly.
Player graphics register updates are also not immediately latched by TIA. Similar to above, this is why the 'O' in 'POWER' in H.E.R.O. isn't drawn correctly.
Double and Triple sized players take an extra color clock to draw. This is why FlapPing doesn't sync and the countdown numbers are slightly misaligned. Since this also effects collisions it is a pretty serious bug.
Special instructions that modify player resets that were borrowed from 7800 code are not necessary for the 2600. This is what casues Halo 2600 to be unwinnable and the car in Dragster to break into pieces.
Writes to timer should cause immediate decrements
RESPs in HBlank should set players at 3 pixels in not 5.
writes to ENAM registers have a one pixel delay in registering
check PAL timing. Lag frames are added when there is an off-nominal number of scanlines per frame, this is tied closely to frame definition but not an independent problem.
sound emulation.
TO DO
Implement HBLank cancelling (but need something to test it on)
Frame definition and input mismatch. This is not technically a bug, rather an architecture choice, but nonetheles produces some trouble in edge cases, such as the paddle always rising in FlapPing
investigate 6532 start up state. Is it uninitialized?
investigate HMove interaction with RESP commands. It looks like there is some trouble with RESP and Hmove happening on the same clock
BONUS
Cosmic Ark stars. Probably some analog or very low level timing effects, but is not currently understood. This seems to be tied to TIA revision. Unlikely to be resolved without circuit analysis of each revision.
second look at delays and timings. Many timing delays give correct results but it's not clear why they would be true from a low level. Partially resolved with revised HMOVE code, but questions remain particularly in RESB and PF.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Good to see you still making progress on this Tompa!
Keep it up!
You surely don't need my help, but I still want to work on this and help it get to completion, so if you want me to look at anything besides Croctopus Chase just let me know.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
BrunoVisnadi wrote:
I'm also planning a The Combatribes TAS. I'll probably take a while to finish these movies because I'm focusing on other projects right now, but I'll finish all 3 still this year (hopefully).
wow that would be amazing! Good luck!
Yeah as Spikestuff says this TAS isn't actually especially difficult, it's just too boring (in my opinion) so I never managed the motivation to do it. I hope your attempt goes better then mine!
Also I noticed you say 'snes' combatribes. This run has some dubious history (I guess form being self published) so you might want to just go to arcade as that is the preferred version it seems, but snes should be fine if obsoletion is the only goal.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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.
BizHawk:
So in Stella we see that, in an amazing coincidence, the ball moves directly into the birds eye! So the TIA does not count this as a video collision, and the ball carries on for one more frame. But, this isn't the case in BizHawk, that one pixel shift means that the ball and the player collide 1 frame earlier, and everything diverges from there.
In the end, the Stella game goes on to lose, while the BizHawk one goes on to win, all because of 1 pixel of shift due to an obscure hardware level delay.
there is still more to research and AtariHawk is doing several other things differently from Stella, but for this game this is the deciding factor.
So I stared at BizHawk's code for a long time trying to find the reason that the 'P' in 'Ping' is not being outlined properly, but in the end, it just seems like it's doing everything properly. This is strange, as other emulator's draw the screen as intended with no problems. So I looked at the game code:
F19D 85 STA $02
F19F BD LDA $FE9E,X *
F1A2 85 STA $0D
F1A4 BD LDA $FEC1,X *
F1A7 85 STA $0E
F1A9 BD LDA $FEE4,X *
F1AC 85 STA $0F
F1AE EA NOP
F1AF EA NOP
F1B0 EA NOP
F1B1 BD LDA $FF07,X *
F1B4 85 STA $0D
F1B6 BD LDA $FF2A,X *
F1B9 85 STA $0E
F1BB BD LDA $FF4D,X *
F1BE 85 STA $0F
The first instruction, STA $02 calls a WSYNC which halts the CPU until a scanline is finished drawing. So the next LDA instruction happens only once horizontal blanking starts. This loop loads one line of the title screen. (The addresses $0D-F are the playfield registers that tell the TIA what to draw.)
The above code (minus the WSYNC) takes 48 cycles to execute. There are 3 color clocks (i.e. pixels) per cycle, which means we have 144 color clocks worth of code there. Horiztontal blanking takes 68 of those clocks, meaning we end at pixel 76 on the screen. The point here is that F1BE has stored a new value to the playfield register before the TIA has had time to draw the first half (80 pxels) of the screen. So the expected behavior is that the last block of 4 pixels will be drawn with the new values (the second half of the screen.) And this is what we see here, As that vertical bar is clearly a copy of the one on the right edge of the title.
So I can only conclude that BizHawk is correct, and this is what should actually be displayed. It's not even hard to test, the next instruction after STA $0F is DEY, and if you just swap the order of these instructions, you give the TIA 6 extra clocks and it gets safely past the half way mark.
Stella seems to be cheating a bit here, as in Debug mode you can see that the TIA has drawn past the half way mark despite the hsync counter and the cycle counter both agreeing that they haven't made it that far. I can't explain this behavior.
This is all very strange, but if anyone has any reason to believe that Stella is doing things correctly, or has pictures of this game being played on a real console to prove things one way or another, please let me know. I will also post asking this on AtariAge (once they let me post.) I also tried e-mailing Kirk Israel, but the address (flapping@alienbill.com) returns a 'no such user' error.
well a helpful poster at AtariAge gave a helpful answer!