Wurde jemals eine 6502 ohne "JMP indirect bug" gefertigt?

Es gibt 23 Antworten in diesem Thema, welches 2.433 mal aufgerufen wurde. Der letzte Beitrag (11. Mai 2024 um 15:44) ist von goloMAK.

  • Ich habe gerade beim Schmökern in dem Buch "Anwendungsbeispiele für den Mikroprozessor 6502" von Herwig Feichtinger aus dem Jahr 1980 von dem - heute bekannten (nur mal als Beispiel Bitte melde dich an, um diesen Link zu sehen. oder Bitte melde dich an, um diesen Link zu sehen.) - aber zu dieser Zeit wohl noch eher nicht so publizierten Bug der 6502 bei indirektem JMP (Opcode $6C) gelesen:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Internet gab es im Jahr 1980 bekanntlich ja noch nicht und solche Infos waren natürlich viel wert, wenn man beim Programmieren der 6502 genau an sowas hängen geblieben ist. :prof:


    Meine Frage hierzu wäre zum letzten Satz im Text:

    Gab es später dann mal 6502 mit der erwähnten Maskenänderung, die diesen Bug beseitigt hat, oder war der Bug auch weiterhin in allen 6502 mit drin? Weiß da jemand was dazu, wie die Fertigung der 6502 damals fortgesetzt worden ist?

  • Gab es später dann mal 6502 mit der erwähnten Maskenänderung, die diesen Bug beseitigt hat, oder war der Bug auch weiterhin in allen 6502 mit drin?

    Beim NMOS-6502 gab es meines Wissens nach keine Maskenänderung dahingehend mehr.

    Die CMOS-Varianten haben den "Bug" nicht mehr, WIMRE.

  • Ja, soweit mir bekannt, blieb das unverändert, denn es wurde logischerweise mit in die Compiler/Assembler übernommen (sprich die nutzten nur die Werte bis FE) und "gute" Disassembler kannten wohl den Sonderfall und zeigten es vermutlich korrekt an.

    Daher gibt es vermutlich auch für die C-Mos-Varianten nur wenig Code, der ein möglicherweise dort korrigiertes Verhalten nutzt (denn mit Nutzung eines entspr. Schalters im Compiler/Assembler hätte man ja bewusst die Kompatibilität zu den klassischen 6502 aufgegeben), aber man kann sich damit (wie auch mit jeder anderen Abweichung) eine Erkennung auf welcher CPU-Variante man gerade "unterwegs" ist implementieren :wink:

    Bleibt die Frage: wurde es wirklich in den C-MOS-Varianten korrigiert?

    Denn das hätte ja -im Umkehrschluss- eine Inkompatibilität dann zur Folge gehabt, wenn dieser Befehl auf 6502 bewusst genutzt wurde. Also im obigen Beispiel 6C FF 03 gecodet wurde, um ABSICHTLICH nach den "getrennt" in 03FF/0300 gespeicherten 16bit-Vektor zu springen. *)

    Damit hätte man also als Programmierer ein Werkzeug, um eine Ausführung auf nem C-MOS-Derivat definitiv zu verhindern...


    *) OT: Als reine 8-bit Architektur war ja auch die Lage im Speicher "alignment", sprich ob der Vektor auf even-odd oder odd-even lag zunächst egal, bei vielen 16bittigen Architekturen wurde so was (also Start auf odd) auch für deren "Schmalspur"-Ableger mit extern nur 8bit Bus natürlich verhindert, da man es hätte gesondert behandeln müssen im eigentichen Core.

    OT2: "Feichtinger"? Ist das wohl der gleiche Feichtinger, der so rein textbasierte Seiten zu alten (commodore-) Computern gehostet hat, über die man immer wieder mal bei Google-Suche stolpert und darüber wohl auch ne Weile mal nen "Abverkauf" seiner Bestände gemacht hatte, es dann aber als Art "Archiv" hat stehen lassen, oder spielt mir da mein Gedächtnis jetzt einen Streich?

    siehe hier: der o.g. Autor war wohl auch Chefredakteur der MC und "Erfinder" der EMUFs: Bitte melde dich an, um diesen Link zu sehen.

    War mir jetzt nicht mehr so bewusst, weiß nur, das auch RDK (Rolf-Dieter-Klein) viel in der MC publiziert hatte zu der Zeit...

    der dort gezeigte "kleinere Formfaktor" EMUF mit 80C537 von Siemens, erinnerte mich sehr an das damals in der Industrie weit verbreitete und erfolgreiche MiniMod537 der Firma Phytec, das jedoch schon auf smd basierte und nochmals etwas kleiner (vorallem schmäler wohl ) ist. Das war wohl somit auch (vom Formfaktor/Konzept her) Urahn aller Raspis und Arduinos heutzutage...

  • a) Das ist kein Maskenfehler. Der Prozessor hat, soweit ich Michael Steil und visual6502 richtig verstanden habe, schlicht keine Möglichkeit, das High-Byte zum Inkrementieren nochmal aus dem Adresspuffer in die ALU zu holen. Man hätte den Chip umkonstruieren müssen, und das wollte/konnte bei MOS nach dem Weggeag von Peddle und Mensch niemand mehr machen. Fußnote im Handbuch war da billiger...

    b) Der 65C02 war ursprünglich ein in-House-Produkt von Rockwell für ihre Mocem-Chipsätze. Da war Kompatibilität wurscht, wie Mensch kürzlich mal erzählt hat, und da er den Chip für den CMOS-Prozeß eh komplett neu aufbauen mußte, hat er halt gleich gründlich aufgeräumt. Manche 'Verbesserungen' hat Rockwell sogar wieder zurückgenommen...

    c) Compiler auf dem 6502 waren ja nicht gerade häufig, und Assembler kenne ich auch keine, die eine Warnung geworfen hätten... vielleicht sowas wie der All-Prozessor-Assembler AS oder irgendwas nach der Jahrtausendwende, das sich an Leute wendet, die den Befehlssatz nicht wie DAS EVANGELIUM auswendig können.

    d) Feichtinger war einer der 'großen Namen' bei Franzis. Ich hätte ihn aber mehr in die 'Elektronik-Ecke' verortet? Siehe a)...

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

    Einmal editiert, zuletzt von mc71 (10. Mai 2024 um 07:11)

  • Ja, soweit mir bekannt, blieb das unverändert, denn es wurde logischerweise mit in die Compiler/Assembler übernommen (sprich die nutzten nur die Werte bis FE)

    Aha?

    Kennst du einen Assembler, der sich geweigert hat, ein "JMP ($03FF)" zu übersetzen?

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Geweigert nicht, aber ne "warning" kam zumindest bei einem der Assembler, die ich damals in der Hand hatte, welcher genau das war? 35 Jahre (oder mehr) her...

    Aber es geht doch mehr drum, ob ein Compiler oder auch eigenständiger (Makro-)Assembler SELBST diese kritischen Adressen gewählt hätten *) und ob ihnen die Konsequenz bekannt war, sprich ob dann in der memory-map auch 300 und 3ff dafür als belegt galten oder eben fälschlicherweise 3ff und 400 mit Absturz/Fehlverhalten als Konsequenz.

    Kann mir NICHT vorstellen, das sowas Elementares NICHT abgefangen worden wäre in solchen Produkten...

    Und wäre es im Chip/Maske korrigiert worden, dann hätte in Konsequenz JEDER Compiler/Assembler nach dem GENAUEN Target fragen müssen und DAFÜR hätte es auch ein unterscheidbares Marking der CPUs gebraucht, sowas ist mir aber nicht bekannt, das A/B/C dahinter steht bekanntlich für 2/3/4 Mhz maximaler Frequenz, aber die funktionieren austauschbar auch in ältesten 1MHz-Geräten, dem wäre ja auch nicht so, wenn das geändert worden wäre...

    Insofern war mein logischer Schluss draus, dass es keine solche Änderung gegeben hat, das deckt sich -für NMOS- auch mit Aussagen diesbezüglich von Leuten wie androSID, die sich die Chips im Detail angesehen haben.

    *) Besser ist natürlich, man hält sich konsequent an ein korrektes Alignment und nutzt somit im Falle der 6502 nur gerade Adressen als Vektoradresse für ind. Sprünge, dann passen auch 128 Vektoren konfliktfrei auf eine Speicherseite.

    Und so war das auch zu verstehen und nachdem auch hinter nem Compiler üblicherweise ein Assembler "werkelt", wenngleich nicht unbedingt separat aufrufbar/nutzbar, hatte ich das so formuliert.

  • aber zu dieser Zeit wohl noch eher nicht so publizierten Bug der 6502 bei indirektem JMP (Opcode $6C) gelesen

    Täusch ich mich, oder betrifft der Bug nicht im Allgemeinen die indirekte Adressierung? Am Einleuchtensten ist dieser Bug mit diesem Befehl beschrieben:

    LDA ($FF),Y

    benutzt $00/$FF.

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Nun ja, das ist doch eh logisch, dass man Sprung Tabellen an geraden Adressen anlegt.

    Die Intel 8086 kann ja 16 Bit Argumente auch nur von geraden Adressen fetchen.

    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.

  • Bei den ZP-internen Indizierungen ist das ja genauso, dass da die Page nicht verlassen werden kann. Bei indirekt X-indizierter Adressierung hat man den Effekt sogar gleich zweimal, einmal beim X-Aufschlag und dann nochmal bei der resultierenden Adresse. ($F8, [7]) steuert die Adresse in $FF/$00 an (Containeradresse wrapt), und ($FE, [7]) landet bei $05/$06 (Index wrapt). Für ein Problem halte ich das nicht.

    Aber auch nicht, was das JMP() betrifft, sofern man die Ausnahme kennt. Zur Not kann man im Assembler die Liste der Zieladressen auf 2 "alignen", damit der Effekt nicht greifen kann. Darum würde ich das nicht mal als Bug bezeichnen, sondern als fehlendes Feature, weil man es seinerzeit sicherlich ganz bewusst weggelassen hat, wie mc71 schon sagte. Denn bei anderen Indizierungsarten, wo die Berücksichtigung eines seitenübergreifenden Zugriffs wichtiger ist, hat man es wiederum bewusst eingebaut und kostet dann natürlich auch etwas mehr Zeit in der Ausführung.

  • Bei den ZP-internen Indizierungen ist das ja genauso, dass da die Page nicht verlassen werden kann. Bei indirekt X-indizierter Adressierung hat man den Effekt sogar gleich zweimal, einmal beim X-Aufschlag und dann nochmal bei der resultierenden Adresse. ($F8, [7]) steuert die Adresse in $FF/$00 an (Containeradresse wrapt), und ($FE, [7]) landet bei $05/$06 (Index wrapt). Für ein Problem halte ich das nicht.

    Hier kann man sich auch streiten, ob das überhaupt ein Bug ist. Wenn ich Zeropage-Adressierung benutze, wieso sollte dann ein Zugriff auf eine Speicherstelle außerhalb der ZP entstehen?

    Ja, das ist nicht gradlinig, aber das Wrap-Around ist hier zumindest ansatzweise nachvollziehbar. Ich hätte hier tatsächlich nie erwartet, dass er auf $100 zugreift, wenn ich LDA ($FF),Y nutze. Mein Mentales Modell erlaubt das Verlassen nicht.

    Aber die Meinungen gehen hier auseinander. Es wäre gut gewesen, wenn es MOS von anfang an richtig dokumentiert hätte, wie es gemeint ist.

    Das JMP-Indirekt-Verhalten ist hingegen ziemlich sicher ein Bug. Wir Mir fällt zumindest keine Argumentation ein, wie man das Verhalten als Soll-Verhalten definieren könnte.

  • Nun ja, das ist doch eh logisch, dass man Sprung Tabellen an geraden Adressen anlegt.

    Die Intel 8086 kann ja 16 Bit Argumente auch nur von geraden Adressen fetchen.

    Das mag logisch zwingend sein für >=16 Bit Prozessoren... aber bei eine Möhre wie dem 6502 ist es völlig Wurst.

  • Das JMP-Indirekt-Verhalten ist hingegen ziemlich sicher ein Bug. Wir Mir fällt zumindest keine Argumentation ein, wie man das Verhalten als Soll-Verhalten definieren könnte.

    Das sehe ich genau so. Das ist für mich ganz klar ein Fehler und unerwünschtes Verhalten.

    Und ich dachte mir beim Lesen der Zeilen im Buch, ähnlich wie Ruudi , dass eine nachträgliche Änderung (Korrektur) nicht ganz unproblematisch wäre. Gerade damalstm wurde ja oft "mit jedem Byte getrickst" und der Fehler ist vielleicht sogar von manchem Programmierer bewusst ausgenutzt und verwendet worden. Wenn dann nachfolgende 6502 sich in dem Punkte anders (im Prinzip korrekt) verhalten, dann hakt es im Programm.

  • unerwünschtes Verhalten

    Von mir ist es durchaus erwünscht, da ich diesen seltenen Fall allein schon deswegen umgehen würde, weil der noch einen TZ mehr bräuchte; sonst kann ich ja gleich auf Z80 umsteigen. ;)

    Aber dafür wurden wahrscheinlich ein paar Transistoren und ein paar Dollar gespart. Ich glaube jedenfalls nicht, dass es ein Bug im Sinne eines versehentlichen Fehlers ist, sondern, dass vielmehr das Weglassen der Berücksichtigung der Page-Überschreitung bewusst geschah, aus Prioritätsgründen. Der Mann (oder die Frau, wie bei Acorn) stand am Reißbrett und machte sich über jeden Befehl Gedanken, und dazu gehört auch der Umgang mit Page-Überschreitungen. Ich denke, übersehen kann man so etwas dabei gar nicht. Vielleicht gibt es dazu noch irgendwo ein Statement von Chuck Peddle.

  • Von mir ist es durchaus erwünscht, da ich diesen seltenen Fall allein schon deswegen umgehen würde, ...

    Es geht ja nicht darum, ob du ihn verwendest. Es geht noch nicht einmal darum, ob ihn irgendjemand verwendet. Es geht darum, dass er nicht das tut, was er tun soll, falls ihn mal jemand verwendet. Er zeigt eben in dem Fall ein falsches Verhalten. :)

  • Der Mann (oder die Frau, wie bei Acorn) stand am Reißbrett und machte sich über jeden Befehl Gedanken, und dazu gehört auch der Umgang mit Page-Überschreitungen. Ich denke, übersehen kann man so etwas dabei gar nicht. Vielleicht gibt es dazu noch irgendwo ein Statement von Chuck Peddle.

    Es wurde außerdem fieberhaft nach Chipfläche gesucht, weil der 6502 nicht auf die vorgegebene Die-Größe passte. Da kam man sicher nicht auf die Idee, zusätzliche Chip-Fläche zu verbraten, um das Verhalten der CPU für ein paar Nörgler 50 Jahre später korrekt zu machen. (Quelle: Chuck Peddles Oral History)

  • Es wurde außerdem fieberhaft nach Chipfläche gesucht, weil der 6502 nicht auf die vorgegebene Die-Größe passte. Da kam man sicher nicht auf die Idee, zusätzliche Chip-Fläche zu verbraten, um das Verhalten der CPU für ein paar Nörgler 50 Jahre später korrekt zu machen. (Quelle: Chuck Peddles Oral History)

    Echt? Das mit den Nörglern hat er vorhergesehen? Sehr weitsichtig der Mann. :thumbsup:

  • ... für ein paar Nörgler 50 Jahre später ...

    Der "Nörgler" heißt Herwig Feichtinger, der erste Chefredakteur und Mitbegründer der Zeitschrift Bitte melde dich an, um diesen Link zu sehen. und die Beschreibung stammt aus dem Jahr 1980. ;)

    Was leider neumodisch ist, ist der Umgang mit Kritik und Hinweise auf Fehler. Hier wird bei "unliebsamen" Hinweisen immer schneller der Spieß umgedreht und die Kritiker als "Nörgler" abgewertet, anstatt zu sagen, "Ja, stimmt so, hast Recht!".

    Erst gestern wieder erlebt an einer Kreuzung, als die Polizei dort kontrolliert hat und einen Radfahrer rausgezogen hat, der bei Rot drüber ist. Früher hätte man geflucht, sich still geärgert und gefragt, was es an Strafe kostet. Heute motzt man erstmal die Polizisten an, ob sie nix Besserers zu tun haben und verliert sich dann irgendwann in obskuren Ausreden wie "meine Oma ist schwanger" und Ähnliches. :D

    Das ist insgesamt eine Entwicklung, die schade ist, aber die trotzdem nichts daran ändert, dass hier nun mal ein Fehler vorliegt. :)

  • Fakt ist, dass man gut begründen kann, warum es so ist, wie es ist, und dass das "Abstellen" dieses "Fehlers" mehr Chipfläche und höhere Komplexität (u. a. zusätzliche Taktzyklen). erfordert hätte.

    Ich bin mir sehr sicher, dass Leute wie Peddle und Mensch ganz genau wussten, wie ihr Prozessor funktioniert und dass ihnen das nicht "passiert" ist, es also kein Fehler war. Es ist leider ein Zeichen der Zeit, Leuten ganz schnell ihre Kompetenz abzusprechen, nur weil man selbst nicht nachvollziehen kann, was da gemeint oder gedacht wurde.

    Was aber offenbar nicht nur neumodisch ist, ist dieses "hätte hätte Fahrradkette" und "warum haben die Dummbratzen das nicht schon 1976 korrekt gemacht". Man ist nicht fähig, die Umstände der damaligen Zeit und des damaligen Herstellungsprozesses zu erkennen und dass da z. B. gewisse Abstriche gemacht bzw. Kompromisse eingegangen wurden.

    Es ist die gleiche Leier wie beim "ROR-Bug". Peddle, Mensch & Co waren sicher keine "Jausenbuben"(*), die den 6502 irgendwie zusammengekleistert haben. Die wussten ganz genau, was sie taten. Sie wussten aber auch, dass das Produkt auf den Markt muss, weil die Firma alles andere als gut dastand. Es war einfach keine Zeit mehr für "elegante Lösungen".

    (*)"Znüne-Buaba" sind diejenigen Mitarbeiter, die man nur dazu brauchen kann, um 09:00 ("z'nüne") die Leberkäsesemmel aus der Metzgerei zu holen.

  • Der Mann (oder die Frau, wie bei Acorn) stand am Reißbret

    Damals noch ein Mann: Bitte melde dich an, um diesen Link zu sehen.

    Was leider neumodisch ist, ist der Umgang mit Kritik und Hinweise auf Fehler. Hier wird bei "unliebsamen" Hinweisen immer schneller der Spieß umgedreht und die Kritiker als "Nörgler" abgewertet, anstatt zu sagen, "Ja, stimmt so, hast Recht!".

    ich glaube mit Nörgler war nicht der originale Autor gemeint.

    Heute motzt man erstmal die Polizisten an, ob sie nix Besserers zu tun haben und verliert sich dann irgendwann in obskuren Ausreden wie "meine Oma ist schwanger" und Ähnliches. :D

    ja, kann man machen aber meistens ist die Strafe danach höher. Einen gewissen Spielraum gibt es ja immer. mündliche Verwarnung (kostenfrei) - Standardsatz - Vorsatz-Satz :D Aber wenn die Stadtkasse Geld braucht kann man auch mal was spenden ;)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN