MC 68000 Stromverbrauch

Lt. Motorola Datenblatt von 1993 (!) zieht dein Saurier ca. 1,6 Watt , 
wenn er mit 16Mhz läuft. Dazu kommt die Leistung, die er an die 
angeschlossene Peripherie abgibt. Mein alter, auf 16 Mhz aufgebohrter 
Mac SE hatte auch eine leicht warme CPU - ist aber schon länger her...
Ist das eine von diesen alten VME Bus Platinen ?

VME Bus hatte 2 lange VE Leisten an einer Seite der Platine und wurde 
damals oft für industrielle Zwecke verbaut. Es gab aber auch sogen. 
PC-104 Platinen in der Grösse einer Europakarte , oft mit aufsteckbarer 
RAM oder EPROM Speicherkarte.
Der Stromverbrauch liegt m.E. im normalen Bereich für die alte Hardware. 
Wenn du nicht noch einen Atari ST,Amiga oder eben alten Mac rumstehen 
hast, wird es dir allerdings nahezu unmöglich sein, dafür noch Software 
zu machen. Das waren alles Systeme mit 68k Hardware. Leider ist 
mittlerweile ist m68k für linux auch so gut wie tot, ausser bei uCLinux, 
da gibts noch ein paar Freaks.

Daniel Rohrhofer schrieb:
> RAMmodul mit 1 Mbit
Evtl. doch 2MByte ? Das wären 16 1Mbit DRAMs.

Mischbestückung: CMOS, 74S, 74(A)LS, 12MHz, 8MHz. Deine CPU hat 12MHz! 
Und damals war bei Industrieboards kein Übertakten angesagt. Und dann 
einige PAL oder GAL. Da sind 3A nichts besonderes.

68K gibts übrigens durchaus noch, als ASIC-Teil z.B.

P12 ist ein 12MHz Typ! Glaubs mir, ich stamme wie A.K. aus dieser Zeit 
;-) Vielleicht brauch ich eine Brille.

Die CPU sollte genüßlich handwarm werden. Dann ist es richtig.

Auf jeden Fall stimmt was mit deinem Bildformat nicht und Falk hat wohl 
Urlaub ;-)) 200K würden auch reichen.

Das Board hat sogar noch die klassische 74x04 Fehloszillator-Schaltung. 
Wenn man bedenkt, das damit wichtige Steuerungen realisiert wurden. Ob 
man das auch in den ersten Herzschrittmachern fand?

Daniel Rohrhofer schrieb:

> Wahrnsinn das modul wurde nur durch das ausgetauscht und zum weg
> schmeißen ist es zu schade wer hat in diesen zeitn noch so unikate wie
> m68k ?

Mein funktionsfähiges original VT100 geb ich nicht her!

Naja. Ich habe noch einige 68K Macs. Sozusagen programmierbare 
Terminals.

Zumindest der Crimson Editor für Windoof hat auch Templates für 68K. Und 
es gibt sicherlich noch einiges mehr im Net. Viel Spaß!


Gibt es keine Ipad App VT100 ?

Daniel Rohrhofer schrieb:

> bissl viel wenn man denkt das ein ATmega 16 im leerlauf nur 25 mA
> verbraucht )

Die ursprüngliche 68000 CPU wurde in NMOS-Technik gebaut (68C000 in 
CMOS). Folglich verbrauchen alle Logiklemente im Zustand 0 Dauerstrom. 
Bei CMOS wird nur beim Schaltvorgang selbst Strom verbraucht.

Ausserdem ist der beim Mega16 verwendete Herstellungsprozess zwar auch 
schon ziemlich alt, aber nicht annähernd so alt und stromfressend wie 
der von der 68000 CPU.

Abdul K. schrieb:

> Gibt es keine Ipad App VT100 ?

Es scheiterte an der doppelt hohen Schrift. Dafür gibt es keinen Font 
:-)

Nachtrag: Es ginge natürlich auch ein PowerPC Mac. Die gibts ja noch 
reichlich. Die können sowohl PowerPC als auch 68K Code ausführen. Ob 
unter MacOS 10 und aufwärts da noch was geht, weiß ich nicht.

Bleibt noch das Problem der Übertragung in die Hardware!

Daniel Rohrhofer schrieb:

> Das mit den 12 Mhz kann nicht ganz stimmen auf den board sind drei
> quarze mit 16 für cpu 24 für vermutlich scsi und die 1,8432 für die uart

Die 16- und 24-MHz Quarze dürften die am linken unteren Eck sein. Mit 
den 74S04 als Oszillator. Der 74S74 Teiler daneben macht dann aus den 
24MHz die 12MHz für die CPU.

Bei solchen VME-Systemen sollte man übrigens den Stromverbrauch vom Bus 
nicht ausser Acht lassen. Allein die vermutlich passiven Abschlüsse 
eines solchen Busses haben bereits einen nicht unerheblichen 
Stromverbrauch.

Daniel Rohrhofer schrieb:
> Das ist laut meinen Wissen keine VME Bus Platine die ich habe habe ich
> aus einer Industrieanlage die nur irgendwelche sachen gesteuert hat.

Die Bilder lassen klar erkennen, daß das sehr wohl VME-Bus-Platinen 
sind.

Die CPU-Karte hat übrigens zwei serielle Schnittstellen inklusive 
RS232-Pegelwandler (das sind die beiden 28poligen Bausteine namens 6551 
sowie die 1488/1489 drumherum). Die Pegelwandler funktionieren nur, wenn 
sie mit +/-12-V versorgt werden, da sie nicht wie ein MAX232 über eine 
integrierte Ladungspumpe verfügen.

