CRC16 (X-Modem) Checksumme in BASIC V2 ?

Es gibt 22 Antworten in diesem Thema, welches 2.931 mal aufgerufen wurde. Der letzte Beitrag (24. Januar 2021 um 18:51) ist von Larry.

  • Das funktioniert so leider alles nicht. Das liegt nicht an eurem tollen Code JeeK und EgonOlsen71 , sondern schlicht weg an der Tatsache, das das BBS Programm damit zu groß wird. Es wird der wenige mir zur Verfügung stehende RAM Bereich überschritten. Das führt nach compiling mit Blitz Compiler zu Laufzeitfehlern. :schreck!:

    Daher habe ich mir einen anderen Weg überlegt wie es funktionieren könnte. Das Transferprotocol X-Modem(1K) bringt die Routinen für die CRC16 Berechnung ja schon mit. Der Code liegt zwar im Bereich ab $b900, also unter dem BASIC ROM, kann aber mittels BBS Kernal Bordmitteln vom BASIC Programm aus angesprochen werden.

    Den oben schon gebildeten String lege ich in einem BBS Buffer Bereich bei $cf00 ab. Nun muss ich "nur noch" das Protokoll dazu bringen, diesen Bereich einmalig für die CRC16 Berechnung zu verwenden.

    Auweia.... jedenfalls ist der BASIC Teil damit in knapp 7 Codezeilen erledigt. Der ML Part mit dem ich das X-Modem Protokoll beackern muss ist noch gedanklich in Arbeit...

    Für Interessierte, so siehts gerade aus:

    Die hier nicht aufgeführten _str2buf und _createis packen den Inhalt der Variablen i$ aus dem Variablen Speicher in den BBS Buffer bei $cf00, bzw. wieder zurück von $cf00 in die Variable i$.

    HOLY MOSES/ROLE wird ggf. wissen was ich meine.... alter BBS Coder.

    EDIT: Sorry keine Zeilennummer in o.g. Codeschnipsel, da ich inzwischen nur noch mit BPP vom Henning arbeite.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • <hi$="{CTRL-A}"+chr$(0)+chr$(255)+p$:for i=len(p$) to 131:i$=i$+chr$(0):next:i$=i$+g$

    Da scheint mir ein Logikfehler zu sein. Das Auffüllen auf 131 sollte doch bezogen auf i$ sein. Es sollte doch eher

    ... :for i=len(i$) to 131: ...

    denn p$ ist der Pfad, der sofern ich das richtig verstehe max. 128 Zeichen haben darf. Da p$ bereits zu i$ hinzugefügt wurde, kann man das Auffüllen nicht bei p$ machen (auf 128 Zeichen). D.h. es werden zu viele CHR$(0) hinzugefügt.

    Außerdem wird nicht der Fall berücksichtigt, dass len(i$) bereits 131 lang ist (wo dann nichts hinzugefügt werden muss. Wenn i$ 131 lang wäre - was dann schon ok wäre - dann wird durch den auf jeden Fall mindestens einen Durchlauf immer noch ein CHR$(0) ergänzt.

    Es müsste dann

    if len(i$) < 131 then for I=len(i$) to 130: ...

    D.h. bei 131 wird nichts hinzugefügt, bei 130 1 Zeichen, 129 2 Zeichen usw.

    Wenn man bei p$ als Referenz bleiben möchte, dann ändern sich die Grenzwerte:

    if len(p$) < 128 then for I=len(p$) to 127: ...

    Außerdem kann ich nur empfehlen, häufig genutzte chr$()-Werte in entsprechende Variablen zu setzen, die auch früh deklariert sind. Das nicht nur schneller, sondern wird auch Platz sparen. Z.B. chr$(0) durch z$. Da amortisiert sich dann die Initialisierung zu Beginn irgendwo eingeflickt als :z$=chr$(0) (8 Bytes) ziemlich schnell, je Vorkommnis spart z$ gegenüber chr$(0) 2 Byte.

    Die hier nicht aufgeführten _str2buf und _createis packen den Inhalt der Variablen i$ aus dem Variablen Speicher in den BBS Buffer bei $cf00, bzw. wieder zurück von $cf00 in die Variable i$.

    Das Wiederherstellen von i$ nach dem Aufruf der CRC-Routine ist vermutlich deswegen, dass dort die letzten zwei Zeichen dann der CRC-Wert ist, oder? Als Alternative hätte ich mir eher gedacht, dass man den CRC-Wert per PEEK() ausliest und dann via PRINTBitte melde dich an, um diesen Link zu sehen.,i$chr$(crclow)chr$(crchigh); rausschreibt, ohne da aufwändig i$ zu manipulieren.

  • p$ beinhaltet den Dateinamen + Endung ",p" oder ",s" (für SEQ) Dateien. Ist also zwischen 3 und max. 18 Zeichen lang.

    Inzwischen musste ich den Code in BASIC wieder verwerfen, da das alles zu viel Speicher frisst. Das komplette BBS Programm geht damit über 160 Blocks, mit Blitz Compiler über 101 Blocks.

    Das ist inzwischen so groß, dass Blitz mit Fehlern compiliert, obwohl keine Fehler vorhanden sind.

    Ich gehe jetzt nur noch hin und POKE diese 133 Bytes in einen freien RAM Bereich bei $c800, und muss den Rest komplett über das Transferprotkoll in ML machen. Aber auch hierbei ist wieder Platzmangel.

    Also an alle die hier mitlesen und sich auf Y-Modem in C*BASE freuen.... abwarten.

    Die Idee mit z$ ist gut. Alles was Platz spart ist gut bei C*BASE :)

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70