FlapPing and writing to playfield registers

[AlyoshaTAS]

Hello AtariAge : )

 

I am posting here a question that has me a bit stumped and was hoping to get some expert opinions.

 

In the homebrew game FlapPing, the title screen displays as intended with most emulators, in particular Stella, but when I try it in an emulator called BizHawk this is what I get:

 

 

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 above code (minus the WSYNC) takes 48 cycles to execute so we have 144 color clocks worth of code there. Horizontal 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, I did so here and you can load it and see:

https://www.dropbox.com/s/6q5ty6d0ixa7kf1/flapping2.bin?dl=0

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 also tried e-mailing Kirk Israel, but the address (flapping@alienbill.com) returns a 'no such user' error.

 

Thank you for any responses!

[Nukey Shay]

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. The "BizHawk" emulator is at fault here.

[AlyoshaTAS]

Ahhhh so that is the explanation, thank you for the concise and helpful answer! I surely would never have figured that out on my own.

[AlyoshaTAS]

Hello again, I have another question that I think is easy to answer but I can't really find a lot of documentation on.

 

 

So here are 5 consecutive frames in FlapPing. On the fourth frame you can see the ball dip into Pterry's head, thus causing a collision and throwing it backwards.

 

This isn't happening because the ball (technically it's missile1) is moving downwards though, it actually has a slight upward velocity at this point. It dips down because an ENAM write is happening at this exact spot, 1 pixel behind where the ball is on that fourth frame.

 

So it looks like there is a 1 color clk delay here in processing the ENAM, but my question is what exactly is happening here hardware wise. Does it simply take 1 extra clock to process the enam after the write to it, or is there something more complicated happening?

 

Thanks for any insight!