Etwas Pedanterie noch zum Abschluss: Der 68000 ist kein µC, sondern ein 
µP.

Rufus Τ. Firefly schrieb:
> Etwas Pedanterie noch zum Abschluss: Der 68000 ist kein µC, sondern ein
> µP.

Für damalige Verhältnisse hatte die 68K sowiel RAM in den Registern, das 
das sehr wohl ein µP war!!

Die gute alte Zeit. Langsam springen die ersten in die Kiste. Na, wenns 
Geld dafür überhaupt noch reicht. Die meisten werden wohl verbrannt.

Ich will auch eine CPU sein!

Die ganz hohe Schule war dann das Booten nur mittels ROM ohne RAM einer 
CPU. Weiß gar nicht, ob das bei der 68K machbar wäre.

Abdul K. schrieb:
> Für damalige Verhältnisse hatte die 68K sowiel RAM in den Registern, das
> das sehr wohl ein µP war!!

Schrieb ich ja, das ist ein Prozessor, und kein Controller. Ein 
Controller ist es trotz der paar Register nicht, weil kein 
Programmspeicher und auch keine Peripherie vorhanden sind ... aber ich 
gehe davon aus, daß Du das auch weißt.

Was soll das sein? Der Code für das Starten per Mäuseklavier?

Natürlich meinte ich µC. Bitte korrigiere das als Moderator. Klaro 
stimme ich dir ansonsten zu. Es war als Scherz gedacht.

Irkan schrieb:
> Daniel Rohrhofer schrieb:
>> Okay ich wollte dich nicht beleidigen ! Das Programmieren wird recht
>> lustig ohne software nur mit txt editor Die Oszi Schaltung ist ein
>> Wahrnsinn das modul wurde nur durch das ausgetauscht und zum weg
>> schmeißen ist es zu schade wer hat in diesen zeitn noch so unikate wie
>> m68k ? Das mit Hyperterminal wäre keine schlechte Idee ! Muss keine neue
>> Hadware anhängen und da ich die Schaltpläne nicht mehr finde habe ich
>> ein kleines Problem.  Ich dachte mehr an monochrom Bildschirm als
>> Ausgabe Gerät
>
> der 68k ist einer der Prozessoren mit der geilsten Assembler-Syntax die
> ich je lernen durfte. Ist im Vergleich wie eine Hochsprache möchte ich
> meinen.
>
> Falls Not am Mann, ist frag doch mal den Luna-Entwickler, der stammt
> auch aus der Zeit und hat ewig Software für den Kram damals geschrieben.
>
> Zur 68k-Programmierung kannst du notfals MagiC-PC oder einen
> Amgi-Emulator nutzen und alle Tools die es dafür gibt. Den
> Turbo-Assembler (Atari) kann ich nur empfehlen.
>
> Gruß, Irkan

Hallo Daniel,

die Programmierung in 68000er Assembler wäre z.B. durch folgende IDE 
unter Windows möglich:

http://www.easy68k.com/


Oder wenn es in C/C++ geschehen soll:

https://www.ashware.com/gnu-68kcoldfire-cc-compiler.htm


Dann brauchst Du natürlich noch einen EPROM-Brenner (und ein 
UV-Löschgerät) um die erzeugten Binärdateien wieder auf die EPROMS zu 
brennen!


Gruß

Markus

Jo, jo, der gute alte VME Bus :P
Abdul K. schrieb:
> 68K gibts übrigens durchaus noch, als ASIC-Teil z.B.

Das ist wahr - ich habe hier sogar einen 68k uCSimm, einen kompletten 
uClinux Rechner auf einer 30pol. SIMM Platine. Nettes Teil, und da ich 
auf der o.a. Karte keine MMU entdecken kann, ist uCLinux vllt. gar nicht 
die schlechteste Wahl.
Übrigens hinkt der Vergleich mit den AVRs ein wenig, denn der 68000 ist 
eine echte 16 bit CPU, hehe.
Ansonsten müsstest du jetzt als erstes mal die Adressbereiche der 
Maschine ausklingeln, also wo sind die UARTs, der Static RAM ( man 
beachte ihn auf der CPU Platte ! ), der DRAM usw. Ohne Unterlagen kein 
so leichter Job. Ich drücke dir die Daumen, das ein generisches 
Monitorprogramm in den EPROMs drin ist. 'Macsbug' ist übrigens der 
'Motorola Advanced Code Debugger' und evtl. gibts davon Quellcode 
irgendwo im Netz.
Ich hab meine 68k Mac Sammlung (Plus, SE, SE30, FX, LC usw. ) beim Umzug 
vor nem Jahr entsorgt, weil ich einfach nicht wusste, was man damit noch 
soll. Selbst SCSI Platten sind heute ja so schwer zu kriegen.

Daniel Rohrhofer schrieb:
> Gibs irgendwo an adapter für die mäuse.

Die Atari Maus ist eine 'dumme' Maus, wo lediglich die Quadratursignale 
an den SubD 9 Stecker geführt werden ( wie beim Mac Plus) . Lässt sich 
relativ leicht aus jeder alten Maus basteln, sofern sie entweder mit 
Gabellichtschranken läuft oder die Quadratursignale am Kamerachip hat. 
Wenn eine optische Maus 2 Chips drin hat ( 1 für USB und einen für die 
Optik) dann ist die Chance gross, das die Quadratursignale am Optikchip 
liegen.

