Lo que sucede es sencillo. BASIC es mucho más lento de lo que parece. De hecho, esta sencilla rutina está borderline para conseguir los 50 Hz (en algunos casos excede los 19968 microsegundos por fotograma), por lo que estaría yendo a unos 42-45 Hz.
Además de ser lento BASIC, leer caracteres del ROM y dibujarlos es algo que es lento de por sí. En este caso, estás dibujando 3 caracteres que se dibujan uno detrás de otro (espacio - O - espacio). Los 2 primeros se dibujan antes de que el haz de electrones pase por la zona de la pantalla donde se está dibujando. Entonces, el haz de electrones recorre las 8 filas de píxeles donde hay 2 O dibujados (porque aún no se ha dibujado el espacio que borraría la siguiente O), dibujando las 2 O's. Entonces, el último espacio se renderiza pero, como el haz de electrones ya ha pasado, se siguen viendo 2 O's por pantalla.
Es fácil comprobar que se trata de esto. Si en lugar de dibujar en la línea 13, dibujamos en la 16 o 17, no veremos 2 O's, sino 1 O y media. En este caso, el haz de electrones pasa por ahí justo cuando estamos a medias de dibujar el tercer espacio, por lo que media O está borrada y la otra media sigue ahí.
Finalmente, si dibujamos en la línea 19, el efecto desaparece, porque da tiempo a dibujar los 3 caracteres antes de que llegue el haz de electrones.
He probado a optimizar un poquito el código, para ver si con eso reducía lo suficiente como para que dibuje en la línea 13 antes de la llegada del haz de electrones. Aún así, lo más que he conseguido es que funcione como debe desde la línea 17 y casi casi la 16:
Código: Seleccionar todo
10 MODE 1
20 DEFINT a-z
30 p=0:x=1:a=1:a$=CHR$(31)+CHR$(1)+CHR$(17)+" O "
40 p=@a$:p=UNT(PEEK(p+1))+UNT(256*PEEK(p+2))+1
50 CALL &BD19:?a$:x=x+a:POKE p,x:IF x=38OR x=1THEN a=-a
60 GOTO 50
Todavía podría mejorarse un poquito, y quizá reducir algunas líneas, si se dibujan sólo 2 caracteres en lugar de 3.