Ich weiß sehr wohl wann es darauf ankommt, max/min-Werte zu benutzen! Das ist hier nicht das Thema! Die Triggerschwellen korrelieren mit Versorgungsspannung und Temperatur in ganz eindeutiger Weise! Genaus die sich ergebende Hysterese mit der Versorgungsspannung. Die Eingangsschwelle wird durch das Verhältnis der beiden W-Werte der Eingangs-FETs bestimmt. L und W sind stark prozeßabhängig. Damit schwankt der Spannungsübergabepunkt oder wie man es nennen will. Es ist alles streng monoton. Zum Testen kann man ein ungepuffertes Gatter wie HCU04 vom Ausgang auf den Eingang kurzschließen. Die sich ergebende Spannung sollte bei VCC/2 zu liegen kommen.
Jens Petersen schrieb: > Abdul K. schrieb: >> Mit so einem Schrott wie die 6502 > > Auch wieder typisch für Z80 Nutzer; keine Toleranz :-) Auf was willst du hinaus? Mein Liebling ist die 6809 ! Der Z80 war einfach mit mehr Möglichkeiten ausgestattet, wenn man auch die undokumentierten Befehle mitbenutzte. Da gab es beim Z80 eine Unmenge.
Winfried J. schrieb: > Genau deshalb mag ich den 6502 und auch die AVR, alles klar und > übersichtlich. Das ist schmeichelt einem einfach strukturierten alten > Freak und wenn der Adressraum nicht reicht dann gibt es noch > Memorymapping. > > Namaste Na ja, beim 6502 kann man ja von Registerschitektur nicht sprechen. Und die Systemarchitektur war im Grunde auch nicht ausbaufähig. Hauptproblem dabei der 8 bit Stackpointer, d.h. nicht wirklich C kompatibel. Eine 16bit Version des Prozessors ist ja auch am Markt gescheitert (IMO zu recht). Übrigens meinen Apple II besitze ich noch :-) Einschliesslich Z80 Karte, 1 MB Ramdisk (selbstgebaut) und eine 8086 Karte (auch selbst gebaut).
Lattice User schrieb: > Eine 16bit Version des Prozessors ist ja auch am Markt gescheitert (IMO > zu recht). Arg krudes Teil. 2 Jahre nach dem Original hätte das Teil wohl Chancen gehabt, trotz der stumpfsinnigen Architektur. Aber zu dem Zeitpunkt wo das Ding rauskam wars nur noch ein Witz.
Tja, der richtig Zeitpunkt. Das ist immer das Problem Nr.1 Ich habe mal Mr. CMOS himself gefragt wegen des HC14. Ist nur ein Ausschnitt und begann eigentlich mit dem HCU04. Er meinte das (Mein Text mit > ): >I must say that the OnSemi DS for HCU04 is crap. No typical values >there. So no compare possible with model. Data sheets are written to avoid claiming anything they could get sued for =-O > > >Can I ask Mr. CMOS another question? >Why is the trigger level of the 74HC14 not half VCC? It is considerable >lower! >I thought this could be TTL conversion compatibility but there is >another variant 74HCT14 extra for TTL. Strange. >Looking at the 74HC74 there is a schmitt-trigger input function in CLK >input. And now interesting: Here it is half VCC ! Schmitt thresholds are at the discretion of the circuit designer.
MCUA schrieb: > Für typische Embedd-Syst. wollte diese blöde x86-Architektur noch nie > jemand haben. Dafür gibt es aber mehr als genug Systeme, die einen 80188/186 einsetzen. Aber das wird wohl an den recht brauchbaren Entwicklungssystemen liegen, die es dafür schon in den 90ern gab (wie z.B. die DOS-C-Compiler von Borland).
Ebend! Das mit der gewohnten Entwicklungsumgebung und der Tatsache, das die meisten Entwickler/Supporter mit DOS vertraut waren, war immer ein Argument. Gerne auch der miserable 386EX. Das ist aber 10 Jahre her! Heute geht der Zug zu ARM, NET usw. Rufus, die Rente wartet ;-)
Borlands Turbo-Pascal 1.0 lief sogar auf meinem Apple unter CP/M mit Z80 und 64KByte RAM. Der erste Bildschirm orientierte Editor den ich hatte ....
Abdul K. schrieb: > Rufus, die Rente wartet ;-) Ach danke, aber ich fürchte, daß sie das bei mir noch eine ganze Weile lang tun wird.
MCUA schrieb: > Für typische Embedd-Syst. wollte diese blöde x86-Architektur noch nie > jemand haben. Waren (sind) nicht 80186er in den Signalanlagen der Bahn verbaut worden.
Abdul K. schrieb: >>Looking at the 74HC74 there is a schmitt-trigger input function in CLK >>input. And now interesting: Here it is half VCC ! Bei NXP finde ich beim HC74 die gleichen unsymmetrischen Vt+/Vt- Werte wie beim HC14. Und bei TI finde ich bei CLK keinen Schmitt-Trigger.
A. K. schrieb: >> Eine 16bit Version des Prozessors ist ja auch am Markt gescheitert (IMO >> zu recht). > > Arg krudes Teil. 2 Jahre nach dem Original hätte das Teil wohl Chancen > gehabt, trotz der stumpfsinnigen Architektur. Aber zu dem Zeitpunkt wo > das Ding rauskam wars nur noch ein Witz. Das wäre 1977 gewesen. Zu diesem Zeitpunkt wäre aber die Binärkompatibilität zum 6502 kein absolutes Muss gewesen. Als er kam war diese Kompatibilität seine einzige Hoffnung, d.h. für 16bit Versionen der erfolgreichen AppleII und C64. Wobei nur ein AppleIII das Licht der Welt erblickt hat, war aber viel zu spät, auch wegen der Inhouse Konkurrenz. Ob Commodore je eine 16bit Version des C64 erwogen hat ist mir nicht bekannt. Zum Vergleich: 8086 wurde 1978 vorgestellt, der 68000 1979.
Ähnlich bizarre Fortsätze wie W65C816 hat übrigens auch Zilog verbrochen. Wobei die eZ80 mit 24-Bit Adressierung und entsprechenden Registern noch die harmlose Version ist. Wirklich krass ist die Z380, eine 32-Bit Version der Z80.
beide kamen zu spät, mit dem 68000 und sogar mit dem "komischen" 8088 war mehr Speicher (ohne Banking) möglich
A. K. schrieb: > Abdul K. schrieb: > >>>Looking at the 74HC74 there is a schmitt-trigger input function in CLK >>>input. And now interesting: Here it is half VCC ! > > Bei NXP finde ich beim HC74 die gleichen unsymmetrischen Vt+/Vt- Werte > wie beim HC14. Und bei TI finde ich bei CLK keinen Schmitt-Trigger. Die Unterschiede sind eine Katastrophe. Aus analoger Sicht. Hier ist es symmetrisch bei NXP: http://www.nxp.com/documents/data_sheet/74HC_HCT74.pdf
Der große Speicherbereich der 68K hat ihr wenig gebracht, dagegen die 1-2 Jahre frühere Markteinführung dem 8086 den Durchbruch - wie wir ja fast jeder neben dem Schreibtisch stehen sehen. Wobei man aber sagen muß, daß der moderne PC nur noch beim Booten ein 86er ist.
Abdul K. schrieb: > Hier ist es symmetrisch bei NXP: > http://www.nxp.com/documents/data_sheet/74HC_HCT74.pdf Stimmt, da bin ich wohl ins falsche DS gerutscht. Allerdings stehen hier keine Triggerlevels drin, sondern nur die üblichen Eingangsparameter. Deren geringer Eingangsbereich von typ Vil=2.1V/Vih=2.4V bei Vcc=4,5V macht deutlich, dass die Hysterese hier viel kleiner sein muss als beim HC14, es sich folglich um eine anderes aufgebaute Schmitt-Trigger Stufe handelt.
Teilweise brauchten die EPROMs mehr Strom als der Prozessor selbst. Die 2716er EPROMs waren schon richtig vornem die kamen schon mit nur einer Betriebsspannung aus beim lesen entgegengesetzt zum 2708 der umständliche DREI verschiedene Spannungen braucht 5V 12V und -8V. Dann gab es noch so komische TMS2716 von Texas Instruments die auch noch die nervige Stromversorgung will.
Yep. Gutdünken oder Absicht? "Schmitt thresholds are at the discretion of the circuit designer."
Bei den DRAM war an jeder Ecke ein Versorgungsanschluß... Ach, da erinnere ich mich: 2x Angebot genutzt für CMOS 64Kx1 8 Bausteine macht: 128KByte für 340DM.
Abdul K. schrieb: > Der große Speicherbereich der 68K hat ihr wenig gebracht, dagegen die > 1-2 Jahre frühere Markteinführung dem 8086 den Durchbruch - wie wir ja > fast jeder neben dem Schreibtisch stehen sehen. Zum Zeitpunkt der PC-Entscheidung hatte IBM bereits ein 68000 System gebaut, für anderen Zweck. Der Grund für 8088 lag einerseits in den Kosten vom Gesamtsystem, im 8-Bit Bus, und auch die nutzbare 8080-Peripherie spielte eine Rolle. Bei 68000 war beispielsweise das Thema DMA schlecht besetzt (bzw. teuer, sofern überhaupt schon da). Andererseits wurden vielen damalige Entscheidungen von IBM auf einen Aspekt konzentriert: Es durfte keinesfalls der Eindruck entstehen, dass ein solches System über kurz oder lang das lukrative Mainframe-Geschäft verdirbt. Eine aus Sicht der Programmierers 32 Bits breite dem Mainframe ähnliche Architektur hätte aber genau dies nahe gelegt. Auf ähnliche Art hatte IBM auch eine andere Entwicklung versemmelt: IBM hatte in den 70ern eine bahnbrechende RISC-Entwicklung, die aus genau diesem Grund letztlich in einem I/O-Satellitenrechner vergammelte, statt das Mainframe-Geschäft zu vermiesen. Bloss keine schlafenden Hunde wecken. Das taten dann andere.
Abdul K. schrieb: > Yep. Gutdünken oder Absicht? Absicht. Eine Stufe wie beim HC14 hätte die Eingangsbedingungen zu weit von den HC74ern anderer Hersteller ohne Schmitt-Trigger entfernt. Ein nettes Gimick, dass manchmal nützlich ist, aber nicht im Weg stehen darf.
A.K. Du hast es geblickt! Übrigens sind wir wieder beim ollen Terminal angekommen: Windows ist nichts anderes! Achso, wollte noch nachtragen: Meine erste Maus kostete 250DM. Ha ha, war ich blöde.
Abdul K. schrieb: > Der große Speicherbereich der 68K hat ihr wenig gebracht Die 68000 und Folgeversionen waren über lange Zeit sehr erfolgreich, nur eben nicht ganz so erfolgreich wie x86.
Ja, netter Satz. Stammt direkt aus dem Shareholder Geschäftsbericht, oder? Wir haben es vermasselt, aber wir waren gut! So gut, das Apple aus lauter Not den PowerPC einkaufen mußte. Weil Motorola keine gescheite CPU jenseits der 040 zurechtbekam und beim 040 schon nicht genug geliefert wurde.
Abdul K. schrieb: > A.K. Du hast es geblickt! Übrigens sind wir wieder beim ollen Terminal > angekommen: Einerseits ja ... > Windows ist nichts anderes! ... aber andererseits nicht deshalb. Der Terminalbetrieb findet sich in Umgebungen wieder, bei denen die eigentliche Arbeit über Terminal-Services oder virtualisiert auf RZ-Rechnerfarmen abläuft, statt auf dem nun zum Grafikterminal degradierten PC. Oder/und in Form immer mehr browserbasierter Anwendungen - grad da kommt noch einiges auf uns zu. Mit Windows hat das allerdings wenig zu tun.
Für Microsoft, Apple und Computerlibhaber: Super Webseite zu kaputlachen: http://www.stupidedia.org/stupi/Portal:Computer
Was man früher Terminal/ etc. nannte haben wir heute alles wieder, nennt sich nur 'Cloud'. Bestes Beispiel sind Spiele, die in der Wolke gerendert und aufs Tablet gestreamt werden.
Und wie ist so die Sicht auf uns, wenn man 16 ist?
Abdul K. schrieb: > Ja, netter Satz. Stammt direkt aus dem Shareholder Geschäftsbericht, > oder? Wir haben es vermasselt, aber wir waren gut! Es lief ja auch wirklich eine Zeitlang gut, nur war eben irgendwann Schluss. Das ist oft so. War Nokia von Anfang an schlecht oder verdammt? Nein, aber irgendwann... Auch Intel kann es passieren, dass in den nächsten Jahren der halbe Client-Markt wegbricht und bei ARMs landet. Beide Architekturen waren eigentlich am Ende, die ersten 32-Bit x86er wie die 68030/40 Schiene, da der Aufwand für eine zu den RISC vergleichbaren Leistung durch die CISC-Architektur und Fehlentscheidungen unterwegs sehr hoch war. Intel hatte aber aufgrund des grossen Erfolgs der PCs genug Resourcen, um mit dem in der Entwicklung und Produktion sehr teuren Pentium-Pro den Knoten zu durchschlagen. Damit war der Kessel geflickt. Ohne diesen Erfolg wäre Intel längst Geschichte. Motorola hatte weniger Resourcen und eine zu diesem Zeitpunkt deutlich verbautere Architektur (was 1978 gut war, das war 1990 ein Problem). Vieles von dem was die 68020 hinzufügte erwies sich als übler Klotz am Bein, wenns um superskalere Implementierung geht. Mit Coldfire flog das meiste davon wieder raus - und darin lebt die 68000 bis heute weiter. > So gut, das Apple aus > lauter Not den PowerPC einkaufen mußte. Und weil es Intel so schlecht geht werden sie demnächst aus lauter Not teilweise auf ARM umsteigen. > Weil Motorola keine gescheite CPU jenseits der 040 zurechtbekam Möglich wärs gewesen, aber der Aufwand war für Motorola zu gross. Die Entscheidung für eine andere Linie war richtig. Beim Versuch, mit der VAX eine einstmals sehr erfolgreiche nun aber überholte Architektur mit immensem Entwicklungsaufwand noch über die Runden zu retten ist DEC fast vor die Hunde gegangen. Das haben sie dann später zwar nachgeholt, aber es war schon Jahre vorher sehr knapp geworden.
Herrlich off-topic. A.K. kann man stundenlang zuhören.
Ich habe mit dem Thema mal angefangen und möchte mich für eure
Bemühungen bedanken und mich entschuldigen das ich jetzt er wieder
Melde.
wie_warr_das_thema schrieb
> Alles ein wenig "Off-Topic" hier?!
Ist aber wurscht Hauptsache mann hat Spass hier. Das Thema geht mehr
oder weniger um die Alten Prozessoren anfang der Achtziger ende der
Sibziger und deren einsatzorte.
Interessant wäre auuch wass Ihr mit dem r6502 oder ähnlichen angestellt
habt?
bko schrieb: > mit dem 68000 und sogar mit > dem "komischen" 8088 war mehr Speicher (ohne Banking) > möglich 8086/88 hatten das Banking eingebaut, Segmentregister sind nichts als eine komfortable Version davon. Während der 68000 immerhin schon eine ausgewachsene 32bit Architektur hatte. Aber wie A.K. oben ausführte, IBM wollte keine Biligkonkurrenz zum Mainframe. Der 68000 war durchaus erfolgreich, neben Apple gabs ja noch Atari ST und Commodore Amiga. Sowie natürlich jede Menge Industrie-Systeme. (siehe VME Bus).
ich weiß ich weiß, ein 68000 (ein 68008 hätts auch getan) wäre damals ein Traum gewesen, ein lahmer 8088 mit nun endlich 256kByte Speicher wahr einfach billiger und hat meine Apple-2 Platine dann abgelöst...
Abdul K. schrieb: > Und wie ist so die Sicht auf uns, wenn man 16 ist? Amüsant, was die Entwickler jenseits des Atlantiks so vor >30 Jahren erschaffen haben. Allerdings hatte ich als 'Digital/AVR/MSP430 native' nie was mit der Entwicklung für solche 'Steinzeit'-MCUs/MPUs zu tun, und habe auch nicht vor Kuchenbleche voll mit EPROMS, SRAMs, Busdecodern, UARTs etc. anzutun ;) So weiß man erst zu schätzen, wie einfach das heute alles ist...
bko schrieb: > ich weiß ich weiß, ein 68000 (ein 68008 hätts auch getan) > wäre damals ein Traum gewesen, ein lahmer 8088 mit nun > endlich 256kByte Speicher wahr einfach billiger > und hat meine Apple-2 Platine dann abgelöst... Verräter! Ich habe den Umstieg auf x86 immerhin noch mit einem Atari ST um ein paar Jahre hinausgezögert.
purer Geldmangel (heute unvorstellbar wie teuer das Zeug mal war) Aber: die Apple2 Platine lebt noch, der 8088 Computer ist schon lange im Schrott gelandet ...
Die Geschichte zu den Segmentregistern muß nun auch noch kommen: Man wollte ursprünglich echte 20 Bits unterbringen, aber die MMU wurde zu groß! Also speckte man ab. Was dann Intel alles damit trieb, darf A.K. erzählen. Das Konzept wurde ja mehrmals neu betoniert.
Lattice User schrieb: > 8086/88 hatten das Banking eingebaut, Segmentregister sind nichts als > eine komfortable Version davon. Während der 68000 immerhin schon eine > ausgewachsene 32bit Architektur hatte. Aber wie A.K. oben ausführte, IBM > wollte keine Biligkonkurrenz zum Mainframe. > Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! Das fand ich echt nervig. Apple hat da drumrum eine Software-MMU gebaut, die solche Segmente automatisch nachlud. Elegante Lösung für ein Problem. Erst der 68010 war was gescheites. Dann hätte Apple auch leichter auf Multitasking gehen können. Da mußten sie dann wieder endlos tricksen, denn nun mußte es beim 68020 zum alten Konzept der 68000 kompatibel bleiben.
Abdul K. schrieb: > Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! Was darf ich mir denn darunter vorstellen? Segmente gabs ja seitens der CPU überhaupt keine, MMU gabs auch nicht und die Adressierung war linear 32-bittig. Wer eine MMU brauchte machte sie sich selber - und wenns bloss mein Design aus ein paar 74LS670 + 74S283 war, mit max je 8MB grossem Code-, Daten und Stacksegment.
Man konnte bei den Relativsprüngen nur vorzeichenbehaftete 16-Bit Offsets angeben. Will man Code-Segmente im Speicher verschieben, geht sowas nur mit Relativsprüngen im Code. Absolutsprünge müßte man neu berechnen! Das ist aber Binärcode, was im Speicher steht! Vielleicht bin ich zu sehr Apple-lastig. Das war eben meine 68K Assemblerplattform. Der Apple Memory-Manager hat diese Segmente nämlich für einen komfortabel verwaltet, automatisches Nachladen von Segmenten von der Diskette usw. Jedenfalls durften sie dort dann nur 32K groß werden. Bei A.K. war bestimmt alles viel besser ;-)
Abdul K. schrieb: > Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! Das fand ich echt > nervig. Apple hat da drumrum eine Software-MMU gebaut, die solche > Segmente automatisch nachlud. Elegante Lösung für ein Problem. > Erst der 68010 war was gescheites. Dann hätte Apple auch leichter auf > Multitasking gehen können. Da mußten sie dann wieder endlos tricksen, > denn nun mußte es beim 68020 zum alten Konzept der 68000 kompatibel > bleiben. Das ist nicht richtig, der 68000 hatte eine 32 bit lineare Addressierung, sowohl für Programmcode als auch für Daten. Relative Sprünge waren auf +/- 32 kByte begrenzt, sowie bei Datenaddressierung mit Baseregister und Offset war auch der Offset nur auf 16 Bit begrenzt. Das machte es schwierig Programme im Speicher beliebig zur Laufzeit rumzuschieben. Der 68010 (als auch der 68020) konnte dann mit einer externen MMU umgehen, der 68030 hatte sie dann eingebaut.
Abdul K. schrieb: > Man konnte bei den Relativsprüngen nur vorzeichenbehaftete 16-Bit > Offsets angeben. Will man Code-Segmente im Speicher verschieben, geht > sowas nur mit Relativsprüngen im Code. Nur wenn du aus "ging bloss" ein "so war es am einfachsten" machst. > Bei A.K. war bestimmt alles viel besser ;-) Besser als so ein Gefrickel jedenfalls schon. Bischen simples Dualport-Mem, ein paar Addierer und Komparatoren und fertig ist eine einfache segmentierte MMU, die für Code und Daten unabhängige Basisadressen und Limits vorgibt. Fast verzögerungsfrei, d.h. ohne Waitstate, und mit problemlos verfügbaren billigen Komponenten. Luxus war das nicht, kein Paging, aber Adressraumtrennung und OS-definiere Segmentbasisadressen waren damit möglich. Klar, mit 68010 funktioniert das besser, aber segmentiert mit je einem einzigen Segment für Code, Daten/Stack gibts ohnehin kein Paging oder partielles Swapping, also ist ein Wiederaufsetzen nach Bus-Error nicht zwingend.
Lattice User schrieb: > A. K. schrieb: >>> Eine 16bit Version des Prozessors ist ja auch am Markt gescheitert (IMO >>> zu recht). >> >> Arg krudes Teil. 2 Jahre nach dem Original hätte das Teil wohl Chancen >> gehabt, trotz der stumpfsinnigen Architektur. Aber zu dem Zeitpunkt wo >> das Ding rauskam wars nur noch ein Witz. > > Das wäre 1977 gewesen. Zu diesem Zeitpunkt wäre aber die > Binärkompatibilität zum 6502 kein absolutes Muss gewesen. Als er kam war > diese Kompatibilität seine einzige Hoffnung, d.h. für 16bit Versionen > der erfolgreichen AppleII und C64. Wobei nur ein AppleIII das Licht der > Welt erblickt hat, war aber viel zu spät, auch wegen der Inhouse > Konkurrenz. Ob Commodore je eine 16bit Version des C64 erwogen hat ist > mir nicht bekannt. > > Zum Vergleich: 8086 wurde 1978 vorgestellt, der 68000 1979. Der AppleIII hatte auch "nur" einen 6502, der aber mit 2MHz lief. Die 16bit Version war der AppleIIGS. Und das der gescheitert ist, kann man nicht sagen. Einen leider etwas unvollständigen Überblick finden man bei Wikipedia: http://de.wikipedia.org/wiki/Apple_IIgs Über die Zeit gab es drei Mainboad-Versionen (ROM 00, ROM 01 u. ROM3). Bei der Einstellung des Modells war eine komplett überarbeitete neue Version (ROM 04 - Codename "Mark Twain") kurz vor der Markteinführung. Die CPU wurde nur mit 2,8MHz getaktet. Es gab aber Beschleunigerkarten mit einer 7MHz CPU, die man später als es noch schnellere CPUs gab (14MHz) auch austauschen konnte.
Abdul K. schrieb: > Man konnte bei den Relativsprüngen nur vorzeichenbehaftete 16-Bit .... Ich habe lange zum posten bebraucht. Aber wie die schreibst war das eine Einschräunkung die sich Apple selbst auferlegt hatte. Beim Atari (das weiss ich sicher) als auch vermutlich beim Amiga gabe es diese Einschränkung nicht.
>Zum Zeitpunkt der PC-Entscheidung hatte IBM .. bewusst den schlechtesten, nicht den besten Prozessor ausgewählt. >Die Geschichte zu den Segmentregistern... gibt es nur weil Intel beim 4004 nicht an grössere Bereiche gedacht hatte (und schlecht von ner DEC abgeguggt hatte ; so extrem schlecht, dass nichtmal vernünftige Stack-adr. möglich war) > Für typische Embedd-Syst. wollte diese blöde x86-Architektur noch nie > jemand haben. Ein paar Ausnahmen gibt es. Aber mit 68k hat die Industrie (nicht PC-Indust.) gejubelt. Sehr viele Systeme sind damit gemacht worden (Stichwort Werkzeug u. CNC-Maschinen, VMEbus) Ja, beim Coldfire ist vieles vom 68k rausgeschmissen worden. Denke mal, dass das später wieder rein kommt(!) Denn RISC ist zwar neuer als CISC, aber es kommt auch immer mehr CISC wieder in RISC rein.
MCUA schrieb: >>Die Geschichte zu den Segmentregistern... > gibt es nur weil Intel beim 4004 nicht an grössere Bereiche gedacht > hatte Intel hat zwar viel auf dem Kerbholz, aber das ist mit Verlaub gesagt an den Haaren herbeigezogen.
MCUA schrieb: > Ja, beim Coldfire ist vieles vom 68k rausgeschmissen worden. > Denke mal, dass das später wieder rein kommt(!) Schon passiert. Die erste Generation war etwas zu radikal rasiert wurden. Aber was dann dazu kam war teils auch völlig neu. Das Hauptproblem der 68020-Erweiterung waren die extrem schlecht dekodierbaren und viel zu komplexen Adressierungsarten. Einzig die anno 68000/10 seltsamerweise fehlende Skalierung vom Index war sinnvoll, der gesamte Rest überflüssig bis schädlich.
A. K. schrieb: > Einzig die anno > 68000/10 seltsamerweise fehlende Skalierung vom Index war sinnvoll Adressregister indirekt mit 32bit Displacement ist doch auch sinnvoll. Ist doch das was Abdul beim 68000 so schmerzlich vermisst hat. Das ganze Memoryindirekt geraffel war aber dann doch zu Arg auf den Mainframe geschielt.
Lattice User schrieb: > Abdul K. schrieb: > Das ist nicht richtig, der 68000 hatte eine 32 bit lineare > Addressierung, sowohl für Programmcode als auch für Daten. > Relative Sprünge waren auf +/- 32 kByte begrenzt, sowie bei > Datenaddressierung mit Baseregister und Offset war auch der Offset nur > auf 16 Bit begrenzt. Das machte es schwierig Programme im Speicher > beliebig zur Laufzeit rumzuschieben. > Der 68010 (als auch der 68020) konnte dann mit einer externen MMU > umgehen, der 68030 hatte sie dann eingebaut. Ja, schrieb ich doch.
So lese und höhre ich euch zu, wie ihr schwelgt in tiefer Trauer. Die CPU´s heute werden kleiner und auch schlauer. Eines Tages wenn wir gehn werden 6502 vertikal als Grabstein stehn. Klaus
Klaus De lisson schrieb: > Die CPU´s heute werden kleiner und auch schlauer. Das mit dem schlauer wage ich zu bezweifeln. Die nehmen einen immer noch wörtlich und machen nie das was man wirklich will ;)
Lattice User schrieb: > Adressregister indirekt mit 32bit Displacement ist doch auch sinnvoll. > Ist doch das was Abdul beim 68000 so schmerzlich vermisst hat. Vermisst, weil keine MMU. Ein Compiler kommt ganz gut ohne aus. Das selbst wäre aber nicht das Problem gewesen - die Codierung war es. Das Problem liegt darin, dass zwar in der 68000 aus dem ersten Codewort die Gesamtlänge des Befehls ableitbar war, nicht aber in der 68020, da die Länge des Adressteils eines Operanden nicht mehr nur vom Codewort sondern vom Inhalt des Adressteils selbst abhing. Noch schlimmer war das bei zwei solchen Adressen im MOVE-Befehl. Denn dann konnte die Position des zweiten Adressfelds erst bestimmt werden, wenn die Länge des ersten Adressfelds ermittelt war. Und erst nach der Dekodierung des zweiten Adressfelds wusste man, wie lang der Befehl insgesamt überhaupt war. Und nun versuch bei sowas mal 2-3 Befehle pro Takt zu dekodieren. Prost Mahlzeit. IMHO hats schon bei 68040 spätestens aber mit 68060 die Empfehlung gegeben, diesen Kokolores nicht zu nutzen, weil schneller ohne. > Das ganze Memoryindirekt geraffel war aber dann doch zu Arg auf den > Mainframe geschielt. Und völlig für die Katz. Zeit spart es jedenfalls keine, nur bischen Register und Platz. Dafür ist aber ein vollständiger Retry von Befehlen mit Pagefault aufgrund der diversen möglichen Überlappungen von Operanden kaum durchführbar. Daher auch die in der gesamten übrigen Prozessorwelt unübliche und sehr zeitraubende Methode des Mikrocode-Interrupts. Der Ablauf solcher Befehle bringt ausserdem jene Pipeline zur Verzweiflung. In heutigen Implementierungen von Intel und AMD wäre das kein wesentliches Problem mehr. Aber damals war aufgrund von Pipeline-Effekten der Ersatzcode aus mehreren Befehlen deutlich schneller, weil man unbhängigen Code dazwischen einstreuen kann.
>Die CPU´s heute werden kleiner und auch schlauer.
Schlauer? Manche werden dümmer! Nur schneller werden sie alle.
Lattice User schrieb: > Das ganze Memoryindirekt geraffel war aber dann doch zu Arg auf den > Mainframe geschielt. Nicht auf Mainframe, die IBMs sind vergleichsweise simpel gestrickt. Das Vorbild war die DEC VAX, nachdem ja die 68000 unübersehbar von der DEC PDP-11 inspiriert war. Die VAX kriegte aber kurz drauf selbst genau das beschriebene Problem und brach DEC fast den Hals.
MCUA schrieb: > Schlauer? Manche werden dümmer! Nur schneller werden sie alle. Nö, manche werden langsamer. Grad in jüngster Zeit. Intels Schritt zum Atom beispielsweise, aber auch AMDs Brazos. Selbst AMDs Bulldozer wird als eher ein Tick langsamer pro Core vermutet.
A. K. schrieb: > Dafür ist aber ein vollständiger Retry von Befehlen > mit Pagefault aufgrund der diversen möglichen Überlappungen von > Operanden kaum durchführbar. Daher auch die in der gesamten übrigen > Prozessorwelt unübliche und sehr zeitraubende Methode des > Mikrocode-Interrupts. Bist du sicher dass nicht schon der 68010 Microcode Interrupts hatte? Bei einer 2 Address Architektur liegt das Nahe um Mehrdeutigkeiten beim Retry zu vermeiden, z.B. weil man im ersten und im zweitem Operanden das gleiche Register mit Postincrement benutzt. Da mir das 68010 Usermanual in meiner Sammlung fehlt kann ich das nicht überprüfen. Apropos Microcode Interrupts. Auf manchen Mainframes wurde bei Memoryindirekt nicht nur die Addresse nachgeladen sondern auch die Addressmodifier. (Z.B. Univac 110x) Damit kann man eine schöne Endlosschleife im Microcode erzeugen, und wenn dieser nicht Interruptable ist steht die Maschine. Und wenn der Frontpanel Reset Button auch vom Microcode abgefragt wurde, ouch. Hatte ich gerüchterweise damals von Telefunkenmainframes gehöhrt.
Es gab einige ominöse Bit-Felder beim Interrupt-Frame auf dem Stack. Die waren im Handbuch nicht weiter ausgeführt. Ich befürchte, du hast Recht.
Lattice User schrieb: > Bist du sicher dass nicht schon der 68010 Microcode Interrupts hatte? Hatte er. Wenn man den 68010 komplett neu designed hätte, dann wäre es evtl. auch ohne Mikrocode-Interrupt gegangen. Hatte man aber nicht. NatSemi hatte das bei der 32000 mit Retry gemacht. Hat die Befehle um eine Latte von Einschränkungen bereichert - und die Chips um ein paar nette Bugs. > Bei einer 2 Address Architektur liegt das Nahe um Mehrdeutigkeiten beim > Retry zu vermeiden, z.B. weil man im ersten und im zweitem Operanden das > gleiche Register mit Postincrement benutzt. Sowas kann man mit Schattenregistern abwickeln. > Apropos Microcode Interrupts. Auf manchen Mainframes wurde bei > Memoryindirekt nicht nur die Addresse nachgeladen sondern auch die > Addressmodifier. Nicht bloss die. Auch ein paar kleinere Kisten mit speicherindirekter Adressierung und Indirektionsbit in der Adresse. PDP-8 beispielsweise.
A. K. schrieb: > Nicht auf Mainframe, die IBMs sind vergleichsweise simpel gestrickt. Das > Vorbild war die DEC VAX, nachdem ja die 68000 unübersehbar von der DEC > PDP-11 inspiriert war. Die VAX kriegte aber kurz drauf selbst genau das > beschriebene Problem und brach DEC fast den Hals. Mit den IBMs kenne ich mich nicht aus, aber es gab noch andere, die hatten definitiv Memoryinderikte Addressierung, z.B. Univac 1106 (mein erster). Die VAX ist natürlich CISC schlechthin, man müsste dafür den Begriff VCISC einführen. Aber ich hatte bei ihrer Einführung nicht den Eindruck dass DEC Probleme hatte. Bis diese zum Klotz am Bein wurde hatte sie sich doch 15 Jahre gut verkauft.
Lattice User schrieb: > VCISC einführen. Aber ich hatte bei ihrer Einführung nicht den Eindruck > dass DEC Probleme hatte. Bis diese zum Klotz am Bein wurde hatte sie > sich doch 15 Jahre gut verkauft. Eben, das meinte ich doch. Wie bei der 68000 Familie, Anfangs kann man sich komplexe Befehle mit hochgradig sequentieller Dekodierung und Ausführung leisten. Spart Platz und der ist Geld wert. Irgendwann ist dann aber Schluss mit innerem Gänsemarsch und du willst einen Befehl pro Takt, oder noch mehr. Und dann wirds bös. Das ist eigentlich der Zeitpunkt, sich Neues auszudenken. Wenn man kann und darf. Auch Intel hat schon dreimal versucht, sich vom Fluch der 8080/x86-Histore zu befreien. Der erste Versuch (432) war ein schnarchlangsames Komplexitätsmonster der Extraklasse und scheiterte deshalb schon im Ansatz. Der zweite (860) war ein recht schräger RISC und interessierte nur ein paar Spezialisten. Der dritte (IA64) verhungert grad dank AMDs 64-Bit Intervention.
A. K. schrieb: > Eben, das meinte ich doch. Verstanden, aber so gesehen hat das DEC das Genick gebrochen. Gibt es schliesslich nicht mehr. > Wie bei der 68000 Familie, Anfangs kann man > sich komplexe Befehle mit hochgradig sequentieller Dekodierung und > Ausführung leisten. Spart Platz und der ist Geld wert. Irgendwann ist > dann aber Schluss mit innerem Gänsemarsch und du willst einen Befehl pro > Takt, oder noch mehr. Da hast du natürlich vollkommen recht. Intel hat für dieses Problem allerdings eine Lösung gefunden, Zerlegung des CISC Befehls in mehrere RISC Befehle die dann in die Pipeline geschoben werden. Allerdings ist der 80x86 relativ einfach im Vergleich zur VAX. Intel hatte allerdings mehr Zeit eine Lösung zu finden, denen stand keine erfolgreiche Konkurrenz im gleichen Markt mit RISC Prozessoren im Nacken.
Lattice User schrieb: > Verstanden, aber so gesehen hat das DEC das Genick gebrochen. Gibt es > schliesslich nicht mehr. Letzten Endes ja. Da ging zu viel Geld den Bach runter. Aber sie hatten es danach noch viele Jahre geschafft, mit Alpha. > Intel hat für dieses Problem allerdings eine Lösung gefunden, Zerlegung > des CISC Befehls in mehrere RISC Befehle die dann in die Pipeline > geschoben werden. Genau das meinte ich ja mit dem oben erwähnten Pentium Pro. Strukturelle Ähnlichkeit dazu lässt sich bis heute in den Intel Prozessoren finden, ausgenommen Atom und die Abirrung Pentium 4. Einzig war Intel damit allerdings nicht. AMD hatte um den Dreh herum den K5 und der Designzwerg Nexgen kam damit sogar als Erster raus. Intels Produkt war allerdings eine Klasse besser (und teurer).
A. K. schrieb: > Auch Intel hat schon dreimal versucht, sich vom Fluch der > 8080/x86-Histore zu befreien. Der erste Versuch (432) war ein > schnarchlangsames Komplexitätsmonster der Extraklasse und scheiterte > deshalb schon im Ansatz. Gab es den 432 überhaupt? Ich denke nicht dass Intel zu diesem Zeitpunkt den x86 bereits als Fluch betrachtet hat. Der 432 war einfach die nächste geplante Generation. Ich hatte ein Usermanual, war nicht viel dünner als das VAX Prozessorhandbuch. > Der zweite (860) war ein recht schräger RISC > und interessierte nur ein paar Spezialisten. Der dritte (IA64) > verhungert grad dank AMDs 64-Bit Intervention. Der IA64 ist dabei noch nicht mal Intels eigenes Gewächs sondern wurde von HP übernommen (und natürlich etwas weiterentwickelt). Mit der AMD64 aka Intel x64 habe ich mich ehrlich gesagt noch nicht auseinader gesetzt, das einzige was ich mir mal angesehen habe ist die Registerarchtektur und das sieht schön symmetrisch aus. Ist der AMD x64 jetzt CISC oder RISC?
Lattice User schrieb: > Gab es den 432 überhaupt? Gute Frage. Ich glaube den gab es wirklich. Aber nicht in Systemen, eher im Prototypenstadium. > Ich denke nicht dass Intel zu diesem Zeitpunkt den x86 bereits als Fluch > betrachtet hat. Nein. Der 432 war als eigentliche nächste Generation nach 8080 vorgesehen, mit 8086 als Interimslösung - und 286 als Rettungsboot. > Der IA64 ist dabei noch nicht mal Intels eigenes Gewächs sondern wurde > von HP übernommen (und natürlich etwas weiterentwickelt). Wer da nun genau was einbrachte weiss ich nicht, aber zur "Blüte" entwickelt wurde er letztlich von beiden zusammen. > Ist der AMD x64 jetzt CISC oder RISC? Wie x86, aber mit 64-Bit Registern und doppelter Anzahl, d.h. 16 statt 8. Plus ein paar Kleinigkeiten wie PC-relativer Datenadressierung.
He Leute, was geht den hier ab? hab hier noch 1x UM6502 uns 2x UM6522 rumliegen! bin ich jetz reich oder was? Was soll ich mit dem Zeugs anfangen? mfg Manfred
Manfred John schrieb: > Was soll ich mit dem Zeugs anfangen? Darfs eine ehrliche Antwort sein? Tonne auf, rein, Tonne zu.
A. K. schrieb: >> Ist der AMD x64 jetzt CISC oder RISC? > > Wie x86, aber mit 64-Bit Registern in doppelter Anzahl, d.h. 16 statt 8. Soweit ich das verstanden habe, sind diese Register nicht mehr an spezielle Funktionen gebunden, z.B. wie (e)cx als Zähler bei den "rep move" Befehlen in der x86 Variante. Aber genug von Intels Verirrungen :-) Zurück zu den 8 Bittern. Wie ist eure Meinung welches der erfolgreichste 8 Bitter ist (einschliesslich Embedded)? Meine Rangliste: Platz 1: 8051 (und Varianten) Platz 2: 8048 (und Varianten) Platz 3 und folgende, keine Meinung.
Lattice User schrieb: > Soweit ich das verstanden habe, sind diese Register nicht mehr an > spezielle Funktionen gebunden, z.B. wie (e)cx als Zähler bei den "rep > move" Befehlen in der x86 Variante. Daran hat sich nichts geändert. Das sind ja ohnehin Spezialbefehle, die allgemeinen Befehle sind schon seit jeher fast alle auf alle Register anwendbar. Shift-Count ist immer noch in CL. Es ist auch die gleiche Codierung. Mit optionalem Präfix-Byte für 3 obere Bits der Registernummern, und 1 Bit für 64-Bit Operationen. Gestrichen wurden eben dafür die INC/DEC Opcodes auf Register.
A. K. schrieb: > > allgemeinen Befehle sind schon seit jeher fast alle auf alle Register > anwendbar. Nicht wirklich, z.B. mul/div will einen Operanten immer in (e)ax und lieferte das Ergebniss immer in (e)ax und (e)dx ab. Beim 68000/PDP 11/VAX gab da keine Einschränkung, und ich wage zu behaupen auch bei keinen der RISCs.
Hey, das Posting zu ändern während ich antworte ist unfair :-) A. K. schrieb: > Es ist auch die gleiche Codierung. Mit optionalem Präfix-Byte für 3 > obere Bits der Registernummern, und 1 Bit für 64-Bit Operationen. > Gestrichen wurden eben dafür die INC/DEC Opcodes auf Register. Präfix byte mit 3 bit Registernummerergänzung stellt natürlich die Registersymmentrie her.
Lattice User schrieb: > Nicht wirklich, z.B. mul/div will einen Operanten immer in (e)ax und > lieferte das Ergebniss immer in (e)ax und (e)dx ab. Deshalb ja "fast". Aber Multiplikation mit einfach genauem Ergebnis gab es schon vorher ohne Kopplung an AX/DX. Anfangs nur mit Konstante, später dann auch r mit r/m. > und ich wage zu behaupen auch bei keinen der RISCs. IBMs Power hatte ursprünglich ein MQ-Register für diverse Operationen wie Multiplikation, Division und 64-Bit Shift/Mask-Ops. Ist keine gute Idee wenn man das Pipelinen will, weshalb das mit PowerPC einkassiert wurde.
Lattice User schrieb: > Präfix byte mit 3 bit Registernummerergänzung stellt natürlich die > Registersymmentrie her. Nein. Das sind die 3 Bits, die für die 3 maximal im Befehl codierbaren Register fällig werden, wenn man davon 16 statt 8 hat, also die jeweils obersten Bits. Weshalb 8/6/32-Bit Befehle mit ausschliessich den alten Registern keinen Präfix brauchen. Was vorher unsymmetrisch war ist es hinterher auch noch. Ach ja: Eine Symmetrie kam doch hinzu. Mit (ggf leerem) Präfix sind alle 16 Register in Byte-Operationen nutzbar.
A. K. schrieb: > Lattice User schrieb: > >> Präfix byte mit 3 bit Registernummerergänzung stellt natürlich die >> Registersymmentrie her. > > Nein. Das sind die 3 Bits, die für die 3 maximal im Befehl codierbaren > Register fällig werden, wenn man davon 16 statt 8 hat, also die jeweils > obersten Bits. Weshalb 8/6/32-Bit Befehle mit ausschliessich den alten > Registern keinen Präfix brauchen. Ok, danke. Wieder etwas schlauer ;-)
Lattice User schrieb: > Zurück zu den 8 Bittern. > Wie ist eure Meinung welches der erfolgreichste 8 Bitter ist > (einschliesslich Embedded)? > > Meine Rangliste: > Platz 1: 8051 (und Varianten) > Platz 2: 8048 (und Varianten) > Platz 3 und folgende, keine Meinung. Wenn man sich auf Controller bezieht, die 4-Bitter wegläßt, ebenso die Japaner, dann ja.
Abdul K. schrieb: > Lattice User schrieb: >> Zurück zu den 8 Bittern. >> Wie ist eure Meinung welches der erfolgreichste 8 Bitter ist >> (einschliesslich Embedded)? >> >> Meine Rangliste: >> Platz 1: 8051 (und Varianten) >> Platz 2: 8048 (und Varianten) >> Platz 3 und folgende, keine Meinung. > > Wenn man sich auf Controller bezieht, die 4-Bitter wegläßt, ebenso die > Japaner, dann ja. 4 bitter hatte ich nicht eingeschlossen. Bei den 8 bittern meine ich schon alle, also Controller, reguläre CPUs allerdings echte 8 bitter wie 8080, 6502, Z80 etc. 8088/68008 gehören nicht dazu. Dazu zählen auch IP Versionen in ASICs/FPGAs. Du bist also der Meinung bist einem Japaner (z.B. NEC µPD78xx) gehöhrt nach diesen Kriterien der Spitzenplatz?
Manfred John schrieb > hab hier noch 1x UM6502 > uns 2x UM6522 > rumliegen! > bin ich jetz reich oder was? > Was soll ich mit dem Zeugs anfangen? Z.B. ins Ebay stellen oder an ein Museum oder Etwas hübsches bauen wie z.B. Eine Dcf77 Uhr und vielleicht noch dafür den RIOT IC 6532 zulegen. p.s.: Elektor hatte da mal so Projekte. (Juniorcomputer,etc...)
Lattice User schrieb: > Bei den 8 bittern meine ich schon alle, also Controller, Guten Morgen, obwohl Ihr wohl noch schlaft. Wenn ich mich richtig erinnere, haben/hatten die 68HC08/68HC11 den größten Marktanteil. Die fehlen ganz in der Auflistung.
Gn Morgen auch, klar vorne liegt die 8051 Familie bei der Zahl der Hersteller, hier aus der Keil-Seite: http://www.keil.com/c51/chips.asp Praktisch jede Fab. hat so ein Teil im Angebot.
Ja, der i432 sollte als Nachfolger von 8080/8085 gelten (Intel hatte da schon die Haken v. 8080/8085 erkannt), aber der i432 hinkte dem Zeitplan hinterher. Und weil Motorola mit ihren CPUs mächtig Konkurenz gemacht hatte (oder auch weil der i432 nicht kompat. war?), hat Intel dann auch am 8086 gearbeitet. Später mal hat Intel (mit AD zusammen) beim Blackfin aber keinen Fehlgriff gemacht, und hat Teile der Register-Archit. vom 68k abgeguggt. > ... der erfolgreichste 8 Bitter .... ist schwer zu definieren, da man das Wort 'erfolgreich' schwer definieren kann. Handhabung? Preis? Stückzahl-ingesamt? Projekt-Anzahl? Entwickler-Ärgernisse? Laufzeit über Jahre gesehen? Sec.Sources?
Jens Petersen schrieb: > Wenn ich mich richtig erinnere, haben/hatten die 68HC08/68HC11 den > größten Marktanteil. Die fehlen ganz in der Auflistung. Das wundert mich jetzt etwas, daß diese Familie den größten Marktanteil gehabt haben soll. Denn, ein 68HC11 befindet sich bei mir nur in einem einzigen Gerät, dem EPROMMER. Vor Jahren schlachtete ich noch viele Altgeräte vom Schrott, und dort begegnete mir mindestens um den Faktor 10 öfter der 8051. Klar ist die Auswahl der Schlachtgeräte nicht ganz repräsentativ, aber man bekommt einen kleinen Eindruck. Der 8051 ist ganz nett, und es gibt sicher Gründe, warum er bis heute überlebte, und noch lange nicht ausstirbt. Etwas stören tut gelegentlich mal der kleine Hardwarestack, wenn man nicht sorgfältig programmiert. Das ist eben einer der Unterschiede zwischen µC und µP, da waren die µP überlegen. In Assembler ist z.B. meine DCF77-Uhr programmiert, hat nur etwa 3-4kByte Code. Aber der Stack hat schon eine Tiefe von 64 Byte, wobei er sich diese mit dem internen RAM der Größe 128 Byte teilt, und dort auch noch die Registerbänke mit drin liegen. Da muß man also etwas aufpassen und sorgfältig arbeiten. Zum Test installierte ich zusätzlich zur manuellen Berechnung und Simulation noch einen Stack-Check-Code, den ich dann später wieder entfernte. Mittlerweile wurde er ja auch an vielen Stellen verbessert, den Core gibt es mit 2 anstatt 12 Clockzyklen, und SiLabs hat Typen mit Taktfrequenzen um 100MHz. Damit eignen sie sich besonders gut für Hochsprachen. Flash wurde ins Innere verfrachtet, leistungsfähige On-Chip-Peripherie gibt es auch. Der 8048 hatte ja eigentlich nur ein kurzes Leben ab 1976, bis er 1980 vom 8051 abgelöst wurde. Immerhin war es aber der erste 8-bit-µC, und leben tut der heute auch noch. Große Dinge kann man dank 4k Speichergröße damit auch nicht bewegen, aber z.B. mal eine PC-Tastatur scannen und über Soft-UART mit dem PC kommunizieren. Etwa 1980 installierte ich bei Kunden die damals neue FTA (Familientelefonanlage), und das Ding war recht störungsanfällig. Dort war auch ein 8048 drin, aber als 8035 mit externem EPROM. Das war sicher auch gut so, denn der Service konnte so leicht die Software auswechseln. In der Anfangszeit mußten die Anlagen nach der Installation beim Kunden noch bis zu drei mal ausgewechselt werden, und Software-Bugs gab es auch reichlich. Der µC lief aber nach Inbetriebnahme ununterbrochen durch, bis die Anlage irgendwann mal aus Altersgründen ausgewechselt wird.
Kann man den 6510 der in den C64 verbaut war auch als normalen 6502 benuten? Sind die soweit compentibel?
Prozessorsammler schrieb: > Kann man den 6510 der in den C64 verbaut war auch als normalen 6502 > benuten? > Sind die soweit compentibel? Jein. Auf den Adressen 0 und 1 liegt der I/O Port und durch den sind die auch nicht Pinkompatibel. Die Befehe sind soweit gleich.
>> Wenn ich mich richtig erinnere, haben/hatten die 68HC08/68HC11 den >> größten Marktanteil. Die fehlen ganz in der Auflistung. >Das wundert mich jetzt etwas... Die 68HC05/08/68HC11 (auch ST6,7) waren/sind in der AutomobilBranche schwer vertreten.
MCUA schrieb: > Die 68HC05/08/68HC11 (auch ST6,7) waren/sind in der AutomobilBranche > schwer vertreten. Dort waren/sind auch die 8051 stark vertreten.
Den 68HC11 gab es wohl auch im PLCC68-Gehäuse, wie den 80C515. Ich kenne den 68HC11 im Detail nicht, befürchte aber, daß die Unterschiede nicht wirklich allzu groß sind.
Wilhelm Ferkes schrieb: > Vor Jahren schlachtete ich noch viele Altgeräte vom Schrott, und dort > begegnete mir mindestens um den Faktor 10 öfter der 8051. Klar ist die > Auswahl der Schlachtgeräte nicht ganz repräsentativ, aber man bekommt > einen kleinen Eindruck. > Den Eindruck hatte ich auch. Neben den Japanern eben. Neuerdings Chinesen und Korea. > Der 8051 ist ganz nett, und es gibt sicher Gründe, warum er bis heute > überlebte, und noch lange nicht ausstirbt. > Ebend. Cypress hat ihn gerade wieder in eine neue Linie eingebaut. > Etwas stören tut gelegentlich mal der kleine Hardwarestack, wenn man > nicht sorgfältig programmiert. Das ist eben einer der Unterschiede > zwischen µC und µP, da waren die µP überlegen. In Assembler ist z.B. > meine DCF77-Uhr programmiert, hat nur etwa 3-4kByte Code. Aber der Stack > hat schon eine Tiefe von 64 Byte, wobei er sich diese mit dem internen > RAM der Größe 128 Byte teilt, und dort auch noch die Registerbänke mit > drin liegen. Da muß man also etwas aufpassen und sorgfältig arbeiten. > Zum Test installierte ich zusätzlich zur manuellen Berechnung und > Simulation noch einen Stack-Check-Code, den ich dann später wieder > entfernte. > Du bist doch fit! Der Keil-Assembler legt dir allerdings die Objekte alle schön selbständig ab! Da muß man solange man nicht Pointer benutzt, keinerlei Arbeit reinstecken. Auch das Overlay funzt super. Gibt es Assembler, die das nicht können? > scannen und über Soft-UART mit dem PC kommunizieren. Etwa 1980 > installierte ich bei Kunden die damals neue FTA (Familientelefonanlage), > und das Ding war recht störungsanfällig. Dort war auch ein 8048 drin, > aber als 8035 mit externem EPROM. Das war sicher auch gut so, denn der > Service konnte so leicht die Software auswechseln. In der Anfangszeit > mußten die Anlagen nach der Installation beim Kunden noch bis zu drei > mal ausgewechselt werden, und Software-Bugs gab es auch reichlich. Der > µC lief aber nach Inbetriebnahme ununterbrochen durch, bis die Anlage > irgendwann mal aus Altersgründen ausgewechselt wird. Damals konnte man selbst so noch Gewinn machen :-)
>Den 68HC11 gab es wohl auch im PLCC68-Gehäuse, wie den 80C515. Ich kenne >den 68HC11 im Detail nicht, befürchte aber, daß die Unterschiede nicht >wirklich allzu groß sind. Hä? total anders.
Er meinte wohl, den HC11 gäbe es in verschiedenen Gehäusevarianten, eben auch in PLCC68 so wie den 515. Den 515 gibts aber NUR in diesem Gehäuse. Ich finde den 8051 recht gelungen: Bit-Befehle, genialer I/O. Er war nie für große Programme gedacht! Man muß auch immer den Compiler dazusehen. Und da ist man beim 8051 mit dem Keil eindeutig im Vorteil. Die Software ist ausgereift und hochoptimierend. Nacharbeit im erzeugten Code lohnt nicht.
Wilhelm Ferkes schrieb: > Den 68HC11 gab es wohl auch im PLCC68-Gehäuse, wie den 80C515. Ich kenne > den 68HC11 im Detail nicht, befürchte aber, daß die Unterschiede nicht > wirklich allzu groß sind. Das sehe ich aber anders. Zum Einen ist der HC11 um einiges schneller unterwegs, da er intern durch 4 teilt und nicht durch 12. Dann hat er nicht diese fiese Stack-Einschränkung, von Neumann, kann 16 Bit dividieren, hat Unterstützung für Zahlen mit Vorzeichen, usw. Ich habe übrigens früher immer gern die OTP-Variante (im Speziellen den 711E9 mit 12 k OTPROM und 512 Bytes RAM und 512 Bytes EEPROM) verwendet, weil der Bestückungs-Aufwand so schön gering war. Während der Entwicklung habe ich natürlich externes RAM angeschlossen. Aber dank des HC24 hat das fast keine PINs gekostet, nur der UART ging für den Monitor flöten. Auch nett war das eingebaute Boot-ROM. Man brauchte also nicht noch irgendein EPROM für den Monitor zu verbauen. Aber jetzt, wo es 8051 mit FLASH als Single-Clocker und eingebauter Debug-Peripherie gibt, verwende ich sie auch. Die Stack-Limitierung nervt zwar ganz gewaltig und ab und an will ich einfach mein N-Flag wieder haben, aber irgendwie geht es dann doch. :-)
Der Stack kann z.B. bei Keil extern auf 16-Bit umkonfiguriert werden. Alles was du dazu brauchst, macht der C-Compiler automatisch. Ist schon genial. Banking übrigens genauso. VonNeumann ist beim 8051 bei externem Speicher immer möglich! Kostet nur ein Gatter. DAS solltest du als Benutzer aber schon wissen, oder?! Wie gesagt, das ist kein Prozessor!
Der 8051 ist extrem beliebt bei ASIC Hersteller wenn es darum geht einen Microcontroller mit zu integrieren. Alles modernere wie Pic etc krankt an den Lizenskosten. Und auch bei weniger versteckten Teilen steht aussen auf dem Chip keineswegs immer 8051 drauf, z.B. die CY7C6801x USB Controller (FX2) von Cypress. Sehr verbreitet. Zum 8048: Der ist keinesweg schon 1980 verstorben, da darf man nicht übershen dass praktisch jeder PC mit 2 davon kommt, einen in der Tastatur und einen am anderen Ende des Tastaturkabels (ursprünglich in der 8041 Variante). Heute ist dieser natürlich im Chipsatz integriert aber nach wie vor existent. Abdul K. schrieb: > Wilhelm Ferkes schrieb: >> Vor Jahren schlachtete ich noch viele Altgeräte vom Schrott, und dort >> begegnete mir mindestens um den Faktor 10 öfter der 8051. Klar ist die >> Auswahl der Schlachtgeräte nicht ganz repräsentativ, aber man bekommt >> einen kleinen Eindruck. >> > > Den Eindruck hatte ich auch. Neben den Japanern eben. Neuerdings > Chinesen und Korea. Die Japaner kann ich schwer einschätzen, der µPD78xx war auf jedem Fall bei Nadeldruckern sehr verbreitet. (Da hatte ich mal einen reverse engineered, samt selbst geschriebenen Disassembler umd Assembler) Bei Chinesen und Koreanern ist erst mal zu klären ob das wirklich eine eigene Architektur ist. Abdul K. schrieb: >> Der 8051 ist ganz nett, und es gibt sicher Gründe, warum er bis heute >> überlebte, und noch lange nicht ausstirbt. >> > > Ebend. Cypress hat ihn gerade wieder in eine neue Linie eingebaut. Bist du sicher? Der FX3 (für USB 3) wird meines Wissens auf ARM basieren, die hausinterne Konkurrenz PSOC5 ist definitiv ARM. Wilhelm Ferkes schrieb: > Etwas stören tut gelegentlich mal der kleine Hardwarestack, wenn man > nicht sorgfältig programmiert. Das ist eben einer der Unterschiede > zwischen µC und µP, da waren die µP überlegen Um da wieder den Bogen zum 6502 zu schliessen, der ist da auch nicht viel besser. Von 0x00-0xFF mit 1 byte addressierbarer RAM, Stack fest auf 0x100-0x1FF. Stackpointer wurde so initialisert dass man in µC Anwendungen beide Bereiche überlappen lassen konnte, also genau wie beim 8081.
Abdul K. schrieb: > VonNeumann ist beim 8051 bei externem Speicher immer möglich! Kostet nur > ein Gatter. DAS solltest du als Benutzer aber schon wissen, oder?! Ich habe in meinen fertigen HC11 Systemen keinen externen Speicher, das ist ja gerade das Schöne! Externen Speicher habe ich nur beim Debuggen gebraucht.
Lattice User schrieb: > Anwendungen beide Bereiche überlappen lassen konnte, also genau wie beim > 8081. Soll heissen: genau wie beim 8051
A. K. schrieb: > NatSemi hatte das bei der 32000 mit Retry gemacht. Hat die Befehle um > eine Latte von Einschränkungen bereichert - und die Chips um ein paar > nette Bugs. > >> Bei einer 2 Address Architektur liegt das Nahe um Mehrdeutigkeiten beim >> Retry zu vermeiden, z.B. weil man im ersten und im zweitem Operanden das >> gleiche Register mit Postincrement benutzt. > > Sowas kann man mit Schattenregistern abwickeln. Wenn der erste Zugriff auf eine Peripherie Addresse geht ist Retry auch gefährlich. 2 oder noch mehr Addressbefehle sind aus heutiger Sicht keine gute Idee gewesen.
Moppel schrieb: > Abdul K. schrieb: >> VonNeumann ist beim 8051 bei externem Speicher immer möglich! Kostet nur >> ein Gatter. DAS solltest du als Benutzer aber schon wissen, oder?! > > Ich habe in meinen fertigen HC11 Systemen keinen externen Speicher, das > ist ja gerade das Schöne! Externen Speicher habe ich nur beim Debuggen > gebraucht. Worauf willst du denn hinaus? Klingt für mich nach Motorola-Fan und Intel-Hasser. Und die umgekehrte Variante kenne ich auch zu Genüge. Ich finde das lächerlich. Der 8051 ist extrem simpel intern aufgebaut. Harvard-Architektur macht die Sache schön einfach. Es gibt genug Alternativen, wenn man was anderes haben will. Der PSoC3 hat 8051, der PSoC5 ARM.
Abdul K. schrieb: > Der PSoC3 hat 8051, der PSoC5 ARM. Den PSoC3 hatte ich übersehen. Ich fürchte aber dass dieser zwischen PSoC(1) und PSoC5 nur ein Schattendasein führen. <Glaskugel> Der ARM wird in solchen Anwendungen auf lange Sicht den 8051 ablösen. </Glaskugel>
Lattice User schrieb: > Der ARM wird in solchen Anwendungen auf lange Sicht den 8051 ablösen. Dafür braucht man keine Glaskugel. Es ist neben dem MIPS Core die einzige 32-Bit Controller-Architektur, die man kaufen kann, ohne von einem Konkurrenten zu kaufen.
Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu umständlich. Mich stört z.B. das man nicht ein einfach vorhersagbare Laufzeitverhalten hat. Beim 8051 kann man die Zyklen einfach auszählen. Für mich ist aber der Compiler und der I/O interessanter. Leider gibts es nur noch C als Sprache. Man muß ja die Libs benutzen können. Das ist das Schlimmste. Persönlich hätte ich mir den AVR im PSoC gewünscht.
Abdul K. schrieb: > Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu > umständlich. Ist die Frage wie er es gemeint hat. ARM wird nicht direkt die 8-Bit Controller im Produktionsvolumen ablösen, aber ARM ist im 32-Bit Controller-Sektor das, was 8051 im 8-Bit Sektor ist. Sehr viele jener, die überhaupt in dem Sektor tätig sind, haben ihn bereits irgendwie im Angebot, oder werden es über kurz oder lang. Und die Dinger drücken nach unten. Der Sektor komplexerer 8-Bit Controller mit grossem Programm gerät ja schon unter Druck. Wer da nicht schon auf viel Erfahrung und Code sitzt, sondern es sich aussuchen kann, der wird immer mehr zu ARMs tendieren, statt sich mit Fiesmatentchen wie etlichen Adressräumen und zueinander inkompatiblen Pointern rumärgern zu müssen.
Wilhelm Ferkes schrieb: > Das wundert mich jetzt etwas, daß diese Familie den größten Marktanteil > gehabt haben soll. Denn, ein 68HC11 befindet sich bei mir nur in einem > einzigen Gerät, dem EPROMMER. In der ELEKTRONIK waren ab und zu 'Marktanalysen' abgedruckt, welche Prozessoren in welchen Segmenten stückzahlmäßig dominieren. Da lagen die 68HCxx immer deutlich vorne. Ich habe sie auch nie eingesetzt, aber das heißt doch nichts. Was im KFZ-Bereich abgeht, bekommt man in der Regel garnicht mit. Beispielsweise wurde der LIN-Bus von einigen Fahrzeugherstellern und Motorola als einzigem µP-Hersteller entwickelt (1999). Das zeigt wie dominierend Motorola/Freescale in dem Bereich ist. Ähnlich ist es mit Renesas (ex. Hitachi) SHx; die verwendet niemand privat. Aber im KFZ-Bereich sieht es ganz anders aus.
Abdul K. schrieb: > Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu > umständlich. Mich stört z.B. das man nicht ein einfach vorhersagbare > Laufzeitverhalten hat. Beim 8051 kann man die Zyklen einfach auszählen. Und diese Zyklen muss man auch viel zu oft zählen weil man das Ding am Rande der Leistungsfähigkeit benutzt. Been there, done that. > > Für mich ist aber der Compiler und der I/O interessanter. Leider gibts > es nur noch C als Sprache. Man muß ja die Libs benutzen können. Das ist > das Schlimmste. > Persönlich hätte ich mir den AVR im PSoC gewünscht. Den hätte man aber einem direkten Konkurrenten kaufen müssen. A. K. schrieb: > Abdul K. schrieb: > >> Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu >> umständlich. > > Ist die Frage wie er es gemeint hat. ARM wird nicht direkt die 8-Bit > Controller ablösen, aber ARM ist im 32-Bit Controller-Sektor das, was > 8051 im 8-Bit Sektor ist. Sehr viele jener, die überhaupt in dem Sektor > tätig sind, haben ihn bereits irgendwie im Angebot, oder werden es über > kurz oder lang. Genau.
A. K. schrieb: > Und die Dinger drücken nach unten. Der Sektor komplexerer 8-Bit > Controller mit grossem Programm gerät ja schon unter Druck. Wer da nicht > schon auf viel Erfahrung und Code sitzt, sondern es sich aussuchen kann, > der wird immer mehr zu ARMs tendieren, statt sich mit Fiesmatentchen wie > etlichen Adressräumen und zueinander inkompatiblen Pointern rumärgern zu > müssen. Das ist schon längst entschieden: Alles was jetzt an jungem Gemüse nachwächst, wird u.a. vor allem auf ARM gehen. Für die ist 8051 billiger Chinakram ohne Mehrwert für hochpreisige Länder. Ich gebe dem 8051 noch 10, vielleicht 20 Jahre. Wobei ich nicht genau weiß, wie das Lizenzmodell ist. Bei ARM muß man wohl für jedes verkaufte System zahlen.
Lattice User schrieb: > Abdul K. schrieb: >> Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu >> umständlich. Mich stört z.B. das man nicht ein einfach vorhersagbare >> Laufzeitverhalten hat. Beim 8051 kann man die Zyklen einfach auszählen. > > Und diese Zyklen muss man auch viel zu oft zählen weil man das Ding am > Rande der Leistungsfähigkeit benutzt. Been there, done that. > War für mich nie ein Problem. Dann hast du schlicht die falsche Plattform für dein Projekt gewählt. Mit einem 8051 baut man Waschmaschinen, keine CNC-Maschinen! (Klar kenne ich Projekte mit Banking u.a. beim 8051...) >> >> Für mich ist aber der Compiler und der I/O interessanter. Leider gibts >> es nur noch C als Sprache. Man muß ja die Libs benutzen können. Das ist >> das Schlimmste. > >> Persönlich hätte ich mir den AVR im PSoC gewünscht. > > Den hätte man aber einem direkten Konkurrenten kaufen müssen. > Das ist das Hauptproblem! Warum sollte jemand sonst so eine Krücke wie den M8C verwenden? Richtig, wurde bei der Übernahme einer Firma quasi kostenlos mitgeliefert...
Abdul K. schrieb: > Lattice User schrieb: >> Abdul K. schrieb: >>> Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu >>> umständlich. Mich stört z.B. das man nicht ein einfach vorhersagbare >>> Laufzeitverhalten hat. Beim 8051 kann man die Zyklen einfach auszählen. >> >> Und diese Zyklen muss man auch viel zu oft zählen weil man das Ding am >> Rande der Leistungsfähigkeit benutzt. Been there, done that. >> > > War für mich nie ein Problem. Dann hast du schlicht die falsche > Plattform für dein Projekt gewählt. > Mit einem 8051 baut man Waschmaschinen, keine CNC-Maschinen! Du willst doch unbedingt Zyklen zählen, nicht ich :) Oft hat du doch gar nicht die Wahl welcher Prozessor eingesetzt wird, und der 8051 ist in vielen ASICs als Controller integriert. (z.B. Fernseher, Monitor, ...). Und wenn dann in so einem System ein 32bit Prozessor gebraucht wird, z.B. weil der Fernseher plötzlich MPEG/H.264 Decoding braucht oder gar auf Linux basieren soll wird der 8051 trotzdem mitgeschleppt um z.B. die Videopipeline zu kontrollieren.
Abdul K. schrieb: > Er meinte wohl, den HC11 gäbe es in verschiedenen Gehäusevarianten, eben > auch in PLCC68 so wie den 515. Den 515 gibts aber NUR in diesem Gehäuse. Konkret meinte ich, sie sind in etwa in der selben Leistungsklasse. Der eine hat mehr Peripherie von diesem, der andere mehr von jenem. Wer sich einmal auf Motorola oder Intel eingeschossen hat, verläßt diesen Bereich nicht so gerne bald: Das bedeutet immer, wenigstens neue Tools anzuschaffen. Moppel schrieb: > Das sehe ich aber anders. Zum Einen ist der HC11 um einiges schneller > unterwegs, da er intern durch 4 teilt und nicht durch 12. Dann hat er > nicht diese fiese Stack-Einschränkung, von Neumann, kann 16 Bit > dividieren, hat Unterstützung für Zahlen mit Vorzeichen, usw. Ich für meinen Teil, fand die 8051-er für mich immer ganz OK. Wenn man alle Spezialitäten kennt, kann man sehr gut damit leben. Z.B. der 80C517, hat eine 32-bit-Hardware-MDU, und hängt im Rechnen größere Klassen glatt ab. Und was macht denn der 68HC11 in meinem EPROMMER? Er steuert ein paar I/O-Ports an, und kommuniziert über 9600 Baud mit dem PC. Könnte genau so gut ein 8051 sein. Der Hersteller hat als Vorliebe aber den 68HC11. Das ist auch ganz OK so. Lattice User schrieb: > Zum 8048: Der ist keinesweg schon 1980 verstorben, da darf man nicht > übershen dass praktisch jeder PC mit 2 davon kommt, einen in der > Tastatur Wie schon gesagt: Er ist teilweise in neuen Tastaturen. Wenn man die öffnet, ist da original ein Baustein mit der Bezeichnung 8048 drin, wenn auch der mal von NEC oder OKI ist. Abdul K. schrieb: > Der 8051 ist extrem simpel intern aufgebaut. Harvard-Architektur macht > die Sache schön einfach. Es gibt genug Alternativen, wenn man was > anderes haben will. Meine Opto-Net-Boards von Feger mit dem 80C517A sind mit Jumpern konfigurierbar, ob Harvard oder Von Neumann. Letzteres geht übrigens mit 2 UND-Gattern, an den Pins PSEN und WR/RD (muß ich mal genauer nachsehen). Die Boards haben auch Vollausbau im Speicher, je 64k RAM und ROM. Das reicht noch ein Weilchen. Die Von-Neumann-Konfiguration ist ja auch ganz praktisch, ich lade die Testprogramme einfach über ein Terminal vom PC aus. Zum Basteln reichen die Dinger auch noch völlig. Ich habe noch vor, die SDCC-Libraries mal an die MDU anzupassen. Dann gehen sie ab wie ein Zäpfchen. Obwohl man diese Bausteine neu nirgends mehr einsetzt. ;-) Jens Petersen schrieb: > Da lagen die > 68HCxx immer deutlich vorne. Das kaufe ich dir sogar unbesehen ab. Wieso sollte es auch nicht so sein? > Was im > KFZ-Bereich abgeht, bekommt man in der Regel garnicht mit. Wie ich schon oben bemerkte, schlachtete ich Schrott. Und da waren einige Motorsteuergeräte (Jetronic, Motronic) von Bosch dabei, hatten immer den 80C515 drinne. Einige Kommilitonen aus dem Studium waren vor 10 Jahren zur Exkursion bei Bosch, genau in dieser Abteilung. Sie kamen aus dem Staunen nicht mehr raus, und sagten, der Code sei vollständig in Assembler geschrieben.
Abdul K. schrieb: > Das ist schon längst entschieden: Alles was jetzt an jungem Gemüse > nachwächst, wird u.a. vor allem auf ARM gehen. Für die ist 8051 billiger > Chinakram ohne Mehrwert für hochpreisige Länder. Ich gebe dem 8051 noch > 10, vielleicht 20 Jahre. Aussterben wird er so schnell nicht, aber ob er in 10 Jahren noch den Spizenplatz einhält glaube ich eigentlich nicht. Im Augenblick drängen ARM Basierende Controller im Niedrigpreissegment auf den Markt. > > Wobei ich nicht genau weiß, wie das Lizenzmodell ist. Bei ARM muß man > wohl für jedes verkaufte System zahlen. Der 8051 als solcher ist lizensfrei, du kannst jederzeit einen eigenen machen. Ansonsten hängt es vom Hersteller des IP Cores ab. Zum ARM: http://www.arm.com/products/buying-guide/licensing/index.php "The manufacturing rights are perpetual" Ich lese das so, dass keine Stückzahllizens anfällt.
Lattice User schrieb: > Aussterben wird er so schnell nicht, aber ob er in 10 Jahren noch den > Spizenplatz einhält glaube ich eigentlich nicht. Im Augenblick drängen > ARM Basierende Controller im Niedrigpreissegment auf den Markt. Das Leben des 8051 wurde schon 1995 abgesungen. Aber es ist richtig, mit Aufkommen der LPC2000-Serien bei NXP versuchte man, über den Preis die 8-Bitter zu verdrängen. Ist ja auch nicht verkehrt, wenn man zum selben Preis einen 32-Bitter bekommt, der keinen höheren Energieverbrauch hat.
Einen eigenen ARM kannst du genauso machen. Oder kann man Op-Code mittlerweile patentieren? Der ARM bietet einfach das Optimum zwischen Die-Fläche und Leistung. @Wilhelm: Sieht so aus, als würden sie bei Bosch Zyklen zählen ;-) Das sie die Leute überhaupt reinliesen, wundert mich.
Wilhelm Ferkes schrieb: > Lattice User schrieb: > >> Zum 8048: Der ist keinesweg schon 1980 verstorben, da darf man nicht >> übershen dass praktisch jeder PC mit 2 davon kommt, einen in der >> Tastatur > > Wie schon gesagt: Er ist teilweise in neuen Tastaturen. Wenn man die > öffnet, ist da original ein Baustein mit der Bezeichnung 8048 drin, wenn > auch der mal von NEC oder OKI ist. Bei PS/2 Tastaturen war es noch nie ein anderer. Als ROM Typ konntest du die schon immer mit eigenem Aufdruck kaufen, diese Kosten spart man sich halt neuerdings. Mit USB Tastaturen werden hier die Karten neu gemischt, dafür ist der 8048 dann doch zu klein.
Abdul K. schrieb: > Einen eigenen ARM kannst du genauso machen. Oder kann man Op-Code > mittlerweile patentieren? > Was man bei uns patentieren kann oder nicht ist leider viel zu oft irrelevant. Und in den USA kannst du einen Mausclick patentieren. Intel hat ja die AMD x64 opcodes auch nicht einfach reimplementiert sondern sich mit einem Crosslizensabkommen von AMD die Erlaubnis geholt.
Abdul K. schrieb: > @Wilhelm: > Sieht so aus, als würden sie bei Bosch Zyklen zählen ;-) > Das sie die Leute überhaupt reinliesen, wundert mich. Mich wundert da nichts. Bei extremen Stückzahlen lohnt es sich eventuell tatsächlich, in Assembler zu programmieren. Da sind Entwicklungskosten vielleicht das kleinere Übel. Sicher holt man gegenüber einer Hochsprache noch etwas Performance heraus, wenn man das richtig macht. Das Assembler aber fehleranfälliger ist, alleine auf Grund der Quellcodegröße und Übersicht, ist mir schon klar. Als ich mit ARM begann, fand ich auf fernöstlichen Seiten ausgezeichnete Tutorials in ARM-Assembler. Und begegnete auch Dingen, daß Leute den ARM vollständig in Assembler programmieren. Übrigens würde ich heute gerne auch ARM wählen, habe es in der Industrie schon einmal getan, und 8051 abgelöst. Lattice User schrieb: > Mit USB Tastaturen werden hier die Karten neu gemischt, dafür ist der > 8048 dann doch zu klein. Das ist wohl wahr. Wenn man bedenkt, daß der 8048 über Soft-UART kommunizierte, weil er keinen UART hat, das war schon schräg.
Lattice User schrieb: > Was man bei uns patentieren kann oder nicht ist leider viel zu oft > irrelevant. Und in den USA kannst du einen Mausclick patentieren. Als NEC 8088/8086 in Form der V20/V30 nachbaute hatten sie im Manual viele Befehle und Register umbenannt. Alles was nicht sowieso jede CPU hatte hiess anders. Offenbar waren nicht die Opcodes das Problem.
A. K. schrieb: > Lattice User schrieb: > >> Was man bei uns patentieren kann oder nicht ist leider viel zu oft >> irrelevant. Und in den USA kannst du einen Mausclick patentieren. > > Als NEC 8088/8086 in Form der V20/V30 nachbaute hatten sie im Manual > viele Befehle und Register umbenannt. Alles was nicht sowieso jede CPU > hatte hiess anders. Offenbar waren nicht die Opcodes das Problem. NEC hatte eine 8086 Secondsource Lizenz. NEC ist nicht gerade klein. Ausserdem gab es das Gericht in einem kleinen Kaff in Texas noch nicht, wo du in so einem Fall erst mal verlierst. Wenn man einen ARM einfach neu entwickelt, muss man auf jedem Fall erhebliche Anwalts und Gerichtskosten mit einplannen. Und dabei ist irrelevant wer am Ende den Prozess gewinnt. Beim 8051 Core gibt es diese Probleme nicht mehr, auch weil Intel in diesem Markt nicht mehr interresiert ist.
Lattice User schrieb: > Beim 8051 Core gibt es diese Probleme nicht mehr, auch weil Intel in > diesem Markt nicht mehr interresiert ist. Auf der Intel-Homepage gibt es seit wenigstens 5 Jahren keinen Support mehr zum 8051. Wie es vorher war, weiß ich aber auch nicht.
>aber ARM ist im 32-Bit Controller-Sektor das, was 8051 im 8-Bit Sektor ist >Ich gebe dem 8051 noch 10, vielleicht 20 Jahre. Bei diskreten 8bit-uC-ICs stand der 8051 vielleicht vor 25 Jahren an oberster Stelle, aber heute nicht mehr. Aber ganz aussterben wird er wohl nie. >Wer sich einmal auf Motorola oder Intel eingeschossen hat, verläßt diesen >Bereich nicht so gerne bald Motorola oder Intel ? Das war einmal. >VonNeumann ist beim 8051 bei externem Speicher immer möglich! Toll. Jede us! >Beim 8051 kann man die Zyklen einfach auszählen. Toll. Jede us! >Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! Hä? >Oder kann man Op-Code mittlerweile patentieren? Das kann ich mir nicht vorstellen. Denn bei Patentanmeldung muss ja gesagt werden, was neu und besser ist UND wie das gemacht werden soll. Und mit Op-Code alleine ist die Realisierung noch nicht dargelegt. Zu ARM: Ein Wechsel von einem zum anderen ARM-Hersteler, kann uU genauso aufwändig (oder aufwändiger) sein , wie der Wechsel zum anderen Hersteller mit anderer CPU. Ausserdem: Der weltweite Marktführer von uCs hat bessere CPUs als ARM(CM..), und ARM überhaupt nicht im Programm und will die auch nicht.
> Ausserdem: Der weltweite Marktführer von uCs hat bessere CPUs als > ARM(CM..), und ARM überhaupt nicht im Programm und will die auch nicht. Was ist unter "besser" zu verstehen? Kannst du das etwas ausführen?
Zyklen zähle ich, wenn der 8051 hartes Timing erzeugen muß. Ich zähle keine, wenn du das auf Performance beziehst. Ist einfach sinnlos, wenn das gegenüber keinerlei Anstalten macht nachzudenken "Jede us!" Was soll das heißen? Jedenfalls nix deutsches.
MCUA schrieb: >>Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! > Hä? Oben schon geklärt. Er bezieht sich dabei auf ein etwas eigenwilliges Speichermodell, das von Apple verwendet wurde um sich eine Hardware-MMU zu ersparen.
> "Jede us!" > Was soll das heißen? Jedenfalls nix deutsches. Könnte - jede Mikrosekunde - bedeuten. Aber was soll's der Beitrag ist so oder so nur Wischi-Waschi.
Ja, das macht Sinn. MCUA hält wohl Rennschweine. @A.K.: Bist du dir sicher, das der 68K relative Sprünge mit 32-Bit Offset konnte? Soweit ich mich erinnere, fand ich solche Befehle nicht im Assembler. Äh, ich meine Op-Code, denn ich hatte keinen Assembler, folglich alles per Hand gecodet. Am Ende hatte ich dann den ADB-Bus Rainbow Software-Dongle geknackt ;-) Waren nur ca. 100 Befehle notwendig, dann dacht die Dongle-Software sie hätte reale Hardware dran.
Abdul K. schrieb: > @A.K.: Bist du dir sicher, das der 68K relative Sprünge mit 32-Bit > Offset konnte? Habe ich nie behauptet. Erst mit 68020 - diese Erweiterung war harmlos. Aber mit Segmenten hat das zunächst Nullkommagarnix zu tun. Erst wenn man auf diese Beschränkung der relativen Adressierung ein entsprechendes Speichermodell eines bestimmten Betriebssystem begründet. Aber das ist dann Sache des Betriebssystems. Mir ist kein 32- oder 64-Bit Prozessor mit fester Befehlslänge bekannt, der den gesamten Adressraum mit relativer Adressierung erfassen kann. Trotzdem wird aus dieser Beschränkung der Codierung keine Segmentierung.
Oh, dann hatten wir aneinander vorbeigeredet. Wie hat dann das BS Programmsegmente verschieben können? Das verstehe ich nicht. Habe ja oben erklärt, wie Apple das realisierte um Garbage Collection durchführen zu können. Der Memory Manager hat periodisch diese 'Segmente' im Speicher sortiert und eventuell auch gelöscht oder neue geladen.
Abdul K. schrieb: > @A.K.: Bist du dir sicher, das der 68K relative Sprünge mit 32-Bit > Offset konnte? Positionsunabhängiger Code geht natürlich auch jenseits von 64KB. Nur eben mit etwas mehr Aufwand. Auch x86-Code sieht etwas anders aus, wenn man dem GCC ein -fPIC zumutet.
Abdul K. schrieb: > Oh, dann hatten wir aneinander vorbeigeredet. Wie hat dann das BS > Programmsegmente verschieben können? So wie überall sonst auch: mit einer Hardware-MMU. Intern gab es keine, also hat man nicht selten extern eine hinzugestrickt. Skizziert hatte ich eine solche oben bereits.
Ah ja. Nun, Apple hatte das mit Handles gemacht.
>Mir ist kein 32- oder 64-Bit Prozessor mit fester Befehlslänge bekannt, >der den gesamten Adressraum mit relativer Adressierung erfassen kann. (also RISC, weil feste Befehlslänge) Das kann norm.weise auch nicht gehen, da in 32 Bit OPcode (so breit ist der Adr.raum von 32bittern ja meistens) nunmal nicht auch noch 32Bit Disp reinpassen können. Aber man kann das (32bit)disp (selbst wenn OPcode nur 16bit breit) auch in ner Mem-Table ablegen, dann geht es wieder. (Allerdings braucht diese (so genannte) 'RISC'-CPU in diesem Fall dafür nat. weitere Mem-zugriffe. (wie ein CISC auch) )
MCUA schrieb: > (also RISC, weil feste Befehlslänge) Ja, aber ich wollte den Begriff vermeiden, weil sich allerhand RISCs mit variabler Befehlslänge tummeln, die dieses Problem nicht haben. Von AVR bis hin zu Motorola/Freescales Frechheit, sogar den Coldfire so zu nennen. > Das kann norm.weise auch nicht gehen, Jep, du hast es gemerkt! ;-) Mit Präfix-Methoden wärs aber prinzipiell möglich, beispielweise indem man 16-Bit Disp und 16-Bit Konstante im Befehl per Präfix-Befehl zu vollen 32-Bit aufbläst. Sowas in der Art findet sich beim MaxQ2000.
> weil sich allerhand RISCs mit variabler Befehlslänge tummeln, bis hin zu > Motorola/Freescales Frechheit, sogar den Coldfire so zu nennen. (ehem) Motorola nennt das wohl VL-RISC, weil RISC scheinbar moderner klingt. Aber VL-RISC ist eigentlich CISC als RISC.
MCUA schrieb: > Aber VL-RISC ist eigentlich CISC als RISC. Natürlich. Es sei denn man sieht es aus dem Übergang vom CPU32-Core zur ersten echten Coldfire-Generation heraus, denn so betrachtet war diese tatsächlich reduziert, hat sich das R also verdient. ;-)
Hä hä. Aber ich steige wohl nun aus. Der Thread dauert immer einige Sekunden bis er aufgebaut ist. Leider erscheinen die neuesten Posts immer am Ende, nicht am Anfang wie bei emails.
MCUA schrieb: > Die 68HC05/08/68HC11 (auch ST6,7) waren/sind in der AutomobilBranche > schwer vertreten. Diese 68-Teile sind sogar hier im Forum noch nicht mal im Filter, der 8051 hingegen schon. Sind sie ausgestorben? Wenn ja, warum? War der 8051 doch noch eine Konkurrenz, vielleicht eine ernst zu nehmende? Vielleicht sogar eine sehr beliebte? Und sicher hat er einige verdrängt. Mir begegnete bisher auch niemand, der über sie klagte. Ich tue das bis heute auch nicht.
Abdul K. schrieb: > Aber ich steige wohl nun aus. Der Thread dauert immer einige Sekunden > bis er aufgebaut ist. Leider erscheinen die neuesten Posts immer am > Ende, nicht am Anfang wie bei emails. Musst nur die Seitenaufteilung einschalten.
Wilhelm Ferkes schrieb: > Diese 68-Teile sind sogar hier im Forum noch nicht mal im Filter. > Sind sie ausgestorben? Wenn ja, warum? Das Forum hier repräsentiert nicht die Welt, sondern nur einen kleinen nicht repräsentativen Ausschnitt davon.
A. K. schrieb: > Das Forum hier repräsentiert nicht die Welt, sondern einen kleinen nicht > repräsentativen Ausschnitt davon. Aber es repräsentiert die User. Wäre schon komisch, wenn hier nur 8051-er her finden, und 68HC11-er weniger. Mit den AVR und ATmega hier im Forum habe ich ja auch nichts zu tun. Ja wo sind denn dann die 68HC11-er stark vertreten? Im US-Ausland? Motorola steht ja von der ehemaligen Namensgebung her für Automotive-Konzern in den USA, etwa was Bosch in Deutschland ist. Ein bißchen anders zwar strukturiert, aber im Groben.
Wilhelm Ferkes schrieb: > Aber es repräsentiert die User. Es repräsentiert einen bestimmten Teil deutscher User, und nicht einmal den nach Stückzahl gewichtet. Du findest hier fast ausschliesslich Leute aus dem deutschsprachigen Raum, weshalb beispielsweise vorwiegend im japanischen Raum verwendete Controller schon mal wegfallen. Auch sind hier nach meinem Eindruck überwiegend Anwender mit eher kleinen Stückzahlen vertreten. Wenns nicht Bastler sind, dann die Kategorie Ing-Büro und unterer Mittelstand. Ein Markt für den sich Freescale nicht gross zu interessieren scheint.
Wilhelm Ferkes schrieb: > MCUA schrieb: > >> Die 68HC05/08/68HC11 (auch ST6,7) waren/sind in der AutomobilBranche >> schwer vertreten. > > Diese 68-Teile sind sogar hier im Forum noch nicht mal im Filter, der > 8051 hingegen schon. > > Sind sie ausgestorben? Wenn ja, warum? War der 8051 doch noch eine > Konkurrenz, vielleicht eine ernst zu nehmende? Vielleicht sogar eine > sehr beliebte? Und sicher hat er einige verdrängt. Mir begegnete bisher > auch niemand, der über sie klagte. Ich tue das bis heute auch nicht. bei mir werkeln noch 2 gelegentlich auf ner CControlBasic II ;-)
A. K. schrieb: > Abdul K. schrieb: > >> Aber ich steige wohl nun aus. Der Thread dauert immer einige Sekunden >> bis er aufgebaut ist. Leider erscheinen die neuesten Posts immer am >> Ende, nicht am Anfang wie bei emails. > > Musst nur die Seitenaufteilung einschalten. Aha. Dafür ist es gut. Was hälst du denn von NIOS?
Habs grad mal schnell überflogen. Klassische langweilige an MIPS orientierte RISC mit 32-Bit Codierung fast ohne besondere Eigenschaften (kennst du eine kennst du alle). Aber mit I/O-Befehlen für Cache-Bypass, was die hier irgendwo mal erwähnte Sache mit dem speziellen Code für volatile Variablen erklärt. Anderswo wird sowas über Adressbereiche implementiert. Diverse Konkurrenten neigen mittlerweile dazu, zur reinen 32-Bit Codierung auch eine 16-Bit Codierung anzubieten - oder auch nur diese - um Platz zu sparen. Hab das hier in aller Kürze nicht gesehen. Anderer Softcore?
Vielleicht etwas off-topic, aber für die die Transistoren nicht trauen, hier mal ein Schaltplan eines Relaisrechners mit etwa 1000 Relais. http://www.cs.ubc.ca/~hilpert/e/simon/index.html
GeraldB schrieb: > Der AppleIII hatte auch "nur" einen 6502, der aber mit 2MHz lief. Die > 16bit Version war der AppleIIGS. Und das der gescheitert ist, kann man > nicht sagen. Den IIGS kann man durchaus als gescheitert ansehen. Die direkten Wettbewerber waren der Atari ST (als Nachfolger von 800XL, 130XE) und der Commodore Amiga 1000 (als Nachfolger von C64, C128D). Beide waren bei gleichem Preis deutlich performanter und damit relativ gesehen günstiger als der Apple. Designvorgabe beim IIGS war, dass Apple II-Software von 1977 drauf laufen sollte. Und zwar ohne Emulation. Daher musste die Kiste erstmal als einfacher 1MHz/64k 6502 hochlaufen, um dann mit fiesen Tricks die besseren Features freizuschalten. Atari und Commodore haben den harten Schnitt gewagt, auf Kompatibilität verzichtet, und waren damit erfolgreicher. Patrick
> Atari und Commodore haben den harten Schnitt gewagt, auf Kompatibilität > verzichtet, und waren damit erfolgreicher. Das ist ja auch der Grund warum Commodore und Atari heute so erfolgreich am Markt bestehen - während Apple kaum noch jemand kennt.
Apple ist ja auch den Umweg über iPod und Co gegangen. Ohne dieses Eierkram wäre der Apfel auch schon verschimmelt.
> Ohne dieses Eierkram wäre der Apfel auch schon verschimmelt.
Umweg? Was soll der Unfug? Apple geht als Unternehmen mit vielen Ideen -
auch viele Wege. Man schaue sich nur Appels erfolgreiche Geschichte im
Notebooksektor an oder die Macintosh-Serie. Du hast einfach keinen
blassen Schimmer.
Schicke (und teure) Computer haben sie schon immer gebaut. Nur die Gewinne sind erst wieder mit den "neuen Ideen" gekommen.
Wilhelm Ferkes schrieb: > Ja wo sind denn dann die 68HC11-er stark vertreten? Im Maschinenbau (Textil) sind die schon mal vertreten. Ich habe da einige Jahre lang Soft+Hardware fuer gemacht. Da wurden die in groesseren Stueckzahlen in Bedienpanels und FUs eingesetzt. Auch kenn ich die Teile von Geldscheinlesern eine grossen Schokoherstellers. Soviel ich noch weiss waren die im franzoesich sprechenden Raum beleibt.
Markus schrieb: >> Atari und Commodore haben den harten Schnitt gewagt, auf Kompatibilität >> verzichtet, und waren damit erfolgreicher. > > Das ist ja auch der Grund warum Commodore und Atari heute so erfolgreich > am Markt bestehen - während Apple kaum noch jemand kennt. Auch Apple hatte erst mit dem MacIntosh wieder Erfolg. Der war zu nix kompatibel, aber dafür von Leuten zu bedienen, die eigentlich keinen Bock auf Computertechnik haben. "Computer as an appliance", als Gerät. Einschalten und benutzen. Genau diese Zielgruppe bedienen auch die iGadgets. Aber es ging um den Apple IIGS. Der musste Rücksicht auf seine Vorgänger nehmen und war damit dem ST und Amiga gegenüber im Nachteil. Patrick
om pf schrieb: > Aber es ging um den Apple IIGS. Der musste Rücksicht auf seine Vorgänger > nehmen ... Nicht nur das, er kam schlichtweg ein paar Jahre zu spät, nämlich erst gegen Ende 1986.
DirkB schrieb: > Schicke (und teure) Computer haben sie schon immer gebaut. Nur die > Gewinne sind erst wieder mit den "neuen Ideen" gekommen. Hast du Apple-Aktien und bist versauert wegen damaligen Gewinneinbruch? So einer würde nämlich genauso argumentieren! Im Allgemeinen schert sich der Konsument nicht um den Ertrag des Herstellers, sondern möchte diesen sogar indirekt minimieren durch Kauf eines besonders guten Gerätes zu niedrigstem Preis. Soweit ich mitbekommen habe, könnte man auch sagen: Sie verkaufen Computer und Gadgets um ihre gedongelte Musik an den Mann zu bringen. Jedenfalls soll die Musiksparte ganz prächtige Gewinne abwerfen. So ganz allgemein. Soll jetzt kein Apple-Thread werden.
Abdul K. schrieb: > Im Allgemeinen schert sich der Konsument nicht um den Ertrag des > Herstellers, sondern möchte diesen sogar indirekt minimieren durch Kauf > eines besonders guten Gerätes zu niedrigstem Preis. Genau. Und das waren damals die PCs mit Windows. (So dachten die meisten Konsumenten) Hätte, wäre, wenn ... es Apple damals so gut gegangen wäre, hätte Steve Jobs ja nicht wieder einsteigen brauchen (mit seinen neuen Ideen). Der hat seinen Job schon gut gemacht.
Rufus Τ. Firefly schrieb: > om pf schrieb: >> Aber es ging um den Apple IIGS. Der musste Rücksicht auf seine Vorgänger >> nehmen ... > > Nicht nur das, er kam schlichtweg ein paar Jahre zu spät, nämlich erst > gegen Ende 1986. Der Amiga 1000 kam Mitte 1985, der Atari ST Ende 1985. Damit hatte der IIGS "nur" 1 Jahr Verspätung. Auch wenn es uns damals ewig lange vorkam... Patrick
Wilhelm Ferkes schrieb: > Schau dir den 8085 an, [...] > Integrierte Peripherie wie z.B. Timer oder UART gab es auch nicht. Der 8085 hatte im Gegensatz zum 8080 und Z80 immerhin einen integrierten UART (allerdings nur mit RxD und TxD, keine Steuerleitungen) und zwei spezielle Maschinenbefehle, um jeweils ein Byte zwischen dem Akku und dem Sende- bzw. Empfangspuffer hin- und herzuschieben. Der interne UART wurde beispielsweise im http://de.wikipedia.org/wiki/Mikrocomputer_für_Ausbildung verwendet, um die Tastatur-Monitor-Baugruppe anzubinden, die im Grunde ein serielles Terminal mit 5V-Pegel war.
Abdul K. schrieb: > Was hälst du denn von NIOS? NIOS (Altera), MicroBlaze (Xilinx), Mico32 (Lattice) sind eher aus der Not geboren einen FPGA optimierten lizenzfreien Softcore anbieten zu müssen. Konkurrenz zu ARM/Mips können und wollen diese nicht sein. A. K. schrieb: > Diverse Konkurrenten neigen mittlerweile dazu, zur reinen 32-Bit > Codierung auch eine 16-Bit Codierung anzubieten - oder auch nur diese - > um Platz zu sparen. ARM Thumb Befehlssatz. Mir ist nicht bekannt ob das auch jemand anders macht, für FPGAs ist ein 2. Befehlssatz eher Balast.
om pf schrieb: > Damit hatte der IIGS "nur" 1 Jahr Verspätung. Ja, aber mit der rasanten Taktfrequenz von nur 2.8 MHz war er auch "nur" ein Jahr nach ST/VC Amiga altes Brot. Der '816 hätte mit bis zu 16 MHz getaktet werden können, und wäre dann zumindest interessant gewesen, aber das ging aus firmenpolitischen Gründen nicht. Naja, daß His Steveness dem Laden dann den Rücken gekehrt hat, dürfte auch daran gelegen haben.
Rufus Τ. Firefly schrieb: > om pf schrieb: >> Damit hatte der IIGS "nur" 1 Jahr Verspätung. > Ja, aber mit der rasanten Taktfrequenz von nur 2.8 MHz war er auch "nur" > ein Jahr nach ST/VC Amiga altes Brot. Exakt deswegen habe ich ihn als gescheitert bezeichnet. Man wollte unbedingt eine Kiste, die mit 1MHz Apple ][-kompatibel hochläuft. Und alles andere musste da dann irgendwie drangepfriemelt werden. Die beiden anderen Firmen, die heute nicht mehr da sind, haben hingegen beim Generationswechsel einen sauberen Cut gemacht.
Hat man den Taktfrequenzwechsel damals nicht zur Laufzeit unterbringen können? Das kann doch auch damals nicht so schwer gewesen sein ? Das sollte doch sogar extern über Portbits und Vorteiler machbar sein?
R. Max schrieb: > Wilhelm Ferkes schrieb: > >> Schau dir den 8085 an, [...] >> Integrierte Peripherie wie z.B. Timer oder UART gab es auch nicht. > > Der 8085 hatte im Gegensatz zum 8080 und Z80 immerhin einen integrierten > UART (allerdings nur mit RxD und TxD, keine Steuerleitungen) und zwei > spezielle Maschinenbefehle, um jeweils ein Byte zwischen dem Akku und > dem Sende- bzw. Empfangspuffer hin- und herzuschieben. > > Der interne UART wurde beispielsweise im > http://de.wikipedia.org/wiki/Mikrocomputer_für_Ausbildung verwendet, um > die Tastatur-Monitor-Baugruppe anzubinden, die im Grunde ein serielles > Terminal mit 5V-Pegel war. Ja, ich hab den 8085 mal in Assembler programmiert, allerdings nur ein Lauflicht bzw. Bitmuster an 2 I/O-Ports des 8255. Der Baugruppe verpaßte ich auch noch einen Timer 8253, damit es wenigstens geringfügig komfortabel wird. Damit kann er sogar PWM, der 8253 war ein interessanter vielseitiger Timer. Auch habe ich hier noch das Buch zum 8085 von Günter Schmitt stehen: Mikrocomputertechnik/8085A. Dort habe ich mir in der Vor-Internet-Zeit einiges abgeschaut. Am Buchende ist ein mehrseitiges Terminalprogramm in Pascal abgedruckt. Wenn ich mal Lust und Zeit habe, wandele ich das in C oder Assembler um, da ich keinen Pascal-Compiler habe, aber das ist kein Problem. Der SDCC beherrscht außer 8051 wohl auch 8085 und Z80. Aber für die Baugruppe noch einen Monitor zu schreiben, wäre sicherlich interessant. Mit den Befehlen SID und SOD konnte man aus einem Byte ein bit maskieren, und seriell herein oder heraus schieben. Im Grunde war das ja nur die Setzung eines Pins. Alles andere mußte man schon zu Fuß machen, und wenn die Baugruppe keinen Timer hatte, mit den Timings der Befehlszyklen herumrechnen. Das war schon etwas schräg, da fast jeder 8085-Befehl eine andere Zyklenzahl hat. Aber ich habe hier auch noch UART-Bausteine liegen, ich glaube, 8250. Aber das Lochraster-Board hat leider keinen Platz mehr. Die Europakarte ist mit 8085, 8255, 8253, RAM und EPROM und Adreßdekoder brechend voll. Ansonsten habe ich hier noch ein paar Zentralsteuerplatinen liegen, die mal aus MFA-Computern stammten, welche verschrottet wurden. Es sind allerdings Einschübe im Europa-Format, die man so direkt gar nicht betreiben kann. Ich habe da auch keine Pläne, es sind einfach nur mal Museumsstücke zur Ansicht. Helmut Lenzen schrieb: > Im Maschinenbau (Textil) sind die schon mal vertreten. Ich habe da > einige Jahre lang Soft+Hardware fuer gemacht. Da wurden die in > groesseren Stueckzahlen in Bedienpanels und FUs eingesetzt. Auch kenn > ich die Teile von Geldscheinlesern eine grossen Schokoherstellers. > Soviel ich noch weiss waren die im franzoesich sprechenden Raum > beleibt. Das ist doch mal eine handfeste Aussage!
Winfried J. schrieb: > Hat man den Taktfrequenzwechsel damals nicht zur Laufzeit unterbringen > können? > Man konnte im Betrieb umschalten. Allerdings hing da einiges an Peripherie dran, was auf 1MHz angewiesen war. So wurde z.B. bei einem Zugriff auf die Slots runtergetaktet, und der Videogenerator griff auch mit der gewohnten Geschwindigkeit auf seinen Speicher zu. Der natürlich auch nicht linear organisiert war, sondern genauso verschachtelt wie beim Apple ][ (bei dem man das Chaos in Kauf genommen hatte, um ein paar Gatter zu sparen).
Lattice User schrieb: > ARM Thumb Befehlssatz. Mir ist nicht bekannt ob das auch jemand anders > macht, für FPGAs ist ein 2. Befehlssatz eher Balast. Ein zweiter ja. Muss ja kein zweiter sein, siehe Cortex M1. Ist platzsparende Codierung bei FPGAs überflüssig?
Lattice User schrieb: > Abdul K. schrieb: >> Was hälst du denn von NIOS? > > NIOS (Altera), MicroBlaze (Xilinx), Mico32 (Lattice) sind eher aus der > Not geboren einen FPGA optimierten lizenzfreien Softcore anbieten zu > müssen. Konkurrenz zu ARM/Mips können und wollen diese nicht sein. > Naja. Ich frage nur, weil ich oftmals größere Hardware-Logik UND nen Mikrocontroller benötige. Aber ich kriege einfach keine Übersicht über die ganzen FPGAs. Außerdem muß es auslesegeschützt sein und wenige Pins. Und auf ne Entwicklungsumgebung, die in GB zählt, habe ich auch keinen Bock. Bleibt da noch was übrig?
A. K. schrieb: > Lattice User schrieb: > >> ARM Thumb Befehlssatz. Mir ist nicht bekannt ob das auch jemand anders >> macht, für FPGAs ist ein 2. Befehlssatz eher Balast. > > Ein zweiter ja. Muss ja kein zweiter sein, siehe Cortex M1. > Ist platzsparende Codierung bei FPGAs überflüssig? Wie immer so pauschal kann man das natürlich nicht sagen. Wichtig bei einem Softcore ist der Logikfootprint. d.h. Bedarf an LUTs und FlipFlops. Speicher in der Form von Blockram ist in der Regel reichlich vorhanden. Ist wie vieles ein Kompromiss. PS. Einen Softcore habe ich mir noch nicht angetan.
Abdul K. schrieb: > > Naja. Ich frage nur, weil ich oftmals größere Hardware-Logik UND nen > Mikrocontroller benötige. Aber ich kriege einfach keine Übersicht über > die ganzen FPGAs. Außerdem muß es auslesegeschützt sein und wenige Pins. > Auslesegeschutz ist heute Standard. Bei FPGAs die von einem externen Flash geladen werden kann man es mit AES verschlüsseln. Ist 100 pin TQFP viel für dich? Oder gar 25-ball WLCSP (2.5 * 2.5 mm)? FPGAs in kleinen Gehäusen sind natürlich auch nicht sehr gross, für einen 8bit Softcore plus Logik reicht es aber. > Und auf ne Entwicklungsumgebung, die in GB zählt, habe ich auch keinen > Bock. Das ist natürlich ein KO Kriterium. (Lattice : >5GB installiert ohne Softcoreunterstützung).
Wilhelm Ferkes schrieb: > Mit den Befehlen SID und SOD konnte man aus einem Byte ein bit > maskieren, und seriell herein oder heraus schieben. Im Grunde war das ja > nur die Setzung eines Pins. Alles andere mußte man schon zu Fuß machen, [...] Ja, hast recht. Da hatte ich den 8085 mit seiner primitiven Hardware-Unterstützung für einen Soft-UART wohl mit dem 8051 in einen Topf geworfen, der einen richtigen UART hat.
R. Max schrieb: > Ja, hast recht. Da hatte ich den 8085 mit seiner primitiven > Hardware-Unterstützung für einen Soft-UART wohl mit dem 8051 in einen > Topf geworfen, der einen richtigen UART hat. Was ich am 8085 gut gelungen fand, ist der gigantische 16-bit-Hardware-Stack. Allerdings nur in einem guten Ausbau mit wenigstens 32k RAM. Anders als in den µC 8048 und 8051. Da konnte man schon mal Programmtechniken anwenden, die mehrbytige Datensätze auf dem Stack an Funktionen übergeben, ohne Variablen zu verbrauchen, oder mal eine rekursive Funktion bedenkenlos anwenden.
Wilhelm Ferkes schrieb: > Was ich am 8085 gut gelungen fand, ist der gigantische > 16-bit-Hardware-Stack. Allerdings nur in einem guten Ausbau mit > wenigstens 32k RAM. Anders als in den µC 8048 und 8051. Bischen andere Grössenklasse. Mikrocontroller wie 8048/51 hatten damals bestenfalls 256 Bytes RAM an Bord, da ergaben riesige Stacks wenig Sinn. Auch die maximal 256 Bytes des 6502 waren eher selten ein Problem.
A. K. schrieb: > Bischen andere Grössenklasse. Mikrocontroller wie 8048/51 hatten damals > bestenfalls 256 Bytes RAM an Bord, da ergaben riesige Stacks wenig Sinn. Ach, vom Preis und der Leistungsklasse tun sich 8085 und 8051 nicht allzu sehr viel. OK, sie hatten zwar jeweils einen Anwendungsbereich, und beim 8051 hätte ich mir gelegentlich 1k Stack gewünscht. Es geht aber auch so, und es ging immer gut.
Wilhelm Ferkes schrieb: > Ach, vom Preis und der Leistungsklasse tun sich 8085 und 8051 nicht > allzu sehr viel. OK, sie hatten zwar jeweils einen Anwendungsbereich, Mit der Grössenklasse meinte ich eher den Speicherausbau. 8051 war als begrenzter Mikrocontroller konzipiert, in erster Linie mit ausschliesslich internem ROM/RAM. Die 16-Bit Speicheradressierung wurde hauptsächlich für ROM-Zugriff genutzt, selten hatte man externes RAM. Es war ja nie vorgesehen gewesen, dass heute routinemässig viele KB RAM drin stecken, die man mangels geeigneter Adressierung nur ziemlich umständlich verwenden kann. Dass man 30 Jahre später noch damit programmiert, mit ROM-Kapazitäten von mitunter einigen hundert KB, das hatte Intel damals nicht im Traum vermutet. Hätte man wohl in lichten Momenten für regelrecht bescheuert gehalten. ;-) Ein 8080/85 hingegen war vor vorneherein für (damals) grosse Speicherkapazität konzipiert und dank eines einheitlichen Adressraums sprach da auch nichts gegen RAM.
A. K. schrieb: > Ein 8080/85 hingegen war vor vorneherein für (damals) grosse > Speicherkapazität konzipiert und dank eines einheitlichen Adressraums > sprach da auch nichts gegen RAM. Was hatte man denn damals an RAM, als der 8085 heraus kam? 1980 hatte man vielleicht 256 Byte oder 512? Ich habe jetzt noch eine RAM-Bank hier liegen, schöne violette Keramik mit 256x1 Bit aus dieser Zeit. Man brauchte 8 Bausteine für 256 Byte. Schon fast eine halbe Europa-Karte voll. Nur für die 256 mickrigen RAM-Bytes. Das RAM-Zeugs war damals teuer oder nicht machbar. Der 8048 wurde wegen Speichergrößen noch auf 1-Byte-Befehle optimiert, sowas kann man sich heute gar nicht mehr vorstellen. Meine spätere Lochrasterkarte mit 8085 konnte ich mit 32k RAM bestücken, aber nur, weil es diese Speicher 20 Jahre später tatsächlich gab. Ich kenne die beiden Dinger 8051 und 8085 sehr gut. Aber es ist schon erstaunlich, daß man früher erst mal nur hauptsächlich an viel Speicher dachte. Viel mehr konnte der 8085 ja auch gar nicht, mit den 6 Registern alleine konnte der gar nicht viel mehr reißen. Die Sachen mit den µC und integrierter Peripherie kamen ja erst später, und damit andere Handhabungstechniken.
Wilhelm Ferkes schrieb: > Was hatte man denn damals an RAM, als der 8085 heraus kam? 1980 hatte > man vielleicht 256 Byte oder 512? Schüttel man deine grauen Zellen neu durch, da kommt was durcheinander. Der AIM65 kam ca. 1977 raus und hatte 4KB SRAM, 8 Stück 1Kx4.
Heute optimiert man wieder. Aus Geschwindigkeitsgründen, damit der Flaschenhals CPU-RAM, möglichst breit wird.
A. K. schrieb: > Schüttel man deine grauen Zellen neu durch, da kommt was durcheinander. > Der AIM65 kam ca. 1977 raus und hatte 4KB SRAM, 8 Stück 1Kx4. Das stimmt, wenn man sowas zeitnah bekam. Von den 1Kx4 habe ich auch noch welche.
> Klassische langweilige an MIPS orientierte RISC mit 32-Bit Codierung fast > ohne besondere Eigenschaften Die werben damit, schön einfache Cores zu haben. Xilinx hat auch ARM Cores, haben auch ein IC, bei dem ARMCM3 drauf mit weitere FPGA-Teile. ...ist aber (meine ich) viel zu teuer. (ca4x teurer als das Äquivalent mit 2 ICs ) >Bei FPGAs die von einem externen Flash geladen werden kann man es mit AES >verschlüsseln. Aber nur bei grösseren FPGAs. Aber auch der unverschlüsselte Bitstream ist faktisch nicht zu knacken, weil Xilinx (und wahrsch. auch Altera) die konkrete Umsetzung geheim halten. >1980 hatte man vielleicht ... 1982: 8085A: ca 14 DM Z80CPU: ca 12 DM 6502: ca 17 DM 2716: ca 9 DM 2732: ca 18 DM 6116: ca 20 DM ..also schon eine ganze Menge EPROM/RAM. (der 8051 war da schon viel zu klein)
Wilhelm Ferkes schrieb: > Ich kenne die beiden Dinger 8051 und 8085 sehr gut. Aber es ist schon > erstaunlich, daß man früher erst mal nur hauptsächlich an viel Speicher > dachte. Viel mehr konnte der 8085 ja auch gar nicht, mit den 6 Registern > alleine konnte der gar nicht viel mehr reißen. Was hat denn die Anzahl Register damit zu tun? Die 8080 Architektur war zwar kein Geniestreich, aber doch universell nutzbar - und aus Software-Sicht(!) praktikabler als die Konkurrenz 6800. Mit 8085 (meist aber Z80) hat man um 1980 herum bereits ziemlich ernsthafte Business-Rechner auf CP/M-Basis gebaut, mit 64KB DRAM (16Kx1 Chips). 1981 gabs mit dem Osborne-1 den ersten CP/M Schleppable mit ebenfalls 64KB. > Die Sachen mit den µC und integrierter Peripherie kamen ja erst später, Für was hältst du den 8048, wenn nicht für einen Mikrocontroller mit integrierter Periphierie? Dessen Inspirationsquelle, der viele Jahre führende Mikrocontroller Fairchild F8 kam 1975 raus.
Die Zeit um 1975 bis 1980 bekam man manche Dinge in Bastelläden erst 3 Jahre nach Markteinführung. Entwickler in Firmen, mit Bezugsquellen und Info-Material, waren da viel besser dran.
A. K. schrieb: > Was hat denn die Anzahl Register damit zu tun? Mit Hilfe der 6 Register, was ja internes RAM war, konnte man im Extremfall den 8085 sogar als Single-Chip verwenden. Wenn man vom externen EPROM mal absah.
Wilhelm Ferkes schrieb: > Mit Hilfe der 6 Register, was ja internes RAM war, konnte man im > Extremfall den 8085 sogar als Single-Chip verwenden. Wenn man vom > externen EPROM mal absah. Sowas ähnlich Bizarres ist mir als DCF77-Uhr mal begegnet. War eine Z80 drin, mit einem(!) SRAM 1kx4. Aber das war ziemlich krank.
Wilhelm Ferkes schrieb: > Die Zeit um 1975 bis 1980 bekam man manche Dinge in Bastelläden erst 3 > Jahre nach Markteinführung. Entwickler in Firmen, mit Bezugsquellen und > Info-Material, waren da viel besser dran. Was man schlecht kriegte waren Mikrocontroller. Ausser im Schrott. Was mal in Elektor&Co aufkreuzte war jedoch im Versand auch zu kriegen, und das waren die universelleren Mikroprozessoren, wie auch SC/MP und statische ROM/RAM.
A. K. schrieb: > War eine Z80 > drin, mit einem(!) SRAM 1kx4. Aber das war ziemlich krank. Ooch, 512 Bytes sind für einen Assembler-Programmierer für eine kleine Maschine aber schon ganz schön viel Holz. Sogar heute manchmal noch. Um das SRAM wenigstens in ganzen Bytes zu lesen und zu schreiben, das ist ja bekannt, wie das geht, müssen wir gar nicht erst diskutieren. Meine DCF77-Uhr auf dem 8051 kommt mit dem internen RAM aus, welches sich bei 128 Bytes auch noch den Stack und die Register und das Flagsegment mit teilt. Man muß das nur höllisch genau berechnen. Das Board hat zwar auch 32k SRAM, wollte es aber so hin bekommen, daß es auch ohne geht. > Was man schlecht kriegte waren Mikrocontroller. Ausser im Schrott. Mir als unbedarftem Bastler wurden 8051 erst 1990 überhaupt bekannt. 1992 kaufte ich beim Schuricht 2 NMOS-8051, mit dem Hintergrund, dann endlich was über die Dinger zu lernen, wenn ich sie mal besitze, und einzusteigen. Und war stolz wie Oskar!!! 1978 las ich zwar schon mal, daß irgendwo ein 8085 das Licht der Welt erblickte, aber ich konnte damals mit dem Zeugs nicht wirklich was anfangen, war bis dahin Analogbastler auf einfachem Level. Eben Fernmelde-Azubi damals.
Wilhelm Ferkes schrieb: > A. K. schrieb: > >> War eine Z80 >> drin, mit einem(!) SRAM 1kx4. Aber das war ziemlich krank. > > Ooch, 512 Bytes sind für einen Assembler-Programmierer für eine kleine > Maschine aber schon ganz schön viel Holz. Sogar heute manchmal noch. Um > das SRAM wenigstens in ganzen Bytes zu lesen und zu schreiben, das ist > ja bekannt, wie das geht, müssen wir gar nicht erst diskutieren. > Doch, müssen wir!
MCUA schrieb: >>Bei FPGAs die von einem externen Flash geladen werden kann man es mit AES >>verschlüsseln. > Aber nur bei grösseren FPGAs. Hängt vom Hersteller ab, Bei Xilinx hast du recht. Die aktuelle Lattice FPGA Familien ECP3 und MachXO2 können entweder AES (ECP3 auch der kleinste!) oder haben Onchip Konfigurationsspeicher (MachXO2). > Aber auch der unverschlüsselte Bitstream > ist faktisch nicht zu knacken, weil Xilinx (und wahrsch. auch Altera) > die konkrete Umsetzung geheim halten. So super geheim ist das auch nicht, und schon gar nicht unmöglich. Aber darum geht es nicht, Kopierschutz ist viel wichtiger. Auch geht es darum Überprduktion zu verhindern (d.h. der Auftragsfertiger produziert ein paar mehr auf eigene Rechnung) @Abdul Schau dir mal den MachXO2 an, ausser in der kleinsten Version haben diese auch User Flash der sich direkt als Programmspeicher für einen Softcore verwenden lässt.
>> Aber auch der unverschlüsselte Bitstream >> ist faktisch nicht zu knacken, weil Xilinx (und wahrsch. auch Altera) >> die konkrete Umsetzung geheim halten. >So super geheim ist das auch nicht, und schon gar nicht unmöglich. Was heisst super geheim? Nur Xilinx kennt den, sonst keiner. Und wenn man's knacken will, muss man den Chip auseinander nehmen, was extrem teuer ist. In Verbind. mit Dev-DNA ist das auch Kopierschutz.
Angehängte Dateien:
-
IMGP2397.JPG
230 KB -
IMGP2398.JPG
220 KB
Um mal wieder auf die Anfangsfrage zu kommen: Ich kenne ihn noch. Auf dem Boden habe ich den Commodore KIM 1, selbst eingebaut in ein hübsches Gehäuse. Samt Literatur und Rechnung (Oktober 1978). Das gute Stück funktioniert übrigens noch. Dazu noch etliche Portbausteine 8255 und andere Altlast-ICs an die heute keiner mehr denkt. (vermutlich ist bei uns vor Generationen mal ein Eichhorn mit eingekreuzt worden ;-) ) mfg Dietmar M.
Der AIM65 Rockwell war auch mal ein schönes Gerät mit Drucker, Alphanumerischer LED-Anzeige und einer Schreibmaschienentastertur. Dafür gabs auch mal Assembler und Bausic Compiler wenn nicht sogar mal einen C Compiler. Hatte ihn leider vor 15 Jahren Verkauft.
War das nicht Bill Gates der mal Ende der Achtziger gesagt hatte dass 640 Kb RAM die nächsten 20Jahre ausreicht?
Overflow schrieb: > War das nicht Bill Gates der mal Ende der Achtziger gesagt hatte dass > 640 Kb RAM die nächsten 20Jahre ausreicht? Hatte er auch gesagt, wofür es ausreichen soll? PC? Denn sonst klingt das, wie: Die Rente ist sicher (nur die Höhe nicht). Für meinen persönlichen Bedarf reichen die 640kB aber von heute ab nochmal 20 Jahre. ;-) @Nichts ist zu Alt: Etwa um 1976 las ich Funkschau, dort waren auch z.B. die 8080-Einplatinencomputer drin, bzw. Selbstbauprojekte (wovon ich aber noch nichts verstand). Mann, war das damals kompliziert: Leser wandten sich bei der Fehlersuche mit Leserbriefen an die Zeitschrift, suchten wochen- und monatelang Fehler, das war alles sehr langwierig ohne Internet.
Nichts ist zu Alt schrieb: > Dafür gabs auch mal Assembler und Bausic Compiler Basic Interpreter, Microsoft. > wenn nicht sogar mal einen C Compiler. Einen PL/65-Compiler in 2 ROMs. Weit unter C Niveau. Aber immerhin.
und Forth "DUP DUP SWAP" der AIM war 1979 mein erster richtiger Computer ( nach "Kosmos Logikus" und einem programmierbarem Taschenrechner HP25)
Wilhelm Ferkes schrieb: > noch nichts verstand). Mann, war das damals kompliziert: Leser wandten > sich bei der Fehlersuche mit Leserbriefen an die Zeitschrift, suchten > wochen- und monatelang Fehler, das war alles sehr langwierig ohne > Internet. Es hatte allerdings auch zur Folge, dass man genug Zeit zum Denken hatte. Heute landen viele Fragen nach wenigen Sekunden intensiven aber vergeblichen Nachdenkens bereits im Internet und es dürfen andere Leute weiterdenken.
A. K. schrieb: > Es hatte allerdings auch zur Folge, dass man genug Zeit zum Denken > hatte. Allerdings. Aus der Zeit habe ich auch noch eine Reihe Bücher hier stehen. Man mußte wirklich seinen Hintern in einen Buchladen oder eine Bibliothek schleppen. Heute suche ich mir Info aber auch im Internet, an Büchern ist in den letzten Jahren kaum noch was hinzu gekommen. > und es dürfen andere Leute > weiterdenken. Andere Leute zum Mitdenken hatte man schlicht nicht, weder Nachbarn, noch Bekannte, noch Kollegen, wenn man in einem anderen Beruf arbeitete, man ist als Bastler oft allein auf weiter Flur. Man mußte wirklich selbst denken. Ich selbst suchte vor 20 Jahren an einem ersten Elektor-Board mit Standard-8051 mal geschlagene 3 Wochen nach einem Fehler, wobei die serielle Schnittstelle am Terminal nur Hieroglyphen ausgab. Oszi hatte ich da noch nicht, und es dauerte eine Weile, bis ich wirklich den Quarz wechselte. Die hatten da tatsächlich eine Quarzschaltung drinne, die einen 3.-Oberwelle-Quarz verwendete, mit einer Festinduktivität zur Unterdrückung der Grundwelle. Und das schwang nicht ordentlich. Da ist man als Anfänger schnell ratlos.
Ich weiß nicht so recht, ob Einsamkeit den eigenen Horizont erhellt. Das denken ja viele. Denkt an die Eremiten und Gurus. Hm. Ich persönlich liebe den Kontrast zwischen meiner Hexenküche und dem Leben draußen. Zumal man nur einmal lebt und jede Zeitverschwendung das Ende näher rückt.
Abdul K. schrieb: > Ich weiß nicht so recht, ob Einsamkeit den eigenen Horizont erhellt. Manchmal schon. Beispielsweise kann man Datasheets selber lesen oder lesen lassen. Im Forum gibts öfter welche der zweiten Kategorie.
Lesen heißt nicht unbedingt verstehen - Weisheit eines Forumbenutzers mit Nachname K.
>War das nicht Bill Gates der mal Ende der Achtziger gesagt hatte dass >640 Kb RAM die nächsten 20Jahre ausreicht? Das war auch der, der seine Hardware nicht ans Laufen gebracht hat, und die er deshalb von Anderen beziehen musste.
Im Prinzip würden 640K sicherlich reichen. Ein ähnliches Statement ist übrigens von wohl Steve Jobs für den Mac überliefert. Er wollte nie mehr als 128K einbauen. Aber mit OOP, hunderten inkompatiblen DLLs, NET-Versionen, PHP Phyton, Ruby usw. (die alle letztendlich das Gleiche tun)...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.