Ich würde mit den EPROMs anfangen, auslesen und gucken, was da so 
passiert. Der Befehlssatz des 68000-ers ist sehr gut nachzuvollziehen, 
so dass eine gute Chance besteht, mit einem Dissassembler was 
herauszufinden.

Oft hatten solche Systeme auch ein über die serielle Schnittstelle 
erreichbares Monitorprogramm, wie hier schon geschrieben. Damit ließe 
sich je nach Umfang der implementierten Funktionen  ev. auch schon ein 
bißchen was herausfinden. Die PALs zu dekodieren und die Funktion daraus 
abzuleiten dürfte nicht ganz trivial sein, da natürlich in diesem Zuge 
auch zu prüfen wäre, welche Adress- und Steuerleitungen wo in den PAL 
gehen.

Abdul K. schrieb:
> Ich will auch eine CPU sein!
So eine alte, die jetzt nach 30 Jahren am Ende ihres Lebens ist,
oder eine brandneue, die bis dahin noch gut 5 Jahre vor sich hat?   ;-)

Irkan schrieb:
> lasst uns ein wenig in Erinnerungen schwelgen...
> s_ascii_save01: move.b  (A0)+,D0        ;Namen kopieren
>                 move.b  D0,(A1)+
>                 beq.s   s_ascii_save02
>                 cmp.b   #'.',D0
>                 bne.s   s_ascii_save01
Ich sag nur: schön, so ein orthogonaler Befehlssatz...

noch ein Rentner schrieb:
> Selbst die hier
> eingesetzten GTE-6551 glänzten immer durch gelegentliche
> Übertragungsfehler.

Man darf nur nicht auf die Idee kommen, das Hardwarehandshake zu nutzen, 
denn das hat der 6551 sehr direkt interpretiert - nämlich mitten 
während der Übertragung eines einzelnen Bytes.

Verzichtet man auf das Hardwarehandshake, dann ist der 6551 aufgrund des 
integrierten Baudratengenerators reizvoller als die eigentlich logische 
Wahl in Form des 6850. Und nicht minder stabil.

Bei 68K-Systemen allerdings wurde auch oft der 68681 von Exar verwendet, 
der all diese Probleme sowieso nicht aufwies.

Ahh, das war also der Grund, warum Apple immer die 8530 SCC von Zilog 
verbaut hat, und nicht die 6551/6850. Die 8530 war allerdings wirklich 
fast schon selber ne CPU :P
In den EPROMs wird wahrscheinlich nur so ne Art Bootloader sein. Ich 
habe hier noch ein PC-104 Singleboard mit '286 , und da haben die EPROMs 
eigentlich nur probiert, ein DOS von der Static RAM Aufsteckkarte zu 
laden, oder sonstwoher - immerhin ist da tatsächlich ein Floppy 
Controller mit drauf gewesen.

Matthias Sch. schrieb:
> Ich habe hier noch ein PC-104 Singleboard mit '286

Das kannst Du nicht vergleichen, das ist einfach nur ein PC.

Solche 68k-Systeme gab es durchaus auch mit vollständigem Betriebssystem 
im ROM, so zum Beispiel das Echtzeitbetriebssystem OS-9/68k von 
Microware.

Des Threadstarters Idee, mit diesem VME-Bus-System etwas mit Linux 
anfangen zu wollen, ist allerdings zum Scheitern verurteilt, da weder 
eine MMU vorhanden ist, noch der Arbeitsspeicher ausreichen dürfte. Auf 
der zweiten Karte scheinen wohl 4 MByte statisches RAM verbaut zu sein, 
auf der Hauptplatine aber nur ein paar hundert kByte.

Allenfalls ucLinux könnte gehen, macht aber auf einem 12MHz-System ganz 
sicher keinen Spaß. Ohne eine genaue Dokumentation der Hardware 
(Adressbelegungstabelle für RAM/ROM und Peripherie) wird sowieso nicht 
allzuviel zu erreichen sein.

68000er Parade

hinz schrieb:
> Matthias Sch. schrieb:
>> Ahh, das war also der Grund, warum Apple immer die 8530 SCC von Zilog
>> verbaut hat, und nicht die 6551/6850.
>
> http://upload.wikimedia.org/wikipedia/commons/9/93...

Haha, das ist aber von 'nem Apple][, der zählt hier nicht :P Für den hab 
ich auch noch ne MIDI Karte rumliegen mit nem 6850.

Rufus Τ. Firefly schrieb:
> noch der Arbeitsspeicher ausreichen dürfte. Auf
> der zweiten Karte scheinen wohl 4 MByte statisches RAM verbaut zu sein,
> auf der Hauptplatine aber nur ein paar hundert kByte.

Die Programme werden beim 68k immer im RAM ausgeführt wenn ich nicht 
täusche, sodass die paar hundert kB der Cache sein könnten und die 4MB 
der normale Arbeitsspeicher.

Der 68k hat einen linearen Adressbereich, es muss nichts segmentiert 
oder per Paging zugegriffen werden. Er hat zwar eine 16 Bit ALU aber es 
können 32 Bit breite Adressen und Operationen durchgeführt werden. Eine 
MMU ist nicht zwingend notwendig.

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68000

Wenn du die Eeproms ausgelesen hast, hilft eventuell ein 
68k-Disassembler:
http://www.monroeccc.edu/ckelly/Files/irapc200.zip

Gruß Ehrhardt

Ehrhardt Balstein schrieb:

