F64Summer -- neuer Checksummer zum Abtippen von BASIC Zeilen

Du siehst mich in meinen Grundfesten erschüttert und den Glauben an die deutsche Ingenieurskunst verlierend . Nein, das war nur als Anmerkung gedacht und nicht als Fehlermeldung.

Jetzt, wo mprg2bas funktioniert, ist es wohl egal, aber ich denke man kann den folgenden Abschnitt umschreiben:

Außerdem würde ich vorschlagen, die Klappe nicht von beiden Seiten zuschlagen zu lassen ("remaining" von oben und "needed" von unten), sondern nur die tatsächliche Länge mitzuzählen (Man verliert allerdings die Chance, sowohl bei remaining als auch bei needed Fehler zu machen, die sich dann aufheben ) Das könnte dann ungefähr so aussehen (but never change a running system!):

Quote from Snoopy

Quote from wizball6502

Quote from LogicDeLuxe

Wer Bedenken hat, daß man Listings beim Abtippen verändert, kann sie ja mit selbstmodifizierenden Code schützen

Bei einem BASIC-Programm? Wer macht sowas?

Mir ist vor Urzeiten mal ein BASIC-Programm am C64 untergekommen, das hatte sich Daten aus den Kommentaren hinter dem REM-Befehl geholt (also eine Art "DATA-Ersatz"). Keine Ahnung, warum das der Autor damals so gemacht hat, aber auch hier wäre das Weglassen des REM-Kommentars ziemlich folgenreich gewesen.

Ich kenne so was ähnliches aus dem 64er-Sonderheft 21, Seite 146: "Maschinenroutinen in BASIC-Zeilen". https://archive.org/details/64er_sonderheft_21/page/n145

Quote from atomcode

Ich kenne so was ähnliches aus dem 64er-Sonderheft 21, Seite 146: "Maschinenroutinen in BASIC-Zeilen". https://archive.org/details/64er_sonderheft_21/page/n145

Vielen Dank für die Quellenangabe, und dafür, dass sich so jeder ein Bild davon machen kann. Meine Frage "Wer macht sowas?" war ja nicht dahingehend gemeint, wie man das hinkriegt, Maschinensprache in REM-Statement unterzubringen, sondern vielmehr, wer den solche "Maschinensprache-in-REM-Statements" in einem Abtipp-Listing einsetzen würde. Maschinensprache in REM-Statements unterzubringen ist eher eine technische Finesse, die Grenzen des Machbaren auszuloten, aber kaum etwas, das bei klassischen Abtipp-Listings eingesetzt werden sollte. Zum Abtippen m.E. eher umständlicher (im Vergleich zu DATA Statements) ohne grossen Mehrwert auf das Endergebnis. In BASIC Weihnachten-Thread wurde übrigens auch - für mich nachvollziehbar - Feedback gegeben, dass die Eingabe von DATA-Zeilen mit Zahlen zum Abtippen angenehmer empfunden wird, als ein String mit dem Byte-Wert dargestellt als ASCII-Zeichen, obwohl es mit dem String technisch weniger Zeichen zum Eintippen wären. Bis das Zeichen auf dem Keyboard gefunden ist, hat man die bis zu 3-stellige Zahl und Komma längst eingetippt.

Somit für mich nach wie vor kein Argument, warum die Checksumme auch über REM-Statements gemacht werden sollte.

zrs1 : Noch eine Frage zur Version "Checksumme ohne REM"... der Vorschlag, dass beim Bilden der Checksumme beim Erkennen des REM-Statements einfach abgebrochen wird (1 Byte vorlesen, damit Doppelpunkt vor REM-Statement auch ignoriert werden kann), spricht da was dagegen bzw. würde der Code dadurch nicht kürzer?

Quote from zrs1

Die Diskussion hatten wir doch ziemlich ausführlich?

Ausführlich - nach meinem Ermessen - eher nicht. Ein Forum ist aber wohl auch nicht der ideale Ort für ausführliche Diskussionen, deshalb habe ich es gut sein lassen.

