Okay, also es gibt gar keinen Fehler, und der Code funktioniert, du möchtest ihn nur effizienter haben? Das wär ja schon mal eine wichtige Information.
Zuerst was Anderes: LDA #$00 : STZ bringt nichts (außer du brauchst die 0 in A für später). Entweder LDA #$00 : STA $1490, oder - effizienter - STZ $1490. $15 ist übrigens nicht "Controller buttons pressed this frame", das wäre $16.
So, okay. Was du sagen willst, ist: "wenn $7B null ist oder $15 null ist, dann setz den Stern zurück". Oder, mit gleicher Bedeutung: "wenn $7B nicht null ist und $15 nicht null ist, dann setz den Stern nicht zurück". Beides kann man in ASM aber nicht so elegant ausdrücken. Das einzige, was man dann noch verbessern könnte, ist, den zweiten Branch umzudrehen: wenn du nicht zu dem branchst, was du willst, sondern zu dem, was du nicht willst, sparst du oft Speicherplatz und Verzweigungen (in diesem Fall den einen Zweig mit dem RTS).
Ich wäre für so was:
CodeRealReturn:
LDA $7B
BEQ .removeStar
LDA $15
AND #$04
BNE .keepStar
.removeStar
STZ $1490
.keepStar
RTS
Wenn du mit den Kommentaren Dinge erklären willst, dann erklär sie am besten auf einer höheren Ebene. Kommentare wie "branch to this label" oder "subtract these values" bringen so gut wie gar nichts. Und "check if [...]" nützt dem Leser auch nicht viel, wenn er nicht erfährt, was denn nach dem Check passieren soll.
In einen Kommentar gehört am besten eine Erklärung in menschlicher Sprache, was ein Block voll Code tut, oder auch eine Erklärung, warum du an dieser Stelle tust, was du tust. Für diesen Block wäre so was schön gewesen wie "remove star power unless the player is ducking and pressing down". Was die Maschine macht - dass da ein Laden oder Branchen passiert - sehen wir auch selber, aber deine Absichten als Programmierer sehen wir nicht.
Ach ja, und die Hälfte deiner Labels sind ziemlich bescheiden benannt ("RealReturn", "ForRealReturn", "Mainuscode", "Bla", "chatto"). Da steigst du in sechs Wochen garantiert nicht mehr durch. Es zahlt sich aus, sich beim Code-Schreiben zehn Sekunden Zeit zu nehmen und sich einen guten Namen auszudenken, damit sich der Code auch ohne Kommentare von selbst erklärt. Spätestens am Ende beim Aufpolieren. Oft sind gut benannte Labels, wenn sie deine Absichten als Programmierer gut genug erklären, sogar ein kompletter Ersatz für Kommentare!