Hallo Besucher, der Thread wurde 21k mal aufgerufen und enthält 128 Antworten

letzter Beitrag von Bodhi1969 am

F64Summer -- neuer Checksummer zum Abtippen von BASIC Zeilen

    Zitat von zrs1

    Was mich daran persönlich stört sind wirklich "nur" die 23 zusätzlichen Bytes

    Noch etwas zum Relativieren :saint::

    Sobald Listings REM-Statements am Ende einer Zeile haben (und ja, es gibt Gründe, die dafür sprechen), dann hat sich das Mehrtippen der 23 Bytes beim Checksummer doch schnell amortisiert, wenn man dann beim Abtippen auf diese REM-Statements dann verzichtet. Bei dem folgenden Beispiellisting wird mittels REM kurz erklärt, wofür die ASCII-Werte stehen. Selbsterklärend ist das ja nicht. Und wenn man hier für jedes REM-Statement eine eigene Zeile nehmen würde, wie vorgeschlagen, sähe das meiner Meinung nach eher unübersichtlich aus.

    Code
    1. 10 geta$:ifa$=""thengoto10:rem auf tastendruck warten
    2. 20 a=asc(a$):rem ascii-wert der gedrueckten taste
    3. 30 ifa>=65anda<=90thengosub100:rem a-z
    4. 40 ifa>=133anda<=136thengosub200:rem f-tasten f1/f3/f5/f7
    5. 50 ifa=20thengosub300:rem delete
    6. ...
    Zitat von wizball6502

    Ich habe das hier (siehe folgendes F64Summer-Listing) mal so ergänzt, wobei die Rahmenfarbe noch auf rot gesetzt wird, wenn die Checksumme falsch ist bzw. grün, wenn die DATA-Zeilen korrekt eingegeben wurden.

    Warum keine Rückmeldung im Klartext? Ein PRINT-Befehl ist schließlich auch nicht schwieriger abzutippen als ein POKE.

    Zitat von wizball6502

    Die Variable "a" habe ich bei der Berechnung der Checksumme noch dazu genommen, damit auch das versehentliche Weglassen von DATA-Einträgen mit Wert 0 in der Checksumme berücksichtigt werden.

    Ein versehentliches Weglassen, würde wohl zu einem "?OUT OF DATA ERROR" führen.

    Zitat von LogicDeLuxe

    Warum keine Rückmeldung im Klartext?

    Ja, mein Farben-Poke-Ansatz ist eher ungewöhnlich und C64-Eigen. Dachte mir halt, die Farbe rot und grün ist Sprache-neutral. Aber ob das dann ohne Anleitung jemand richtig interpretiert, das ein roter Rahmen eine falsche Checksumme bedeutet. Genauso gut könnte man bei rot meinen: aha, das Programm läuft und signalisiert damit Aktivität. Vor allem, weil nicht alle wissen, was die Adresse 53280 bedeutet. Also vergesst bitte diesen Ansatz. Mit Text ist wohl tatsächlich besser (Keep it simple).

    Zitat von LogicDeLuxe

    Ein versehentliches Weglassen, würde wohl zu einem "?OUT OF DATA ERROR" führen.

    Haha. Stimmt. Und auch Mac Bacon hat Recht. Das Multiplizieren wäre besser.

    Mein eigener selbst-verifizierender Vorschlag am Beispiel des C64 Checksummers (hier die Version MIT ignorieren von REM):

    Prüfsumme ist hier pro DATA Zeile schieben und addieren in einem 10Bit-Ring. Scheint bei ein paar kleinen Tests bisher robust gegen vertauschte Werte und leicht veränderte Werte zu sein ...


    Noch nicht ideal ist, dass 0-Bytes sich nicht auf die Prüfsumme auswirken ... vielleicht finde ich noch was besseres ohne den Code zu sehr aufzublähen.

    Zitat von LogicDeLuxe

    Es wirkt sich aber schon aus, wenn eine 0 an einer falschen Stelle ist, oder etwas anderes dort steht, wo eine 0 sein sollte. Von daher sollte das schon passen.

    Ein 0-Byte ist aber was ganz anderes als eine '0' im Code... da hast du was falsch verstanden.

    LogicDeLuxe Ja, nur eine 0 vergessen (oder zuviel einfügen) bliebe unbemerkt ... aber vielleicht ist das wirklich etwas, womit man ganz gut leben kann :)


    edit: sowieso alles Blödsinn, die 0 bleibt nur genau dann unbemerkt, wenn die Prüfsumme gerade im Ausgangszustand (alle Bits 1) oder 0 ist. Das ist wohl eher unwahrscheinlich.


    Nochmal ein bisschen verbessert, gibt ja keinen zwingenden Grund, die Zeilennummer in der Prüfsumme zu codieren, mitzählen geht auch und braucht nicht mehr Code .. damit kann ich jetzt einen 13-bit Ring nutzen :)

    Findet jemand Schwachstellen in der Vorgehensweise? Ist die Menge an Code für die Selbstüberprüfung vertretbar? Würde das dann demnächst mal vernünftig (optional!) einbauen und auf Github pushen...

    Nochmal eine leicht verbesserte Version:

    • Startwert 5 ist kürzer zu tippen UND verhindert, dass eine eventuelle 0 am Anfang nicht bemerkt wird
    • Prüfsummen positiv .. nur bei einer einstelligen Prüfsumme wäre das Resultat in negativer Darstellung sicher kürzer, und das ist ein unwahrscheinlicher Fall
    • Logik umsortiert, damit wird das Programm kompakter und es wird im Ausnahmefall (Prüfsumme gelesen) gesprungen statt im Regelfall (Byte gelesen)

    Eine Frage am Rande in die Runde: ;)


    Ich könnte das auch so formatieren, dass eine Zeile exakt 80 Zeichen lang wird. Das ist aber beim Eintippen blöd, weil beim letzten Zeichen der Cursor die logische Zeile verlässt, man muss also mit den Cursortasten zurück um "Return" zu drücken. Was haltet ihr davon? Sind 80 Zeichen lange Zeilen ok zum abtippen oder sollte man sich auf 79 Zeichen beschränken?

    Zitat von zrs1

    Nochmal eine leicht verbesserte Version

    Evtl. das kleine "l" als Variable vermeiden, da sie nicht von einer 1 zu unterscheiden ist. Jedenfalls bei der Schrift, die mir das Forum anzeigt. Oder alternativ das Listing in Großbuchstaben anbieten.


    Zitat von zrs1

    Sind 80 Zeichen lange Zeilen ok zum abtippen oder sollte man sich auf 79 Zeichen beschränken?

    80 Zeichen wäre doch nur eine unnötige Fehlerquelle beim Abtippen, wenn man eben nicht dran denkt, den Cursor auf die Zeile zurück zu bewegen, bevor man RETURN drückt. Idealerweise sollte es auf 79 Zeichen beschränkt sein, und zwar mit allen erlaubten Leerzeichen bei Formeln, zwischen Schlüsselwörtern, nach der Zeilennummer und ausgeschriebenen Befehlen, um sicher zu gehen. Mit Leerzeichen wäre das sogar lesefreundlicher und erleichtert so eine evtl. Fehlersuche. Und sie wären natürlich optional, für Leute, die sie doch lieber weglassen wollen.

    Soll ja kein Wettbewerb werden, möglichst lange oder wenige Zeilen zu verwenden. Kurz halten ist natürlich gut, aber nur da, wo es die Abtippfreundlichkeit nicht vernachlässigt.

    Zitat von LogicDeLuxe

    Soll ja kein Wettbewerb werden, möglichst lange oder wenige Zeilen zu verwenden.

    Nunja, jede zusätzliche Zeile bedeutet etwas mehr Abtippaufwand, also möchte ich schon zumindest in den DATA-Zeilen dabei bleiben, die so lang wie möglich zu machen, ohne unnötige Leerzeichen. Aber ja, 79 ist an der Stelle besser, sonst passieren wohl zu leicht Abtippfehler. In den Zeilen, in denen es sowieso egal ist, baue ich ein paar Leerzeichen zur Lesbarkeit ein (obwohl man die "Würste" in C64 BASIC ja wahrscheinlich auch gewohnt ist...)


    Sieht dann so aus, diesmal in der Version ohne ignorieren von REM:

    Bin gerade fleißig am basteln, die neuen Features sollten bald im git repo landen um getestet zu werden :)

    Derzeit scrollt beim einfachen LIST die Zeile 0 aus dem sichtbaren Bildbereich. Will man keine Leerzeichen weglassen, könnte man das IF aus Zeile 0 negiert in Zeile 1 schieben. Dann passt das Listing komplett auf einen Bildschirm und viel wichtiger: die fehlerträchtige 2 muss einmal weniger getippt werden ;)

    Code
    1. 0 s=5:l=4:for i=820 to 985:read x
    2. 1 if x<256 then s=2*s-(s>4095)+x and 8191:poke i,x:next
    Zitat von ADAC

    Ähm.... vllt. ist das ne blöde Frage, aber: tuts der denn auch mit dem 2018er Weihnachsheft?

    Die Berechnung der Prüfsumme hat sich nicht geändert, also ja, es sei denn man aktiviert das skippen von REM und tippt ein Listing mit REM ab :)

    Zitat von wrglprmft

    Derzeit scrollt beim einfachen LIST die Zeile 0 aus dem sichtbaren Bildbereich. Will man keine Leerzeichen weglassen, könnte man das IF aus Zeile 0 negiert in Zeile 1 schieben. Dann passt das Listing komplett auf einen Bildschirm und viel wichtiger: die fehlerträchtige 2 muss einmal weniger getippt werden ;)

    Äh ... ok, komische Begründung :) Aber deine Version braucht in der Tat zwei Zeichen weniger, also warum nicht ;)

    Zitat von zrs1

    Äh ... ok, komische Begründung :) Aber deine Version braucht in der Tat zwei Zeichen weniger, also warum nicht ;)

    Wenn wir schon beim Zeichen zählen sind. Komischerweise :) werden die 79 Zeichen pro Zeile nicht ausgenutzt. Zeile 9 z.B. könnte noch eine weitere Zahl aufnehmen und würde immer noch bei höchstens 79 Zeichen bleiben.

    Ich hab es nicht gedebugged, aber wenn ich das Coding richtig verstehe, berechnest Du die benötigten Zeichen der aktuellen Zahl inklusive vorhergehendem Komma. Ein Komma wird aber nur in einer laufenden Zeile benötigt und nicht in einer neuen. Daher wird am Beginn einer neuen DATA-Zeile ein Zeichen mehr "verbraucht" als wirklich ausgegeben wird.

    Code
    1. /* remaining = 73 - (needed - nsumlen); */
    2. remaining = 73 - (needed - nsumlen - 1); /* oder */
    3. remaining = 74 - (needed - nsumlen);

    Die magic number 73 kommt wohl aus 79 - 1 - 1 - 4 (Ein Zeichen Zeilennummer, ein unvermeidbares Leerzeichen und vier Zeichen für DATA).

    Es könnte meiner Ansicht nach auch für die erste Zeile die 78 durch 79 ersetzt werden. Denn wir wollen ja 79 Zeichen verwenden (oder gibt printf was komisches zurück?)

    Code
    1. int remaining = 78 - printf("4 sys%" PRIu16 ":data%u", startaddress, (unsigned)*r++);

    wrglprmft Danke fürs Analysieren, ich habe es inzwischen aber gefunden und gefixt :)


    Die 73 war wirklich falsch, da stand ursprünglich auch mal eine 74. Dann waren allerdings manche Zeilen plötzlich 80 Zeichen lang, deshalb dachte ich, ich hätte mich da einfach verrechnet. War es aber gar nicht. In dem Zweig für den self-verifying code war ein viel blöderer Bug: Die Zeilennummer wurde an der falschen Stelle hochgezählt, deshalb war die Längenberechnung für Zeile 10 noch mit Zeilennummer 9 X/


    Also, neue gefixte Version ist eingecheckt, außerdem mit deinem Kürzungsvorschlag im BASIC code. Der C64 Checksummer ohne REM-Skip sieht jetzt so aus:

    Gefixter Windows-Build (diesmal auf FreeBSD cross-compiled, ich hoffe es ist korrekt) hängt an.

    Ja, manchmal muss man etwas erst kaputt reparieren, bevor man das wahre Problem entdeckt.

    Die mksums.exe funktioniert übrigens bei mir.


    Mir ist noch aufgefallen, dass beim F64SUMMER Leerzeichen in Zeichenketten (fälschlicherweise) als überflüssig behandelt werden; und zwar in DATA-Zeilen, denn dort müssen Zeichenketten nicht notwendigerweise mit Hochkomma beginnen.


    Code
    1. 0 DATA BLUMEN TO PFERDE
    2. 0 DATA BLUMEN TOPF ERDE

    erzeugen beide die Summe A19F.