Diskussion:Motorola 68000

Schade

Schade dass Motorola das Wettrüsten gegen Intel so früh verloren bzw. aufgegeben hat und sich so der x86-PC ohne echte Konkurrenz so durchsetzen konnte, wie wir es heute kennen !

Als der Motorola 68000-CPU vorgestellt wurde, war er eine Sensation und niemand hätte geglaubt, dass Intel mal so den CPU-Markt dominieren wird.

Schade, wenn man sich überlegt wie es hätte sein können, wäre es nicht schön wenn es neben Apple und den PC-Hersteller noch Firmen wie Atari, Commodore oder Sinclair geben würde ?

Diese Entwicklugn verwundert nicht weiter und ist nur zum Teil Schuld von Motorola - die Hauptschuld tragen die Systemhersteller Commodore, Atari und Apple. Schon zu 8Bit Zeiten kochte jeder sein eigenes Süppchen und vor allem bei Commodore zu 8Bit Zeiten passte wirklich nichts zusammen. Ein Programm für den C64 lief nur auf diesem und dem C128 im 64 Modus. Nicht aber auf den CBM-Modellen oder der 264-Linie. Die Strategie die Kunden mit proprietären Systemen an sich zu binden, funktionierte nur im Privatkundensegment. Intel wurde durch IBM groß und zwar durch deren PC, XT und AT Serien. Den Fehler den Motorola gemacht hat, war sich zu früh von der 68k Linie zu trennen. Intel hat schon mit dem i486 auf RISC-Technologien gesetzt (CRISC mit eingebettetem RISC-Core für die häufigsten Befehle) und damit den Trend gesetzt, das die Hauptleistungssteigerungen der Zukunft im wesentlichen über die Taktfrequenz gehen würde. Hier gibt es aber bei reinen CSIC-CPUs wie der 68k Familie natörliche Grenzen. Das wußte auch Motorola und fing mit der PowerPC CPU völlig neu an. Das hieß aber für die Kunden alle neu kaufen: Hardware und Software und das war die Gelegenheit zu Intel-basierenden Systemen zu wechseln. Der M68060 kam 1994 auf den Markt und war dem i486 ebenbürtig, teilweise durch seine Superskalarität sogar weit überlegen. Doch zur selben Zeit führte Intel die Taktvervielfachung ein und enkopplete damit die CPU-Frenquenz vom System. Das war der Beginn des großen MHz-Rennens und das konnte der M68060 nicht mehr. Und wenn ich dann noch vor Erscheinen des 68060 ankündige, das nach diesem Schluß sein wird mit dem 68000, dann brauche ich mich nicht wundern, wenn dieser zum Ladenhüter wird. 79.212.190.136 18:29, 8. Aug. 2014 (CEST)

Embedded-Versionen, andere Hersteller

Auf dem Bild sieht man immerhin, dass der 68000 auch von anderen Herstellern (hier Thompson) hergestellt wurde. Wenn ich mich recht entsinne, gab es auch welche von United Technologies und von Rockwell (ohne Garantie). Darüber hinaus sollten diverse Embedded-Derrivate erwähnt werden, so z.B. 68302 und 68360 sowie die ganzen CPU32-Derrivate (alle von Motorola). Auch von anderen Herstellern gab es Embedded-Derrivate, so von Toshiba (TMP68301) und von Philips/Valvo (68070). wb 2006-11-01

Hitachi, Rockwell, Signetics, Toshiba...............--Untiunte

Palm

Meines Wissens nach stellt PalmOne auch nur noch Geräte mit Intel ARM-Prozessor her. Von Billig-Handys weiß ichs nicht genau, aber ich gehe mal davon aus, dass die auch nicht mehr damit ausgestattet sind (Mal abgesehen vielleicht von 5-€-Schlecker-Handys). Motorola hat die letzten 68k-basierten-Prozessoren übrigens in die Firma Freescale ausgegliedert, wär vielleicht interessant das zu erwähnen. Bei Motorola selbst hat man die Dinger abgeschrieben. - 22. Mai 2007

mit 8 MHz Taktfrequenz kam im 64-poligen DIL-Gehäuse (siehe Bild) auf den Markt

wie schon im betreff - DIL im Text, DIP als Bildunterschrift, und so wie auf dem foto kam er wohl nicht auf den markt, sondern im keramik-gehäuse (Der vorstehende, nicht signierte Beitrag stammt von Untiunte (Diskussion • Beiträge) -- Frank Murmann 09:38, 11. Mär. 2008 (CET))

Laut dem Artikel DIL sind DIL und DIP synonym. -- Frank Murmann 21:40, 10. Mär. 2008 (CET)

VHDL

Der VHDL-Code unter diesem Link ist unvollständig. Es werden lediglich die Befehle decodiert. Die Implementierung fehlt. => Quatsch. http://tams-www.informatik.uni-hamburg.de/vhdl/models/m68000/m68000.vhd

