Schnelles Füllen und Löschen mit SYS

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

  • @Bladrunner:
    Falsch der in PostBitte melde dich an, um diesen Link zu sehen. gepostete Code gefährdet niemanden.
    Und funktioniert.
    Es ist zwar der Fall, daß zwei Bytes über den Pointer geschrieben werden,
    die werden allerdings in einen Bereich 2/3 geschrieben, der vom Basic nicht genutzt wird.
    Und das kann jeder, der ein Handbuch mit Zeropage-Adressen hat nachlesen.

    Schönen Gruß.

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

    Ich möchte dich hier mal an dein Zitat aus PostBitte melde dich an, um diesen Link zu sehen. erinnern:
    "Und ich behaupte ja auch nicht von mir tolle, fehlerfreie Codes zu verfassen."

    Nun du behauptest zwar nicht von dir, daß du ein guter Programmierer bist,
    aber du behauptest offenbar, daß du andere Programme verstehst, was aber nicht der Fall ist.


    Schöne Gruß.

  • Zitat-Bladerunner:
    !Warnung! BIF gefährdet ihre Programme! !Warnung!
    Codes von BIF enthalten nicht durchdachte Zugriffe auf Systemroutinen.
    Nebeneffekte von Fehlfunktion bis Absturz sind nicht auszuschließen.
    Use @ your own risk! You have been warned!

    Du kannst ja mal sagen, was du mit solchen Kommentierungen bezwecken willst.
    Du behauptest ja nicht, daß du einen fehlerfreien Programmcode zustande bringst, wie du selbst gesagt hast.

    Schönen Gruß.

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

    Grundsätzlich gilt beim Programmieren immer, wenn ich ein Programm verändere, dann ist es auch ein anderes Programm, das anders funktioniert.

    Diese Änderung kann geringfügig und für den Programmablauf unerheblich sein.
    Die Änderung kann aber auch bedeuten, daß das Programm anders funktioniert, als geplant.

    Und das ist im Prinzip Programmierer Grundwissen.


    Schönen Gruß.

  • Ach BIFi, kleines Tröllchen,
    ein Quad-Post? Hast Du etwa Blutdruck?
    Ab von der Tatsache dass es nichts bringt mit Dir zu reden, was ich auch nicht mehr tun werde, da es mir ganz ehrlich zu blöde ist, sei Dir versichert dass ich durchaus das Handwerk des Programmierens erlernt habe. Im Gegensatz zu Dir versuche ich damit allerdings nicht mein Ego aufzupolieren und ich verkaufe mich auch nicht als weltbesten Programmierer, dein einzig wahren mit dem großen Durchblick.
    Da du kognitiv augenscheinlich nicht in der Lage bist zu erfassen was meine Aussage in dem Posting sollte, diese Erläuterung. Ich sehe das hier nicht als Wettbewerb, und ich bin dir sicher keine Beweise schuldig.
    Selbst wenn ich nicht programmieren könnte stünde mir dennoch Kritik zu - man muss auch kein Designer sein um ein misslungenes Design zu erkennen, und es bedarf nicht des Landwirtes um faules Korn zu erkennen.
    Deine Programme sund und bleiben Hacks mit undefinierbarem Ausgang, miserabel dokumentiert und einzig dem Zwecke dienend deine Selbstherrlichkeit auszuleben.
    Ich habe mich entschlossen darauf hinzuweisen damit niemand auf diesen Mist hereinfällt. Es wird keine Diskussion mehr mit mir zu Pointern, Speicherzellen, See-Only-Memory, Bif-Pages, RAM-ROM-Tricks und niemals aufgestellten Behauotungen dazu was unter Basic (oder deiner Vorstellung davon was denn Basic so sein möge) möglich ist oder auch nicht geben.
    Du, und da erlaube ich es mir mal persönlich zu werden, hast den Schuss nicht gehört und wirst ihn auch niemals hören. Ich glaube auch nicht dass Du ihn überhaupt hören möchtest, weil dir die Trollerei ja sehr gut gefällt.
    Nur, ich werde das nicht mehr mitspielen. Ich warne, und fertig. Wärst Du in meiner IP unterwegs, hätte ich dir schon länger den letzten Fisch zu geworfen und dich gebannt, hier bin ich Gast, also werde ich in Zukunft einfach nur /ignore anwenden und in deinen Threads einen Beitrag erstellen der meine Warnung enthält, und fertig. Vielleicht passe ich die dann noch ggf. an, aber einen Fehler mache ich sicher ab jetzt nicht mehr: Mit Dir diskutieren - da kann man nämlch auch gleich mit einer Parkuhr reden.

    <°|||||3<<, da, ein letzter für Dich.
    :winke:

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

  • hier bin ich Gast, also werde ich in Zukunft einfach nur /ignore anwenden und in deinen Threads einen Beitrag erstellen der meine Warnung enthält, und fertig.

    ...jetzt müsste die Signatur nur noch ein Link auf diesen Thread sein. :thumbsup:

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

  • -Also noch mal, es geht hier um einen Nachweis, und zwar dafür, daß mein Programm in PostBitte melde dich an, um diesen Link zu sehen. fehlerfrei funktioniert.
    -Es wurde richtig gesagt, daß die angesprungene Rom-Routine vor dem Rücksprung mit RTS noch zwei Bytes in den Speicher schreibt.
    Diese Bytes werden nach 2/3 geschrieben.
    -Die Speicherstellen werden vom Basic-Betriebssystem nicht benutzt und daher tritt im Listing-PostBitte melde dich an, um diesen Link zu sehen. auch keine Fehler auf.

    -Jeder Basic-Programmierer kann das überprüfen.
    z.B. indem er vor dem Aufruf des Lösch-Programms die Speicherstellen 2 und 3 löscht.

    10 :fori=0to200::poke2,0:poke3,0:
    11 :a=49152:b=1000:c=1:gosub30,loeschen
    12 :print;peek(2);peek(3)::next

    Das beweist, daß die zwei Bytes nach 2/3 geschrieben werden.

    Schönen Gruß.

  • Mac Bacon:

    Schönen Gruß an die Assembler-Ecke.

    Mit dem Link auf diesen Thread könnte sich dann übrigens jeder Programmierer selbst ein Bild machen und ausprobieren, wer recht hat.

    Schönen Gruß.

  • ...jetzt müsste die Signatur nur noch ein Link auf diesen Thread sein. :thumbsup:

    Gute Idee, done.

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

  • Habe meine Predigt zu solchen Threads Bitte melde dich an, um diesen Link zu sehen. und etwas angepasst:


    ::BIF UNSER

    Vater BIF, der du bist als BASIC-FAN.
    Geheiligt werde dein BASIC V2.
    Dein POKE komme,
    dein SYS geschehe,
    wie im Direktmodus als auch in einem dreizeiligen Einzeiler.
    Unseren täglich BASIC-Trick gib uns heute und vergib uns unsere BASIC Ahnunglosigkeit,
    wie wir auch vergeben den BASIC V2 Ungläubigen.
    Und führe uns nicht zu Assembler sondern erlöse uns von 38911 Bytes und Garbage Collection.
    Denn dein ist das Zeropage-Gefrickel und das String und der Doppelpunkt in Ewigkeit.

    ::GOSUB10,PRAY:END

    ___________________________________________________________
    Meine Kreationen: 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. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

  • syshack:
    Amen.

    Wenn man vermeiden will, daß die zwei Bytes nach 2/3 geschrieben werden, muß man wie ich schon gesagt habe das Unterprogramm z.B. in den Kassettenpuffer kopieren und mit RTS/Return(96) abschließen.
    Man kann dann das Programm ganz normal, wie gewohnt mit :sys variable: aufrufen.

    0 :rem--a=startadresse
    1 :rem--b=bereichslaenge
    2 :rem--c=loeschcode
    3 :rem--r=intallations/sys-adresse
    9 :
    10 :a=1024:b=1000:c=42:gosub60:end
    19 :
    60 :r=900:gosub64:rem--ram-loesch(a,b,c)
    61 :poke780,c:poke114,b/256:poke113,b-peek(114)*256
    62 :poke89,a/256+peek(114):poke88,a-int(a/256)*256:sysr:return
    63 :
    64 :fori=.to16:poker+i,peek(45762+i):next:poker+i,96:return:--install(r)


    Schönen Gruß.

  • Da die Signatur als zu verallgemeinernd wahrgenommen wurde, hier explizit meine Warnung für den Code aus Posting Eins.
    Dieser Code besitzt Nebenwirkungen, ein Aufrufen in einer anderen als der vom TS dargelegten Weise kann (und wird) zu Fehlfunktionen führen. Auch sonst in einem Basic-Programm legitime Aufrufkonventionen sind hier kontraindiziert, was den Code zum einem Hazardspiel verkommen lässt.
    Ich (und ich bin mir sicher, das Gros der Nutzer hier) teile nicht die Ansicht des TS darüber dass ein (sonst legitimer) veränderter Aufruf eine Änderung des Codes darstellt und somit der Nutzer schuld am Fehlverhalten der Software wäre - denn der Code der den Fehler verursacht steckt in der Routine selbst.

    Ich kann also nur dringend davon abraten diesen Code zu nutzen (zumal Haubitze Bitte melde dich an, um diesen Link zu sehen. einen absolut fehlerfreien, dokumentierten und wohl auch schnelleren Code zur Verfügung stellt).

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

  • Der in Post#111 gepostete Code ist der Orginalcodeteil aus dem DIM-Befehl, der beim DIM-Befehl das Variablenlöschen macht.

    Ich denke mal, daß allgemein bekannt ist, daß der DIM-Befehl keinen Fehler verursacht.

    Auch für Assembler-Programmierer, die die Speicherstellen 2/3 als Sprungvektoren benutzen sollte diese Lösung daher zufriedenstellend sein, weil der Codeteil, der vorher über den Pointer zwei Bytes nach 2/3 geschrieben hat fehlt.
    Das RTS bewirkt einen Rücksprung, bevor der Pointer geschrieben wird.

    Der Haubize-Code benutzt übrigens auch die Speicherstelle 2 für die Übergabe eines Codes an das Assembler-Programm.

    Es ist daher so, daß der Haubize-Code nur Speicherstelle 2 benutzt, während beim BIF-Code-PostBitte melde dich an, um diesen Link zu sehen. die Speicherstellen 2 und 3 benutzt werden.
    In beiden Fällen entsteht aber für Basic-Programme keine Gefährdung.


    Schönen Gruß.

  • Ich bin leider kein Programmierer und kenne mich daher net aus! :nixwiss::gruebel:cry:

    Könntet Ihr das ganze ab PostBitte melde dich an, um diesen Link zu sehen. auch für Laien verständlich schreiben? :winke:ROTFL

    :argue:kill:

    Net zu lange darauf warten, bin nimmer der Jüngste :alt::facepalm:


    lg

    :wurm:

    Ps: Sorry, konnte mich nicht mehr zurückhalten :schande:

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

    .........................................................:thumbsup: ----------> Bitte melde dich an, um diesen Link zu sehen.

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

  • Segi, Du auch in diesem Thread? :wilkommen:

    Also ich halte es für mich hier einfach so: wenn ich nicht verstehe, worum es geht, dann brauche ich es auch nicht. Andererseits, wenn mir bei nem Problem der Schuh drückt und ich finde es hier wieder... dann hab ich in der Regel vorher eine einfachere, wasserdichte Lösung gefunden.

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

  • Segi, Du auch in diesem Thread? :wilkommen:

    Also ich halte es für mich hier einfach so: wenn ich nicht verstehe, worum es geht, dann brauche ich es auch nicht. Andererseits, wenn mir bei nem Problem der Schuh drückt und ich finde es hier wieder... dann hab ich in der Regel vorher eine einfachere, wasserdichte Lösung gefunden.

    Ach, es hat mich einfach in den Fingern gejuckt!
    Wegen der endlosen Diskussion! :D

    Mein Post war ja eh nur "ironisch" gemeint (Verstehen tu ich´s trotzdem nicht)

    Alles von vorne und trotzdem nur das gleiche :saint: "oder selbe?"

    Aber macht ja nix!

    So nebenbei, wenn ich wieder wo ne Sammlung kaufe :bgdev , kann ich da mitlesen :popkorn:

    lg

    :wurm:

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

    .........................................................:thumbsup: ----------> Bitte melde dich an, um diesen Link zu sehen.

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

  • @Segenhard:
    Zur Erklärung:
    -Bei dem Code in PostBitte melde dich an, um diesen Link zu sehen. verwende ich ein ROM-Unterprogramm im DIM-Befehl zum Löschen von Speicherbereichen. Das funktioniert auch sehr gut.

    -Es wurde dann aber von Mac Bacon entdeckt, daß das Unterprogramm vor dem Rücksprung noch zwei Bytes über den Pointer 95/96 in den Speicher schreibt.

    -Ich habe das bestätigt und gesagt, daß diese 2 Bytes in die Speicherstellen 2/3 geschrieben werden. Dort stellen sie für Basic-Programme keine Gefahr dar.
    Und daher dachte ich die Diskussion wäre damit beendet.

    Teil-2:
    -Mac Bacon hat dann allerdings weiter entdeckt, das wenn man statt dem :sys45762: ein :sys variable: ausführt, das dann der Pointer verstellt wird und die 2 Bytes in einen anderen, möglicherweise gefährdenden Speicherbereich geschrieben werden.

    -Ich habe dann das Listing PostBitte melde dich an, um diesen Link zu sehen. veröffentlicht, mit dem auch bei Variablenbenutzung das Schreiben von den 2 Bytes nach 2/3 erfolgt.
    Man mußte einfach :sys v+0: machen. Das Plus Null bewirkt dann, das die Bytes wieder nach 2/3 geschrieben werden.

    -Da aber von Bladerunner weiterhin behauptet wurde, daß eine Programmgefährdung auftritt, habe ich dann schließlich in Post#111 noch eine Variante veröffentlicht, die das ROM-Unterprogramm bei 45762 in den Kassettenpuffer kopiert.
    Das RTS am Ende bewirkt hier ein Rücksprung. Daher werden bei dieser Code-Variante keine 2 Bytes mehr in den Speicher geschrieben und auch die Speicherstellen 2/3 bleiben unverändert.

    -Das sollte eigentlich auch Bladerunner zufrieden stellen.
    Ob es das tut muß man allerdings abwarten.


    Schönen Gruß.

  • Ja, wie lieb und bemüht hier die versucht wird, "diese" Lösung zu verkaufen ... wie Segi selbst bereits gesagt hat und wenn man lesen könnte: es vergebene Müh'.

    @Segi, bei einem der nächsten Stammtische in Wien kann ich dich darüber weiter informieren (vielleicht nicht gleich am 15., aber es kommt sicher die Gelegenheit). :D

  • Bitte melde dich an, um diesen Link zu sehen. wie du in post 111 schreibst kann man die fehler deiner routine umgehen wenn man sie umkopiert.
    nun meine frage warum dann nich gleich ne kleine ASM routine im kasettenpuffer unterbringen und mit sys starten?

    ich frage nur weil ich in BASIC nun mal ne NULL bin.

    salute

    PS: einzigster vorteil waere evtl das die routine kuerzer ist?

  • nun meine frage warum dann nich gleich ne kleine ASM routine im kasettenpuffer unterbringen und mit sys starten?

    Das kann ja jeder... und ich fürchte um nichts anderes geht es hier.

    Geeignete Stellen im ROM direkt zu nutzen ist ja noch ok, aber wenn man sie erst irgendwo ins RAM kopieren und dort noch zurechtpatchen muss, kann man eine vernünftige Routine auch gleich direkt ins RAM schreiben.

    Für jemanden, der kein Assembler kann, sind beide Lösungen gleich kryptisch, ein paar magische Zahlen halt. Für jemanden, der Assembler kann, ist das Lesen des Codes der gebifften Version ungleich komplizierter.