> Die Programme werden beim 68k immer im RAM ausgeführt wenn ich nicht
> täusche, sodass die paar hundert kB der Cache sein könnten und die 4MB
> der normale Arbeitsspeicher.

68000er hatten keinen Cache und Programme wurden sehr wohl auch aus dem 
EPROM ausgeführt.

A. K. schrieb:
> Ehrhardt Balstein schrieb:
>
>> Die Programme werden beim 68k immer im RAM ausgeführt wenn ich nicht
>> täusche, sodass die paar hundert kB der Cache sein könnten und die 4MB
>> der normale Arbeitsspeicher.
>
> 68000er hatten keinen Cache und Programme wurden sehr wohl auch aus dem
> EPROM ausgeführt.

mein letzter Kontakt damit war der 68030, möglicherweise habe ich da was 
verwechselt, ja.

hinz schrieb:
>> Haha, das ist aber von 'nem Apple][, der zählt hier nicht :P Für den hab
>> ich auch noch ne MIDI Karte rumliegen mit nem 6850.
>
> Selbstverständlich zählt der! Und wenns dir um den 68000 geht, den gabs
> als Steckkarte für die Kiste.

Ich hatte auch jahrelang so eine Kiste (Space 81 von Segor 
selbstbestückt) aber wir reden hier nun mal von echten 68000ern. Die Z80 
Karte war ja schon krank, aber die 68k Karte war wirklich Unsinn. Wer 
hat das gebraucht ( und war das nicht ein 68008 ?)

Ehrhardt Balstein schrieb:
> mein letzter Kontakt damit war der 68030, möglicherweise habe ich da was
> verwechselt, ja.

Auch der 68030 hat sehr wohl ausm ROM gearbeitet. Bestes Beispiel war 
mein kleiner SE30 ( mit CoPro 68881) . Der gesamte Bootcode und 
QuickDraw waren in den ROMs und wurden auch nicht ins RAM kopiert.

noch ein Rentner schrieb:

>> Er hat zwar eine 16 Bit ALU
>
> Nee, 32 Bit. Sonst ginge kein ADD.L oder ASL.L usw..

Irrelevant.

Es gab einen 8-Bit 68xx-µC mit 1-Bit ALU (bitseriell).
Die Z80 hatte m.W. eine 4(!)-Bit ALU, aber 16-Bit Add/Sub.
Die Z8000 hatte eine 16-Bit ALU, aber sogar 32-Bit Mult/Div.

Man merkte auch, dass die 68000 keine 32-Bit ALU hatte, denn 32-Bit 
Datenoperationen brauchten mehr Takte, auch Reg-Reg. Anders bei 
Adressrechnungen, aber dafür braucht es nur einen Adder, keine ALU.

Wenn hier schon all die Rentner versammelt sind, muss ich mich auch als 
ebensolcher offenbaren. Ich habe hier noch jeweils ein KatCe (mit 
68000)und ein KatCe 332 (mit 68332) herumliegen, von denen ich damals 
sehr begeistert war. An das KatCe hatte ich damals sogar einen 
ISA-Floppycontroller (mit uPD765 ?) adaptiert und mit der KatCe 332 mein 
niemals ganz fertiggebautes Rastertunnelmikroskop gesteuert. Leider habe 
ich nicht die Zeit, die Projekte weiterzuführen. :-(

Und dann liegt hier auch noch ein ganzer Stapel VME-Boards mit 68020 und 
68030, die teilweise sogar noch originalverschweißt sind...

Wo mein SC/MP II ist, weiß ich momentan nicht. Ich hoffe, dass das gute 
Stück nicht beim Umzug abhandengekommen ist. :-/

Aber die PDT-11/150 steht hier noch wohlbehalten im Keller, gleich neben 
dem HP-85 und MZ-821.

Der MZ-80K wurde aber leider versehentlich beim Entrümpeln des Hauses 
meiner Eltern entsorgt. heul

Matthias Sch. schrieb:
> VME Bus hatte 2 lange VE Leisten an einer Seite der Platine und wurde
> damals oft für industrielle Zwecke verbaut. Es gab aber auch sogen.
> PC-104 Platinen in der Grösse einer Europakarte , oft mit aufsteckbarer
> RAM oder EPROM Speicherkarte.
> Der Stromverbrauch liegt m.E. im normalen Bereich für die alte Hardware.
> Wenn du nicht noch einen Atari ST,Amiga oder eben alten Mac rumstehen
> hast, wird es dir allerdings nahezu unmöglich sein, dafür noch Software
> zu machen.

So schlecht sieht's da gar nicht aus
Emulatoren
http://leonard.oxg.free.fr/SainT/saint.html
http://www.winuae.net/ (aminet ist auch noch online 
http://aminet.net/tree?path=dev)

Irkan schrieb:
> Zur 68k-Programmierung kannst du notfals MagiC-PC oder einen
> Amgi-Emulator nutzen und alle Tools die es dafür gibt. Den
> Turbo-Assembler (Atari) kann ich nur empfehlen.

5240, 4e75 1)

Falls jemand TurboAss und Bugaboo sucht...
http://www.sarnau.info/software:turboass

1) addq.w #1, d0 + rts und anderes brennt sich mit der Zeit ins Gehirn, 
wenn man eine zeitweise fast nur 68k Assembler schreibt/debuggt. Und bei 
so was http://dss.in.tum.de/files/brandt-research/fullscreen.txt  kennt 
man irgendwann auch alle wichtigen Ausführungszeiten

p.s.

1

 s_ascii_save01: move.b  (A0)+,D0        ; 8

