Trying to understand the purpose of this operation:

[Dugongue]

So every once in a while I do a side-by-side comparison of the JP/US versions of games to work out what's changed between revisions. I was looking at the JP and US version of Blaster Master, specifically Page 6 which contains the AI code for objects in the side/tank view sections.
I'm not fully through the page but I've found at least 8 separate occurrences of the operation "LDY #$00" added in various spots. At first I thought this must have been a case where the original code falsely assumed that Y, or certain status flags, would always have a specific value at that point, and this was a fix for that. But that doesn't seem to be the case.

Attached is a specific example. The code itself has to do w/ the speed of Jason's swimming animation (faster if the D-Pad is pressed). I made a trace log for the original code + the same code with the operation skipped over. This operation doesn't seem to have any direct effect on the following code, since the next relevant values of Y/the status flags are set by other operations afterward.

It's probably not that important but the fact they would go out of their way to add something so specific multiple times makes me wonder what the purpose could possibly be. I was just wondering if it rang a bell for something someone has seen in another game.

[calima]

My guess: they changed their optimizer to fix a missing Y clear, like you assumed, just not for handmade asm. Then the fixed version could not determine it wasn't needed in some of those places.

If the addition looks automated, then the code may have been compiled from something else.

[Bregalad]

I can't answer the original question, but I can say I witnessed that the AI of enemies in Blaster Master is extremely glitched, so I wouldn't be suprised if it would have been coded very badly, and (insufficient) fixes would have been made between the JP and US versions of the game. Even the movement when using the vehicle is erratic and sometimes you can exit the vehicle, only to be stuck outside and never climb in it ever again. It's also possible at the gate between world 1 and world 2, on world 1 side, to be stuck below the game with the vehicle and be unable to leave with the vehicle, effectively making you stuck there.

Great music, OK levels but what a shame the game is so full of glitches !

[Controllerhead]

Sup dewey!

It's odd to see two NOP's replaced with a seemingly useless LDY immediate as TAY happens after the JMP. They are both 2 bytes, and the NOPs take 4 cycles instead of the LDY immediate's 2, but hmmm.... i guesssss it could be a precise timing thing? but that seems like a stretch. Very strange.

Are the other LDY #$00's also replacing NOP's? Also Check to see if the Y register is ever referenced after the other LDY #$00's before being altered identically, if it is, then you might be on to something. Maybe watch out for BEQ / BNE branches too, as LDY #$00 will set the Z flag if it is the latest thing altered.

Otherwise LDY #$00 will give the sliiightest speed advantage over two NOPs and maybe prevent a frame of lag here and there. Possibly. That may be of interest to you. Also could cause a movie desync in that same situation, if the NOP version gets a frame behind, or the LDY version gets a frame ahead, depending on which version it was recorded on; ....but i don't know about the rest of the code, so i can't say for sure.

Edit: He added the NOP's himself. D'oh! I am a NOP. Pardon me whilst i halt and catch fire.

[aa-dav]

I bet this is just some macro like "LDXY" which programmer thoughtlessly used.
Or scraps of removed code.

[Dugongue]

It's odd to see two NOP's replaced with a seemingly useless LDY immediate as TAY happens after the JMP.

Sorry I didn't explain that very well, the NOPs I manually added into the US ROM to see if it resulted in any difference in the trace. The JP rom has no operation there at all.

My guess: they changed their optimizer to fix a missing Y clear, like you assumed, just not for handmade asm. Then the fixed version could not determine it wasn't needed in some of those places.
If the addition looks automated, then the code may have been compiled from something else.

I bet this is just some macro like "LDXY" which programmer thoughtlessly used.

These were my thoughts as well. The way the branching is structured looks a lot to me like other examples I've seen of C-like control structures compiled to 6502.
The only other difference I've seen so far is a change to a branch that removed a redunant RTS, which also seems like the result of an updated optimizer.
So presumably if I keep looking through the code for all new instances of LDY #$00 I should find one where it actually does something.

[aa-dav]

Does it look real what someone in 1988 had compiler for NES with optimizations and so on?
It looks unreal for me.
I think "automated" here is just "macros".