Schnelles Füllen und Löschen mit SYS

Es gibt 161 Antworten in diesem Thema, welches 22.455 mal aufgerufen wurde. Der letzte Beitrag (17. Oktober 2016 um 02:26) ist von BIF.

  • Der Code hier im Thread zeigt schon direkt wie heikel das sein kann. Ersetze unbedarft den direkten Aufruf durch eine Variable und *BUMM*.

    Also du stellst mit deinen Posts hier verschiedene Thesen in den Raum, ohne ein einziges konkretes Beispiel zu nennen.

    ...kein weiterer Text...

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Frage:
    Und warum sollte ich den direkten Aufruf durch eine Variable ersetzen,
    wenn es dann Probleme gibt?
    Für mich persönlich wäre das eher unlogisch.
    Ich denke mal das das eine Frage ist, die ihr nicht beantworten könnt.

    Schönen Gruß.

  • Nicht eine einzelne Systemroutine ist das Problem. Die Verwendung am Interpreter vorbei ist das Problem. Und ein Programm welches (ob im ROM verankert oder nicht) mittels SYS / USR aufgerufen wird ist halt nunmal nicht integrer Bestandteil des BASIC, sondern eine separate Maschinenroutine.
    Aber genau das ist der Punkt den wir schon oft diskutiert haben und wo sich auch diesmal nichts ändern wird, weil Du es anders siehst als ich (und eine ganze Ladung anderer).

    Das konkrete Beispiel hast Du selbst geliefert, siehe Mac Bacons Einwurf.

    Nochmal: Mach dein Ding, mach es gern, aber wenn Du es teilen magst tu es bitte so dass es anderen auch wirklich hilft. Und dazu gehört halt eine zumindest insofern vollständige Beschreibung dass die Anwendung klar ist und Fallstricke geklärt sind.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Frage:
    Und warum sollte ich den direkten Aufruf durch eine Variable ersetzen,
    wenn es dann Probleme gibt?
    Für mich persönlich wäre das eher unlogisch.
    Ich denke mal das das eine Frage ist, die ihr nicht beantworten könnt.

    Schönen Gruß.

    Du weisst das vielleicht, und vermeidest es. Andere, die hier nur den Schnipsel sehen, ohne jede Erläuterung dazu, bauen es ein, bauen es vielleicht auch um und rufen es halt mit Variable auf, und dann geht der Mist hoch und sie wissen nicht warum.
    Genau darum geht es die ganze Zeit. Nicht jeder der hier reinschaut wird sich deinen Code mit einem ROM-Listing in der Hand zu Gemüte führen. Bei vielen kann man davon ausgehen dass sie die angebotene Routine unbedarft einsetzen.
    Hey, das ist ja Basic, also kann ich es benutzen wie jeden anderen Basic code. Ich rufe alles gern mit Variable auf - HUCH?!


    Oder halt auch nicht, weil es ein Basic-Hybride ist...

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Aber dann solltest Du diese Randbedingungen auch offen darlegen wenn Du deine Codes auf einer offenen Plattform wie diesem Forum anbietest. Sonst fliegt dem nächsten dein Code um die Ohren und er hat keine Ahnung was da schief läuft.

    :thumbup:

    Ansonsten:

    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    Ich schwöre mir, nie wieder auf einen BIF-Post zu reagieren
    ...

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Zitat von Bladerunner

    Es ist fehleranfällig und funktioniert nur in einem sehr eng gesteckten Rahmen.

    Das gilt doch aber auch für Assembler, oder nicht? Der C64 gehört noch zu der Generation von Rechnern, die man auf Hardwareebene vollständig verstehen und manipulieren konnte. Heute ist die Hardware zu komplex und wir brauchen Abstraktionsschichten.

    Die "Macht" die man beim C64 hat, bedeutet automatisch auch Instabilität, weil es keine Schutzmechanismen dagegen gibt, wenn ein Unkundiger Gott im Rechner spielt und Fehler macht, weil er die Macht dazu hat.

    Wenn man nur ein Bit anders setzt, wenn nur ein Befehl zuviel/zu wenig oder falsch parametriert ist, dann kommt auf einmal Müll raus. Das ist doch in ASM nicht anders. Ich habe das bei meinem letzten Rasterbar Experiment bemerkt. Mein Code ist übrigens grauenhaft und besteht aus lauter nops, weil ich zu faul war, Zyklen zu zählen um Schleifen zu bilden und den Code zu straffen. Ich muss ja dann auch mitzählen wieviele Zyklen die Schleifenabfrage verbraucht und dann war's mir zu doof. Ein nop mehr oder weniger entscheidet zwischen "Schrott'" und "schön".

    Wenn man den C64 gewohnt ist und tiefer in die Materie eindringt, dann ist man es eigentlich auch gewohnt ihn zu manipulieren. Jedes Programm ist ein fragiles Gebilde was nur stabil wirkt, es aber in Wirklichkeit nicht ist. Es gibt dort nicht die Schutzmechanismen und Automatismen, auf die man sich heutzutage verlässt und verlassen muss, weil es nicht mehr anders geht.

    "Sauberes Programmieren" gibt es aus meiner Sicht auf Hardwareebene eigentlich nicht. Es sind alles Hacks. Vor allem, wenn man auf Performance aus ist oder verblüffene Demo Effekte.

    Von daher kann ich die Mentalität, aus der BIFs Krypto-Zeugs kommt, nicht wirklich kritisieren. Es ist eigentlich typisch für alle C64 Coder, dass sie früher oder später in die Trickkiste greifen, um ein Ziel möglichst effektiv oder spektakulär zu erreichen.

    Was man dagegen kritisieren kann ist BIFs Erklär-Armut und natürlich weiß ich, dass es schon zu V2 Zeiten eine Art "Style Guide" gab, bzw. Programmierregeln ("aus gosubs springt man nicht seitlich heraus"). Das ist ja auch gut.

    Nur so wie in Java, wo der Compiler einen zwingt seine Klassen als Dateinamen so zu benennen wie in der Definition im Quellcode, so ist der C64 eben nicht. Wo man über die Stränge schlagen darf, wird auch über die Stränge geschlagen und dies ausgenutzt um Leistung oder Geschwindigkeit zu erpressen.

  • Das gilt doch aber auch für Assembler, oder nicht? Der C64 gehört noch zu der Generation von Rechnern, die man auf Hardwareebene vollständig verstehen und manipulieren konnte.

    Bei Assembler weiß ich dass der Code keinerlei Schutzmechanismen bietet, ich agiere also gleich vorsichtiger. Ein Standard-Basic-Programm (wenn ich auf Poke / Sys verzichte) wird mir nicht abstürzen (einige wenige gloriose Bugs mal ausgenommen, wie die Print 5+"A"+-5 Geschichte) sondern mit einer Fehlermeldung abbrechen. Das Programm kann Fehler enthalten aber es wird den Rechner nicht in den Tod reissen. Bei Assembler sieht das anders aus, also gehe ich gleich mit anderer Vorsicht zu Werke. Aber auch unter Basic benutze ich Poke / Sys nur wenn ich die betreffenden Speicherzellen und Routinen genau kenne und weiß was ich damit anrichten kann.


    Wenn man den C64 gewohnt ist und tiefer in die Materie eindringt, dann ist man es eigentlich auch gewohnt ihn zu manipulieren. Jedes Programm ist ein fragiles Gebilde was nur stabil wirkt, es aber in Wirklichkeit nicht ist.

    S.o., reines Basic ist zumindest stabil genug dass man nach dem Fehler folgenlos im Code selbigen suchen kann, weil es einem nicht den Interpreter zersprengt. BIF umgeht den Interpreter, in dem er die Routinen im System eingenständig aufruft und dabei Teils so nicht vorgesehene Einsprungsadressen nutzt. Wenn er sicher weiß was er da tut ist das auch okay, aber es ist nur sehr bedingt zur Weitergabe geeignet, da man nicht unterstellen kann das jeder Basic-Programmierer sich genug mit Assembler auskennt um die Routinen die er da nutzt analysieren zu können und alle Fehlerquellen aufzuspüren.
    Ich geh noch einen Schritt weiter: Ich wette auch BIF ist das nicht immer bewusst, und der Fehler der ihm von Mac Bacon gezeigt wurde war ihm vorher nicht klar. Solange er diesen Hack für sich alleine nutzt, soll mir das völlig egal sein. Wenn er es aber in die Öffentlichkeit trägt kann ich erwarten dass er es erklärt, ansonsten muss er eben die Kritik anderer ertragen - hier ist ein Forum und Diskussion/ Disput gehört zur Konversation hinzu.

    "Sauberes Programmieren" gibt es aus meiner Sicht auf Hardwareebene eigentlich nicht.

    Einspruch!
    Wenn es das nicht gäbe wäre es im Umkehrschluss nicht möglich stabile Systeme zu schaffen. Das geht aber, wie der Basic-Interpreter selbst ja zeigt. Es gehört natürlich eine Portion Verständnis dazu was wo passiert, und ich bin mir sicher die Entwickelr bei Microsoft/Commodore hatten eine ausführliche Referenz erstellt um selbst in ihrem Code klar zu kommen und zu wissen wo welche Funktion liegt, was sie tut, mit welchen Parametern sie angesprungen wird und was sie verändert oder zurückgibt.
    Das Saubere Arbeiten findet hier in der Dokumentation statt, und die ist bei BIF mangelhaft/ungenügend.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • "Sauberes Programmieren" auf Hardwareebene: gibt es. Beispiele: Luftfahrt, Medizintechnik, Automobilbau etc...

    Wissen ist das einzige Gut, das sich beim Teilen vermehrt. Also seid vorsichtig damit!

  • Zitat von Bladerunner

    BIF umgeht den Interpreter, in dem er die Routinen im System eingenständig aufruft und dabei Teils so nicht vorgesehene Einsprungsadressen nutzt.

    Ist es aber nicht so, dass man bereits am Interpreter vorbei geht, wenn man allein schon einen SID-Ton erzeugen oder in den Grafik-Modus wechseln will um eine Linie zu zeichnen? Das geht unter V2 Basic meines Wissens nicht ohne Pokes. Bessere Basic-Systeme erlauben Hardware-Zugriff mit eigens dafür vorgesehenen Basic-Befehlen, z.B. "Sound" und "Graphic" an Basic 3.5.


    Zitat von Tale-X

    "Sauberes Programmieren" auf Hardwareebene: gibt es. Beispiele: Luftfahrt, Medizintechnik, Automobilbau etc...


    Ja, akzeptiert. Ist der 6502 nicht heute noch in Herzschrittmachern verbaut? Wär blöd wenn da was im Code schief gewickelt wäre.

    Sauber programmieren heißt also, Konventionen zu achten, auch wenn man die Macht hat, sie zu brechen.

  • Ist es aber nicht so, dass man bereits am Interpreter vorbei geht, wenn man allein schon einen SID-Ton erzeugen oder in den Grafik-Modus wechseln will um eine Linie zu zeichnen?

    Nein, denn da setzt Du mit deinen Pokes Register, und die sind genau dafür vorgesehen. Du rufst ja nicht dafür irgendwelche Systemroutinen auf die eigentlich für einen anderen Zweck gemacht wurden.
    Selbstredend gilt hier auch schon das man wissen muss, welche Speicherstelle was macht. V2 ist da halt eigentlich nicht für gemacht, Grafik und Sound sind unter Assembler deutlich besser umzusetzen. Grafik, weil da Massen an Daten rumkommen, Sound, weil eine vernünftige Zeitsteuerung einen Interrupt voraussetzt. Basic kann zumindest wenn es um mehr als Experimente geht da einfach nicht vernünftig genutzt werden. (Mit Graus denke ich an die Ursprungsversion von Hanse die die Karte der Nordsee in Hires anzeigte - und man konnte zusehen wie die einzelnen Pixels gesetzt wurden. In der gängig verbreiteten Version wurde die Karte dann mit Charset dargestellt, das ging flüssig.)

    Sauber programmieren heißt also, Konventionen zu achten, auch wenn man die Macht hat, sie zu brechen.

    jop - und genau das macht BIF nicht. Ihm sind sie egal, und er erläutert auch nicht was er da tut, und das ist in Kombination brandgefährlich für jeden Aussenstehenden der unbedarft an seine Codes herangeht.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Zitat von Bladerunner

    Du rufst ja nicht dafür irgendwelche Systemroutinen auf die eigentlich für einen anderen Zweck gemacht wurden.

    jsr $ea81 (Endstück der Interrupt Service Routine des Kernals) oder jsr $e544 (BS löschen) sind also "legale" Aktionen.

    Was Demo Coder tun um den Rahmen zu öffnen oder um Kernal Bugs für VSP Experminete zu nutzen ( Bitte melde dich an, um diesen Link zu sehen. ) dürfte aber eher als "Hack" gelten.

    Wobei so wie wir gerade diskutieren ("es gibt doch saubere Hardware-Programmierung"), dann ist alles, was sauber dokumentiert und unter festen Bedinungen reproduzierbar ist, "legal". Auch kranke BIF-Hacks und Demo Effekte. Entscheidend ist die Doku, die den Verwendungsrahmen und die Nebenwirkungen klar absteckt. Dann können solche Algorithmen auch in einer Herzschrittmacher-Software laufen.

  • um Kernal Bugs für VSP Experminete zu nutzen

    Öhm? Was haben denn die weißen Figuren mit dem schwarzen Kaffee zu tun?!

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Eine absolut vollständige Dokumentation, wie sie hier verlangt wird kann keiner und auch ich nicht bieten.
    Das heißt nämlich ein vollständiges Studium und Verständis des ROM-Codes in allen Aspekten.
    Und das gehört bestenfalls in die Assembler-Ecke.
    Als Basic-Programmierer verlasse ich mich da natürlich auf die Erfahrung und Tests.

    Wenn ich ein Programm veröffentliche heißt das natürlich nicht,
    daß ich damit eine Vollkasko-Versicherung mitliefere und mitliefern muß.
    Das zu Fordern ist reine Mobberei.

    Jeder Programmierer muß selbst entscheiden, ob er ein Programm einsetzt oder nicht.

    Im übrigen wird hier von einigen nicht kritisiert, daß mein Code nicht funktioniert.
    Sondern es wird kritisiert, daß er funktioniert.
    Und daß, wenn man den Code manipuliert dann Fehler auftreten....(hahaha)
    Das ist aber natürlich bei fast allen Codebeispielen so.


    Schönen Gruß.

  • Da kritisiert wurde, daß man den SYS-Befehl in PostBitte melde dich an, um diesen Link zu sehen. nicht mit Variablen aufrufen kann, veröffentliche ich hier noch mal einen Alternativ-Code in dem ich zeige, daß auch das geht.

    Quellcode:
    0 :rem-- a=adresse
    1 :rem-- b=bereichslänge
    2 :rem-- c=fuellcode
    3 :rem-- d=rom-adresse
    9 :
    50 :d=45762:rem---ram-fuell(a,b,c,d)
    51 :poke780,c:poke114,b/256:poke113,b-peek(114)*256:poke768,61
    52 :poke89,a/256+peek(114):poke88,a-int(a/256)*256:sysd+0:sys58451:return

    Der Zusatz :sysd+0: , also plus Null, bewirkt, das der Schreibzugriff wieder bei 2/3 landet und damit für den Programmablauf unproblematisch ist.
    :poke768,61: bewirkt, daß das Programm nach der Fehlermeldung weiterarbeitet.
    sys58451: setzt dann 768 wieder auf die Standard-Werte.

    Schönen Gruß.

  • jsr $ea81 (Endstück der Interrupt Service Routine des Kernals) oder jsr $e544 (BS löschen) sind also "legale" Aktionen.
    Was Demo Coder tun um den Rahmen zu öffnen oder um Kernal Bugs für VSP Experminete zu nutzen ( Bitte melde dich an, um diesen Link zu sehen. ) dürfte aber eher als "Hack" gelten.

    Wobei so wie wir gerade diskutieren ("es gibt doch saubere Hardware-Programmierung"), dann ist alles, was sauber dokumentiert und unter festen Bedinungen reproduzierbar ist, "legal". Auch kranke BIF-Hacks und Demo Effekte. Entscheidend ist die Doku, die den Verwendungsrahmen und die Nebenwirkungen klar absteckt. Dann können solche Algorithmen auch in einer Herzschrittmacher-Software laufen.

    Es gibt da kein legal / illegal, sondern eher ein sicher / unsicher.
    Mitten in Routinen zu springen die für Zweck x geschrieben wurden und zufällig noch Y erledigen weil man grade y braucht ist halt insofern unsicher als das unbeabsichtigt weitere Aktionen laufen können.
    Das unterscheidet ja den Registerzugriff auch vom Aufrufen einer Routine. Was Democoder so nutzen würde ich auch in der Regel nicht als Code für den Alltagseinsatz bezeichnen. Demos sind hochspezialisierte Programme, die bewusst mit den Grenzen der Hardware spielen.
    Wäre der Code den Bif liefert ordentlich dokumentiert könnte man immer noch streiten ob es der beste für den Zweck ist, aber zumindest könnte sich auch ein unbeteiligter Dritter im Klaren werden wie man ihn sicher nutzen kann und ob er ihn nutzen möchte. Das ist in der aktuellen Form nicht möglich.

    Eine absolut vollständige Dokumentation, wie sie hier verlangt wird kann keiner und auch ich nicht bieten.
    Das heißt nämlich ein vollständiges Studium und Verständis des ROM-Codes in allen Aspekten.
    Und das gehört bestenfalls in die Assembler-Ecke.
    Als Basic-Programmierer verlasse ich mich da natürlich auf die Erfahrung und Tests.

    Moment mal, DU präsentierst dich hier immer wieder als ach-so-schlau mit all deinen Tricks. Wenn Du wirklich fit bist solltest Du in der Lage sein die Anwendung eines von DIR geschriebenen Codes zu erläutern und die Routinen die DU dafür benützt anzusehen und zu prüfen ob sie noch was anderes tun. Niemand ist perfekt, und man kann da ja mal was übersehen. Da würde niemand was sagen. Du lässt es aber gleich bleiben und wenn was schief geht ist die Schuld immer bei anderen. Und damit rennst Du hier gegen eine Wand.
    Und Sorgfalt gehört überall hin, nicht nur in die Assembler-Ecke. Erfahrung und Tests können Wissen und Sorgfalt ergänzen, aber nicht ersetzen.

    Wenn ich ein Programm veröffentliche heißt das natürlich nicht,
    daß ich damit eine Vollkasko-Versicherung mitliefere und mitliefern muß.
    Das zu Fordern ist reine Mobberei.

    Das erwartet niemand von Dir. Wie gesagt, Fehler können jedem passieren und das ist absolut verzeihlich. Aber eine sorgfältige Dokumentation (und vielleicht auch mal ein wenig Einsicht wenn man auf Fehler im präsentierten hingewiesen wir) stände auch Dir gut zu Gesicht.


    Im übrigen wird hier von einigen nicht kritisiert, daß mein Code nicht funktioniert.
    Sondern es wird kritisiert, daß er funktioniert.

    Da hätte ich jetzt gern eine Quelle von Dir.

    Und daß, wenn man den Code manipuliert dann Fehler auftreten....(hahaha)

    Der Code wurde von Mac Bacon nicht manipuliert - er wurde nur anders aufgerufen, was für ein normales BASIC-Programm absolut legitim ist. Wenn man das nicht darf, gehört es nunmal explizit erwähnt.
    Du kannst einem Endanwender nicht übelnehmen dass er eine legitime Aufrufsvariante für ein Unterprogramm verwendet. Wenn der Code dabei versagt, muss man ihn eigentlich als fehlerhaft werten, denn er passt nicht mehr zu den Sprachkonventionen.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Also, wer Interesse an dem Code hat, der wird den sicherlich als Bereichung sehen.
    Und wer kein Interesse daran hat, der hat es eben nicht.

    Und wer mehr wissen will, der muß genau das selbe tun, wie ich auch auch,
    und zwar in einem Buch blättern oder im Internet recherchieren.

    Schönen Gruß.

  • Wie zu erwarten war. Es bleibt also bei halbgaren, unerklärten Hacks.
    Amen.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Eine absolut vollständige Dokumentation, wie sie hier verlangt wird kann keiner und auch ich nicht bieten.
    Das heißt nämlich ein vollständiges Studium und Verständis des ROM-Codes in allen Aspekten.

    Wer sowieso das ROM lesen kann, kann sich die paar Zeilen auch selbst und ohne Seiteneffekte schreiben und braucht dann auch keine Tipps mehr, an welcher Stelle was zufällig halbwegs äquivalentes im ROM steht, das man dann nur unter zusätzlichen Einschränkungen zum selben Zweck missbrauchen kann. Ad absurdum.

  • Wer sowieso das ROM lesen kann, kann sich die paar Zeilen auch selbst und ohne Seiteneffekte schreiben und braucht dann auch keine Tipps mehr, an welcher Stelle was zufällig halbwegs äquivalentes im ROM steht, das man dann nur unter zusätzlichen Einschränkungen zum selben Zweck missbrauchen kann. Ad absurdum.

    +1
    Da vermisse ich glatt den Bedanken-Knopf.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Meine Auffassung ist folgende:

    Wenn Mac Bacon das Programm verändert und dadurch Risiken für den Nutzer entstehen,
    dann ist es auch die Pflicht von Mac Bacon darauf hinzuweisen.

    Und nicht meine.

    Schönen Gruß.