Posts by Mac Bacon

    Um zumindest DIESE Diskussion hier zu beenden hat Zirias jetzt zwei Wochen Zeit zum Nachdenken.

    Dass Du Zirias sperrst, um eine "Diskussion zu beenden", ist leider genau das Verhalten, das Zirias oben - zu Recht - bemängelt.


    Ich gehe davon aus, dass gleich das Argument kommt: "In den NUBs steht aber, dass den Anweisungen der Mods Folge zu leisten ist" - hier wurden aber keine Anweisungen gegeben, denen nicht Folge geleistet wurde.


    Würden Mods bei Kritik - sowohl an sich selbst als auch an anderen Moderatoren - nicht immer gleich den unerträglichen Korpsgeist auspacken, würden solche Konflikte deutlich weniger ausarten.

    First, if I have a printed book, I want to read exactly in this book. No need to use internet for content understanding.


    And second, no one knows how long the link guides to the right content. Internet is changing every second.

    Then print out the "No More Secrets" PDF. As long as there is no final spec for the native mode, duplicating already existing information about undocumented opcodes is just a waste of precious time.

    The section about the unintended opcode SAX seems to confuse two different things:

    The text describes the opcode $cb (which does X = A&X minus arg), but the table holds information about opcodes $83/87/8f/97 (these just store A&X to target address).


    I guess the reason for this mistake is the fact that different sources of information use different mnemonics for the same opcodes, or (as in this case) the same mnemonic for different opcodes.


    As the information on unintended opcodes in this manual is incomplete anyway (and partially out of date), I strongly suggest to remove it completely and just add a link to "No More Secrets" instead.

    The only thing that is then really needed in the manual is a statement like

    "In 6502 mode, the 45GS10 supports the unintended opcodes $0b, $2b, [complete list here].

    It does not yet support the unintended opcodes $02, $12, [complete list here]."

    Mir ist klar das ein C64 Programm nicht (immer) im C128 Modus läuft, aber dass schon das Laden (ohne die Option ,1 !!!) zu Problemen führt, war mir nicht bewusst.

    Nach dem Laden an den Basicstart werden die Programmzeilen automatisch neu verlinkt, denn das Programm könnte ja an einer anderen Adresse gestanden haben, als es gespeichert wurde.

    Überlange Zeilen bzw. eine andere Verletzung der "normalen" Basic-Kodierung könnten dann der Grund für den Aufhänger sein.

    Reports from proof readers are welcome.

    What I have found so far:


    Virtually every instance of implied addressing (1-byte instruction) is described as immediate addressing (2-byte instruction) instead.


    In the 4502 chapter, LDA is described as "undocumented instruction that loads a and x", possibly a copy-and-paste mistake.

    SBC is described as being affected by the status of the D flag. Does this mean the known bug in the 65CE02 is fixed? Then it would no longer be compatible to a real C65.


    In the 6502 section, DEC is said to be able to decrement the accumulator (correct for 4502, wrong for 6502).

    Bleibt die Frage, woher das Sprite kommt, denn das ist beim Nachstellen des "D6-Problems" in VICE ja nicht da. Es muss sich um Sprite 6 handeln (-> D6), es steht an X-Position 320 (256 + 64, da XPOS=64 und das MSB dazu gesetzt ist (stimmt auch mit der Beobachtung überein), die Y-Position ist 64 (-> D6, könnte hinkommen). doppelt breit und hoch könnte auch hinkommen ... die Farbe ist schwarz (64 MOD 16 = 0, passt auch) ... warum wird es in VICE nicht angezeigt?

    Weil die Sprite-Daten aus dem RAM kommen und dessen Einschaltzustand vom Chiptyp abhängt -> vermutlich ist das Sprite auch in VICE sichtbar, nur besteht es dort zufällig komplett aus Nullbits.

    Ich weiß jetzt nicht, wie Mac Bacon s RAM-Test genau testet, aber wenn da der Speicher von $0000 bis $FFFF mit einem Muster gefüllt wird, erkennt man einen Adressierungsfehler unter Umständen nicht.

    Version 3 schreibt direkt nach dem Test eines Bytes bereits den Wert für den nächsten Durchlauf, d.h. sämtliche Adressierungsfehler müssten(tm) erkannt werden.

    Im vorliegenden Fall würde ich langsam anfangen, die PLA zu verdächtigen: Mein Speichertest schaltet ja auf "ROMs und I/O aus, nur RAM aktiv". Wenn in anderen Konfigurationen Speicherfehler auftreten, wäre meine erste Vermutung, dass die PLA evtl. eins der ROMs aktiviert hat oder so...


    EDIT: Schlechte Verbindungen zum Prozessorport und/oder dem Expansionsport ginge natürlich auch.

    Hi!


    Vor einiger Zeit ging es in diesem Thread unter anderem darum, welche Rechenoperationen in BASIC schnell bzw. langsam sind. Um mal ein paar vergleichbare Zahlen zu bekommen, habe ich jetzt ein paar sehr einfache Messungen gemacht, und zwar mit diesem simplen Programm:

    Code
    1. a = 1.23456789
    2. b = 9.87654321
    3. t = ti
    4. for i = 1 to 1000
    5. v = {hier stand der zu messende Ausdruck}
    6. next
    7. print ti - t

    Als "zu messender Ausdruck" stand da dann z.B. "a", "a+b", "a*b", "sin(a)" und so weiter. Ein Großteil der gemessenen Zeit wird natürlich auch von der FOR/NEXT-Schleife verbraucht, weshalb die Ergebnisse entsprechend korrigiert werden müssen. Auch nach einer solchen Korrektur sind die Ergebnisse natürlich nur grobe Näherungen, aber als Diskussionsgrundlage taugen sie allemal. :D

    Hier die Ergebnisse:

    Die erste Spalte zeigt den Ausdruck, die zweite Spalte das unkorrigierte TI-Ergebnis. Die "korrigierten" Ergebnisse in der dritten Spalte wurden errechnet, indem einfach der kleinste Wert aus der zweiten Spalte von ihnen abgezogen wurde: Das FOR/NEXT und die Zuweisung zu "v" sind damit aus der Messung heraus. Natürlich sind jetzt alle "korrigierten" Ergebnisse etwas zu klein, schließlich wird "." nicht wirklich in Nullzeit ausgewertet, aber das schien mir vertretbar.

    In der vierten Spalte wurden die Ergebnisse dann so skaliert, dass "a+b" den Wert Eins erhält, um die einfache Float-Addition als Vergleichswert nutzen zu können.


    Was fällt auf?

    "." ist deutlich schneller als "0" - das dürfte zwar den meisten schon bekannt sein, aber hier sieht man, wie groß der Unterschied ist.

    Variablen-Lookups sind sehr viel schneller als Zahlenliterale - auch das ist klar, denn Zahlen wie 12345 werden vom Interpreter ja erst Stelle für Stelle zusammengerechnet.

    "a" ist deutlich schneller als "USR(a)" - das hat mich sehr gewundert, denn für den USR()-Aufruf habe ich den Zeiger direkt auf ein RTS zeigen lassen. Das übergebene Argument war also direkt auch der Rückgabewert.

    "1e10" ist deutlich schneller als "10000000000".

    RND() braucht mit negativem Argument deutlich länger als mit positivem oder Null.

    LOG, EXP, COS und SIN brauchen so viel Zeit wie 20 Additionen oder 8 Multiplikationen.

    SQR, TAN und Potenzierung brauchen so viel Zeit wie 40 Additionen oder 16 Multiplikationen (wer mit einzelnen Bits hantiert, sollte statt 2^v also lieber ein Array zurechtdefinieren und dann b(v) nehmen).


    Dass SQR so extrem langsam ist, liegt daran, dass der Interpreter gar keine eigene Wurzelfunktion eingebaut hat: Bei SQR(a) rechnet der einfach a^.5, nimmt also die langsame Potenzierungsfunktion.

    Für mich sieht es typischerweise danach aus, als würde der VIC eine falscher RAM Bank ansteuern, so wie es z.b. bei einem defekten CIA U2 passiert?

    Dann wäre das Bild komplett im Eimer. "Ein Teil des Bildes ok und ein anderer Teil nicht" lässt sich nur dann mit falscher VIC-Bank erklären, wenn das Spiel Split-Screen-Grafik mit verschiedenen VIC-Bänken macht. Hier bei Commodore-Soccer ist das aber offensichtlich nicht der Fall, das sieht man z.B. schon daran, dass innerhalb einer Zeile ein Teil ok ist und ein Teil nicht.

    Lustigerweise benutzt Commodore Soccer die unterste VIC-Bank, genau wie das Einschaltbild, welches aber korrekt angezeigt wird. Hast Du den VIC schon in einem anderen Board getestet?

    Ich will das Problem nicht aberkennen, aber das physikalische Prinzip dahinter ist mir nicht klar. Wieso sollte eine dauerhafte mechanische Belastung, in der nichts bewegt wird, zum Reißen des Blechs führen?

    (Hervorhebung von mir)

    Ich nehme an(!), dass die durch die Jahreszeiten verursachten Temperaturunterschiede auch eine gewisse Mitschuld tragen: Einem unbelastenen Blech wären die wohl egal, aber bei Dauerbelastung führen die vielleicht zu einem Emüdungsbruch.


    EDIT: ...und dass $User in jugendlichem Übermut den Hebel mit Schmackes hat hochschnappen lassen, gab es ja auch noch.