Posts by wizball6502

    Any version I know ... In pause mode, you can step single frames.

    Thanks for pointing out GTK because it doesn't seem to work with the "classic" version 2.4 or at least I could not find a working shortcut to frame-step in that version. Very useful in some situations.

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

    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.

    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:

    <offtopic start>


    Und dann gleich bei Hans Ippisch bzw. Tommy Tallarico einloggen, damit dein C64-Spiel auch für die Intellivision Amico-Konsole umgesetzt wird, was ja Ende 2020 DIE Co-Op und Partyspiel-Familien-Unterhaltung werden soll (für bis zu acht Personen).

    Und Frogs von ZeHa sollte da auch gleich mit. :dafuer:

    <offtopic ende>

    Vice is pretty helpful in analyzing critical transitions with alt+p for pause and alt+shift+p for stepping a single frame.

    What version is that to be able to do single frame stepping in Vice? I think I can only pause in my version. Thanks.

    War wahrscheinlich etwas zu anspruchsvoll für die meisten.

    Vielleicht liegt es einfach daran, dass momentan die Vorbereitungen für ZeHa's BASIC Weihnachten-Heft am Laufen sind und viele BASIC 10Liner Freunde sich dort ebenfalls angesprochen fühlen, etwas beizutragen. Wäre doch auch etwas für dich (falls nicht schon geschehen). :thumbsup:

    Supercool. Ein Zehnzeiler, den man länger als 30 Sekunden spielt, hat schon was. Und er macht Spass. Könnte man das Spiel vielleicht sogar auf eine PUR-80 Version reduzieren, wenn man die Anzeigen textlich kurz haltet und noch ein wenig zaubert?

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

    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.

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

    Ist das nicht bei dir jetzt schon der zweite für dieses Jahr?

    Wenn du dich auf mein Assembler/Maschinensprache-unterstütztes Weihnachts-Spiel beziehst, dass ich weiter oben erwähnt hatte - das habe ich im Sinne der Sache zurückgestellt bzw. werde ich zwar fertigstellen, aber in einer anderen Form veröffentlichen, da es über 1KB an DATA-Zeilen erzeugt hätte - was in etwa 70 gefüllte BASIC-Zeilen mit DATA-Statements entspricht. Also etwas, an dem wirklich nur Datatypist(inn)en und der Zehnerblock einer PC-Tastatur eine Freude gehabt hätten. Ich finde das Ergebnis zwar cool, aber für das BASIC-Weihnachten-Heft m.E. fehl am Platz. Bin mit dem reinen BASIC-Beitrag (ca. 90 Zeilen) auch ganz zufrieden. :D

    Zum "Retro-Feeling" gehört es IMHO auch, zuerst mal den Checksummer abzutippen.

    Stimmt. Aber wolltest du beim F64Summer BASIC-Programm nicht noch zumindest ein Total über alle DATA-Werte (z.B. c=c+a+b) machen, damit man auch dort sicher sein kann, dass alle DATA-Zeilen korrekt eingegeben wurden?

    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. Damit erhält der User auch gleich ein visuelles Feedback, dass der Checksummer nun aktiv ist. 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.

    Code
    1. 0 fora=820to984:readb:pokea,b:c=c+a+b:next:ifc<>167229thenpoke53280,2:end
    2. 1 data169,73,141,2,3,169,3,141,3,3,169,80,141,4,3,169,3,141,5,3,96,169,255,133
    3. 2 data21,76,131,164,32,124,165,173,0,2,240,6,165,21,73,255,208,1,96,133,252,138
    4. 3 data72,152,72,165,20,73,255,133,251,162,0,134,2,189,0,2,133,253,240,44,36,2
    5. 4 data48,4,201,32,240,33,201,34,208,6,169,255,69,2,133,2,160,8,6,253,42,69,251
    6. 5 data74,144,6,169,104,69,252,133,252,102,252,102,251,136,208,235,232,208,205
    7. 6 data160,3,170,181,251,41,15,32,207,3,153,36,4,136,181,251,74,74,74,74,32,207
    8. 7 data3,153,36,4,232,136,16,229,169,1,160,3,153,36,216,136,16,250,104,168,104
    9. 8 data170,96,201,10,144,3,233,9,96,105,48,96
    10. 9 poke53280,5:sys820

    Dies aber das nur als Idee/Vorschlag.

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

    Ich verstehe das. Aber zusätzliche 23 DATA-Werte entsprechen nur etwa einer DATA-Zeile bei der C64-Version. Finde ich also schon zumutbar. Vor allem: Entweder ist jemand eh zu bequem die schon vorhandenen DATA-Zeilen abzutippen und lädt sich das Binary einfach runter oder er/sie sieht die zusätzliche Tipp-Vorarbeit als indirekte Wertschätzung und Teil des Abtipp-Flairs ein kleines Software-Tool einsetzbar zu machen - als Basis für das Haupt-Listing.


    Ich werde vermutlich dem User (in der "Publisher" Rolle) die Entscheidung überlassen und eine Build-Option einbauen, so dass die Checksummer mit oder ohne dieses Feature gebaut werden können.

    Würde das aber dann nicht darauf hinauslaufen, dass der Abtipper dann darauf achten müsste, ob er nun bei einem Listing mit 4-stelligen Checksummen den F64SummerWithREM oder F64SummerWithoutREM Checksummer verwenden soll? Am Einfachsten wäre es für mich als Publisher, wenn ich in meinem Listing lediglich ein kleiner Hinweis auf den F64Summer mit Versionsnummer und URL-Link auf den C64-Wiki-F64Summer-Eintrag angeben könnte.


    Dazu noch eine Frage zur Version "Checksumme ohne REM": Gibt der Checksummer dann überhaupt noch eine Checksumme aus (somit nur für die Zeilennummer), wenn z.B. folgende Zeile eingeben und Return gedrückt wird?


    10 rem **** alles klar, herr kommissar ****


    Wenn eine Checksumme angezeigt wird, dann wäre das m.E. klar besser als gar keine Ausgabe, weil ansonsten die Checksumme von der Zeile davor noch auf dem Bildschirm steht, und DAS dann wirklich für Verwirrung sorgen würde.

    Ok. Ich fasse abschliessend nochmals kurz Pro und Kontra für den Vorschlag zusammen, REM-Kommentare aus der Checksummenberechnung auszuschliessen:


    PRO:

    • Schreibfehler in REM-Kommentaren könnten von der Redaktion im letzten Moment noch korrigiert werden, ohne dass die Checksumme neu berechnet werden müsste. Andernfalls ist der Aufwand zu gross, etwas zu ändern. Schreibfehler machen aber keinen so guten Eindruck.
    • REM-Kommentare könnten komplett ausgetauscht werden ohne Impact auf die Checksumme, z.B. Lokalisierung für ein anderes Sprachgebiet (das gilt dann aber nicht für Text in Strings)
    • REM-Kommentare könnten vom Abtipper optional nur teilweise oder ganz weggelassen werden, ohne dass die Checksumme davon betroffen wäre. Durch das Weglassen wird Zeit beim Abtippen gespart und das Programm läuft dann auch etwas schneller
    • Ein Hinweistext "REM-Statement hat keinen Einfluss auf die Checksumme und kann zugunsten der Performance weggelassen werden." könnte helfen, das unterschiedliche Verhalten des Checksummers zu erklären.
    • Technisch vermutlich realisierbar.
    • Das Checksummer-Tool würde mit diesem Feature um lediglich 23 Bytes bzw. Data-Werte länger (c64)

    KONTRA:

    • Nicht intuitives Verhalten. Es könnte den Eindruck erwecken, dass der Checksummer nicht richtig funktioniert
    • Eine Funktion sollte sich erwartungsgemäß immer gleich Verhalten (Principle of least surprise)
    • Unnötige Anforderung, weil REM-Statements in der selben Zeile wie Code nichts zu suchen haben. Sinnvoller ist es REM-Statements sparsam und in einer eigenen Zeile unterzubringen.
    • Es scheint bisher niemand ein Problem damit zu haben, REM Statement eintippen zu müssen, um an die Checksumme zu gelangen. Auch waren in den bisherigen BASIC Weihnachten Listings eh nur ganz wenige REM-Statements vorhanden.
    • Erforderliche Änderung nicht getestet, somit nicht bestätigt, dass es problemlos funktioniert und sich in allen Situationen richtig verhält. Nebeneffekte ungewiss.
    • Selbstmodifizierender Code oder REM-Statements als DATA-Ersatz setzt eine exakte Abbildung des kompletten Listings voraus. Ohne korrekt erfassten REM-Statements würde das Programm nicht korrekt laufen.
    • Das Checksummer-Tool würde mit diesem Feature um ganze 23 Bytes bzw. Data-Werte länger (c64)

    Ich hoffe, ich habe da die wichtigsten Punkte berücksichtigt. Wie auch immer die Entscheidung schlussendlich ausfällt, danke ich für die faire Diskussion und Argumentationen. Und Danke an zrs1 , dass du dir sogar die Mühe gemacht hast, die Logik probehalber einzubauen.

    Ich als Benutzer eines Checksummers wäre massiv verwirrt, wenn Änderungen in einem Kommentar sich nicht auf die Prüfsumme auswirken, das Weglassen aber schon -- daher ist das für mich keine Lösung.

    Ich bin ja schon längst bei dir mit deinem Approach jetzt. Ich fände das auch total suboptimal, wenn man den Doppelpunkt oder das REM-Statement drin lassen müsste. Das war nur als - zugegebenermassen schlechten - Kompromiss gedacht, weil du das Programm ja möglichst kurz halten willst - was ich auch erstrebenswert finde.

    Snoopy Auch ohne Fettdruck und Unterstreichen, weiss ich, auf was ihr besteht: Ein Programm soll das machen, was von ihm erwartet wird. Punkt. Das hat zrs1 bereits erläutert mit dem Hinweis auf das "Principle of least surprise". Ich denke bei solchen Diskussionen immer ein wenig an Apple, die es schafft, die Endanwender-Sicht einzunehmen und nicht darauf beharrt, technisch logisch zu denken. Es geht ja darum, dass ein Mensch ein Listing Abtippen und am Schluss ein Hochgefühl seiner Abtipparbeit erleben möchte. Wie kann man es also schaffen, dass ein erwünschenswerter "Flow" also ein Glücksgefühl auch schon beim Abtippen eintritt? Entsteht der Flow dadurch, dass ich, wenn ich in einer Zeile ein Zeichen ändere und Return drücke, sich die Checksumme ändert? Oder eben die Checksumme möglichst schnell übereinstimmt und ich zur nächsten Zeile übergehen kann?


    Prinzipien sind keine Gesetze und können je nach Anwendungsfall relativiert werden. Man könnte denn F64Summer mit diesem Zusatzfeature (REM-Kommentare haben keinen Einfluss auf Checksumme) auch genausogut gegenüber anderen Checksummern als "bessere Lösung" verkaufen, das auf die Bedürfnisse der 80%-Anwendungsfälle möglichst gut eingeht und nicht einfach versucht, logisch korrekt zu sein.

    aber auch hier wäre das Weglassen des REM-Kommentars ziemlich folgenreich gewesen

    Ja klar. Es gibt auch solche, die mit Hilfe des {Delete}-Charakters BASIC-Code verstecken, was sich auf die Checksumme auswirkt, aber man im Listing dann nicht mehr sieht.


    Grundsätzlich geht es aber hier doch um klassische Abtipplistings für eine Zielgruppe, die ein BASIC-Programm erfolgreich abtippen können möchte. Da macht man solche verqueren Sachen nicht.

    aber sind das nicht mehr als 10 Zeilen? :weg:

    Schlaumerker. ;)


    Bei der "Explained"-Version des Zehnzeilers oben habe ich jeden Befehl einer Zeile auf eine einzelne Zeile genommen und erklärt. Das Original siehst du hier. Aber das so abzutippen wünscht man nicht mal seinem ärgsten Feind.