Das ist eigentlich nur die übliche Formulierung.
Nein.
Wenn man sich schon Jahrzehnte damit beschäftigt hatte,
...ist das immer noch nicht zu spät, um dazu zu lernen.
Posts from Mac Bacon in thread "Heute so gecodet..."
-
-
Dabei bin ich mir auch noch nicht sicher, ob das die beste Umwandlung ist:
Ich glaube nicht...
Steck da mal "A=$0f" rein. Liege ich richtig mit meiner Annahme, dass da ein unsigned-8-Bit-Integer (in A) zu zwei BCD-Bytes gewandelt werden soll?"hex" ist eine Darstellungsform, der Inhalt eines Registers kann als hex dargestellt werden, aber er ist nicht "hex".
-
Ist natürlich eine CBM 2031, war ein typo.
Ok, danke.
2030 ist mir nicht bekannt, so wurde aber wohl diese Serie benannt:
Quote[...] CBM 2030 series [...]
A singe drive model (CBM 2031) costs $595 for 130K bytes of storage.
The CBM 2030 Series drives, initially developed by Shugart Assiciates and Matsushita, use the same media as Commodore's 340K byte CBM 2040 drive for read-compatibility [...]
Da ist es wieder: In der Ankündigung der Serie steht was von "130K bytes", aber das tatsächlich erschienene 2031-Laufwerk benutzt doch das gleiche 170k-Format wie die 1541 und die 4040, also das Format mit "2A" im Header und 683 Blöcken.
In den original-Commodore-DOS-Sourcecodes, die Michael Steil auf github gestellt hat, gibt es irgendwo eine Konstantendefinition in der Art von "FORMAT2030='B'". In der Entwicklungsabteilung von Commodore scheint es dieses ominöse 130k-Format also wohl tatsächlich gegeben zu haben - und ich wüsste wirklich gerne ob jemals ein entsprechendes Produkt auf den Markt gekommen ist.
-
Ein kleiner Gehilfe bei der Reparatur einer CBM 2030
War das ein Tippfehler oder geht es wirklich um das Laufwerk mit dem "2B"-Diskettenformat, über das man fast gar keine Informationen im Netz findet? Mich interessieren die Eckwerte des Formats, d.h. Gesamtzahl Blöcke, Blöcke pro Spur, etc.
-
Unfassbar: ich habe das erste Mal in meinem Leben die (zp,x) Adressierung verwendet
Pics or it didn't happen!
-
Gibt es dazu eine Erklärung, warum das so ist? Ich würde es gerne verstehen wollen.
Need more info.
Dann ging der eigene Charset nicht mehr...
War einfach ein Datenmüll-Charset aktiv? Oder ist das Programm abgeschmiert? Bei Fehlern mit $01-Banking kann es sein, dass man Daten in die I/O-Chips statt in das RAM "unter" den I/O-Chips kopiert.
Oder es liegt an der Position der Kopierschleife im Programm: Hast Du den ganzen Code-Teil verschoben oder nur ein JSR verschoben? Gerade bei sehr obskurem Fehlverhalten kann man so einen Bug "beheben", obwohl man ihn in Wirklichkeit nur verschleiert hat...
-
C zeigt das Ergebnis für unsigned-Vergleiche, N zeigt das Ergebnis für signed-Vergleiche.
Stimmt nicht! Das konnte ich jetzt schon irgendwo lesen. Denn:
$7F (127) - $80 (>-128) = $FF (N=1)
$01 (1) - $FF (>-1) = $02 (N=0)
Ja. Kurz gesagt: Das N-Flag enthält einfach das Vorzeichen des Ergebnisses (also dessen Bit 7), nachdem das Ergebnis auf acht Bits zurechtgestutzt wurde.
Oder anders ausgedrückt: Wenn man das Register mit dem Argument vergleicht, dann ist danach N genau dann gesetzt, wenn das Argument einer der 128 Werte ist, die auf den Registerwert folgen. Ist das Argument aber der Registerwert selbst, oder einer der 127 Vorgängerwerte, dann wird N gelöscht.
Wenn man sich das Verhalten der Flags tabellarisch darstellt, dann bildet N einen diagonalen Streifen, während C ein Dreieck inklusive der Hauptdiagonale belegt.
-
Ich dachte immer, dass bei CMP das C-Flag immer das N-Flag in invertiert ist, aber nein!
Das wäre ja Verschwendung teurer Transistoren.
C zeigt das Ergebnis für unsigned-Vergleiche, N zeigt das Ergebnis für signed-Vergleiche.
-
Nein, eher nicht.
Der Meinung bin und bleibe ich sehr wohl.
Mein Beitrag bezog sich auf das, was ich zitiert hatte (und was Du in Deiner Antwort weggelassen hast): Nämlich dass man von "viele geschachtelte Klammern" auf "man muss häufiger zwischenspeichern" rückschließen könne - und das stimmt nun mal nicht.
Welche Art der Auswertung Du in Deinem Programm bevorzugst und ob das irgendwie kürzer oder schneller oder lesbarer geht, ist dafür völlig unerheblich.
-
Allein die vielen geschachtelten Klammerpaare lassen erahnen, dass man häufiger zwischenspeichern muss.
Nein, eher nicht. Ein Ausdruck wie A + (B * (C + (D * (E + (F * (G + (H * I))))))) mag kompliziert aussehen, lässt sich aber - wenn man von innen nach außen rechnet - auf Assembler-Ebene ganz leicht sequenziell verarbeiten.
Deine Beispiele im Vergleich:
(WO AND WU) OR (WR AND WL) OR (WL AND WO AND RU) OR (WO AND WR AND LU) OR (WR AND WU AND LO) OR (WU AND WL AND RO)
Hier berechnet man die ersten fünf Klammerausdrücke und speichert die fünf Ergebnisse ab. Dann berechnet man den sechsten Klammerausdruck und fährt direkt fort, indem man die fünf zuvor gespeicherten Ergebnisse aufODERt.
Jetzt die optimierte Variante (der aktuelle Rechen- und Speicherschritt ist unterstrichen):
(WU AND WL AND RO) OR (WO AND ((WR AND LU) OR WU OR (WL AND RU))) OR (WR AND (WL OR (WU AND LO)))
Schritt 1:
(WU AND WL AND RO) OR (WO AND ((WR AND LU) OR WU OR (WL AND RU))) OR (WR AND (WL OR (WU AND LO)))
Schritt 2:
(WU AND WL AND RO) OR (WO AND (TEMP1 OR WU OR (WL AND RU))) OR (WR AND (WL OR (WU AND LO)))
Schritt 3:
TEMP2 OR (WO AND (TEMP1 OR WU OR (WL AND RU))) OR (WR AND (WL OR (WU AND LO)))
Nach dem Speichern von nur drei Zwischenergebnissen liegt die Formel dann bereits in dieser Form vor:
TEMP2 OR TEMP3 OR (WR AND (WL OR (WU AND LO)))
Die kann man jetzt von innen nach außen in einem Rutsch ausrechnen.
-
Es muss zwingend ein Vorzeichen im String sein und die Zahl hinter dem Vorzeichen muss zweistellig sein, also 04 statt 4.
Was eine ordentliche Doku doch alles ausmacht.
Irgendwas stimmt aber trotzdem nicht: "9e+02" wird auch mit der eingefügten Null noch zu "90.000".
-
Ich finde diese E-Notation zwar schön kurz und nett, dass Basic das kann, aber die Schreibweise ist so gar nicht anschaulich. Eine Zahl mit vielen Nullen, bzw. mit vielen Stellen vor oder nach dem Komma beeindruckt einen und man hat ein Gefühl für Riesigkeit und Winzigkeit einer Zahl. Dieses Gefühl habe ich beim Betrachten der E-Notation überhaupt nicht. Ich muss so viel darüber nachdenken, was diese e-Zahl mir nun "in echt" sagen will, dass ich die Zahl an sich gar nicht mehr beeindruckend finden kann.
Mag sein, aber sobald man zwei Zahlen vergleichen will, kehrt sich das um: Zum Beispiel sieht man sofort, dass 1e38 das exakt Tausendfache von 1e35 ist. In Dezimalschreibweise müsste man Stellen zählen oder die Zahlen untereinander anordnen, um das zu sehen.
Außerdem ist die Exponentialschreibweise ein guter Einstieg in das Verständnis der Fließkommaarithmetik und der signifikanten Stellen - etliche Dezimalstellen gaukeln stattdessen eine Genauigkeit vor, die das interne Zahlenformat des Computers gar nicht bietet.Daneben nochmal ein Extra-Programm (econ.prg), indem man entweder Dezimalzahlen eingibt oder E-Zahlen und dann ein Umrechnungergebnis erhält.
- Bei negativen Zahlen erscheint in der Dezimaldarstellung das Minus zu spät (Eingabe "-9e-9").
- Exponenten ohne Vorzeichen funktionieren nicht richtig (Eingabe "9e9") - den Zwang zu Vorzeichen kann man natürlich in die Doku schreiben, aber Basic akzeptiert solche Eingaben, daher war ich etwas verwundert.
- bei kleinen Exponenten funktioniert manchmal die Dezimaldarstellung nicht (Eingabe "9e+2"), es werden zuviele Stellen angehängt.
- ...und als Trennzeichen würde ich statt '.' eher ein Leerzeichen vorschlagen: mit zwei verschiedenen Bedeutungen für das gleiche Zeichen kommt man sehr schnell in Teufels Küche. -
Code
if ( false===$stmt ) { $this->error("Query Error !".htmlspecialchars($mysqli->error)); } $stmt->bind_param($param,$strings);Bricht der Aufruf von error() das ganze Skript ab? Ansonsten ergäbe die nächste Zeile einen Fehler.
Und die anderen beiden if-Blöcke überprüfen vermutlich falsche Bedingungen... Copy/Paste-Fehler? -
Tja, es gibt schon Injection und Exploit-Beispiele wie hier: Please login to see this link.
Die verlinkte Seite zeigt aber doch gerade, warum prepared statements vor Injections schützen. Häh?!
-
Zwar nicht heute, sondern vor vielen Jahren gecodet, aber dank der hier erwähnten Bezier-Kurven wurde ich wieder dran erinnert: Ich hab mal ein Malprogramm in Basic7 geschrieben, und irgendwann hab ich versucht, sowas wie Bezierkurven einzubauen.
Das Programm ist ganz fürchterlich und sollte von niemandem angesehen werden, herunterladen auf eigene Gefahr.
Nach dem Starten der Datei "Hirespaint V3" werden die anderen Dateien nachgeladen. Man kann es mit einem Joystick in Port 2 steuern, besser ist aber eine 1351-Maus in Port 1. Wenn man einen Joystick benutzt, ersetzt die Esc-Taste die zweite Maustaste.
Diverse numerische Zusatzeingaben werden über die X-Position des Pointers gemacht, unter anderem auch die Farbwahl (fragt nicht, man muss halt die Basic7-Farbnummern kennen
).Fast alle Zeichenfunktionen basieren auf den entsprechenden Basic7-Anweisungen (Box, Circle, Draw, etc.) mit dem Unterschied, dass das Programm eine Assembler-Unterroutine als ständiges "Undo" benutzt, so dass man eine Art Gummibandfunktion erhält - wenn auch extrem langsam. Zusätzlich zum sichtbaren Bild hält das Programm vier weitere Bildpuffer im Speicher, davon wird Nummer vier für das Undo gebraucht.
Am Anfang sollte man einmal "Clear" anwählen, damit der Grafikbildschirm gelöscht wird.
Bei der Funktion "Bezierkurve" setzt man dann mit dem ersten Klick den Startpunkt, mit dem zweiten Klick den Endpunkt und mit allen folgenden Klicks verändert man abwechselnd die Positionen der beiden Kontrollpunkte.
Im Gegensatz zu einer echten Bezierkurve muss man die Kontrollpunkte allerdings ca. 1,5-mal so weit entfernt setzen (ich könnte es geometrisch erklären... ...aber ich lasse es lieber ).
Hat die Kurve die gewünschte Form, muss man mit der rechten Maustaste (oder eben ESC) abbrechen.
Ich hab mir den Code jetzt nicht mehr näher angesehen, aber wenn ich mich recht erinnere, wird die Kurve einfach nur durch 2*16 Liniensegmente angenähert, wobei die Mitte zwischen den beiden Kontrollpunkten einen zusätzlichen Kurvenpunkt definiert und die beiden Hälften der Kurve jeweils als "in den Raum gedrehter Viertelkreis" beschrieben werden können.Eine echte Bezierkurve wäre auch interessant, aber dafür sollte man vielleicht nicht unbedingt Basic benutzen...
-
Hätte ich in der SB geschrieben: "Vergiss es, mit SQL ist es ein Einzeiler" wäre ich in der Luft verrissen worden
Die biffige Lösung da oben ist ja durchaus interessant (Matrixmultiplikation etc.), aber auf lange Sicht tut man $Leuten einen größeren Gefallen, wenn man ihnen das Angeln beibringt statt das Gammelfisch-zu-Labskaus-verarbeiten.
-
Für die "too long, didn't read"-Fraktion:
[...] In SQL wäre das alles einfach [...]
-
Na, wenn die Koordinatenpunkte "zwischen" den Pixeln liegen, dann liegen horizontale und vertikale Linien ebenfalls "zwischen" den Pixeln. Welche Pixel soll man da setzen? Und wenn man sich für sowas wie "im Zweifel links oben" entscheidet, dann hat man Probleme mit sehr flachen und sehr steilen Linien - die würden dann aus zwei Segmenten bestehen, aber eines der Segmente bestünde nur aus einem einzigen Pixel und das andere Segment aus allen anderen.
-
Warum die theoretischen Koordinatenpunkte in die Mitte der realen Pixel gesetzt werden (und nicht "zwischen" die Pixel), wird klar, wenn man horizontale oder vertikale Linien zeichnet...
-
Mit diesen Änderungen in 55 bis 65 gehts aber wie gedacht:
Mein ursprüngliches Python-Programm hat auch die Größe jeder Lücke in Pixeln ausgegeben, aber für die C64/Basic-Version war die Aufteilung in "common gap size" und die kompakte Liste aus Nullen und Einsen durchaus Absicht. Ich hätte vielleicht erklären sollen, wie man die Ausgabe lesen muss...