2

                move.b  D0,(A1)+        ; 8

3

                beq.s   s_ascii_save02   ; 10/8 (taken/not taken)

4

                cmp.b   #'.',D0               ; 8

5

                bne.s   s_ascii_save01   ; 10/8

6

s_ascii_save02:

8 + 8 + 8 + 8 + 10 = 42 Zyklen

1

2

               moveq #'.', d1; 4

3

s_ascii_save01:  move.b  (A0)+,D0        ; 8

4

                move.b  D0,(A1)+        ; 8

5

                cmp.b d1, d0  ; 4

6

                dbeq d0, s_ascii_save01; (cc false 10/14, cc true 12)

8 + 8 + 4 + 10 = 30 Zyklen... scnr

Lothar Miller schrieb:

> Ich sag nur: schön, so ein orthogonaler Befehlssatz...

Die Codierung war allerdings das exakte Gegenteil. Der Code vieler 
Befehle war eigentlich der Code anderer Befehle mit dort nicht 
zulässiger Adressierungsart. Wie etwa
 MOVEP = ORI   #,Ax
 EXTx  = MOVEM regs,Dx
und noch viel mehr von dieser Art.

Auch sind völlig freie 2-Adress MOVE Befehle zwar angenehm für den 
Programmierer, aber eine Höllenmaschine für CPU-Architekten. Was schon 
bei der 68010 zu der Verzweiflungstat Motorolas führte, Befehle, die auf 
einen Busfehler liefen, nicht wie sonst üblich ohne Auswirkung auf 
Register und Speicher für späteren Neuversuch abzubrechen, sondern 
virtuellen Speicher über ziemlich aufwendige Microcode-Interrupts halb 
ausgeführter Befehle zu realisieren.

Wenig durchdacht war auch die Bitadressierung. Wenn die Bits von rechts 
nach links aber die Bytes von links nach rechts nummeriert werden, dann 
steckt man spätestens bei Bitfeldern in der Falle. Was dazu führte, dass 
mit der 68020 die alten Einzelbit-Befehle von rechts nach links und 
Bitfeldbefehle und neue Einzelbitbefehle von links nach rechts 
nummerierten.

A. K. schrieb:
> Lothar Miller schrieb:
>
>> Ich sag nur: schön, so ein orthogonaler Befehlssatz...
>
> Die Codierung war allerdings das exakte Gegenteil. Der Code vieler
> Befehle war eigentlich der Code anderer Befehle mit dort nicht
> zulässiger Adressierungsart. Wie etwa
>  MOVEP = ORI   #,Ax
>  EXTx  = MOVEM regs,Dx
> und noch viel mehr von dieser Art.

Vermutlich um OpCode-Space zu sparen.


> Wenig durchdacht war auch die Bitadressierung. Wenn die Bits von rechts
> nach links aber die Bytes von links nach rechts nummeriert werden, dann
> steckt man spätestens bei Bitfeldern in der Falle. Was dazu führte, dass
> mit der 68020 die alten Einzelbit-Befehle von rechts nach links und
> Bitfeldbefehle und neue Einzelbitbefehle von links nach rechts
> nummerierten.

Beautiful things are always small! <tm ehydra>

Andreas Schweigstill schrieb:
> Wo mein SC/MP II ist, weiß ich momentan nicht. Ich hoffe, dass das gute
> Stück nicht beim Umzug abhandengekommen ist. :-/
>

Gestern wollte ich noch das Stichwort SC/MP fallenlassen, aber dann kams 
mir wie Spam vor.


> Aber die PDT-11/150 steht hier noch wohlbehalten im Keller, gleich neben
> dem HP-85 und MZ-821.
>

Und, setzt du dich manchmal zwischen die Petriosen?


> Der MZ-80K wurde aber leider versehentlich beim Entrümpeln des Hauses
> meiner Eltern entsorgt. *heul*

Ja, das dachte ich auch mal. Der Weihnachtsmann ist nie ein Fremder!

Ich hatte damals mal Prospekte für den MZ-80K angefordert. Tage später, 
ich war gerade in der Schule, kam ein Vertreter bei meinem Vater vorbei. 
Die dachten wirklich ich wolle das Ding kaufen.
Wen ich das Teil heute betrachte, kann ich nur froh sein es nicht 
bekommen zu haben. Ist nicht wirklich was interessantes! Da war der c't 
86 viel förderlicher fürs Wissen.

Lothar Miller schrieb:
> Abdul K. schrieb:
>> Ich will auch eine CPU sein!
> So eine alte, die jetzt nach 30 Jahren am Ende ihres Lebens ist,
> oder eine brandneue, die bis dahin noch gut 5 Jahre vor sich hat?   ;-)
>

Nun, diese CPU ist aber dann auch 100x schneller!

Meiner Meinung nach, ist die Lebensdauer so gut wie immer durch 
Fremdeinwirkung begrenzt. Das ist so wie mit den Energiesparlampen. Die 
sterben oft auch durch Unfälle. Man stößt mit dem Nischel dran und so...

Damit die nächste Frage gleich beanwortet ist: Meine Losgröße ist sicher 
über 1000 CPUs vom Typ 8051 und Varianten.

Schön war das an einem Board mit 8051 und 8255 zu sehen: Der 8255 war 
fast immer der tote Baustein. Da hängten die Kunden ihre Schaltungen ran 
und wie die aussahen, das konnte ich öfters erahnen. Manche Platinen 
stanken nach Hühnerstall, andere verschwanden in der Kirchturmuhr eines 
Schmiedemeisters. Ihr könnt euch vorstellen, wieviel Strom die über eine 
8255 schickten...
Jedenfalls, je exponierter ein IC auf den Platinen ist, umso eher stirbt 
es!