Harvard-Architektur bei PC-relativer Adressierung?

Wie passt das zusammen? Wenn Programm- und Datenspeicher getrennt sind, hat es doch gar keinen Sinn, eine "Datenspeicherzelle" anzusprechen, die "100 Byte der aktuell ausgeführten Code-Adresse" liegt. Oder wie ist das zu verstehen? Wurde so etwas auf irgendeinem System überhaupt genutzt? --RokerHRO 09:11, 29. Sep. 2010 (CEST)

Das passt schon zusammen. Diese Adressierungsart dient dazu, Konstante Daten im Code-Segment (z. B. im ROM) lesen zu können. HaTe 12:15, 29. Sep. 2010 (CEST)

Aber wenn beim Lesen von Daten automatisch das Bus-Signal "Daten" ausgegeben wird, landet der Lesezugriff nicht im Codesegment, sondern im Datensegment. (Wobei der M68k keine Segmente kennt, etwa wie die x86er). Und es steht nirgends im Artikel, dass man dieses Bus-Signal per Software beeinflussen könnte oder dass es bei PC-relativer Adressierung (die bei M86k recht häufig benutzt wird, da man nur so ohne Relokation PIC ermöglicht) auf "Code-Zugriff" statt auf "Datenzugriff" steht. --RokerHRO 20:04, 29. Sep. 2010 (CEST)

Zugriffe für PIC sind _keine_ Datenzugriffe sondern Instruction Fetch aufgrund von _relativen_ Jumps ("BRANCH"). Die Unterscheidung zwischen Programm (-daten), konstanten Daten, variablen Daten habe ich jetzt mal "Segmente" genannt weil die CPU der Speicherzugriffs-Hardware die Möglichkeiten gibt, hier unterschiedliche Speicherbereiche, z. B. ROM / RAM anzusprechen. HaTe 08:31, 30. Sep. 2010 (CEST)

Der M86k kann auch auf Daten lesend und schreibend über eine PC-relative Adressierung zugreifen, im Gegensatz zum 8086, der nur PC-relative (bzw. "IP-relative") Sprunganweisungen kennt. Im Artikel sind auch Beispiele dafür genannt. --RokerHRO 20:13, 30. Sep. 2010 (CEST)

nein, nur _lesend_! "Only data alterable addressing modes", siehe http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf HaTe 23:23, 30. Sep. 2010 (CEST)

Ah, in der Tat: Alle Adressierungsarten, die den PC mit einbeziehen, sind Read-only. Wieder was gelernt. Warum steht das noch nicht im Artikel? Über die Bus-Signale, die dann generiert werden, steht in dem Dokument aber leider nichts. Hast du dafür auch Quellen? Dann ab in den Artikel damit! :-) --RokerHRO 08:41, 1. Okt. 2010 (CEST)

Als Quelle ist nun unter Weblinks eine Dokumentation des Herstellers angegeben. --Steg~dewiki (Diskussion) 18:37, 22. Jul. 2022 (CEST)

Speicherangaben

KiB wird nach Entscheidung per Meinungsbild nicht verwendet: http://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Benennung_von_Datenmengen -- TheBug 22:15, 2. Jan. 2011 (CET)

neun Adressregister

Ich habe die Angabe von acht auf neun Adressregister korrigiert. Das A7 Register, das auch als Stapelzeiger verwendet wird, ist doppelt vorhanden. Im Supervisormodus ist A7 ein der Supervisor-Stapelzeiger 188.98.139.205 19:08, 8. Feb. 2011 (CET)

Neun Adressregister

Wenn schon korrekt, dann bitte 10 Adressregister beim MC68020/030/040/060, da diese Prozessoren einen weiteren physikalischen Stackpointer (MSP = A7) besitzen, der das RTOS Task-Switching unterstützt (siehe mein Buch M68000 Anwendungen Band 2, Anwender- und Systemprogrammierung, Franzis, München 1994, ISBN 3-7723-6303-2). Damit gibt es A0-A6 sowie USP (User Stackpointer), ISP (Interrupt Stackpointer) und MSP (Master Stackpointer). (nicht signierter Beitrag von 91.52.5.29 (Diskussion) 12:28, 25. Jan. 2014 (CET))

68000/16, DIL/PLCC

»Mit dem Übergang zu höheren Taktraten wurden dann ab 16 MHz nur noch 68-polige PLCC-Gehäuse verwendet.«

Beleg? Ich kenne einige Atari-Beschleunigerkarten, mit 16 MHz, die mit einer 68000-16 im DIL-Gehäuse daherkamen. Beleg: 68000, DIL, "16 MHz" und 68000/16, DIL – daher streiche ich den Satz. Götz Hoffart 17:08, 13. Apr. 2015 (CEST)