Hello, Guest the thread was called15k times and contains 128 replays

last post from Bodhi1969 at the

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!):

  • Ganz ehrlich --- mprg2bas ist aus einem Mini-Tool entstanden, das genau das macht, was der Name vermuten lässt -- und für den Checksummer hier eher "unkontrolliert gewachsen" :) Wenn ich Code plane sieht das selbstverständlich komplett anders aus. Mir gefällt auch das "recursive make" nicht besonders, und die Notwendigkeit, für andere Build-Optionen erst ein "clean" zu machen -- und natürlich die Menge an gedoppeltem Code für die verschiedenen CBM Plattformen... das sollte man besser mit bedingter Assemblierung lösen.


    Aber: Das Tool ist insgesamt so klein, da finde ich lohnt es sich nicht, das alles "richtig schön" zu machen -- es tut ja jetzt was es soll und ist sehr überschaubar ;) Wenn du natürlich Lust hast, hier zu refactorn -- du kannst gerne einen pull request einreichen ;)

  • 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? :gruebel

    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

  • 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? :saint:

  • wizball6502 Die Diskussion hatten wir doch ziemlich ausführlich? Was wenn zwischen Doppelpunkt und REM noch ein Leerzeichen ist (nur zum Beispiel)? Das Verhalten wäre mir zu inkonsistent, das verwirrt den Anwender ziemlich sicher -- so möchte ich das nicht einbauen. So wie es jetzt ist, als optionales Feature das 23 Bytes kostet, finde ich es ok. Ich konnte außerdem an anderer Stelle 2 Bytes einsparen, die Checksummer ohne dieses Feature sind jetzt also geringfügig kürzer.

  • 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. :thumbsup:
    • 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.

  • Moooment mal ... ;)

    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

    Also eigentlich eher weniger, jedenfalls eben nicht um den Preis von 23 Bytes ... weil meiner Meinung nach das REM im C64-BASIC eine Krücke mit deutlichen Nachteilen ist, und daher besser nicht verwendet werden sollte. Ich gestehe aber anderen andere Meinungen zu, und IMHO ist da die beste Lösung, dass jeder selbst entscheidet, was er haben will.

    Meine Hoffnung war, mit dem REM-Skipping einen neuen Standard zu etablieren, weil Standards vieles einfacher machen.

    Kann man hier von einem "Standard" sprechen? Wer heute Abtippheftchen veröffentlicht tut das doch für ein gewisses "Retro-Feeling" -- da gehört es IMHO dazu, dass der Checksummer mit abgetippt wird, also im Heft auch abgedruckt ist. Wenn es ein optionales Feature gibt kann sich der, der das haben will, das entsprechend abdrucken. Als "Default" beim Build wähle ich natürlich die Einstellungen, die ich selbst am nützlichsten finde :o Mal sehen ob ZeHa für seine neue Ausgabe auf die neuere Version geht, und wenn ja, welche Einstellungen er bevorzugt ;)

    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. :thumbsup:

    Das kann ich natürlich tun (wobei es einfach sein sollte, das selbst zu bauen -- man braucht eigentlich nur einen C-Compiler, den cc65 und GNU make im Pfad, der Rest steht im README.txt) -- führt aber durchaus zu einer weiteren Verbesserungsoption: Die Optionen sollten sich nicht gegenseitig ausschließen (z.B. indem mit verschiedenen Optionen gebaute Checksummer in verschiedenen Ausgabeverzeichnissen landen). Dann könnte man einen fertigen Build (mit Windows binaries) anbieten, der einfach alle Möglichkeiten enthält. Da werde ich mir wohl bald was einfallen lassen.

    ch 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?

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


    Ich persönlich finde aber, siehe oben, der abgedruckte Checksummer gehört zu so einer "Retro-Veröffentlichung" eh dazu. Die Checksummen selbst sind in allen Versionen miteinander kompatibel ... wenn aber jemand ein Listing abtippen will, das mit mksums -r erstellt wurde, und dazu einen Checksummer ohne das "REM skip" feature verwenden will, MUSS er alle Kommentare weglassen um die korrekten Checksummen zu bekommen.

  • 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.

    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). ^^

  • 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.

    Wie gesagt, die Prüfsummenberechnung ist die gleiche (und wird, so weit lehne ich mich aus dem Fenster, auch IMMER gleich bleiben). Ich werde demnächst mal das Tag für Version 2.0 setzen (vorher schaue ich noch, dass ich den Build so anpasse, dass man verschiedene Varianten "nebeneinander" bauen kann) -- wenn man das mit Standardeinstellungen baut ist nur die Selbstverifikation neu. Da kann es dann also keine Verwirrung geben :) Diese Selbstverifikation finde ich für diejenigen, die den Checksummer erst noch abtippen, aber ein wirklich nützliches Feature. Muss dann aber ZeHa entscheiden, ob er das haben will oder nicht :)

  • 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ß ;) )

  • Mac Bacon man KANN REM benutzen, aber dann muss es eben auch mit abgetippt werden, wenn es in der gleichen Zeile mit anderem Code ist und man den Checksummer in default-Einstellungen hernimmt :) Wie gesagt, ich finde andere Meinungen völlig ok und habe deshalb eine entsprechende Build-Option eingebaut.


    Ich ziehe an der Stelle mal die fiese Maintainer-Karte: Im "default Build" wird der F64Summer REM nicht speziell behandeln, fertig aus :P -- wer das nicht mag kann gerne forken, das Ding steht ganz bewusst unter der sehr liberalen BSD 2-clause License :)

  • 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.

  • ZeHa hat mich auf ein weiteres Problem aufmerksam gemacht, das zu falschen Checksummen führen kann:


    Für geshiftete Zeichen gibt es in PETSCII verschiedene mögliche Codierungen. Im BASIC-Text ist das zunächst mal kein Problem, da alle Codierungen mit Bit 7 den BASIC Tokens vorbehalten sind -- der Rest ist eindeutig. Innerhalb eines Strings habe ich aber z.B. für ein geshiftetes A zwei Möglichkeiten, es zu codieren: $61 oder $c1. Der BASIC Editor nimmt immer $c1. 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 mksums würde in diesem Fall mit $61 rechnen, beim Abtippen bekomme ich aber eine Prüfsumme mit $c1. :huh:


    Deshalb habe ich vorhin eine neue Version auf github eingecheckt, bei der mksums per default innerhalb von Strings "falsche" Codierungen korrigiert. Ich habe nicht jeden einzelnen Fall getestet, 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. Kann mir jemand sagen, ob das so richtig ist? :)

  • 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.

    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.

  • 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.

    Ja sicher, bei Vergleichen ist es offensichtlich nicht egal. Und klar steckt der Fehler in solchen Tools. Da es die aber anscheinend nichtsdestotrotz gibt und sie verwendet werden ist es wohl sinnvoll, in mksums entsprechende Workarounds einzubauen...

    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.

    Danke, den zweiten Block hatte ich gar nicht bemerkt -- dann ergänze ich das der Vollständigkeit halber auch gleich in mksums!


    edit: ist drin, so sieht jetzt der Workaround aus.

  • Nochmal danke an ZeHa fürs testen der neuesten Änderungen, die scheinen jetzt alles korrekt zu machen, was im ersten Heft vorkam -- hoffen wir, dass das auch für sein zweites gilt :)


    Deshalb habe ich den Stand eben zur Version 2.0 erklärt, auf Github kann man entsprechend einen tarball (bzw ein zip) des source von v2.0 herunterladen. Wer das jetzt verwenden will hat die Wahl, ob er selbst-verifizierende Checksummer will und ob die Checksummer REM ignorieren sollen.

  • 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.

    "Ich bin das Schwert, ich bin die Flamme." (Heinrich Heine)


    „Lerne leiden, ohne zu klagen!“ (Friedrich III.)

    Edited 2 times, last by syshack: Diskussion zum F64Summer aus dem Thread "Weihnachten auf dem Commodore (BASIC-Heft) - Vorbestellung 2019"​ nach hierher verschoben. ().

  • 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.