|
Das hauptsächlich interessante Ereigniss tritt dabei zu ca. 24% ein. Das zweite zu etwa 16% und das Letzte von mir beobachtete und zum Crash Führende zu ungefähr 60%. Eine 4 Variante erschien bei mir bis jetzt nur ein mal, ist hier also unwichtig. Möglich wird das Ganze selbstverständlich durch einen Bug. Dieser wird mit einer Matrix 21 × 0 provoziert und führt zu kompletten Datenverlust ( Beschreibung von Mat x : y × 0 unter 'Sonderzeichen 1' ). Führt nun einfach auf einem resetetn TR genau das Folgende aus:
| |
1. MatMenu - Mat x : 21 × 0
| | |
2. ProgMenu - in Programm
- Fill(21, Mat x - [Quit] - [EXE] - [AC]
|
| |
3. MemMenu - Del Stat -
[Curser unten] - Del DrawMem - [C. u.] -
Del Mat - [C. u.] - Del Stat - [C. u.]
- [AC] - [C. u.] - Del V-W 6
|
Wenn auf dem Display jetzt haufen n = 35423 erscheint, drückt ihr [AC] und dann 3 × die [Cursortaste] nach unten. Jetzt könnt ihr mit beliebigen Tasten das "Programm" ändern. Vorsicht allerdings mit den Cursortasten, denn eigentlich befindet ihr Euch noch im MemMenu , sodass es zum automatischen Reseten kommen kann. Drückt ihr [Menu] , kommt ihr auch in dieses, könnt jedoch nichts mehr an dem Ablauf der Störungen ändern. Erst im MemMenu ist das wieder möglich. Klappt es nicht auf Anhieb, probiert es noch mal, sonst entgeht euch was wirklich sehr Lustiges.
|
|
Ausgehend von einem Tipp von
"Spektrum-Leipzig",(jetzt Casio-City) der auf ein Bug des Befehls PxlTest hinweist, hab ich mal ein bisschen experimentiert. Und das kam dabei raus:
| |
ClrGraph
While 1
PxlTest Abs Int Ymin+1, Abs Int Xmin+1
WhileEnd
|
Das ist der prinzipielle Aufbau, der vom Betrachungsfenster unabhängig sein dürfte. Auf dem Display erscheint beim Ausführen eine Menge von scheinbar wahllos angeordneten aktivierten Bildelementen. Näher untersucht erkennt man aber doch so etwas wie eine Ordnung. Z.B. sind zu jeder Variablen A ~ Z bestimmte Positionen auf dem Screen zugeordnet. Bei Ran#->A~Z seht ihr sozusagen das Alphabet auf dem LCD. Dabei verläuft die Reihenfolge von rechts Unten/Mitte beginnend nach oben und, am Ende angekommen, nach links weiter springend usw. Hinzu kommen noch einige andere veränderbare Größen, wie F Start u.ä. Richtig interessant wird es allerdings erst, wenn ihr in die einfache Schleife Befehle einbaut, die den Speicher extremer beinflussen, also Listen bzw. Matrizen (oder beides). Bsp:
| |
ClrGraph
While 1
PxlTest Abs Int Ymin+1, Abs Int Xmin+1
Seq(Ran#,X,1,Int 255Ran#+1,1->List 1
|
Die Teilung verändert dabei (wahrscheinlich) die Geschw. + das Muster. Die einzufügenden Zahlen (hier 0 < Ran# <1) das Muster.
| |
Identity (Int 10Ran#+1->Mat A
|
|
Ich glaube bis 10 reicht, da das Muster sonst zu grob wird.
Das Ganze schient also tatsächlich in Zusammenhang mit dem Speicher zu stehen, ja zeigt vielleicht mit seinen spezifischen Mustern direkt die verwendete Kapazität des Speichers an.
Noch ein abschließendes Beispiel für einen Bildschirmschoner (für ein LCD natürlich wirklich wichtig):
| |
ClrGraph
While 1
PxlTest Abs Int Ymin+1,Abs Int Xmin+1
Int 2Ran#
Not Ans=>Identity (Int 10Ran#+1
Ans=>Seq(Ran#,A,1,Int 255Ran#+1,1
WhileEnd
|
Und ein Beispiel für einen neueren fx, der die Matrixmanipulation mittels der direkten Dimensionsbestimmung mit Dim ermöglicht:
| |
ClrGraph
While1
PxlTest Abs Int Ymin+1,Abs Int Xmin+1
Int 3Ran#
Not Ans=>{Int 20Ran#+1,Int20Ran#+1->Dim Mat A
Ans=1=>Seq(Ran#,A,1,Int 255Ran#+1,1
Ans=2=>Identity (Int 10Ran#+1
WhileEnd
|
Übrigens wird das Alles eigentlich gar nicht angezeigt. ClearScreen hat ebensowenig Einfluß, wie man im RunMenu mit Graph To Table das vorhergehende Bild bzw. keine aktivierten Pixel sieht. Trotzdem werden im Bildspeicher 200 (!) Byte angegeben. ClrGraph ist wirklich notwendig, um die Ausführung zu garantieren, da z.B. nach dem Zeichnen einer Grafik nichts angezeigt werden würde.
To be continued...
|