Abdul K. schrieb:
> ist die Lebensdauer so gut wie immer durch Fremdeinwirkung begrenzt.
Ja, durch Abkündigung...  :-(

Lothar Miller schrieb:
> Abdul K. schrieb:
>> ist die Lebensdauer so gut wie immer durch Fremdeinwirkung begrenzt.
> Ja, durch Abkündigung...  :-(

Das ist ein wichtiger Aspekt, sicherlich! Gern werden dir _hier _sogar 
ausnahmsweise die allermeisten zustimmen!

Schön, das wir das Edisongewinde bislang behalten durften. Kindertod sag 
ich da nur.

Lothar Miller schrieb:

>> ist die Lebensdauer so gut wie immer durch Fremdeinwirkung begrenzt.
> Ja, durch Abkündigung...  :-(

Kaufen kann man 68000er aber noch. Sogar die alten NMOS-Versionen. 
Zumindest in Kleinstückzahlen.

Die 68000er Reihe ist aber auch noch komplett (außer dem 68010 
anscheinend) bei Freescale mit Product Status "Active" gelistet: 
http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=68K

Abgesehen davon wird die 68k-Architektur bis heute noch in den ColdFire 
Mikrocontrollern weitergeführt. Also sooo tot isses ja dann doch nicht, 
dass hier die Rentner in alten Kriegserinnerungen schwelgen müssen ;-)

Zumal die Rente für manche dieser "Rentner" noch weit weg ist, 
insbesondere bei der grad diskutierten Grenze von 72 Jahren. Prinzip 
Schiebewurst.

Aber in Erinnerungen zu schwelgen ist auch schon. Insbesondere dann, 
wenn die Einen drin schwelgen und schöne rosa Bildchen malen. Weil es 
den Anderen Gelegenheit gibt, darauf hinweisen, dass nicht alles so 
rosig war wie geschildert. ;-)

Ich befürchte, wie sind wohlmöglich die einzige Generation die nie einen 
Krieg im eigenen Lande sah. Unser Krieg bestand schlicht darin, morgens 
nicht zu verschlafen, damit die Stechuhr nicht rot anzeigt. Viel mehr 
war nicht gefordert!
Die folgenden Generationen kämpfen da um ganz andere Dinge: 
Leiharbeitsklaven, informationelle Überforderung, Kernkraftunfälle, usw.
Wie lange die Grenzen der EU noch halte, ist auch fraglich. Die 
Container aus China sind ja erst der Anfang.

Rente werde ich wie sehr viele, praktisch keine bekommen. Die hat man 
unser Generation einfach entzogen. Sehr praktisch, die die das zu 
verantworten haben, sind dann alle schon tot oder zu senil zum 
bestrafen.

Manchmal würde uns ein arabischer Frühling vielleicht gut tun. Wir 
machen immer alles mit.

Wer immer er auch ist, schrieb:
> Abdul K. schrieb:
>> Manchmal würde uns ein arabischer Frühling vielleicht gut tun. Wir
>> machen immer alles mit.
>
> Vielleicht sieht man das in der idyllischen Oberlausitz so :-)
>

Wenn du schon von anderen die Intimsphäre offenbarst, solltest du auch 
wissen das ich im Westen groß wurde.


> Wir hatten 1968 und ich habe ab einem gewissen Alter nie das gemacht,
> was mir gesagt wurde. Daher auch der fehlende Rentenanspruch.
>

Dann hast du ja virtuell plus gemacht.
Zu meiner Zeit im normalen Leben machte man 8 Stunden das was die Firma 
dachte, danach gings ans Hobby. Diese Grenze verschwimmt zunehmend. Ein 
Grund für oftmals psychische Probleme.

noch ein Rentner schrieb:
> Andreas B. schrieb:
>> dass hier die Rentner in alten Kriegserinnerungen schwelgen müssen
> Du scheinst noch jung zu sein.
Ich würde raten 2012-1977 = 35. Habe ich richtig geraten?  ;-)

Abdul K. schrieb:
> Ich befürchte, wie sind wohlmöglich die einzige Generation die nie einen
> Krieg im eigenen Lande sah.
Find ich gut so. Ich kann auch leben ohne einen Krieg gesehen zu haben. 
Ich muss nicht überall dabei gewesen sein...

Daniel Rohrhofer schrieb:
> Ich finde es ur komisch das ich auch noch ein RAMmodul mit 1 Mbit habe
> und wenn das angeschlossen wird habe ich eine Stromaufnahme von 4 A

Das zeigt uns doch schon, das früher nicht alles besser war. Wer würde 
denn heute noch so eine Brate akzeptieren? Einen Energy Award gibts 
dafür sicher nicht. Ich bin zwar auch nicht mehr der jüngste ( Hab mit 
nem ZX81 angefangen ) aber man muss sich auch mal trennen können, 
hehehe.

Naja die 4A sind relativ zu betrachten. Wenn du mit der VME Bus Karte 
eine Maschine steuerst die rund 20kW aufnimmt interessieren die 20W fuer 
die Steuerung auch niemand mehr. Da nimmt allein schon ein Schuetz ca. 
10..20W auf.

Daniel Rohrhofer schrieb:
> Gibs irgendein Programm zum EPROM zusammen fügen ?

