As I've already said multiple times, if you want me to add that, you are going to explain that LSR $19 will not do what the user would expect.
LDA #$02 sets A to 2.
LDA $19 sets A to the value in $19.
LSR #2 shifts A two steps.
#2 is equivalent to #$02.
The logical conclusion is that LSR $19 will shift A a varying number of steps.
This is not true. The real behaviour is reading $19, shifting it one step, and storing it back to $19; it alters the flags, but leaves A unchanged. In other words, it's identical to PHA : LDA $19 : LSR : STA $19 : PLA (except faster and smaller). To shift a variable number of steps, you need either a loop, a jump table, or self modifying code. (Don't bother mentioning jump tables or self modifying codes, they're irrelevant in this context.)
That LSR $19 will act unexpected must be explained. You may use another RAM address, or a placeholder (for example $-- or !ram), if you prefer that; and I'm happy with a "won't work" notice, you don't need to explain what actually happens. The RAM-using shifts are very rare, anyways.
Things I haven't said half a dozen times:
- I'd call it "accumulator" or "A register" instead, not "normal bit".
- The ROR/ROL descriptions are still wrong; if carry is set prior to entering those codes, A will be #$80 or #$03. Add a CLC or SEC. (Preferably SEC in at least one of them, to make it clearer what happens. Or both, your choice.)
- I'd put "shifting digits multiple steps" on one line. No reason to split lines when not needed, it
things harder to read.
- "Resetted" isn't a word I normally use; I normally say "cleared". Clearing a bit that's removed doesn't make much sense either; say that those values are thrown away.
<blm> zsnes users are the flatearthers of emulation