Mein aktueller Eindruck: Obwohl es aus Abtipper-Sicht - auch für dich, falls ich das richtig interpretiert habe - grundsätzlich Sinn machen würde, auf den Inhalt des REM-Statement beim Bilden der Checksumme zu verzichten, wird dieser Änderungsvorschlag wegen zusätzlich einzugebenden 23 DATA-Werten im offiziellen Build für V2 nicht berücksichtigt, obschon man diese 23 Zahlen Tipparbeit schnell eingespart hat, wenn man dadurch REM-Statements in sämtlichen zukünftigen Abtipp-listings weglasssen könnte bzw. schneller zum Ziel kommt, weil die darin vorhandenen Abtippfehler für die Checksumme irrelevant sind. Ist das nicht etwas am falschen Ende gespart? Meine Hoffnung war, mit dem REM-Skipping einen neuen Standard zu etablieren, weil Standards vieles einfacher machen.

Bei meinen eigenen neuen Abtipp-Listings habe ich übrigens mal probiert, REM-Statements nur noch in einer eigenen Zeilen anzugeben, werde damit aber nicht glücklich. Das Listing wird dadurch schnell doppelt so lang als nötig und dadurch auch unübersichtlicher. Alternativ eine separate Beschreibung des BASIC-Codes anzufertigen, ist mir dann aber zu aufwendig und läuft auch schnell auseinander, sobald man Änderungen am Code macht bzw. nachträglich Zeilen ändert. Schlussendlich habe ich für meine BASIC Weihnachten 2019-Beiträge auf Detail-Kommentare verzichtet und nur noch die groben Code-Blöcke mit REM-Statements getrennt. Meines Erachtens soll der eigentliche Spass am Abtippen aber gerade dadurch entstehen, dass man nachvollziehen kann, was man da eingibt, was mit dem Weglassen der Detail-REMs aber etwas verloren geht. Ich denke da übrigens auch an all die zukünftigen TheC64-Neubesitzer (ab dem 12. Dezember), die das erste Mal seit 35 Jahren wieder einmal ein BASIC-Listing abtippen wollen aber beim Abtippen von POKE-Adressen, die einem nichts sagen, ist die Lust dann doch schnell wieder dahin, weil so der gewünschte Lerneffekt ausbleibt.

Die Lösung für mich sieht daher wohl folgendermassen aus:

• Ich würde für meine eigenen Abtipplistings (die ich in Zukunft für Interessierte als PDF zum Herunterladen anbieten möchte) gerne den F64Summer mit REM-Skipping verwenden, damit ich ausgiebig Gebrauch von REM machen kann. Dazu folgende Bitte: Könntest du mir einen solchen Build für mich erstellen? Das wäre supernett.
• Ich würde gerne das Abtipplisting zu der F64Summer-Spezialversion (mit REM-Skipping) zentral auf einer Internet-Seite anbieten, so dass ich in meinem Listing nur noch eine Referenz-URL auf diese Internet-Seite angeben müsste, hadere aber damit, diese Spezial-Version ebenfalls im C64-Wiki-Eintrag vom F64Summer unterzubringen, wenn nur ich es bin, der diese Version einsetzt. Wie stehst du dazu? Oder ist es für dich lieber, wenn diese Spezialversion gar nicht im Internet zu finden ist, sondern nur zusammen mit dem Abtipp-Listing publiziert wird (im selben PDF)? Und durch welchen Zusatz, soll diese REM-Skipping-Version von der Standard-Version unterschieden werden?

Vielen Dank für deine Geduld zu diesem leidigen REM-Thema. So doof das klingt, aber mir liegt eine positive Abtipp-Erfahrung für meine zukünfitgen Abnehmer meiner Listings am Herzen und ein gut dokumentiertes Listing macht für mich eben nur Sinn in Kombination mit dem REM-Skipping-Checksummer.

Quote from zrs1

Mal sehen ob ZeHa für seine neue Ausgabe auf die neuere Version geht, und wenn ja, welche Einstellungen er bevorzugt

Ich hatte ZeHa bereits einmal darauf angesprochen, und er sieht das total entspannt, d.h. ihm ist das lange nicht so wichtig, wie mir. Und wenn ich ZeHa wäre, dann würde ich denselben Checksummer verwenden, der auch für das BASIC Weihnachten-Heft 2018 publiziert wurde bzw. Checksummen verwenden, die damit 100% kompatibel sind, weil die meisten Leute den ja schon mal abgetippt und irgendwo gespeichert haben und diesen intuitiv auch zum Abtippen der neuen Listings wiederverwenden wollen. Wäre nur logisch, sonst muss man mit Rückfragen rechnen. Oder er schreibt irgendwo hin "REM-Statements dürfen NICHT abgetippt werden". Das wäre dann die andere Variante, wobei aber das Risiko für mich zu hoch wäre, weil nicht alle das Kleingedruckte lesen.

Für mich geht das Abtipp-Thema aber weit über das Forum64 hinaus und ich sehe es darum vielleicht etwas anders bzw. finde es gut, dass wir mit dem Szene-Projekt wie BASIC Weihnachten erste Erfahrungen mit dem Thema Abtipp-Listings, Checksummern, PETSCII-Darstellung in Listings etc. sammeln konnten und damit unsere ersten Schlüsse ziehen durften, was funktioniert und was man besser machen könnte.

Ich bin dann in diesem Zusammenhang auch gespannt, welches Tool ZeHa dieses Mal für die Aufbereitung der Listings auf Basis des .PRG files heranziehen will, da jedes der bekannteren Konvertierungs-Tools seine Vor- und Nachteile hat (habe beim Erstellen der C64-Wiki-Seite zum Thema "PETSCII in Listings" einige Problemzonen bei den Tools entdeckt). Aber das gehört hier nicht zum Thema.

Quote from zrs1

Mir ist das völlig egal, wer was wo veröffentlicht ... ein Hinweis auf den Ursprung (z.B. github url) wäre nett

Vielen Dank dafür, dass du das locker siehst, wobei mir schon wichtig wäre, dass man unter dem Begriff F64Summer nicht x verschiedene Varianten im Netz findet, das hilft dann niemandem. Weil, ich verstehe Leute auch irgendwie, die sich sagen, ich möchte heute ein neues BASIC-Spiel abtippen, der Weg zum Ziel ist der Checksummer (weiss aber nicht mehr genau, wo ich den gespeichert habe), also suche ich mir das PRG zum Checksummer kurz im Netz. Ansonsten fühlt sich das wiederholte Abtippen des Checksummers an, als ob man zuerst ein System-Update (à la PS4) über sich ergehen lassen muss, bevor man zum Kern der Sache kommt.

Hinweis auf den Urheber versteht sich für mich von selbst. Wobei der direkte Bezug zum Urheber Zirias im ersten BASIC Weihnachten-Heft etwas unterging . Das könnte ZeHa im neuen Heft bzw. im Nachdruck vielleicht noch berücksichtigen (wenn noch nicht geschehen).

Quote from zrs1

weil meiner Meinung nach das REM im C64-BASIC eine Krücke mit deutlichen Nachteilen ist, und daher besser nicht verwendet werden sollte.

*hust* ich hab da mal was korrigiert.

Im Ernst: Wenn heute jemand Basic V2 schreibt, dann wird er auch REM benutzen, insbesondere bei ZeHas Weihnachtsheft. Mir fallen eine Menge Dinge ein, die man aus gutem Grund in Basic nicht tun sollte, aber trotzdem werde ich diese Dinge bestimmt auch weiterhin zu Gesicht bekommen. Beim Schreiben eines Hilfsprogramms würde ich deshalb nicht davon ausgehen, dass sich alle an zusätzliche Regeln (wie "bitte kein REM benutzen") halten.

(ich bin übrigens kein Fan des Abtippens, ich argumentier nur so zum Spaß )

Ich mache es so, dass ich REMs komplett weglasse (ich brauche ohnehin jede Millisekunde) und stattdessen eine separate Beschreibung hinzufüge, welche die Grundstruktur bzw. den groben Ablauf und die Algorithmen unter Angabe der entsprechenden Zeilennummern beschreibt. Besonders wichtige oder schwer durchschaubare Stellen kann man so noch extra erklären.

Das erfüllt m.E. genauso den Zweck, wenn nicht noch besser. Man kann ordentliche Sätze bilden und muss auf Umlaute nicht verzichten. Man könnte ja immer noch im Listing zusätzlich über die wichtigsten Abschnitte kurze REM-Zeilen als Titelzeile einfügen, die man nicht mit abtippen muss.

Kommentare, von wegen 100 A=A+1:REM HIER WIRD A INKREMENTIERT, GEZ. SHERLOCK, braucht doch ohnehin keiner. Es sollte neben dem Grundprinzip vor allem das erklärt werden, was nicht offensichtlich ist. Im Visual Studio hab ich dafür jede Menge Platz, und außerdem wird es kompiliert. In BASIC V2 ist das m.M.n. meistens nur Ballast, bzgl. Speicher und Geschwindigkeit.