Es scheint, als ob die SRecord Tools dazu in der Lage sind :
http://srecord.sourceforge.net/

Das Zerlegen ist ein Klacks für objcopy, aber nur die SRecord Tools 
scheinen die Teile auch wieder zusammenzukriegen. Der Befehl scheint 
'-unsplit' zu sein. Frage mich, warum sie nicht einfach '-join' dazu 
gesagt haben.

Hier noch die hitzige Debatte bei den AVRFreaks zu diesem Thema:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=591772

Daniel Rohrhofer schrieb:
> 5 V 50 A
> 24 V 20 A

Wem das aufn Kopf fällt, der braucht keinen Hut mehr :D

MCUA schrieb:
>>Auch sind völlig freie 2-Adress MOVE Befehle zwar angenehm für den
>>Programmierer, aber eine Höllenmaschine für CPU-Architekten.
> Und dennoch haben einige neuere CPU-Archit. diese Befehle drin.
> Ausserdem braucht man es intern ja "nur" in 2 Befehle zu zerlegen.

Nur?
Speicherindirekt mit Präindex ([bd,An,Xn],od)
d.h. erst wird bd (base displacement) + An + Xn * Skalierung gerechnet, 
dann der Wert an dieser Adresse gelesen, od (outer displacement) 
hinzuaddiert und dann auf die endgültige Adresse zugegriffen. Und dann 
das ganze bei einem move...

Schön, das die Jungs das damals in Pascal geschrieben haben. Sieht man 
ja heute bei kommerzieller Software so gut wie gar nicht mehr.
Man beachte ausserdem, wie viel Strings die Leute schon für den 
einfachen Vorgang des Festplattenformatierens verbraten haben. Scheint 
was besonderes gewesen zu sein - oder eben wertvolle Patientendaten :P

Arc Net schrieb:
> Nur?
> Speicherindirekt mit Präindex ([bd,An,Xn],od)
> d.h. erst wird bd (base displacement) + An + Xn * Skalierung gerechnet,
> dann der Wert an dieser Adresse gelesen, od (outer displacement)
> hinzuaddiert und dann auf die endgültige Adresse zugegriffen. Und dann
> das ganze bei einem move...

Wie oft diese Befehle wohl dann wirklich benutzt wurden? Letztlich kann 
man sie ja durch einige simplere Befehle ersetzen.

Meiner Meinung nach der falsche Ansatz. Wenn schon Spezialbefehle, dann 
müssen die auch einen direkten Vorteil bieten (Laufzeit, 
Speicherbedarf).

MCUA schrieb:

>>Auch sind völlig freie 2-Adress MOVE Befehle zwar angenehm für den
>>Programmierer, aber eine Höllenmaschine für CPU-Architekten.

> Und dennoch haben einige neuere CPU-Archit. diese Befehle drin.
> Ausserdem braucht man es intern ja "nur" in 2 Befehle zu zerlegen.

Welche wären das? Auf die Oberklasse beschränkt, ohne Controller. Bei 
x86 gibts das, aber als neue CPU-Architektur würde ich die nicht grad 
bezeichnen.

Wobei dieses Thema bei einer OoO-Implementierung allerdings auch viel 
von seiner Problematik verloren hat. Ein Problem war das hauptsächlich 
davor. NS hatte dieses Thema bei anno 32032 nie fehlerfrei in den Griff 
bekommen. Bei aktuellen Implementierungen ist das einfach bloss 
ineffizient - aufgrund der Latenzzeit ist es effizienter, die Befehle 
bereits im Programm zu trennen.

Abdul K. schrieb:

> Wie oft diese Befehle wohl dann wirklich benutzt wurden? Letztlich kann
> man sie ja durch einige simplere Befehle ersetzen.

So lief es ja auch. Bei 68040 und insbesondere 68060 gab es effiziente 
und ineffiziente Befehle und Adressierungsarten. Befehle mit zu 
komplexer Dekodierung oder zu komplexem Ablauf wurden langsamer 
dekodiert und ausgeführt als die Ersatzsequenz aus effizienten Befehlen.

Der 2-Adress MOVE der 68020 mit erweiterten Adressierungsarten war 
grauenhaft zu dekodieren, die VAX lässt grüssen. Die Länge der Codierung 
des ersten Operanden ging nicht allein aus dem ersten Befehlswort 
hervor, sondern es flossen teilweise auch Teile der Adressbeschreibung 
des ersten Operanden mit ein. Und erst nachdem diese Länge ermittelt war 
wusste der Dekoder, wo der zweite Operand im Befehl überhaupt codiert 
wurde. Und erst nach der Dekodierung des zweiten Operanden wusste er, wo 
der nächste Befehl anfängt. Mit solchen Codierungen superskalar zu 
dekodieren war reichlich aufwendig.

Anno 68000 war dieser Aspekt noch einfach, da die Positionen der 
Operanden und die Länge des Befehls vollständig aus dem ersten 
Befehlswort ermittelbar waren. Die 68020 lief mit Volldampf in die 
falsche Richtung und ich kann mit lebhaft vorstellen, wie die Designer 
sich (oder ihre Kollegen) später in den Hintern gebissen haben, ob ihrer 
Kurzsichtigkeit ein paar Jahre zuvor.

Beim CPU32 flog schon manches wieder raus, beispielsweise die 
speicherindirekten Adressierungen. Coldfire setzte dieses 
Gesundschrumpfen weiter fort.

