Unclear bug in FOR loop (was: Bugs & Quirks in the [...] ROMs)

[Soloman]

Just discovered another bug, or am I mistaking? I am programming the game "Deal or no deal" (USA). In the Netherlands we have the roots of this television-show. When I programmed a screen where the available briefcases are shown, the VIC (Vice emulator) froze when I choose briefcase 1. The subroutine shows all briefcases except those that are opened. In a subroutine I print rows with the availables cases. This is the coding of the lowest part, suitcase 3 to 1:



The thing is, this one freezes, but when I erase the STEP -1, the problem is solved!! Isn't that strange?
Don't mind the colors, those are the colors of the TV-show.


(mod: thread split off from Bugs & Quirks in the VIC-20 BASIC & KERNAL ROMs, as the described issue is unrelated, and rather a programming bug)

[Mike]

Either post the complete program which crashes or produce a minimal test case that reproduces this behaviour, then we can look further.

The code snippet you show in the screenshot above is incomplete, on its own there is exactly a zero % chance it could crash the BASIC interpreter or even VICE.

Judging from some earlier posts of yours, you seem to have an unlucky business with POKEs. Mind you, one single POKE to a wrong address can mess up the workings of BASIC interpreter or KERNAL, big time. Especially, when the target address is not hard-coded as literal, but contained in a variable, stray POKEs to unintended addresses can easily happen when said variable is changed somewhere else in the program. That can easily lead to unexpected bahaviour, outright errors or crashes in some other, completely unrelated parts of the program.

[Soloman]

Either post the complete program which crashes or produce a minimal test case that reproduces this behaviour, then we can look further.

The code snippet you show in the screenshot above is incomplete, on its own there is exactly a zero % chance it could crash the BASIC interpreter or even VICE.

Judging from some earlier posts of yours, you seem to have an unlucky business with POKEs. Mind you, one single POKE to a wrong address can mess up the workings of BASIC interpreter or KERNAL, big time. Especially, when the target address is not hard-coded as literal, but contained in a variable, stray POKEs to unintended addresses can easily happen when said variable is changed somewhere else in the program. That can easily lead to unexpected bahaviour, outright errors or crashes in some other, completely unrelated parts of the program.

EDIT - I found it, I am stupid, stupid, stupid, stupid. It was so simple......
Sorry, sorry, sorry.

[tokra]

So? What went wrong? Your code-snippet looked fine. And the STEP -1 command was fine as well.

[Orangeman96]

EDIT - I found it, I am stupid, stupid, stupid, stupid. It was so simple......
Sorry, sorry, sorry.

Soloman,

I can't remember the last time I used a POKE was (or a PEEK for that matter) since I embarked on a long-overdue migration away from BASIC, and started programming in 6502 Assembly on the "Venerable VIC-20" a little over a year ago. (Quite honestly, I am not sure I even want to remember how to POKE and PEEK! )

I wish you the best of luck in your adventures learning Assembly!

OGM

P.S. Please note that you can call JSR $CB1E from BASIC as a sort of "PRTSTR" (print string) routine in your Assembly programs instead of JSR $FFD2 / "CHROUT" (output character to currently identified/selected device) provided you punctuate your section of text in memory with a $00 (or BRK in your assembler). (You can also include a $0D ([RETURN]) prior to the punctuating $00.)

[Soloman]

So? What went wrong? Your code-snippet looked fine. And the STEP -1 command was fine as well.

Pfff.
This is a part of a subroutine that shows the suitcases. In the game you have to open an amount of suitcases. The suitcases you opened are removed, so I made them invisible by giving the suitcasenumber the color of the background (blue), so they became invisible.
When it was the last suitcase, the color of the background was not changed to the original color (yellow). The consequence was that everything printed afterwards did not appear on the screen, because the character-color was the same as the background-color. I thought the system froze, but that was not the case.

Stupid me!

[Mike]

When it was the last suitcase, the color of the background was not changed to the original color (yellow). The consequence was that everything printed afterwards did not appear on the screen, [...]

Thank you for clearing that up.

On a short note, the hap-hazard change of "STEP -1" to 'nothing' (i.e. STEP 1) results in a non-working FOR loop: the first iteration is performed, but none thereafter - in CBM BASIC, FOR ... NEXT checks the loop control variable only at NEXT, not at FOR. In other BASIC dialects, the FOR loop would be skipped entirely. This change in semantics for sure couldn't have been what you wanted, so the bug must have been somewhere else - in this case it was the missing change back to the default foreground colour.

That's the kind of errors that can get everyone still, even with lots of years of programming experience. You're not alone.

[Soloman]

EDIT - I found it, I am stupid, stupid, stupid, stupid. It was so simple......
Sorry, sorry, sorry.

Soloman,

I can't remember the last time I used a POKE was (or a PEEK for that matter) since I embarked on a long-overdue migration away from BASIC, and started programming in 6502 Assembly on the "Venerable VIC-20" a little over a year ago. (Quite honestly, I am not sure I even want to remember how to POKE and PEEK! )

I wish you the best of luck in your adventures learning Assembly!

OGM

P.S. Please note that you can call JSR $CB1E from BASIC as a sort of "PRTSTR" (print string) routine in your Assembly programs instead of JSR $FFD2 / "CHROUT" (output character to currently identified/selected device) provided you punctuate your section of text in memory with a $00 (or BRK in your assembler). (You can also include a $0D ([RETURN]) prior to the punctuating $00.)

Learning assembler is very nice to do. The 6502-chip isn't that difficult, but I love brainteasers like printing decimal numbers by an assembler program or adding large numbers, things like that. And it will be a milestone for me writing my first game in assembler. I am not that far yet.