Hallo Leute,
seit Tagen versuche ich den OneLiner vom Basic in Assembler zu bekommen, jedoch ohne Erfolg.
10 PRINT“Welle“;:GOTO 10
siehe Video: https://m.youtube.com/watch?v=0yKwJJw6Abs
Habt ihr eine Idee wie man da vorgehen könnte?
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Deus am
Hallo Leute,
seit Tagen versuche ich den OneLiner vom Basic in Assembler zu bekommen, jedoch ohne Erfolg.
10 PRINT“Welle“;:GOTO 10
siehe Video: https://m.youtube.com/watch?v=0yKwJJw6Abs
Habt ihr eine Idee wie man da vorgehen könnte?
Steht im Kommentar:
Instructions (on a real C64, press C= key instead of Ctrl):
10 PRINT"[Ctrl-P][Shift-RFCDE][Ctrl-Y][Shift-EDCFR][Ctrl-P]";: GOTO 10
Na, das war nicht die Frage, oder? Aber:
Hey, was für ein simpler aber cooler Effekt!
seit Tagen versuche ich den OneLiner vom Basic in Assembler zu bekommen, jedoch ohne Erfolg.
Habt ihr eine Idee wie man da vorgehen könnte?
Willst Du eine fertige Lösung oder Hinweise, um es selbst hinzubekommen? Falls letzteres: erklär mal wie weit Du bist und woran es hängt. Die Kernalfunktion $ffd2 und die Interpreterfunktion $ab1e kennst Du?
Der Effekt ist schick, aber es ist ein typischer Basic-Effekt, der funktioniert, weil er langsam ist.
Dabei ist der Print-Befehl ja schon besonders schnell.
Ohne künstliche Verzögerung kann ich mir gut vorstellen, dass der Effekt in Assembler so schnell ist, dass man ihn optisch nicht mehr genießen kann. Das sieht man dann wenn es soweit ist und kann ggf. künstlich bremsen. Die Schleifenmechanik in Asm ist ja viel schneller.
Wenn man das Ganze ohne Basic-Aufrufe abbilden will, wird das nicht nur zu schnell, sondern man muss sich auch überlegen wie man das "Hochscrollen" des Bildschirms bewirken will, denn mit Poken ins ScreenRAM allein ist es ja nicht getan. Aus meiner Sicht zu umständlich und auch zuviel für eine Anfänger-Übung.
Willst Du eine fertige Lösung oder Hinweise, um es selbst hinzubekommen? Falls letzteres: erklär mal wie weit Du bist und woran es hängt. Die Kernalfunktion $ffd2 und die Interpreterfunktion $ab1e kennst Du?
Wenn ich ehrlich sein soll, wäre mir eine Lösung am liebsten. Denn ich habe wirklich keine Lösung dafür zur Hand. Die beiden Funktionen kenne ich noch nicht, bin erst seit kurzem auf dem C64 am coden.
Ich denke aber auch, dass ASM so schnell sein wird, dass der Effekt nicht so zu Stande kommt.
Wenn ich ehrlich sein soll, wäre mir eine Lösung am liebsten.
Die beiden Funktionen kenne ich noch nicht
$ffd2 sendet das Byte im Akku zum aktuellen Ausgabekanal (d.h. zum Bildschirm, solange die Ausgabe nicht irgendwohin umgeleitet wurde).
$ab1e gibt den nullterminierten String aus, dessen Adresse per A/Y übergeben wurde. Die Ausgabe erfolgt via $ffd2, allerdings ist dies eine Basic-Funktion, d.h. es gibt diverse Bedingungen zu beachten: Die Länge ist auf 255 Zeichen limitiert und bestimmte Zeichen wie z.B. Anführungszeichen können nicht verwendet werden.
Ich denke aber auch, dass ASM so schnell sein wird, dass der Effekt nicht so zu Stande kommt.
An der Geschwindigkeit ändert sich so kaum etwas, denn die meiste Zeit wird hier eh vom Scrolling verbraucht.
Respekt!
Unter meiner Mütze ist jetzt gerade „OverFlow“ Alarm, aber genau so wollte ich es haben. Wenn man jedoch wie ich die Funktionen nicht kennt dann kommt man auch nicht drauf es so zu schreiben.
Vielen Dank und noch mal Respekt.
Na, das war nicht die Frage, oder? Aber:
Hey, was für ein simpler aber cooler Effekt!
Ups, da habe ich wohl in der Eile drüber gelesen.
Hallo zusammen,
Das Ganze etwas aufgehübscht, weil ich einfach Zeit hatte.
An der Geschwindigkeit ändert sich so kaum etwas, denn die meiste Zeit wird hier eh vom Scrolling verbraucht.
Also den Unterschied merkst schon gewaltig, vor allem kriegt man so das Tearing weg und kann gemütlich einen VSync einbauen.
Der Effekt ist schick, aber es ist ein typischer Basic-Effekt, der funktioniert, weil er langsam ist.
Dabei ist der Print-Befehl ja schon besonders schnell.
Ohne künstliche Verzögerung kann ich mir gut vorstellen, dass der Effekt in Assembler so schnell ist, dass man ihn optisch nicht mehr genießen kann. Das sieht man dann wenn es soweit ist und kann ggf. künstlich bremsen. Die Schleifenmechanik in Asm ist ja viel schneller.
Wenn man das Ganze ohne Basic-Aufrufe abbilden will, wird das nicht nur zu schnell, sondern man muss sich auch überlegen wie man das "Hochscrollen" des Bildschirms bewirken will, denn mit Poken ins ScreenRAM allein ist es ja nicht getan. Aus meiner Sicht zu umständlich und auch zuviel für eine Anfänger-Übung.
Der Trick ist es den String zu rotieren, kannst das Hochscrollen völlig fallen lassen.
Der Trick ist es den String zu rotieren, kannst das Hochscrollen völlig fallen lassen.
Das ist höchstens die "Straightforward"-Implementierung, unterschlägt aber die eigentliche Raffinesse des BASIC-Einzeilers, die auf der Barber-Pole-Illusion beruht.
Ob ich jetzt eine Zeile, um eine Zeile, hochkopiere oder die identische Zeile durch das rotieren des Strings erzeuge und so exakt das Selbe in den Screenram kopiere macht keinen Unterschied. (Außer natürlich ein Stückchen längerer, langsamerer Code.)
Und die Raffinesse ist aus Basic heraus zu verstehen. Aus ML/ASM ist es dann der Rollstuhl, laufen mit gebrochenen Beinen.
Funktioniert übrigens auch mit den vertikalen Linien.
So und jetzt das ganze mit senkrecht gesplitteten Rasterbars! Ne Spass würde ich heute auch nicht mehr hin bekommen.
Mir hat schon der kopp gebrummt als ich meine alten Listings gesehen habe (Sie AVATAR Bild) das Intro war von mir.
Gilt das auch?
Das ist nett.
Würdest du den Quellcode posten?
Es dürfte ähnlich sein wie oben nur mit entsprechenden Offsets +40 Zeichen und +1 Zeichen. Die Linien werden in einer doppelten for next Schleife von oben nach unten und von links nach rechts gemalt denke ich.
Poste doch den Code, es ist eine gute Anfängerübung und vielleicht fällt jemandem eine Kürzungsmöglichkeit oder dergleichen auf. Auf die Art habe ich hier auch viel lernen dürfen.
Das ist die ganze Änderung zu oben.
Ich schreib linear in den ScreenRam, nur eine Schleife.
Der String hat 13 Zeichen.
Das ergibt in der Zeile 39 Zeichen, somit verrutscht in der nächsten Zeile die Ausgabe um ein Zeichen.
Die nächste Zeile fängt also mit 12 Zeichen an, die danach mit 11 Zeichen aus dem String. So erzeugt das denn Offset um +1.
Ich brauch mich also um das Zeilende nicht zu kümmern und schreib einfach weiter.
Um jetzt aber nicht jedesmal den gleichen Screen Ram zu schreiben, rotiere ich am ScreenEnde den String um ein Zeichen nach links.
Dazwischen warte ich dann noch 2 mal auf den Raster, damit kein Tearing/Flackern auftritt und die Geschwindigkeit reduziert wird.
Ach und noch was, ich fang das Ende des Screen rams nicht sauber ab, ich schreib bis maximal $400+12 Screen Daten, kann also alles böse ins Auge gehen.
Ich zerschieße auf jedenfall die Sprite Adressen. Bei einer Datenmenge von $3E8 sollte man abbrechen.
Hab ich zum Schluss vergessen noch sauber zu korrigieren.
Ob ich jetzt eine Zeile, um eine Zeile, hochkopiere oder die identische Zeile durch das rotieren des Strings erzeuge und so exakt das Selbe in den Screenram kopiere macht keinen Unterschied. (Außer natürlich ein Stückchen längerer, langsamerer Code.)
Du hast dir aber schon den Artikel über die Barber-Pole-Illusion durchgelesen?
Und die Raffinesse ist aus Basic heraus zu verstehen.
Nochmal: es funktioniert in BASIC genau nur aufgrund der Barber-Pole-Illusion, welche hier die senkrechte Bewegung des Scrollens in eine waagerechte Bewegung der Wellen "umwandelt". Das geht hier auch überhaupt nur, weil ein Vielfaches der ausgedruckten Zeichenkette genau die Zeilenbreite-1 ist (3x13 = 39 = 40-1). Mit anderen Längen funktioniert die Illusion nicht mehr und man sieht auch in BASIC wieder 'nur' das normale Hochscrollen.
Umgekehrt kann ich in Maschinensprache mit der "straightforward"-Implementierung alles mögliche nach links oder rechts schieben, ohne daß der zu erzielende Effekt auf die Barber-Pole-Illusion zurückgreifen muß. Die Welle kann also z.B. auch 12 Zeichen oder 14 Zeichen lang sein. Nur ist DA dann überhaupt nichts tricky dran - der Maschinencode macht einfach im Speicher das, was man auch auf dem Bildschirm *sieht*.
Aus ML/ASM ist es dann der Rollstuhl, laufen mit gebrochenen Beinen.
Ich hab' übrigens auch schon ein paar Programme in Maschinensprache geschrieben. Das hält mich nicht davon ab, den BASIC-Einzeiler in seiner Einfachheit richtig gut zu finden.
Wie oben im Quellcode und in meiner Erklärung beschrieben, nutze ich genau die Ein-Zeichen-Differenz einer Zeile aus.
Ich schreibe den Ram linear. Nur die Implementierung des Zeilen nach oben kopierens "simuliere" ich mit dem rotierenden String.
Ist wesentlich unaufwendiger, da ich nur 13 Zeichen umkopieren muss und nicht 40x25. Macht den Code einfacher.
Ich kenne die Barber-Pole-Illusion, ist mir auch als solche bekannt. Und ja, das ist Teil der Illusion, die Wahl der Character macht dazu noch die Wellenform.
Und zum Schluß noch eine Entschuldigung, wollte dir damit nicht auf den Schlips treten. Aus Basic-Sicht ist es ja auch schön simple.