Hallo Mikrocontroller-User!! Ich habe eine dringende Frage: Wie viel Strom nimmt der MC 68000 bei 16 Mhz auf, da ich ein Board habe wo der µC nur 2 EPROM,2 UART,2 RAM @ 256 Kby , 1 PIO und einen SCSI-Controller ansteuert( Relativ viel, für einen µC) und ich habe es eingeschalten ein LED leuchtet das andere blinkt in regelmäßigen Abständen und der µC erwärmt sich !! Ich bin es Gewohnt das der µC fast nie warm wird. Könnte es sein das der µC defekt ist ? MFG Daniel Rohrhofer
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 ?
Das ist laut meinen Wissen keine VME Bus Platine die ich habe habe ich aus einer Industrieanlage die nur irgendwelche sachen gesteuert hat. Aus der Rechnung folgt das der 68k ungefähr 0,32 A zieht und die ganze Schaltung zieht ungefähr 1,35 A also daraus folgt 1,03 A ( Is doch ein bissl viel wenn man denkt das ein ATmega 16 im leerlauf nur 25 mA verbraucht ) Und das ärgste der µC macht fast nix nur warten. 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 P.S.: Ich werde noch ein foto hinzufügen falls ich es schaffe es kleiner zu machen
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.
Angehängte Dateien:
-
2012-02-09_09.01.43.jpg
1,6 MB
Einen alten atari 1040 habe ich noch nur ist die maus kaputt linux sollte auch kein problem darstellen. Der hersteller des board ist vds den eprom inhalt kann ich auch anhängen per bedarf Das Ram modul besteht aus 64 * 16 kb rambausteinen 8 bit modus
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.
Da hat man die Rechenleistung noch gefühlt! Irgend wann gibt es Solar µChips mit denen man nebenbei noch einen Heizlüfter speisen kann ;-)
Angehängte Dateien:
-
2012-02-07_17.14.28.jpg
1,6 MB
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 eprom die im bild zusehen sind sind gegen andere ausgetauscht worden Ich habe bei mir im keller einen adapter gefunden der einen abnschluss für 5 12 gnd hat ein bissl sinnlos ! Gib es irgendeine möglichkeit mit meinen atari 1040 den eprom zu programmieren weil ich das gerne als vorzeige objekt hätte um zu demonstrieren was man mit alten controller machen kann gib es eine möglichkeit einen bildschirm anzuschließen ?
> Bildschirm anzuschließen
Ein serielles Terminal sollte möglich sein. Früher (TM) gab es sowas
standalone, heute braucht man einen PC und hyperterminal o. ä.
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?
Bildschirm schrieb: > Früher (TM) gab es sowas > standalone, heute braucht man einen PC und hyperterminal o. ä. Dafür ist ein PC mit Hyperterminal heute (TM) wesentlich günstiger und man kann ihn sogar noch anderweitig nutzen. Noch früher (TM) stand da ein Fernschreiber und als Datenträger gab es Lochstreifen, die dunklen, damit der Kontrast besser war und man sie schneller einlesen konnte.
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
Hey, so ein im 13"-Bildschirm integriertes VT 100 mit eigener Tastatur war sehr praktisch. ;-) Hab ich überall mitgeschleppt, wenn es an solchen Rechnern bzw. an Xenix/Unix-Rechnern was zu tun gab ...
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.
Ich habe einen bekannten gefragt ob er soetwas hätte er sagt mir zehn minuten später das er einen bildschirm hätte ( in blau stufen?) und er mir ihn schenkt. Gibs irgend einen controller der das betreiben kann ?
Abdul K. schrieb: > Gibt es keine Ipad App VT100 ? Es scheiterte an der doppelt hohen Schrift. Dafür gibt es keinen Font :-)
>controller
Auf Deiner Platine gibt es zwei serielle Schnittstellen, über eine von
diesen könntest Du Zugang zum System-Monitor finden. (ohne Gewähr)
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: > 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
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.
lasst uns ein wenig in Erinnerungen schwelgen...
1 | s_ascii_saveblk:moveq #1,D0 ;Block sichern |
2 | bra.s s_ascii_save00 |
3 | s_ascii_save: bsr s_source_da ;Sourcetext vorhanden? |
4 | beq main_loop ;nein |
5 | bsr s_chk_block ;'alles' oder 'Block' |
6 | s_ascii_save00: move.w D0,D2 ;Rückgabe merken |
7 | bmi main_loop ;UNDO gedrückt |
8 | lea fname_src(A4),A0 ;Name des Sourcecodes |
9 | lea fname_temp(A4),A1 |
10 | s_ascii_save01: move.b (A0)+,D0 ;Namen kopieren |
11 | move.b D0,(A1)+ |
12 | beq.s s_ascii_save02 |
13 | cmp.b #'.',D0 |
14 | bne.s s_ascii_save01 |
15 | s_ascii_save02: subq.l #1,A1 ;Default-Extension einsetzen |
16 | move.l spezial_11,D0 |
17 | rol.l #8,D0 |
18 | cmp.b #' ',D0 |
19 | beq.s s_ascii_save04 ;keine Extension |
20 | move.b #'.',(A1)+ |
21 | move.b D0,(A1)+ |
22 | s_ascii_save03: rol.l #8,D0 |
23 | cmp.b #' ',D0 |
24 | beq.s s_ascii_save04 |
25 | move.b D0,(A1)+ |
26 | bne.s s_ascii_save03 |
27 | s_ascii_save04: clr.b (A1)+ |
28 | lea spezial_11+4,A1 |
29 | moveq #3,D1 |
30 | s_ascii_save05: rol.l #8,D0 |
31 | move.b -(A1),D0 |
32 | cmp.b #' ',D0 ;Defaultextension gespiegelt nach D0 |
33 | bne.s s_ascii_save06 |
34 | clr.b D0 |
35 | s_ascii_save06: dbra D1,s_ascii_save05 |
36 | lea fpath_temp(A4),A0 |
37 | lea fname_temp(A4),A1 |
38 | lea s_asc_save(PC),A2 ;Header für Exfsel_input() |
39 | tst.w D2 |
40 | beq.s s_ascii_save07 ;alles abspeichern |
41 | lea s_asc_saveb(PC),A2 ;Header für Block |
42 | s_ascii_save07: bsr _fsel_input |
43 | bmi main_loop |
44 | tst.w D7 ;ABBRUCH |
45 | beq main_loop |
:-)
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
Danke für die vielen Beiträge ! Einen Eprom brenner hab ich plus uv lampe zum löschen. Ich habe von anfang eh uP gemeint . Der Atari Assembler wäre ja richtig geil nur ohne maus ist des ein Käse zu Bedienen. Gibs irgendwo an adapter für die mäuse.
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.
Okay das mit der maus könnte eine lösung sein . Scsi platten habe ich noch viele ~30 stück von 4 gb bis 70 gb alles drinnen Das einzige was nervt is der adressbereich bestimmem ich kann zwar doe pal auslesen nur das auswerten ist was anderes
Ich habe die beiden EPROMS ausgelesen und ein sehr kompisches Programm gefunden. Wer den Programmcode haben will soll es mir sagen, dann werde ich ihn schicken per E-Mail Matthias Sch. schrieb: > 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. Die einzige Möglichkeit ohne die Schaltung zu zerlegen ist es über das Programm herauszufinden wo die Adressbereiche 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...
Okay, wird zwar viel Arbeit zahlt sich am Ende doch aus !!! Das mit dem Terminalprogramm mag nicht so ganz, weil wenn ich es zusammen hänge bekommt mein PC eine Meldung das das Board läuft mehr aber nicht Daraus folgt ich habe es zwar richtig angeschlossen aber wahrscheinlich fehlt das bedienmodul welche ich zur Zeit nicht finde
Da haste ja hier die Rentner geweckt ;-) Ein Board mit den 6551 würde ich nicht mehr anfassen. Selbst die hier eingesetzten GTE-6551 glänzten immer durch gelegentliche Übertragungsfehler. Mein uraltes Terminal (Hazeltine) hatte auch einen R6551, wo bei gestörten ESC-Sequenzen wiederholt Müll auf dem Bildschirm entstand. Das war nevig. Insgeheim habe ich die 8080-Fraktion beneidet. Die 8251 waren stabil.
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: > 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/Super-serial-03.jpg
Rufus Τ. Firefly schrieb: > dann ist der 6551 aufgrund des > integrierten Baudratengenerators reizvoller Ja klar! Was ich vermutet habe, war, dass der E-Takt mit typ. 1 oder 2 MHz nicht richtig zu den 1,8432 MHz synchronisiert wurde. Auch völlig ohne Handshake traten die Übertragungsfehler auf. Wie geschrieben auch beim Hazeltine (Esprit-III hieß es wohl). Die Erlösung kam dann erst mit dem R6501Q, wo CPU und UART mit dem gleichen Takt synchron betrieben wurden. Der konnte dann auch neue Befehle: SMB, RMB, BBS und BBC. Die CMOS CPU auch noch PHX, PHY, ... Wahnsinn!
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.
Daniel Rohrhofer schrieb: > Danke für die vielen Beiträge ! Einen Eprom brenner hab ich plus uv > lampe zum löschen. Ich habe von anfang eh uP gemeint . Der Atari > Assembler wäre ja richtig geil nur ohne maus ist des ein Käse zu > Bedienen. Gibs irgendwo an adapter für die mäuse. beim atari kann man die maus mir der tastatur bedienen, ich weis nicht mehr genau welche tasten es waren, alt, crtl, alt-crtl irgend so ne kombination, halten, dann die pfeiltasten li,re , up, down. es gibt zwei geschwindigkeiten.
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.
Matthias Sch. schrieb: > 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. Selbstverständlich zählt der! Und wenns dir um den 68000 geht, den gabs als Steckkarte für die Kiste.
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.
Ehrhardt Balstein schrieb: > Er hat zwar eine 16 Bit ALU Nee, 32 Bit. Sonst ginge kein ADD.L oder ASL.L usw..
Matthias Sch. schrieb: > Auch der 68030 hat sehr wohl ausm ROM gearbeitet. 'Non modo sed etiam', nicht nur sondern auch. Besonders schön waren die PC-relativen Programme, die man an beliebigen (aligned) Adressen laufen lassen konnte.
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.
A. K. schrieb: > denn 32-Bit > Datenoperationen brauchten mehr Takte, Stümmt! ASL.L braucht 2 Takte mehr als ASL.W. Aber immerhin brauchte man nicht selber zu stückeln.
Die Übertragungsfehler halten sich zurzeit noch in grenzen. Habe noch keine merkbaren Fehler gesehen. Der Adress bereich ist ein Katastrophe zum herausfinden. !!! Der 8251 ist das volle Vieh bei der Übertragung keine Fehler einfach nix
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
Ehrhardt Balstein schrieb: > Wenn du die Eeproms ausgelesen hast, hilft eventuell ein > 68k-Disassembler: > http://www.monroeccc.edu/ckelly/Files/irapc200.zip Würde ich ja gerne aber wenn der Pc schon wieder spinnt dann geht nix ! Nervt extrem wenn man glaubt es geht und dann doch nicht ! Frage: Wer hat diese Programm noch und würd für mich den EPROM Inhalt in Assembler konvertieren, währenddessen ich den Fehler suche MFG
So ich poste einmal die Beiden HEX -Daten nach dem mein PC meint er müsse das Programm nicht starten ( Startet zwar ist nach 3 sec wieder geschlossen )
Daniel Rohrhofer schrieb: > Beiden HEX -Daten Die erste Datei ist laut meinen wissen für die unteren 8-bit die andere für die oberen 8
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 ;-)
Andreas B. schrieb: > dass hier die Rentner in alten Kriegserinnerungen schwelgen müssen Du scheinst noch jung zu sein. Das schöne an unserer Generation ist, nie einen Krieg mitbekommen zu haben. Es gäbe auch rein garnichts zu schwelgen.
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.
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 :-) Wir hatten 1968 und ich habe ab einem gewissen Alter nie das gemacht, was mir gesagt wurde. Daher auch der fehlende Rentenanspruch. Zurück zu obigen .hex-Dateien. Die müßte ich erst zusammenpacken und dann auf einen alten 68k Rechner packen. Da hätte ich auch einen Simulator zu laufen. Aber zur Zeit wäre mir das etwas zuviel Aufwand.
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...
Wegen Den EPROM Inhalt per bedarf könnte ich in selber zusammenfügen aber wird ein bisschen dauern da ich beruflich zurzeit sehr beschäftig bin
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.
Helmut Lenzen schrieb: > 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. Alleine das Netzteil für die ganze Anlage wiegt ungefähr 7 kg ( Mit schönen Trafo ) Daten:(Kleinspannung) 5 V 50 A 24 V 20 A Gesamt 730 W für Kleinspannung Habe aber vor den Trafo zu ersetzen und gegen Schaltnetzteile einzutauschen ( Wegen des Gewichtes ) Was hätte das für einen Sinn eine Schausteuerung zu bauen wenn sie fast 20 kg wiegt ? Gibs irgendein Programm zum EPROM zusammen fügen ? Ist glaub ich besser als mit der Hand die beiden Inhalte zusammen zu kopieren
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
Anbei die .bin Datei und noch als .hex im S2-Format. Am Anfang müßten Stackpointer (0x5800) und Startadresse (0xf8001e) stehen. Am Ende der .bin finden sich einige Texte.
Okay danke für den zusammen gefügten Inhalt, sehe wider durch den Inhalt den Verwendungszweck der Steuerung : Röntgentechnik ( komme zwar aus dem Fachbereich , passiert aber häufig das wir auch andere sachen bekommen, man kann ja nie wissen ) MFG Daniel
>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. Manche CPU-Architekturen haben das sogar noch verbessert! >Der 68000 ist kein µC, sondern ein µP. Was aber nicht heisst, dass es keine 68k-µCs gäbe. >Jo, jo, der gute alte VME Bus :P Aber, der wird auch heute noch eingesetzt. Manche preisen den sogar (immer noch) als hoch leistungsfähig an, und setzen den (allerdings in neuerer Version) bei teuren Maschinen usw ein. >Die Programme werden beim 68k immer im RAM ausgeführt Die CPU merkt ja gar nicht, "wo" das herkommt. >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. >Abgesehen davon wird die 68k-Architektur bis heute noch in den ColdFire >Mikrocontrollern weitergeführt. Aber nur mit Einschränkungen im Befehlssatz. ColdFire kann die Befehle meist nicht auf 8/16 Bit Daten anwenden.
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.
>>>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? Bsp.weise M16C und Verwandschaft. Die können sogar MATH(.B,.W,.L) Mem, Mem. -rechnet also an den int. Registern vorbei (ist beim R32C sehr schnell) (Beim Nachfolger RX hat man das allerdings wieder gestrichen.)
MCUA schrieb: > Bsp.weise M16C und Verwandschaft. Und ich schrieb noch ausdrücklich "ohne Controller"...
>Befehle mit zu >komplexer Dekodierung oder zu komplexem Ablauf wurden langsamer >dekodiert und ausgeführt als die Ersatzsequenz aus effizienten Befehlen. Wenn der konkrete Befehl wirklich länger braucht als die Ersatzsequenz, hat man natürlich was falsch gemacht. Was aber nicht heissen kann, dass man prinzipiell keine komplexeren Befehle creieren sollte, bloss weil man das mit mehreren einfacheren Befehlen ersetzen könnte.
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.
>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... 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.
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.
Hi, sorry für die Leichenfledderei. Aber: Ist eigentlich jemandem außer mir aufgefallen, dass der 68000er auf dem ersten Foto von Daniel als einziger Käfer anders herum auf seinem Sockel steckt? Könnte doch eher ungünstig für Leistungsaufnahme, Erwärmung und Lebensdauer sein, oder?
Du wirst davon ausgehen können, daß das kein Problem ist. Aus Layoutoptimierungsgründen werden und wurden Bauteile durchaus auch in unterschiedlicher Orientierung plaziert.
Ist Daniel noch da? Auc Sorry für die Leichenfledderei, aber ich habe heute beim Aufräumen exakt die selbe CPU Platine ausgegraben, zusammen mit einer Bildschirmsteuerung mit 6845 und offensichtlich einer RGB Erweiterung... Gruß, Holm
Hallo alle Auch ne Sorry für Leichenfledderei. Diese Board stammt aus Röntgengerät, der in Franken gebaut wird. Waren eine Topmodell aus 80er, der bis zu Ende 1990er (!) gebaut wird (hohe nachfrage) Ich hatte diese Board inkl Backplane und Netzteil an Holm geschenkt, weil das Motorola 68K ihm interessiert. Aber was ich nicht wusste, dass diese Board extra für meine Arbeitsgeber gebaut wird und ich habe extra nach Dokument für ihm gesucht und Serviceabteilung gefragt....alles Dokument ist vernichtet, fast! Einzige was ich gefundet habe: Anschlussschema an Frontplatte. Nebenbei hat Frima in diese Zeitraum 1990er bis jetzt schon 3x Besitzerwechsel und Namenwechsel gehabt..damit dürfte dünster aussieht seien. Wenn Holm ihm zum laufen bringt, dann weisst er wie meine Arbeitsgeber früher heisst. @barclay66, ist keine Problem, da der zwangbelüftet wird. Grüss Matt PS: achja, bin nahezu taub, hab gewissene Schwierigkeit mit Grammatik. ;-)
Das finde ich doch auch so aus dem Binary oben raus Matt: 0001ad90 20 20 43 6f 70 79 72 69 67 68 74 20 62 79 20 20 | Copyright by | 0001ada0 56 6f 73 73 6b 75 65 68 6c 65 72 20 47 6d 62 48 |Vosskuehler GmbH| :-) Gruß, Holm
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
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.