miller@uiucdcs.UUCP (miller ) (02/19/84)
#N:uiucdcs:36100046:000:3552
uiucdcs!miller Feb 19 01:56:00 1984
* * * IMPORTANT NOTE * * *
The Problem:
The c64 has a bug in the OS which will crash your machine. Move the cursor
down to the last line on the screen. Type more than 80 characters. Now delete
characters back across the 80th column. At that point, your machine will die a
violent, but certain, death. This will occur whether you do this in direct
mode, in a Basic program, or even machine language. All that is needed is for
(someone) to print the delete character ( CHR$(20) ) back across the 80th
column of a continuous line at the bottom of the screen.
I mentioned this problem on the net last year when I posted a listing of all
bugs of which I am aware. In addition, Paul Orman of Eagle Online Firmware
contacted "Compute's Gazette" and informed them of what we knew at that time.
They mentioned the problem in the "Horizons 64" section two issues ago (but did
not give Paul credit for the information).
The Cause:
Paul recently found out exactly what was causing the problem. He is submitting
the information to another publication. It seems that the section of code that
updates the screen is smashing CIA #1. You see, color RAM is located at $D800-
$DBFF. CIA1 follows that starting at $DC00. The OS does a bad job of bounds
checking and when that situation arises, copies location $0286 (current char.
color code) onto the CIA registers. When it stores into location $DC0F
(Control Register B) it's all over. The c64 thinks it's getting a Shift-
Run/Stop, the keyboard freezes, and you lose control of the machine.
The Solution:
Ultimately, Commodore should fix their kernal. Since we can't hold our breath
for that to happen, you can avoid the problem in 2 ways or (sort of) fix it in
one. The first way to avoid the problem is simply don't delete back past the
80th column at the bottom of the screen. The second way to avoid the problem
is to use a "safe" color code. You see, the bit in the CIA's CRB that is
causing the problems is bit 1 (bit 0 is on the right). If bit 1 is set, the
machine bombs. So, don't use a cursor color with that bit set, e.g., color
codes 0, 1, 4, 5, ... are OK. You can get a list of which codes are
what colors in your Programmer's Reference Guide. The way to (sort of) fix it
is to have your program check CRB from time to time and reset the bit if
needed if you think the situation might arise and you want to use a "dangerous"
cursor color. For example, try the following 3 experiments:
1) turn your machine off/on
2) go down to the last line and type 80+ characters (no returns)
3) hit delete several times until it bombs
4) note that you can't recover
1) repeat 1 above
2) change the cursor to white (CTRL 2, or color code 1)
3) repeat 2 above
4) repeat 3 above but notice that the machine does NOT bomb
1) repeat 1 above
2) enter the program: 10 POKE 56335,8
3) repeat 2 and 3 above
4) note that when it bombed, the program automatically started running (a
"feature" of the bug). But now, you have regained control of the machine!
P.S. When I say the 80th column, I am NOT talking about 80 column boards. I
mean the normal 40 column screens when you type a single line with no returns
(just wraparound past 40). 80 column boards do not have this problem as they
do things differently.
Before we discovered this bug and how to avoid it, we lost literally *hours* of
work on several occasions. Hopefully, this note will help keep you from
falling into the same trap.
A. Ray Miller
Univ Illinois
[Official bug of the 1984 Winter Olympics]