Aus technischer Sicht richtig. Der Unterton meines Beitrags war einfach 
der: Wie kann ein Entwicklungsteam auf solche blöden Ideen kommen? Hat 
die niemand kontrolliert? Verständnis hätte ich für sowas nur bei einem 
lonely Bastler in seinem Kämmerchen, der Kraft seines momentanen 
Unkenntnisstand einfach keine bessere Idee hatte und alles richtig 
machen wollte.

Verwundert -
Abdul

Abdul K. schrieb:

> Aus technischer Sicht richtig. Der Unterton meines Beitrags war einfach
> der: Wie kann ein Entwicklungsteam auf solche blöden Ideen kommen?

"Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen."

Das war der damalige Trend. Man hatte nicht den Ausblick auf 10-20 Jahre 
im Auge, sondern genau und nur die grad zu implementierende Version. 
Intel war ja auch nicht klüger, auch die haben sich im Laufe der Zeit 
einige Eier ins Nest gelegt, die sie Jahrzehnte später nicht wieder los 
wurden.

Viele Designer quer durch die Welt bastelten solche Super-CISCs 
zusammen, teilweise massiv beeinflusst von einer der dominanten 
Architekturen dieser Zeit, der VAX. NEC hatte ein Ding konzipiert, das 
fast wie eine VAX aussah. NS hatte sich bei der 32000 ebenfalls 
unübersehbar daran orientiert.

Parallel dazu entstanden bereits die ersten RISCs, anfangs allerdings 
teilweise unter Ausschluss der Öffentlichkeit. IBMs erste RISC wurde als 
internes Betriebsgeheimnis behandelt und versenkt, weil zu gefährlich 
für die lukrativen Mainframes. Es war bereits Mitte der 70er, also lange 
vor dem Höhepunkt der CISC-Blase, als IBM (John Cocke) feststellte, das 
diese Gigantomanie völliger Unfug ist.

Die VAX wiederum ... Nun ja, als DEC eine neue Generation fertig hatte, 
deren Performance nicht mehr von im Gänsemarsch dekodierten Operanden 
und Befehlen gebremst wurde, ware der Verein ob des Aufwands beinahe 
pleite. Da wusste nun jeder wohin die Reise geht.

MCUA schrieb:

> Bsp.weise M16C und Verwandschaft.

Und ich schrieb noch ausdrücklich "ohne Controller"...

MCUA schrieb:

> Wenn der konkrete Befehl wirklich länger braucht als die Ersatzsequenz,
> hat man natürlich was falsch gemacht.

Das war schon bei der VAX so. Deren CALL Befehl war so komplex, weil mit 
allerlei oft unbenutzten Möglichkeiten versehen, dass der Normalfall 
eines Unterprogrammaufrufs oft mit einem simplen BSR realisiert wurde. 
Weil schneller.

> Was aber nicht heissen kann, dass man prinzipiell keine komplexeren
> Befehle creieren sollte, bloss weil man das mit mehreren einfacheren
> Befehlen ersetzen könnte.

Klar. Der Haken ist nur, dass dabei leicht lange Abhängigkeitsketten 
entstehen. Die bei einer Aufdröselung in Teiloperationen effizienter mit 
anderen Operationen verzahnt werden können und den OoO Core dann nicht 
so an der Arbeit hindern.

Sinnvoll kann das bei Blockmoves sein, wenn der Microcode die wirklich 
gut dem jeweiligen Core in Abhängigkeit von der Länge und Adresslage 
anpasst. Das kann eine Lib zwar auch, ist dann aber direkt vom Core 
abhängig.

MCUA schrieb:

> Auch die Summe von Einzelbefehlen (die auch Abhängigkeiten haben können)
> kann in Summe eine lange Abhängigkeitskette ergeben, die womöglich noch
> länger ist als Die des komplexen Befehls.

Klar. Aber wenn es sich nicht grad um sowas wie Stringbefehle handelt, 
dann kann ein einzelner Befehl erst dann abgeschlossen werden (retired), 
wenn er vollständig fertig ist. Und kann dabei von keinem anderen Befehl 
überholt werden.

Folge: Reorder Buffer und Scheduler des Cores laufen voll und alles 
wartet darauf, dass der Komplexbefehl endlich fertig wird. Das ist 
natürlich egal, wenn sonst grad nichts parallel läuft oder laufen 
könnte, aber wehe wenn doch.

Wenn man den Komplexbefehl in Teiloperationen ausführt, dann werden die 
ebenso einzeln abgeschlossen und stopfen den Core nicht zu. Andere davon 
unabhängige Operationen im Befehlsfluss werden davon dann nicht 
behindert.

Je nachdem wie ein mögliches SMT/Hyperthreading implementiert ist könnte 
ggf. auch ein unabhängiger Thread auf dem gleichen Cores durch solche 
Komplexbefehle beeinträchtigt werden. Nicht jedoch durch die 
Teiloperationen.

Du wirst davon ausgehen können, daß das kein Problem ist. Aus 
Layoutoptimierungsgründen werden und wurden Bauteile durchaus auch in 
unterschiedlicher Orientierung plaziert.

Hallo Holm, (ops, hab doch Account hier )

Hehe, VDS/Vosskühler ist Hersteller und Lieferant von diese System, der 
aber extra für meine Arbeitsgeber gebaut wird. So hat alte Mitarbeiter 
mir gesagt.


Aber ich sehe, dass ihr trotzdem damit anfangen kannst, ohne meine 
Zuhilfe.

Falls ich weitere diese System in Schrott findest, solle ich dem retten?

Beste Grüss
Matt