Es ist schade, dass es noch kein Rubrik "Antike Mikroprozessoren" gibt, ich habe das Gefuehl, es waere an der Zeit.
Bei einer Literatursuche habe ich einen kleinen dreibaendigen Artikel ueber die Entwicklung des Motorola 6809 gefunden den ich angehaengt habe (Die Artikel sind in der BYTE 1979 veroeffentlicht und alle auf archive.org zu finden. Ich habe nur die Fuellseiten entfernt).
Die Technologie ist natuerlich ca. 45 Jahre alt, es war offensichtlich viel mehr Schweiss und Hirnschmalz notwendig um eine CPU zu bauen (man sollte nicht vergessen, dass viele Sachen die wir heute als gegeben sehen noch nicht gab!). Vor allen das Silicon-Design muss ja 1980 eine richtige Herausforderung gewesen zu sein! Die 6809 hatte ca. 4500 Transistoren hatte. Leider war die 6809 im Jahre 1979 schon veraltet (und zu teuer) als sie auf den Markt kam, denn Intel hatte gleichzeitig den 8086 veroeffentlicht, mit 29000 Transitoren und einem "richtigen" 16-Bit-Prozessor und groesseren Adressraum (segmentiert allerdings, Protected Mode kam erst bei 80286).
Gleichzeitig waren die Acht-Bitter (Z80, 6502) schon etabliert und billiger.
Fuenf Jahre spaeter war der 80268 in Stueckzahlen (fuer den IBM AT) verfuegbar, leider hatte sich die 68000 nicht so richtig durchgesetzt obwohl die 68000 die bessere Technologie (32 Bit Technologie) hatte und 1979 schon verfuegbar war (es gab sehr viele Workstations, aber IBM hatte es geschafft einen Quasi-Standard mit dem IBM-PC und IBM-AT zu setzen).
6809 war schon super und mit den vielen Adressierungsarten gut zu programmieren. Der Eurocom II war mein erster richtiger Computer für den ich viel Geld ausgegeben hatte.
Mein erster Computer war ein Eurocom 1, also ein 6802 (nicht 6502). Und für jemanden aus dieser Ecke war ein 6809 natürlich ein Traumcomputer. Ich habe dann später als Student für den deutschen Importeur für Dragon Computer gearbeitet und einen als Leihstellung gehabt. Leider nur das 32 kB Modell, also ohne OS/9.
6809 war schon super und mit den vielen Adressierungsarten gut zu
programmieren. Der Eurocom II war mein erster richtiger Computer für den
ich viel Geld ausgegeben hatte.
Die schickste Version des 6809 war die CMOS-Ausführung von Hitachi namens HD6309. Die konnte /noch mehr/ als der 6809.
Leider dauerte es sehr, sehr lang bis die Information über die undokumentierten Fähigkeiten allgemein verfügbar wurde ...
Aber auch ohne diese Erweiterungen war der 6809 so ziemlich der beste unter den 8-Bit-Prozessoren. Schick war beispielsweise die Möglichkeit, komplett positionsunabhängigen Code schreiben zu können, d.h. ein Programm konnte auch um ein Byte im Speicher verschoben werden, und lief dann trotzdem.
Das nutzte u.a. das Modulkonzept des Echtzeitbetriebssystems OS-9 (von Microware), das später als OS-9/68k weiterlebte.
Aber auch ohne diese Erweiterungen war der 6809 so ziemlich der beste
unter den 8-Bit-Prozessoren. Schick war beispielsweise die Möglichkeit,
komplett positionsunabhängigen Code schreiben zu können, d.h. ein
Programm konnte auch um ein Byte im Speicher verschoben werden, und lief
dann trotzdem.
Das war damals (TM) eine geniale Sache. Relocated Objects bei der Z80 war immer aufwaendig.
Das nutzte u.a. das Modulkonzept des Echtzeitbetriebssystems OS-9 (von
Microware), das später als OS-9/68k weiterlebte.
Ich hatte nur einen Artikel in der mc (die Zeitschrift) gesehen. Sehr beeindruckend fuer 1983.
Geile Zeit.
Da gab es noch einen Fortschritt: Jedes Jahr war wirklich was neues!
Nicht wirklich, zu teuer, zu instabil, zu unflexibel - nicht aus sich heraus - aber die Softwarekompatibilität bei Folgeprozessoren war nicht gut gegeben.
Es gab früher auch mal Diskussionen hier, die drehten sich u.a. auch um die zu hohen Entwicklungskosten bei 68000 und Folgemodellen.
Der Akai S 1000 Sampler ist u.a. auch deswegen zum Studiostandard geworden, weil die Bibliothek hervorragend war.
Mein "Erster" war der 6802 auf einer Motorola Dev. Board mit Monitor, Keypad und LED Display. Da mußte man alles Hand assemblieren und die Op Codes mit der Hand eintippen. Aber es ging, auch wenn nicht viel Platz (256B) für Programme zur Verfügung stand. Über einen Bus Verbinder hätte man ein größeres System aufbauen können. Das Internet gab es da für uns auch noch nicht. Alle Dokus waren in Druck Form und im Ordner organisiert. Und viele eigene Notizen. Man war total auf sich selber angewiesen. Das war Ende der 70er Jahre.
Nicht wirklich, zu teuer, zu instabil, zu unflexibel - nicht aus sich
heraus - aber die Softwarekompatibilität bei Folgeprozessoren war nicht
gut gegeben.
Es gab früher auch mal Diskussionen hier, die drehten sich u.a. auch um
die zu hohen Entwicklungskosten bei 68000 und Folgemodellen.
680x0 gab es in
Apple Lisa
mc68000 computer (Zeitschrift mc)
Apollo, HP 9000-300
Commodore Amiga
Atari ST
Sega Spielekonsolen
u.v.a.m. (lt. Wikipedia sogar im Airbus 320).
Übrigens sind m.E. ein paar Eckpunkte der m68k-Architektur von der IBM S/360 inspiriert (32 bit, 16 Hauptregister, 24 bit Adressraum, allerdings gleich mit Stack) - auch wenn ich dafür nie einen Beleg gelesen habe.
Mein einziger 6809-Rechner, der Musiksynthesizer Wersi MK1.
Zwei 6809 teilen sich den Speicher, ein 68B09 und ein 68B09E.
Staub wischen wäre mal wieder nötig. Als Bausatz selbst aufgebaut.
Ich hatte nur das Mini Kassettenlaufwerk, das war ein ziemliches Glückspiel das Basic Interpreter oder Assembler fehlerfrei geladen wurde. Und Mühselig die Infos zusammenzusuchen, Nix Internet.
Sehe ich auch so. Das Interruptsystem und die Echtzeitfähigkeiten - gerade in der damals aufkommenden Domäne "Musik" - waren bei den 68000ern um Klassen besser, als das gleichzeitig verfügbare Intel/IBM-Gedöhns. Wenn es nicht die Massen an business-PCs gegeben hätte, dann würden die DAWs heute allesamt mit solchen Prozessor-Familien laufen. So gab und gibt es das nur auf der Apple-Schiene, die einige (aus guten Gründen) auch heute noch bevorzugen.
Mein einziger 6809-Rechner, der Musiksynthesizer Wersi MK1.
Zwei 6809 teilen sich den Speicher, ein 68B09 und ein 68B09E.
Staub wischen wäre mal wieder nötig. Als Bausatz selbst aufgebaut.
Vor solchen Dingern hatte ich immer großen Respekt. 1000 Chancen, irgendetwas falsch zu verdrahten oder zu löten - oder eben zu töten!
Hier die Beschreibung zum Teilschaltplan mit dem 68B09E. Beide laufen mit gegeneinander versetztem Takt und können so auf denselben Speicher zugreifen.
Für die Tonerzeugung gab es noch 20 Einchip-Prozessoren Z8601 und einen für die Hüllkurve.
Ja der funktioniert noch. Einmal war der Schaltregler-IC defekt, aber das war zum Glück ein Standardtyp. Und anfangs hatte ich noch einige kalte Lötstellen, die ich erst im Laufe der Zeit finden konnte. Man konnte die Z8601-Steckkarten einzeln per Software ausschalten, damit waren die Fehler einzugrenzen.
Nicht wirklich, zu teuer, zu instabil, zu unflexibel - nicht aus sich
heraus - aber die Softwarekompatibilität bei Folgeprozessoren war nicht
gut gegeben.
Zu teuer? Vielleicht - aber zu instabil, unflexibel? Das wäre mir neu. Kommt evtl. darauf an, wie man "unflexibel" definiert. Auch der 68008 war ja durchaus populär und man konnte diesen ja durchaus in 8-Bit Systeme integrieren. Sie z.B. NDR-Klein-Computer.
Es gab früher auch mal Diskussionen hier, die drehten sich u.a. auch um
die zu hohen Entwicklungskosten bei 68000 und Folgemodellen.
Im Gegensatz zu? 8-Bitter? 8086? Spätestens ab 80286 waren ja immer Chipsätze nötig. Im Embedded Bereich waren ja 68070 oder 68332 durchaus populär.
Der Akai S 1000 Sampler ist u.a. auch deswegen zum Studiostandard
geworden, weil die Bibliothek hervorragend war.
Wie kommt man jetzt auf den AKAI? Der Sprung war jetzt etwas groß...
https://github.com/ijsf/wersi-mk1-ex20-re
den hatte ich schon mal erwähnt, ein echter Assembler-Künstler. Er hat viele Jahre später einen Softwarefehler im MK1 gefunden und irgendwie ein Workaround reingebastelt das noch ins Eprom passte. Es geht nur um die MIDI-Schnittstelle, die versehentlich kein end-of-transmission Byte schickte, wenn man SysEx-Daten abrief.
Ich hatte den Fehler auch mal bemerkt, aber keinen Rat gewußt. Mein AtariST hörte nicht mehr auf, wirre Daten zu empfangen. Mein Programm war in OmikronBasic programmiert.
Motorola 68000 - Amiga 500 - legendär. :-)
Die Entwicklung ging bis mindestens zum 68040.
Hätte mir damals beinahe noch den Amiga 4000 gekauft, kurz vor der Commodore Pleite. Zum Glück rechtzeitig zum x86 umgeschwenkt.
Bei der Betreffzeile musste ich zuerst an einem neuen Microchip ATmega 6808 denken. :-) :-) :-)
Das Interruptsystem und die Echtzeitfähigkeiten -
gerade in der damals aufkommenden Domäne "Musik" - waren bei den
68000ern um Klassen besser, als das gleichzeitig verfügbare
Intel/IBM-Gedöhns.
Ja, aber für die Sackgasse. So Anfang der 90er war der Atari ST noch die bessere Kiste, obwohl der nur auf 8MHz lief - und die Intel/DOS-Kisten vielleicht mit 33MHz.
In den Fachzeitschriften für Musik tauchten die ersten Workstation-Anhimmelungen und Intel-PC-Anbetungen auf.
Schon ein paar Jahre später (so ab '96) konnte man über diese "PowerPC" nur noch lachen.
Die Situation ohne Internet war eher für die Intels besser (oder für die Apples). Für die 68000er gab es sehr viel spezielles (Doku)Material, und auch viele Zeitschriften. Man kann die Situation aber auch mit "aus dem Wasserschlauch trinken" charakterisieren - derweil kam das Basisknowhow aber eher von der DOS-Seite bzw. von der Unix-Seite und auch die Tools und die Workflows waren irgendwie die besseren da.
Vom Lernzeit/Aneignungs-Teil stehen die 68000 auch nicht so toll da, geht man von 10 Jahren aus.
Nicht wirklich, zu teuer, zu instabil, zu unflexibel - nicht aus sich
heraus - aber die Softwarekompatibilität bei Folgeprozessoren war nicht
gut gegeben.
Das habe ich anders in Erinnerung. Kannst Du das genauer erklären? Ich erinnere mich an die Sache mit dem Auslesen des Status-Registers, das irgendwann nur noch im Supervisor-Mode (oder hiess das privileged?) ging, aber das war schnell korrigiert. Ich habe im Studium auf 68000, dann 68332 entwickelt und habe das Teil als sehr elegant in Erinnerung.
Zum 6809 muss ich sagen, dass ich das Buch von Rodney Zaks noch immer im Regal habe. Als der rauskam, habe ich sehr viel mit 6502 gemacht, und war von den 16-Bit Möglichkeiten im 6809, der integrierten Multiplikation und der einfachen Möglichkeit, relokatible Programme zu schreiben, sehr beeindruckt. Der 6502 ist ja bewusst primitiv gehalten.
Im Nachhinein muss man aber sagen, dass der 6809 einfach zu teuer war und zu spät kam, um im zwischen 6502 und Z80 bereits aufgeteilten Markt irgendwas reissen zu können, und dann kamen ja auch bereits 16Bit Prozessoren und bald danach der 68000. Die Marktforschung hat den Markt für den 6809 einfach falsch eingeschätzt.
Ich habe im Studium auf 68000,
dann 68332 entwickelt und habe das Teil als sehr elegant in Erinnerung.
Das Problem der 68000 Reihe kam später. Mit 68020 wurde der Befehlssatz dermaßen komplex, dass es schwierig wurde, ihn im späteren Verlauf konkurrenzfähig performant zu implementieren. Spätestens als es superskalar wurde. Ein Problem, das auch NS 32000, NEC V70 und DEC VAX hatten. Intel x86 hatte das zwar in schwächerer Form auch, aber da war derart viel Geld im Spiel, dass es finanziert werden konnte.
Allein die Länge eines Befehls zu ermitteln, konnte ein Höllenjob sein, weil die Codierung eigentlich dafür ausgelegt war, die Teile eines Befehlscodes schrittweise abzuarbeiten. Bei 68000 war das noch einfach, ging aus dem ersten Wort hervor.
Dass Befehle mit mehreren Speicheroperanden zum Problem werden können, merkte Motorola bereits beim 68010. Als der einzige Ausweg für virtuellen Speicher darin bestand, abgebrochene Befehle mitten im Mikrocode zu unterbrechen und exakt dort neu aufzusetzen. Die gängigere Neuausführung brächte hässliche Nebeneffekte.
Die Marktforschung hat den Markt
für den 6809 einfach falsch eingeschätzt.
Die Marktforschung hat auch vergessen, dem 6809 Prozessor eine direkte Addition seiner beiden 8-Bit-Akkus A und B zu erlauben.
Es gibt keinen "ABA" Befehl wie vom 6800 bekannt!
Der Workaround ist:
PSHS B;
ADDA ,S+
Lustig, sehr performant.
Dafür hatte er irre Adressierungsarten, die sich niemand merken konnte (Assembler-Programmierer) und kein Compiler braucht. Z.B. extended indirect sowie indexed mit 15 Untervarianten.
Mitte der 80er bekam unser Theater das dritte ausgelieferte vollcomputerisierte Mischpult von Neumann Berlin (ein 48 Kanalpult).
Der Zentralrechner wurde von uns zwar nur selten benutzt, weil du bei Musical nur sehr wenig Szenen speichern kannst, lief aber mit dem 6809 und dem weltbekannten Betriebssystem 'Flex'. Schon mal davon gehört?
Ich habe im Studium auf 68000,
dann 68332 entwickelt und habe das Teil als sehr elegant in Erinnerung.
Die Ataris waren auch DOS-Kompatibel, jedenfalls einigermaßen. Ich habe noch einen Aufbauplan für den Arbeitsspeicher und auch die passenden PC-Speichermodule in der Schublade. Problem ist, einen Ersatz-Atari zu bekommen, falls was schiefgeht.
Die Sampledisks für den YamahaTX16W (auch so ein 68000er) konnte ich am Windows-Rechner abspeichern.
Mit 68020 wurde der Befehlssatz dermaßen komplex, dass es
schwierig wurde, ihn im späteren Verlauf konkurrenzfähig
performant zu implementieren.
Naja, das war aber beim 386 und va. beim 486, Pentium schlimmer. Beim 68060 hat man es dann aus meiner Sicht doch hinbekommen, und schon damals war es viel wichtiger, dass es der C-Compiler gut hinbekommt. Man wollte diese neuen Prozessoren (auch Pentium & Co) nicht mehr in Assembler programmieren. Viele zumindest nicht, ich auch nicht. Das Problem war doch eher, dass Apple da schon beim PowerPC war und Commodore und Atari schon aus dem Markt. Es gab halt keine nennenswerte Kundschaft mehr für eine 68000 jenseits des 68060.
Ich bin vom Amiga damals 1993 auf einen 386DX40 mit Linux umgestiegen.
Das Preis/Leistungsverhältnis war bei Linux halt deutlich besser. Viele Tools, ich ich auf dem Amiga hatte, waren eh von Unix bzw. BSD portiert.
Aber es wird jetzt sehr offtopic...
Das Problem der 68000 Reihe kam später. Mit 68020 wurde der Befehlssatz
dermaßen komplex, dass es schwierig wurde, ihn im späteren Verlauf
konkurrenzfähig performant zu implementieren.
Naja, das war aber beim 386 und va. beim 486, Pentium schlimmer.
Nicht wirklich. Nur durch die Prefixe wird es kompliziert, aber die wurden anfangs auch nicht voll in die schnelle Decodierung eingebunden. Ohne sie ist es relativ übersichtlich. Das Problem mehrerer Speicheroperanden besteht im Mainstream der Befehle überhaupt nicht.
Bei 68000 ist die Länge eines Befehls vom ersten Wort bestimmt. Beim 68020 MOVE erweitert sich das im ersten Schritt auf das erste Wort des ersten Operanden, um dadurch herauszufinden, wo überhaupt der Code des zweiten Operanden beginnt. Erst bei dem dann weiss man, wo der nächste Befehl beginnt, wo im Befehl die Registernummern und Konstanten stecken, wie der Ablauf aussieht. Die VAX war noch schlimmer dran.
In einer bestimmten Phase der Entwicklung von Highend-Prozessoren war das aufgrund des Aufwands ein kritischer Punkt, zeitweilig mit Predecode-Information im I-Cache, aber noch heute steckt das Thema in den Intels und AMDs als μOp-Cache drin, und zwischendurch mal in Intels Trace Cache. Aber heute hat man das Transistor-Budget dafür.
Bei einer Literatursuche habe ich einen kleinen dreibaendigen Artikel
ueber die Entwicklung des Motorola 6809 gefunden den ich angehaengt habe
(Die Artikel sind in der BYTE 1979 veroeffentlicht und alle auf
archive.org zu finden. Ich habe nur die Fuellseiten entfernt).
Und genau da war ein grosser Teil von dem, was 68020 zusätzlich
einbrachte, komplett für den Arsch.
Da geb ich dir Recht. Hätte es nicht gebraucht. Aber ich sehe hier trotzdem keinen Nachteil vom 680x0 zum x86, eher anders rum. Nur hat halt irgendwann die x86 Serie sich durchgesetzt und damit war der Markt und das Geld da.
Aber die Entwicklung des x86 hat gezeigt, dass man selbst verkorkste CISC Architekturen performant bekommt, wenn man will.
Dass Befehle mit mehreren Speicheroperanden zum Problem werden können,
merkte Motorola bereits beim 68010. Als der einzige Ausweg für
virtuellen Speicher darin bestand, abgebrochene Befehle mitten im
Mikrocode zu unterbrechen und exakt dort neu aufzusetzen. Die gängigere
Neuausführung brächte hässliche Nebeneffekte.
Man nimmt einfach :) eine zweite CPU zu Huelfe.
Da das nicht besonders genial ist, sind auch schon andere darauf
gekommen.
Ob der wohl so häufig war, dass er wichtig gewesen wäre?
Nunja, konsequenterweise hat man nicht nur die Addition der beiden Akkus "eingespart".
Genausowenig kann man diese subtrahieren oder vergleichen.
Nur mit selben Workaround:
Ersten Akkuwert auf den Stack schreiben, dann im nächsten Befehl den Speicherwert von dort zurücklesen und jetzt mit dem zweiten Akku verwursteln, und nicht vergessen den Stackpointer korrigieren.
Wieviele Taktzyklen das jeweils sind, das will ich jetzt nicht nachsehen. Nur ungefähr: viele.
Und in Summe addiert sich das eben in einem Programm.
Alle Additionen, Subtraktionen und Vergleiche der beiden Akkuregister A und B.
Und mehr Arbeitsregister (Akkus) hat(te) er ja nicht, der 6809.
Mit der Ausgliederung der uP / uC Sparte von Motorola zu Freescale kam das AUS für den 6809, spätestens 2004.
Und in Summe addiert sich das eben in einem Programm.
Genau darauf will ich ja raus: Es summiert sich nur dort, wo man das überhaupt nennenswert verwendet. Und bei einer Akku-zentrierten Architektur sind die wichtigsten Operationen jene zwischen Akku und Speicher.
Letztlich bedeutet es nur, dass die 6809 nicht besonders geeignet ist, um reine 6800 Programme auszuführen. Die werden länger und langsamer. Aber das war auch nicht das Ziel. In der Gegenrechnung kann man beispielsweise sehr viel besser mit Indexregistern umgehen, eine grosse Schwäche der 6800 Architektur. Da wurde schon kurz darauf bei der 6801 etwas nachgeholfen.
Bei einer Literatursuche habe ich einen kleinen dreibaendigen Artikel
ueber die Entwicklung des Motorola 6809 gefunden den ich angehaengt habe
(Die Artikel sind in der BYTE 1979 veroeffentlicht und alle auf
archive.org zu finden. Ich habe nur die Fuellseiten entfernt).
Danke. Sehr schöne Reihe!
Natuerlich war das ein Zufallsfund. Gesucht hatte ich zellulare Automaten, vulgo "Conways game of life". Manchmal findet man solche Perlen im Internet und die Qualitaet und Tiefe der Artikel aus den achtziger Jahren ist schon beeindruckend (auch alte Ausgabe der Scientific American wuerden heute als Fachpublikation durchgehen).
Bei mir im Schrank steht noch irgendwo "Programming the 6809". Damit habe ich mir damals in Basic auf einem Dragon32 einen Assembler geschrieben.
Wenn man dessen (doppelt) indirekte Adressierung erst mal kapiert hat, war die einfach genial, und das Thema pointer in C, was später dann irgendwann mal danach vorbei kam, war dann halt was völlig normales.
Übrigens sind m.E. ein paar Eckpunkte der m68k-Architektur von der IBM
S/360 inspiriert (32 bit, 16 Hauptregister, 24 bit Adressraum,
allerdings gleich mit Stack) - auch wenn ich dafür nie einen Beleg
gelesen habe.
Die Hauptinspiration war eher die PDP-11. Der Befehlsaufbau mit 1 oder 2 Registerargumenten mit 3bit Mode und 3bit Register ist nahezu 1:1 übernommen, nur die detaillierte Zuordnung, und dass es 8 Daten- und 8 Adressregister gibt ist etwas anders.
Meine Erfahrung .. der 68000 ist sehr schön in Assembler zu programmieren, aber von der Cycle-Performance eher schnarchlahm.
Die Marktforschung hat auch vergessen, dem 6809 Prozessor eine direkte
Addition seiner beiden 8-Bit-Akkus A und B zu erlauben.
Das wurde später beim 6309 (unter vielen anderen Optionen) korrigiert,
leider (wohl um Ärger mit Motorola zu vermeiden, da sie ja eigentlich nur Second Source sein sollen) nie veröffentlicht.
Der ADDR Befehl ist mit seinen 3 Byte und daher 4 Takten nicht der schnellste, aber man brauchte halt das Prefix-Byte um einen freien Opcode zu finden und das Postfix für die beteiligten Register. Schneller als der 6809 Workaround ist es aber allemal.
Auf die Gefahr hin, hier ein paar Opas von der 5 V - Heizdecke zu werfen, bin ich froh, heute einen Cortex-M0/M4/M7 für ein paar Groschen verwenden zu können :-)
Aber wenn der Thread schon nostalgisch anfängt, wären die Cortexe doch
eindeutig Offtopic.
Na gut. Den 6809 hatte ich zunächst auf dem Schirm, bin dann aber zum 68K umgeschwenkt. Der Hauptgrund war, daß dieser mit dem Motorola FFP-Paket (fast floating point) genauso schnell rechnen konnte wie der spezielle AMD9511.
Um das in die jüngere Vergangenheit zu übertragen: Ein AVR8 mit 16 MHz ist wohl schneller ;-)
Nach dem Aufkommen vom MC6809 in 1981 hatte ich mir auf der Grundlage obiger Bücher einen eigenen SBC mit doppelseitiger Europakarte gebaut und mittels ASR33 und Kassentenrecorder (SpeedTape) betrieben. Eine angepasste Variante des offen zugänglichen PSYMON (Percom) lief darauf einwandfrei. Leider habe ich all diese nostalgischen Sachen bei einem Umzug entsorgen müssen. Anfänglich war ich schon drauf und dran und wollte den Computer von SWTPC im Europakartenformat nachbauen, um so noch eine OS9-Welt für mich zu erschaffen. Das habe ich aber dann zeitlich nicht mehr hingekriegt, obwohl ich alle Unterlagen inkl. SW einer SWTPC-Kiste mit S-50-Bus und FLEX bzw. OS9 zu Hause liegen hatte. Soviel von der warmen Heizdecke mit meinen nostalgischen Gedanken.
Übrigens kann man auch heute noch zahlreiche MC6809-Einplatinenrechner auf eBay oder KA z.T. auch zum Nachbau finden. Auch gibt es Quellen, wo SW für CoCo oder TRS-80 etc. der vergangenen Jahre akriebisch aufgelistet und bereitgestellt werden. Das Thema MC6809 ist noch lange nicht tot.
Als Nachtrag und Ergänzung für einen MC6809-SBC als Kit aus Thailand
Damit dürfte man aber kaum so etwas wie OS-9 oder auch nur Flex nutzen können; nur eine ACIA, kein Timer, nur 32 kiB RAM, kein Massenspeicher (FDC o.ä.).
Weiter oben habe ich die FUG verlinkt, dort finden sich nicht nur Dokumentation, Sourcen und Software, sondern auch Links auf Emulatoren, mit denen man das grandiose Feeling des "+++"-Prompts live und in (einer) Farbe erleben kann.
Wenn man sich auf u.a. eBay umschaut sieht man, dass CPUs der Typen MC68(B)09P, MC68(B)09E, HD63(B)09P und HD63(B)09E auf vielen Seiten von zahlreichen chinesichen Anbietern für kleines Geld angeboten werden. Dass heisst aber auch, dass diese CPUs für experimentierfreudige und wissbegierige Bastler und andere weiterhin in ausreichender Stückzahl zur Verfügung stehen werden.
Einen einfachen SBC (von Jeff Tranter) hatte ich neulich auf EasyEDA.com gesehen, wo man Schaltung und Layout zum Nachbau und Platinenherstellung zur Verfügung stellt. Irgendwo auf 'github.com' findet man auch noch den zugehörigen Monitor (auf Motorolas ASSIST09-Basis) nebst BASIC (keine Ahnung von wem) zum Betreiben dieses SBCs.
Der 6809 haben wir in Argentinien, mitte 90s noch in einige Geräte wie Stempeluhren und Mautsysteme verkauft. Die Stempeluhren wurden bei mir mit 68HC11 ersetzt, außer EPROM war alles in einem Chip, die E varianten wahren zu teuer für die Produktion, die Mautsysteme gingen in Richtug PC.
Der 68HC11 ist nicht 6809 basiert aber 6803, wenn ich mich richtig erinnere, es gab auch einen 6811. Schöne Geräte damals.
Der 68k war auch in Oszilloskopen von HP, Tektronix und Nicolet zu finden. Und in Routers von Cisco und Motorola selber. Die von Moto haten 040s oder 060s, ohne Kühler... die von Cisco 030s.
Woher hast Du die Zahl? Der Traffic, den die zugehörige Mailingliste erzeugt, ist recht heftig, und das bei einer im Grunde genommen vollkommen toten Technik (denn wer außer an "Retro" begeisterten Menschen beschäftigt sich /heute noch/ mit 6809?)
Steht auf der Introseite:
http://www.flexusergroup.com/flexusergroup/fug2.htm
Der einzige HD63B03, der hier noch läuft, ist der Hauptprozessor in meinem Yamaha DX7 Synthi. Aber das macht er wunderbar. Als Keyboard Helferlein ackert noch ein 6805 da drin.
Sag mal, willst du mich nerven? Ja, ich habe gesehen, das das alles schon über 20 Jahre alt ist. Seitdem sind die Flexuser sicher nicht mehr geworden. Lass es alles einfach ruhen, okay?
Hallo, ich habe in den achziger Jahren des letzten Jahrhunderts jede Menge Systeme mit dem 6809 entwickelt.
Besonders geschätzt habe ich seinen umfangreichen Befehlssatz, sein "Memory maped I/O", seine zwei Stackpointer und und und.
Die Aufgabe, mit der 6809-CPU einen Mikrocontroller zu entwickeln, war "relativ einfach".
RAM, ROM (EPROM, EEPROM)
VIA 6522 (16 I/O-Pins, Schieberegister usw)
A/D Wandler
D/A Wandler
PCM war etwas aufwändiger, konnte man aber mit einem Sägezahn-Oszillator samt Comperator lösen.
Ich habe mit dem 6809 die komplette Steuerung des weltweit ersten, Computer gesteuerten Kamerawagen (Panther) realisiert.
Der Kamerawagen konnte 300 KG !!!! vollkommen frei von Vibrationen und einer Wiederholgenauigkeit von 0,7 Mikrometer verfahren.
Die Wiederholgenauigkeit war für Werbe-Großaufnahmen wichtig.
Der Kamerawagen bekam ua wegen dieser Eigenschaften 1989 in Los Angeles den technischen Oskar (Award of research and technology).
Mit Keilriemen- und und Spindelantrieb als Regelstrecke hatte ich mit ständig sich ändernden Regelparametern zu kämpfen.
Dem konnte ich nur mit "KI", mit einem "Lern- und Evolutions-Algorithmus (survival of the optimum) beikommen.
All das brachte ich mit dem 6809 in einem 32 Kb Programm unter
Aber auch ohne diese Erweiterungen war der 6809 so ziemlich der beste
unter den 8-Bit-Prozessoren. Schick war beispielsweise die Möglichkeit,
komplett positionsunabhängigen Code schreiben zu können, d.h. ein
Programm konnte auch um ein Byte im Speicher verschoben werden, und lief
dann trotzdem.
Tja, guck dir aktuelle Betriebssysteme an, von Windows zu Linux etc.
Brauchen das alle nicht.
Obwohl es verfügbar wäre, zumindest unter den Intel Prozessoren.
Aber es war so unbeliebt oder unverstanden, daß es wieder abgeschafft wurde.
Unter Win16 auf 286 durch Segmente war es noch möglich, dieselbe DLL nur ein mal in den Speicher zu laden mit 2 unabhängigen Daten und Stacks.
Da David Cutler, der Idiot hinter Win32, unbedingt seinen DEC Alpha weitervervenden wollte der das nicht konnte, hat er das nicht nur ignoriert, sondern kaputt gemacht.
komplett positionsunabhängigen Code schreiben zu können, d.h. ein
Programm konnte auch um ein Byte im Speicher verschoben werden, und lief
dann trotzdem.
Tja, guck dir aktuelle Betriebssysteme an, von Windows zu Linux etc.
Brauchen das alle nicht.
Die verwenden das, wenn verfügbar. Es erleichtert ASLR. Nur nicht so, wie du gemeint hast. Segmentierung verschwand, dafür kam mit amd64 die PC-relative Datenadressierung in den üblichen Befehlen.
Obwohl es verfügbar wäre, zumindest unter den Intel Prozessoren.
Im amd64/x86-64 long mode exisitiert klassische Segmentierung m.W. nicht mehr, ist reduziert auf Basisadressen für FS/GS.
die Titelzeile ist historisch gesehen paradox; als "Revolution" wird ja eher der Apple Macintosh angesehen (Werbespot "1984") und der kam erst in Schwung nachdem Steve Jobs den 6809 für den 68000 raus kickte. Diese Episode hat es sogar in den Steve Jobs Film geschafft:
die Titelzeile ist historisch gesehen paradox; als "Revolution" wird ja
Noe, ist der Titel des Artikels von 1979.
Ich fand schon interessant wie primitiv heute die Entwicklung der ICs erscheint (und sie haben es gut hinbekommen). Auch die Abwaegung welche Funktionen im Silizium gepackt wurden und welche (per Assembler) programmiert werden, fand ich schon sehr interessant (z.b. ich finde die Block-Befehle bei der Z80 sehr fortschrittlich, aber die kamen mit Kosten, man brauchte Transistoren auf dem Die).
Man koennte natuerlich sagen, dass die 65xx/68xx die ersten RISC-Microprozessoren waren (mit der Registerbank auf der ZeroPage oder DP), auf der anderen Seite waeren die Z80 so Richtung CISC (natuerlich kommt jetzt die VAX als Beispiel: ACBL LIMIT, INCR, INDEX, LOOP enthaelt INDEX >= LIMIT, erhoehe den INCR und spring nach LOOP. Auch mit Floats!)
Block-Befehle bei der Z80 sehr fortschrittlich, aber die kamen mit
Kosten, man brauchte Transistoren auf dem Die).
Wobei komplexe Befehle in der Bilanz mitunter zum Rohrkrepierer werden. Weil je nach Generation eine an die Aufgabe angepasste Ersatzsequenz effizienter sein kann. Gerade REP MOVSx der x86 zeigt das, weil das über die Zeit zwischen 8086 und heute oft der langsamste Weg war, Ersatzcode besser war oder evtl noch ist. Heute steckt dafür viel Mikrocode auf dem Chip, der zur Laufzeit immer wieder prüfen muss, was ein der Aufgabe angepasster Code ohnehin schon weiss.
Man lernt hinzu. Dass die zunehmende Komplexität von 68020, NS 32000 und NEC V70 ein Schuss in den Ofen ist, merkte ich so ungefähr anhand der Begegnung mit den ersten ARMs in den 80ern und dem folgenden Jahrzehnt. Was anfangs wie ein Traum für (Assembler-) Programmierer aussah, das entwickelte sich zum Alptraum für CPU-Konstrukteure.
Man koennte natuerlich sagen, dass die 65xx/68xx die ersten
RISC-Microprozessoren waren
Der RISC-Ansatz bestand und besteht nicht in der Reduktion der Anzahl der Befehle, sondern in deren Komplexität, im Ablauf. Weshalb es mir widerstrebt, ADC (zp),y als RISC zu betrachten.
Der RISC-Ansatz bestand und besteht nicht in der Reduktion der Anzahl
der Befehle, sondern in deren Komplexität, im Ablauf. Weshalb es mir
widerstrebt, ADC (zp),y als RISC zu betrachten.
Wie meinst du das? Etwas mehr Input dazu?
Die 68k haben um die 100 Befehle, die Intel zu dieser Zeit auch nicht viel mehr.
Man kann das ganze ja denken, +optimierten C-Compiler und sowas (also RISC-optimiert) gab es ja zu dieser Zeit gar nicht. Aber sehr viele bessere Programmierkultur und Programmierfreunde usw. als heute.
Von der Taktfrequenz waren die Ataris auch nicht so tolle, und die Übertaktung hatte ihre Tücken.
Und hinsichtlich der Hingabe zur Computertechnik ist es ja auch echt übel, dass die 68k so in der Sackgasse untergegangen sind. Das hätte man damals mal wissen sollen, dann hätte man eine Vielzahl von Büchern mit dem Prädikat "Müll" versehen können, was beim Atari ST sowieso ein wenig gängig war. Teilweise so ähnlich, wie trinken aus dem Feuerwehrwasserschlauch - In so ziemlich jedem Buch stand was anderes, und jeder wollte was anderes verkaufen. Das heißt aber wenig Zusammenhängendes, und ehe man sich versieht, und ein wenig mehr verstanden hat, ist die Technik auch schon veraltet und Museumsreif.
Bin kein Experte, hab trotzdem 105 Punkte erreicht! ;-)
Ebenfalls nicht, hab aber einen Zehner mehr. Wobei der Quiz IMHO an zwei Stellen krankt.
-der angebliche IRQ-Controller im Chip ist bestenfalls die halbe Wahrheit/Logik, die andere Hälfte steckt bsp. in den Interruptsteuerungenn der jeweiligen Peripherie wie Z80-PIO (DDR-Type U855)
-vielen Fragen drehen sich weniger um die CPU-Architektur (Fragen für Hardwerker) als in welche Rechenkästen die CPU verbaut wurde und welche Software darauf rödelte (Softwerker-Fragen).
Anbei ein Diagramm der wichtigstens timings des Z80 (U880).
Der RISC-Ansatz bestand und besteht nicht in der Reduktion der Anzahl
der Befehle, sondern in deren Komplexität, im Ablauf. Weshalb es mir
widerstrebt, ADC (zp),y als RISC zu betrachten.
Wie meinst du das? Etwas mehr Input dazu?
ADC (zp),Y hat einen komplexen Ablauf, der aus mehreren Einzeloperationen besteht. Charakteristisch für RISC ist die Auftrennung von solchen Befehlen in mehrere eigenständige Befehle mit einfachem Ablauf:
Load (zp) to temp1
Load (temp1+Y) to temp2
Add temp2 to A
Die 68k haben um die 100 Befehle, die Intel zu dieser Zeit auch nicht
viel mehr.
Wie gesagt, die Anzahl Befehle ist für das Konzept nicht relevant.
Man kann das ganze ja denken, +optimierten C-Compiler und sowas (also
RISC-optimiert) gab es ja zu dieser Zeit gar nicht.
Maßgeblich beteiligt an der Entwicklung von RISC war John Cocke bei IBM, und da hatte man in den 70ern bereits Erfahrung mit der realen Nutzung von Befehlen komplexer Maschinen, und auch mit Compilern.
https://en.wikipedia.org/wiki/IBM_801
Wenn man partout frühe Formen von RISC sucht, wird man eher bei RCAs 1802 fündig. Aber im Grunde ist das müßig, eine Spielerei a posteriori, weil diese Überlegungen im Kontext von Mikroprozessoren erst später Einzug hielten.
Wenn man partout frühe Formen von RISC sucht, wird man eher bei RCAs
1802 fündig. Aber im Grunde ist das müßig, weil diese Überlegungen im
Kontext von Mikroprozessoren erst später Einzug hielten.
Der ganze Streit um RISC/CISC ist nur was für Pfennigfuchser und Rekordjäger. Letzten Endes geht es dabei nur um die Kosten für die CPU versus Kosten für Memory und die zugehörige Minimierung der Gesamtkosten. Alles Andere ist aus meiner Sicht Marketing.
ist die Technik auch schon veraltet und Museumsreif.
Das ist so, in der Sturm und Drang Zeit. Fehler mendeln sich mitunter aus. Außer wenn derart viel Geld und existierende Codebasis besteht, dass einmal gemachte Fehler ad infinitum konserviert werden. Nicht nur bei x86. Auch die 360 Architektur von IBM lebt bis heute bei IBM weiter.
Letzten Endes geht es dabei nur um die Kosten für die CPU
versus Kosten für Memory und die zugehörige Minimierung der
Gesamtkosten.
In Relation zur Performance. Natürlich. Um was den sonst? Die Goldene Palme für künstlerisch wertvolle Gestaltung gibt es in der Branche bis heute nicht.
Alles Andere ist aus meiner Sicht Marketing.
Damals auch schon. Eine IBM 801 könnte jeder bauen, und so kam es dann Jahre darauf auch in Gestalt der ersten öffentlich bekannten RISCs. Bis dahin aber blieb sie geheim, achtete IBM sorgfältig darauf, dass sie ihre hohen Gewinne durch aufwändige und teure Mainframes nicht riskierten. Eben Marketing.
Heute spielt das keine grosse Rolle mehr, aufgrund des immensen Budgets an Transistoren. Aber in den oben erwähnten 80ern fiel mir auf, dass man mit sowas wie ARM2 sehr viel komplexere 68K CPUs egalisieren konnte. Ein Design wie 68K hätte Acorn nicht stemmen können, eine sehr viel einfachere ARM CPU jedoch konnten sie mit relativ wenigen Leuten bauen.
Ein unglaubliches Erlebnis: Ich lies meinen Computer kürzlich die Nachrichten im Internet lesen. Darauf hin, bettelte mich das Teil an, es doch möglichst bald in einen bombensicheren Bunker übersiedeln zu lassen. Auf welche abfällige Ideen diese Dinger heutzutage doch manchmal kommen. Weiß gar nicht, was in das Ding gefahren ist...
Der ganze Streit um RISC/CISC ist nur was für Pfennigfuchser und
Rekordjäger. Letzten Endes geht es dabei nur um die Kosten für die CPU
versus Kosten für Memory und die zugehörige Minimierung der
Gesamtkosten. Alles Andere ist aus meiner Sicht Marketing.
Nein, das waren damals ganz harte wirtschaftliche Überlegungen. Es wurde immer weniger in Assembler programmiert, so dass das für Assembler-Programmierer bequeme CISC-Modell immer unwichtiger wurde. Und Code-Generatoren wie im Compiler-Backend hatten überhaupt kein Problem damit, die komplexen Befehle durch eine Sequenz simpler (und damit auch kürzerer) Befehle zu ersetzen.
Dadurch konnte man beim RISC nicht nur Chip-Fläche und Entwicklungszeit beim CPU-Design sparen, sondern sich auf universeller kombiniernare Befehle konzentrien, die durch die Code-Generatoren effizienter nutzbar waren.
Beim 6809 hätte man z.B. die komplexen Adressierungsarten weglassen und stattdeseen mehr Adressregister einbauen können (-> 68k). Denn die ganzen komplizierten Adressierungarten hätte man dann einfach durch LEAx für einfach indirekten Zugriff und Addition/Subtraktion auf den Adressregistern ersetzen können. Das wäre universeller und evtl. keinen Zyklus langsamer gewesen.
Vielleicht kann mir das hier jemand glaubhaft beantworten:
Warum gibt es einen HD6309 in unterschiedlicher Ausprägung heutigentags? Wie ist der Übertrag der Fertigungsunterlagen und der Weiterentwicklung vom MC6809 ausgehend zu bewerten? Was sind oder waren die Antriebskräfte, die zu diesem weiterentwickelten Produkt letztlich geführt haben? Werden diese Chips auch heute noch in Stückzahlen gefertigt oder sind die im Markt befindlichen Teile vor längerer Zeit bereits gefertigt worden?
Warum gibt es einen HD6309 in unterschiedlicher Ausprägung heutigentags?
Gibt es nicht. Der wird schon lange nicht mehr hergestellt.
Wie ist der Übertrag der Fertigungsunterlagen und der Weiterentwicklung
vom MC6809 ausgehend zu bewerten?
Hitachi war Second-Source-Produzent und hatte die (originäre) 68xx-Architektur von Motorola lizenziert. Was soll da bewertet werden?
Was sind oder waren die Antriebskräfte, die zu diesem
weiterentwickelten Produkt letztlich geführt haben?
Diese Frage ist unverständlich. Vielleicht solltest Du sie besser auf einem Soziologie-Proseminar stellen.
Werden diese Chips auch heute noch in Stückzahlen gefertigt
Nein.
oder sind die im Markt befindlichen Teile vor längerer Zeit
bereits gefertigt worden?
Ja. Viele "im Markt befindlichen Teile" sind aus alten Platinen ausgebaut worden oder schlichtweg umgestempelter Schrott. Denn abgesehen von irgendwelchen Bastlern setzt schon seit Jahrzehnten niemand mehr 68xx oder 63xx mehr ein, so schade man das auch aus Sicht seiner persönlichen Geschichte auch finden mag.
Dein Satzbau ist merkwürdig, Deine Fragen sind es auch.
Der ganze Streit um RISC/CISC ist nur was für Pfennigfuchser und
Rekordjäger. Letzten Endes geht es dabei nur um die Kosten für die CPU
versus Kosten für Memory und die zugehörige Minimierung der
Gesamtkosten. Alles Andere ist aus meiner Sicht Marketing.
Nein, das waren damals ganz harte wirtschaftliche Überlegungen. Es wurde
immer weniger in Assembler programmiert, so dass das für
Assembler-Programmierer bequeme CISC-Modell immer unwichtiger wurde. Und
Code-Generatoren wie im Compiler-Backend hatten überhaupt kein Problem
damit, die komplexen Befehle durch eine Sequenz simpler (und damit auch
kürzerer) Befehle zu ersetzen.
Man darf natuerlich auch nicht vergessen, dass RISC-Programme vereinfacht ausgedrueckt groessere Binaries haben als CISC-Programme. Und in den '70er - '80er Jahren des vorigen Jahrhunderts waren Lade- oder Pageing-Zeiten Groessenordnung laenger (das wurde bei der Vax780 in 1977 als Begruendung fuer den OpCode-Bloat angegeben). Speicher war auch teuer (meine uVAX hatte im Grundausbau ein ganzes Megabyte).
Zeiten haben sich geaendert, Speicher ist billig, die Massenspeicher sind schell und auch billig. Dafuer hat man jetzt eine Unmenge an Frameworks die den Speicher und den IO fressen.
