F64Summer -- neuer Checksummer zum Abtippen von BASIC Zeilen

Hallo zusammen,

hier kommt der offizielle Thread zum neuen Checksummer, der für BASIC-Weihnachten entstanden ist.

Der F64Summer unterstützt bis jetzt folgende Systeme: VC-20, C64, C16/116/+4 und C128. Dazu gehört ein Tool für den PC, das aus einem .PRG eine Liste der Prüfsummen zu den Zeilennummern generiert.

In Aktion (auf dem C64):

Verwendung:

Den Checksummer nach abtippen speichern, dann mit RUN starten und danach NEW eingeben, dann ist der Rechner bereit für die Eingabe eines BASIC Programms mit Prüfsummen. Nach dem Abtippen eines Programms mit Checksummer empfiehlt es sich, das abgetippte Programm zunächst auf Diskette zu speichern (die Verwendung der Datasette ist, außer in der C128-Version, tabu!) und den Rechner anschließend zu resetten bzw auszuschalten. In der Regel gibt es keine Probleme, wenn ein Programm sofort gestartet wird, allerdings verwenden manche Programme die gleichen Speicherbereiche wie der Checksummer, in diesem Fall wären Abstürze unvermeidbar.

Code/Download:

... wird zu gegebener Zeit hier im Thread veröffentlicht

Technische Beschreibung:

Der Checksummer hängt sich in zwei BASIC Routinen ein: IDLE (Vektor $302/303) und TOKENIZE (Vektor $304/305).

In IDLE wird einfach #$ff (255) in $15 (C128: $17) geschrieben, bevor die originale IDLE Routine angesprungen wird. Das ist nötig, um später erkennen zu können, ob TOKENIZE für einen Direktmodus-Befehl oder für eine Programmzeile aufgerufen wurde -- in letzterem Fall schreibt der BASIC Interpreter zunächst die Zeilennummer nach $14/$15 (C128: $16/$17) -- Da Zeilennummern mit einem Highbyte #$ff nicht erlaubt sind, kann man so einfach feststellen, ob eine BASIC Programmzeile eingegeben wurde oder nicht.

Die TOKENIZE Routine des Checksummers ruft zunächst die originale BASIC TOKENIZE Routine auf -- die arbeitet auf dem Eingabepuffer ab $200, danach liegt dort der tokenisierte BASIC Text der eingegebenen Zeile. Als nächstes wird geprüft, ob $200 nur ein 0-Byte enthält, dann war die Eingabe leer und es wird zurück zum BASIC Interpreter gesprungen. Dann kommt der oben erklärte Check von $15 bzw $17; wenn da immer noch #$ff (255) steht, wurde ein Befehl im Direktmodus eingegeben und es wird ebenfalls direkt zurückgesprungen.

Ansonsten wird ein 16bit Galois LFSR* mit der invertierten Zeilennummer initialisiert. Invertiert deshalb, weil Zeile 0 erlaubt ist, und das LFSR mit nur 0-bits nicht funktionieren würde. Eine Schleife liest dann Zeichen für Zeichen aus dem Puffer bei $200. Ab BASIC 3.5 (C16/116/+4 und C128) steht auch die Zeilennummer noch als Text im Eingabepuffer, in diesen Versionen werden die Textzeichen der Zeilennummer zunächst überlesen und dann erst zu der Hauptschleife übergegangen. Die Schleife merkt sich, ob gerade innerhalb eines Strings gelesen wird (pro Vorkommen von einem Anführungszeichen wird ein Flag umgelegt) und wenn sie sich gerade außerhalb eines Strings befindet, werden Leerzeichen überlesen, da sie die Logik des BASIC-Programms nicht ändern.

Pro gelesenem Zeichen iteriert dann eine innere Schleife über alle 8 bits. Pro Bit wird das LFSR einmal mit Feedback geschoben, allerdings wird das Ausgabebit vor dem Feedback zusätzlich mit dem jeweiligen Bit des gerade bearbeiteten Zeichens ver-XOR-t.

Wird ein 0-Byte gefunden ist die Zeile zuende, der aktuelle Status des LFSR wird ausgegeben (direkt in den Bildschirmspeicher), danach folgt der Rücksprung zu BASIC. Auf dem C128 muss für diese Ausgabe noch geprüft werden, welcher Bildschirm gerade aktiv ist, je nachdem erfolgt die Ausgabe in den Bildschirmspeicher das VIC-II oder den des VDC.

Diese Vorgehensweise führt dazu, dass der Checksummer bei vertauschten Zeichen eine andere Prüfsumme ausgibt. Leerzeichen innerhalb von Strings sind ebenfalls relevant für die Prüfsumme, die außerhalb eines Strings allerdings nicht. Da die Prüfsumme erst nach der Tokenisierung gebildet wird ist es auch egal, in welcher Schreibweise BASIC-Befehle eingegeben werden (z.B. PRINT oder einfach ?).