Es hängt am Ende auch davon ab, welchen Anspruch das Programm stellt. Ob das Herumspielen MIT dem Programm oder AN dem Programm im Vordergrund steht. Im letztgenannten Fall sollte man etwaige REM-Zeilen sowieso übernehmen, um sie beim Bearbeiten des Programms an Ort und Stelle zu haben. Tut man das nicht, müsste man dazu ins Heft schauen, und dann sind wir ohnehin wieder beim oben erklärten Prinzip, die Beschreibung separat zu machen.

Quote from zrs1

Wenn aber ein BASIC-Programm mit irgendeinem anderen Tool (am PC) erstellt wurde, kann es sein, dass die "falsche" Codierung genommen wird. Bei der Ausführung ist das egal, aber

Auch bei der Ausführung ist das nicht egal. Sowas wie get a$:if a$ = "x" then geht natürlich schief, wenn das "x" im Programm einen anderen Code verwendet als der Kernal benutzt. Ein PC-Tool, das die falschen Codes verwendet, ist schlicht und einfach kaputt.

Quote from zrs1

meine Annahme ist folgende:

Die Range $60-$7f bzw $c0-$df enthält die gedoppelten Zeichen in PETSCII. Der BASIC Editor nimmt dabei immer die Codierung der Range $c0-$df. Das Zeichen π (pi) ist dabei eine Ausnahme, es kommt sogar 3 mal vor und wird vom BASIC Editor als $ff codiert.

AFAIK stimmt das so. Das Gleiche gilt für die Grafikzeichen von $a0 bis $be (Tastaturcodes), diese wiederholen sich von $e0 bis $fe ("falsche" Codes). $bf und $ff sind aber unterschiedliche Zeichen und beide Codes werden von der Tastatur erzeugt.

In dem besagten Fall ging es nur um die Ausgabe eines Grafikzeichens, dort war es tatsaechlich egal. Natuerlich heisst dies nicht, dass es fuer alle moeglichen anderen Faelle auch gilt

Ein Nachtrag zur Datasette. Ich habe ein paar größere Tests gemacht und leider klappt mein Vorgehen doch nicht. Zwar bekommt man auch trotz aktiven Checksummer

eine Speicherung auf Datasette hin, aber das Ergebnis ist dann leider Nudelsalat. Wenn man sich den Stand per List anschaut sieht es eigl gut aus, ist es aber nicht. Ein List -10 spuckt dann bspw. nichts aus, obwohl der Checksummer ja bis 8 geht. Tippe ich nur List ein, sehe ich aber alle Zeilen. Tippe ich list 10-100 ein sehe ich auch den Checksummer, also irgendwie sind dann die Zeilennummer nicht mehr richtig zugeordnet.

Dann muss ich wohl auf so'n neumodischen Quatsch wie Floppy umsteigen

<EDIT MOD> Diskussion zum F64Summer aus dem Thread Weihnachten auf dem Commodore (BASIC-Heft) - Vorbestellung 2019 nach hierher verschoben.

Quote from muellerarmack

Ein Nachtrag zur Datasette. Ich habe ein paar größere Tests gemacht und leider klappt mein Vorgehen doch nicht. Zwar bekommt man auch trotz aktiven Checksummer

eine Speicherung auf Datasette hin, aber das Ergebnis ist dann leider Nudelsalat. Wenn man sich den Stand per List anschaut sieht es eigl gut aus, ist es aber nicht. Ein List -10 spuckt dann bspw. nichts aus, obwohl der Checksummer ja bis 8 geht. Tippe ich nur List ein, sehe ich aber alle Zeilen. Tippe ich list 10-100 ein sehe ich auch den Checksummer, also irgendwie sind dann die Zeilennummer nicht mehr richtig zugeordnet.

Dann muss ich wohl auf so'n neumodischen Quatsch wie Floppy umsteigen

Der Checksummer dürfte sich ja relativ einfach in einem anderen Bereich verschieben lassen. Source ist ja vorhanden.

Wenn man sich auf BASIC Listings einschränkt, z.B. nach $C000 oder so.

Dann würde sich das nicht mit der Datassette beissen.

Wieso liegt der Checksummer eigentlich im Kasettenpuffer und nicht direkt bei z.B, $C000?

Hat das technische Gründe oder war es eher Gewohnheit (und ein klein Wenig "vergessen" von Datasettenbenutzern)?