Wird ja immer besser. ![]()
Was, glaubst Du, war der Sinn und Zweck von Bitte melde dich an, um diesen Link zu sehen.?
Es gibt 161 Antworten in diesem Thema, welches 22.517 mal aufgerufen wurde. Der letzte Beitrag (
Wird ja immer besser. ![]()
Was, glaubst Du, war der Sinn und Zweck von Bitte melde dich an, um diesen Link zu sehen.?
Mac Bacon:
Anstatt mich raten zu lassen, könntest du das ja mal sagen.
Die Speicherstellen 2/3 sind überigens normalerweise ungenutzt.
Und damit wäre dann geklärt, daß kein Fehler im Programmablauf auftritt.
Schönen Gruß.
herrlich, der Benutzer ist also Schuld wenn er Basic benutzt um eine Basic Routine aufzurufen?
Er hat ja nicht die Routine verändert, nur einen alternativen Aufruf verwendet.
Denn Schuh darfst du dir anziehen,BIF.
Grundsätzlich kann jeder Programmierer den Code auch abändern.
Ich hab das auch mal ausprobiert.
:sys d:
führte bei mir zu einem Re´dimed Array Error.
Das heißt, das der Nutzer eigentlich sofort weiß, daß er was falsch gemacht hat.
Falls jemand doch sys mit Variable benutzen will, sollte er dann das 2. Listing mit
:sys d+0: nehmen.
Schönen Gruß.
Die Speicherstellen 2/3 sind überigens normalerweise ungenutzt.
Und damit wäre dann geklärt, daß kein Fehler im Programmablauf auftritt.
Möchtest Du diese Aussage vielleicht Bitte melde dich an, um diesen Link zu sehen.
Zitat von Memory MapHex: $03-$04 Dez: 3-4 Inhalt dez/(Adresse,Hex))170,177 ($B1AA) Vektor für Umwandlung Fließkommazahl nach Ganzzahl (Low/High-Byte)
Grundsätzlich kann jeder Programmierer den Code auch abändern.
Ich hab das auch mal ausprobiert.:sys d:
führte bei mir zu einem Re´dimed Array Error.
Das heißt, das der Nutzer eigentlich sofort weiß, daß er was falsch gemacht hat.Falls jemand doch sys mit Variable benutzen will, sollte er dann das 2. Listing mit
:sys d+0: nehmen.Schönen Gruß.
Er weiss vielleicht wo was schieflief, aber nicht was, da Re'dimed Error nunmal nichts direktes mit dem Fehler zu tun hat. Und nicht der Nutzer hat was falsch gemacht. Der Code ist einfach murksig.
Man kann ja von einem Endanwender nicht erwarten dass er sonst gültige Sprachkonzepte nicht verwendet. Und noch weniger dass er bei einem dann auftretenden Fehler denkt "Oh, das hab ich falsch gemacht, das hätte mir aber doch auffallen müssen dass der gottgleiche BIF-Code hier ein Literal erwartet!"
Aber was red' ich eigentlich, Du würdest es selbst dann nicht einsehen wollen dass der Fehler bei dir liegt wenn Du der letzte Mensch auf Erden wärst.
Möchtest Du diese Aussage vielleicht Bitte melde dich an, um diesen Link zu sehen.
Die beiden Zeiger bei Adresse 3 und Adresse 5 werden zwar von Kernal/Basic mit gültigen Werten vorbelegt, diese Zeiger werden aber meines Wissens vom ROM-Code gar nicht benutzt. Da können also wirklich nur dann Probleme auftreten, wenn das eigene Programm über diese Zeiger springt. Gedacht ist das Feature vermutlich für eigene USR()-Routinen, da für Input und Output der Fließkomma-Akku benutzt wird, die eigene Routine aber evtl. lieber mit Integers arbeitet.
EDIT: Bevor sich das $jemand als Erfolg auslegt: Das Überschreiben der Speicherstellen 2 und 3 ist eine Sache; die Verwendung des nur unter Nebenbedingungen entsprechend initialisierten Pointers $5f/$60 ist etwas völlig anderes. Wenn man diese Tatsache ordentlich dokumentiert hätte, ja dann...
Also gut, dann gebe ich zu, daß ich mit der Dokumention dieses Nicht-Fehlers noch nicht so weit war.
Schönen Gruß.
naja also da wir hier ja in der basic ecke sind und es um Loeschen mit SYS geht mal mein drecks code dazu,
0 c=0:a=0:rem hilfsvariablen
1 ad=49152:rem startadresse routine
2 rem routine installieren
10 for i=0 to 28:read a:c=c+a
20 poke ad+i,a:next
30 read a:if c=athen print"ok!"
40 data 165,2,160,0,166,254,240,10,145,251
50 data 200,208,251,230,252,202,208,246,166
60 data 253,240,6,145,251,200,202,208,250,96,5207
69 rem routine aufrufen
70 poke 2,0:rem setze loeschzeichen
80 poke 251,0:rem setze low startadresse
90 poke 252,6:rem setze high startadresse
100 poke 253,64:rem setze low laenge
101 poke 254,0:rem setze high laenge
102 sys 49152:rem rufe routine auf
Alles anzeigen
wie man sieht geht das super einfach und schnell, und das auch in BASIC!
nachteil man muss die routine erst installieren und
aufpassen das man sie nicht loescht wenn man einen teil
des speichers loescht.
vorteil sie kann ueberall im speicher liegen(ausser unter den roms)
und ist nur 29bytes lang.
salute
wie man sieht geht das super einfach und schnell, und das auch in BASIC!
Sehr schön, ich liebe reine BASIC-Lösungen.
Respekt, so sollte das sein. Sauber, gut dokumentiert, frei von Sideeffects. DAS ist mal ein hilfreiches Stückerl Code. ![]()
![]()
Sehr schön, ich liebe reine BASIC-Lösungen.
![]()
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ß.
Jetzt hab ich mir den Thread erst im Nachhinein reingezogen, also in Gesamteindruck komprimiert und in der Tat immer das gleich Bild:
BladeRunner, MacB weist in einer Eselsgeduld, und auch respektvoll, ohne jede Untergriffe auf all die Probleme und Risiken hin, die BIF mit seinen Postings hervorruft und in Verweigerung auch nur im Ansatz die Hinweise aufzunehmen, wird in einer unverständlichen Abwehrhaltung ständig versucht sich rechtzufertigen oder die Schuld anderen zuzuweisen. Auch wenn ByteBreaker das zu relativieren versucht, es ändert sich grundsätzlich daran nichts.
Das Forum ist gewissermaßen ein öffentlicher Raum und auch ein sozialisierter Bereich, der auch eine Norm vorgibt. Wenn man diese nicht einhält, ist mit entsprechenden Reaktionen, wie in diesem Thread zu rechnen. Hier als Einzelperson der Community die eigene Sichtweise aufzwingen zu wollen, sich selbstherrlich darzustellen, ist noch in keiner Gesellschaft gut angekommen. Wenn man als Sägengeiger Popstar werden will, dann nützt es nichts der Welt vorzuwerfen, sie sei Schuld daran, dass es nicht klappt, weil man ja die Qualität des Sägengeigens nicht erkennt ... (ja, das spiegelt nur Teilaspekte dieses Threads wider, schon klar).
Aber das ist ja nichts Neues, dass immer wenige eine ganze Gruppe durch abweichende Verhaltensweisen "beschäftigt" und integrative Maßnahmen sich einer gewissen Norm unterzuordnen, manchmal - zumindest in diesem Fall - nicht fruchten.
@ Haubitze
+1
Wie wandelt man eigentlich Assembler Code in DATAs um?
Man müsste sein PRG in den Speicher laden und dann die Bytes auslesen und dezimal ablegen, kommasepariert, mit "DATA" Einschub alle 40 Werte.
Gibt es sowas schon?
Ja, sowas gibt es, hab aber grad keinen Link zur Hand. Notfalls nach "Datazeilengenerator" googlen.
Hier im Forum wurde das Thema mal kurz behandetl:
Bitte melde dich an, um diesen Link zu sehen.
Wie wandelt man eigentlich Assembler Code in DATAs um?
Der passionierte BASIC-Profi gibt die DATA-Zeilen aus dem Kopf ein.
Der Basic Profi kennt also die 6502-Opcodes und rechnet sie samt Parametern byteweise im Kopf um.
Ich dachte, dafür muss man Assembler-Profi sein. ![]()
Danke für den Link, den Beispiel-Source darin passe ich mir an.
Du wirst lachen, ich hatte einen in der Schule der hat exakt so programmiert:
Rechner an, Monitor gestartet, Hexcodes reingehämmert, laufen lassen.
Und erstaunlicherweise lief das in der Regel fehlerfrei. Der Typ war echt spooky.
![]()
Krass. Es ist auch so interessant zu sehen, wie viele sehr junge Leute es gab, die die neue Technologie in den 80er Jahren durchdrungen und beherrscht haben. Die haben mit 16 Jahren mit der Hardware Sachen gemacht, das hätten damals auch Informatik-Profs nicht geblickt. Zumal man bis in die 90er Informatik studieren konnte ohne einen Rechner auch nur anzufassen.
Diese brillante Jugend von damals scheint es heute nicht mehr zu geben. Die Genies von damals arbeiten heute bei DICE (Battlefield 1), bei NVIDIA oder sonstwo hochdotiert.
Die Jugend heute kennt nur noch geschlossene Systeme zum wischen und tippen. Bleibt zu hoffen dass u.a. der Raspberry Pi diesen Verdummungs-Trend wirksam abfängt.