Der Code des Checksummers wird auf allen Systemen in den Datasettenpuffer geschrieben, außer auf dem C128, dort wird der RS-232 Puffer verwendet.

---
*) Erklärung auf Wikipedia: https://en.wikipedia.org/wiki/…ift_register#Galois_LFSRs

Wie versprochen jetzt zu Weihnachten die komplette Veröffentlichung:

Github: https://github.com/Zirias/f64summer
CSDb: https://csdb.dk/release/?id=173072

Auf der CSDb findet sich auch ein Download-Link mit binaries (Tool für windows und .PRG Files für alle unterstützten Commodore-Rechner).

Die hier veröffentlichte Version 1.0 behandelt jetzt das offenbar häufiger auftretende Problem versehentlich "geshifteter" Leerzeichen. Per default werden die beim erzeugen von Prüfsummen automatisch in normale Leerzeichen konvertiert und es wird eine Warnung ausgegeben. Dazu existiert eine Option (-s), um tatsächlich Prüfsummen MIT geshifteten Leerzeichen zu erzeugen.

Also ich freue mich wenn der verwendet wird, steht unter BSD-2clause (was grob heißt mach damit was immer du willst, aber "give credits" *g*) -- hatte das auch eher als einmalige simple sache angesehen, wirklich viel Aufwand war es nicht...

Wegen wiki, da ist die Verbreitung vielleicht noch etwas zu gering?

Zitat von wizball6502

Super. Urheber- bzw- Quellenangabe versteht sich für mich von selbst. Wirst du lieber als zrs1, Zirius oder deinem richtigen Namen referenziert?

Bitte entweder "Zirias" oder realname Der Nick hier ist nur aus der Not geboren...

Allgemein: Freut mich, dass das Tool so gut ankommt Die Grundidee war echt simpel, viel zu programmieren war es auch nicht -- aber ich habe mir Mühe gegeben, dass die einzelnen Checksummer so klein wie möglich werden (ohne auf so simplen Kram wie "aufaddieren" der ersten Checksummer auszuweichen)

edit: Tatsächlich "tricky" war für mich der VDC (80col) Support auf dem C128, aber genau das hat auch Spaß gemacht, weil es was neues war *g* Wäre echt cool, wenn das mal jemand nutzt

Jetzt gehen die Ideen aber durch die Decke

Aber ehrlich, warum das denn? Was hier so gepostet wird, wird ja wohl niemand ernsthaft abtippen, oder? Dafür gibt's copy&paste...

Was ich mir vorstellen könnte ist, das mksums tool noch zu erweitern: Im Moment gibt es nur die Zeilennummern und die zugehörigen Prüfsummen aus*), cool wäre wenn dabei auch noch der BASIC Quelltext rauskäme. Das würde aber auch bedeuten, im Prinzip die Funktionalität von petcat mit einzubauen, also einiges an Arbeit ...

*) sieht dann etwa so aus:

Danke dafür! Bei dieser plötzlichen Aufmerksamkeit überlege ich mir tatsächlich, was ich da noch verbessern könnte

Wenn ich was mache wird auf jeden Fall das Berechnungsverfahren gleich bleiben, für volle Rückwärtskompatibilität.

Wie schon erwähnt wäre es sicher sehr praktisch, wenn mksums nicht nur Prüfsummen sondern fertig formatierten Source zum drucken ausgeben könnte -- aber das halte ich auch für ziemlich aufwendig, mal sehen ob mir da was einfällt.

Was haltet ihr davon, wenn die Checksummer sich selbst verifizieren würden? Damit könnte man (in gewissen Grenzen) Abstürze durch falsch eingegebene DATA werte vermeiden, allerdings zum Preis, dass man für den Checksummer selbst ein bisschen mehr abtippen muss...

Zitat von wizball6502

Das Elegante an diesem Checksummer ist meiner Meinung nach - im Vergleich zum 64er Checksummer - wie kurz das Checksummer-Listing ist.

Vielen Dank Das war in der Tat auch (neben einer "robusten" Prüfsumme) das wichtigste Design-Ziel, kurzer Code.

Kleine Anmerkung zum Wiki:

Zitat

There is also a Windows 32-bit application „mksums.exe“ ...

mksums ist plattformunabhängig, habe es auch mit Linux und FreeBSD getestet, andere Systeme sollten auch kein Problem sein. Ein fertig compiliertes Binary gibt es aber nur für Windows, für andere Systeme muss man den Source selbst compilieren