golem.de: Als Deutschland eine eigene CPU hatte - Olympia CP3-F

    Die elektronischen Schreibmaschinen waren trotzdem so breit wie die Schreibwalze plus Walzendrehknöpfe. Kommt halt darauf an, ob man eine Maschine nur für A4 hochkant oder auch für A3 oder größer baut und wie filigran die ganze Technik ist, die man da unterbringen will. Mitte der 70er waren alleine die benötigten Stepmotoren wahrscheinlich noch etwas größer/schwerer.

    1ST1

    Die Schreibwalze kam beim Schreiben aber aus dem Gehäuse heraus. Da musste auf dem Schreibtisch entsprechender Freiraum vorhanden sein. Ein Kaffeebecher neben der Maschine konnte beim Schreiben leicht umgestoßen werden. Ich habe noch eine elektromechanische Olivetti TEKNE3 mit Typenhebeln, bei der die Schreibwalze beim Schreiben nach beiden Seiten aus dem Gehäuse herauskommt. Dagegen waren die Kugelkopfschreibmaschinen ein echter Fortschritt. Die Steppermotoren waren mit der Walze bzw. dem Schlittenantrieb über Zahnriemen und Zahnradumlenkungen verbunden und konnten so im Gehäuse montiert werden, dass dadurch die Außenabmaße nicht größer wurden. Das Gewicht der Maschinen war zwar noch erheblich, aber kein Vergleich zu der TEKNE3.

    Ich kenne die Tekne 3, und auch deren Nachfolger Editor 4 und 5, hab sogar technische Unterlagen dafür (genau wie für viele andere Maschinen aus Ivrea). Aber wenn ich das dann mit der Breite von der TES 401 oder einer ET 1xx, 2xx oder 2xxx vergleiche, die aber auch A4 Quer können (die Breitwagen-Modelle der ET 1xx und 2xxx können sogar A3 quer, es gab allerdings auch von der Tekne, Editor und Lexikon Breitwagenmodelle), dann sind diese ersten elektronischen Maschinen doch recht groß. Erst mit der Praxis 30/35 ab 1980 gab es wieder kompakte A4-Hochkant-Maschinen, die aber dadurch dass sie leicht und portabel sind, auch nicht so robust sind. Eine Tekne 3 / Editor 3 habe ich nicht da, aber die anderen alle schon, siehe teilweise oben im Musumsbereich des Forums meine Galerie bzw. Liste in meinem Blogspot.

    1ST1

    Hallo,

    ich habe vor einige Zeit mal ein paar technische Zeichnungen zur Olympia ES100 eingescannt.

    Falls jemand Interesse hat: https://github.com/RoSchmi/ES100.

    Ich habe damals in den 1980ern auch das Eprom der ES100 teilweise per Hand disassembliert und den Code etwas abgeändert, um die Maschine als Computertastatur und Drucker verwenden zu können. Falls es Interessierte gibt, könnte ich die Listings mal einscannen.

    Guten Morgen

    RoSchmi

    Darf man nachfragen, welche Hardware, Software Werkzeuge (AID du damals verwendet hast, oder hattest du damals schon ein gesamtes Evaluation Kit

    wie kammst du an den Rom Inhalt, bzw wie hast du ihn dann ggf manuell? übersetzt

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

    Ich hatte das Elektor SC/MP System und dafür eine EPROM-Programmerkarte. Damit konnte ich das 2516 Eprom der Schreibmaschine auslesen und mit dem Monitor-Programm des SC/MP (ELBUG) die Speicherinhalte ansehen. In den Handbüchern Fairchild F8 USER'S GUIDE und FORMULATOR USERS'S GUIDE F8-F3870 konnte ich zu den Maschinensprachen-Bytes in HEX die Assembler Mnemonics heraussuchen und so das Programm analysieren und teilweise ändern. Das geänderte Programm wurde dann in ein 2732 Eprom geschrieben und dieses (nach geringen Hardwareänderungen) in die Maschine eingesetzt. Das war alles recht mühsam.

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

    Zitat von ThoralfAsmussen

    Magst Du das evtl. mal komplett fotographieren ?

    Das kann ich demnächst mal machen, bin allerdings die kommende Woche nicht zu Hause. Wo sollte man das Listing ablegen? Gibt es hier im Forum eine Stelle für solche "exotische" Dokumente?

    Zitat von fanhistorie

    Also hast du über Elbug die RAM Tabelle auslesen können, und analyisiert,

    hast du später das Programm auch unter SC/CP lauffähig bekommen, oder ging das nicht,

    Mit RAM Tabelle hatte ich nichts zu tun. Im Monitor des SC/MP konnte man die Speicheradresse eingeben und sah dann den entsprechenden Inhalt (Hier aus dem EPROM). Auf dem SC/MP waren die Programme nicht lauffähig, der hatte ja einen anderen Prozessor. Das Programm war ja an den 3870 Prozessor gebunden.

    Zitat von RoSchmi

    Das kann ich demnächst mal machen, bin allerdings die kommende Woche nicht zu Hause. Wo sollte man das Listing ablegen? Gibt es hier im Forum eine Stelle für solche "exotische" Dokumente?

    Das eilt ja nicht.

    Ich würde es ja unter "Programmieren" einstellen. Schön als extra-Thread und paar passende Schlagwörter dazu. Und dann noch einen Link von hier auf den Thread, dann wird es auch von Leuten gefunden, die nach der Schreibmaschine suchen.

    Ich finde ja schon witzig, daß man sich eine Schreibmaschine quasi zum "Terminal" umbaut. Aber, daß man dazu vorher den Code in ein Notizbuch schreibt - und das anscheinend auch noch fehlerfrei im vllt. ersten Anlauf - ist ja schon heute niemandem mehr vermittelbar. ;) Das glaubt in 50 Jahren niemand mehr - und evtl. wird so ein Büchlein dann eine totale Kuriosität.

    Die meisten Homecomputer-Programm-Bastler kennen das ja vielleicht schon noch, aber eher für prinzipielle Abläufe und Skizzen oder Bitmap Muster, nicht für den "echten" und anscheinend kompletten Code.

    Wenns dann auch noch läuft, ist es schon fast ein richtig cooles Demo und evtl. auch mal "edukativ" benutzbar. In einem Sommer-Coding Kurs für Teenager oder so. Und natürlich für andere, die sich sowas gern mal ansehen. Wird ja viel zu selten aufgehoben, soetwas.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    von olympia gab es eine drucker testbox.

    mit der man einen test text, ohne einen computer, über den parallelen centronics anschluss direkt ausgeben konnte.

    die basierte auf der huckepack 3870 version.

    da änderte und erweiterte ich den text zu einem demotext mit steurbefehlen
    um alle möglichkeiten der olympia schreibmaschinen / druckern, ohne einen computer, vorführen zu können.

    ursprünglich machte ich es für manche olympia vertriebsniederlassungen,

    dafür bekam ich ein paar der sehr teueren 3870 und ich erstellte dann ein paar der testboxen.

    ich benutzte die olympia box dann auch mit demotexten und steuerbefehlen für epson, philips, siemens, itoh und anderen drucker herstellern.

    so wollte mancheiner der hersteller und der händler auch so eine demo-test-box und ich fertigte dann eine eigene version mit einem preiswerten mcs-48, 8748, 8035 usw. und einem eprom.

    in das dann die demotexte einfach 1:1, ans eprom ende, kopiert wurden.

    es gab dann auch eine version mit sram und einem akku, die parallel zum drucker angeschlossen wurde.

    so wurde jedes zum drucker übertragenes zeichen parallel abgespeichert und so konnte man jederzeit sich einen eigenen text selbst erstellen oder den dann in ein eprom brennen.

    ich hatte dann auch eine version mit einem iec, einem ieee-488 und einem rs232/v24 anschluss.

    von diesen demo-test-boxen verkaufte ich ein paar hundert stück.

    auf den messen benutzte ich die gerne um die angebliche epson kompatibilität der anderer hersteller zu testen.

    so bekam ich mancheinen auftrag, dann die mit dem passendem demo und dem befehlssatz zu liefern.

    für die olympia, epson, philips gp300 und siemens pt88? tinten und nadel drucker hatte ich auch eine interne platinen version. so druckten die direkt nach dem einschalten ihren demotext.

    gruß
    helmut

    edit......
    diese box hatte ich auch mit 2x (4x) 4067 oder 2x (4x) 4051 und einem 4066 gehabt.
    so konnte man fast jede beliebige tastaturmatrix benutzen und darüber texte usw. automatisch ausgeben
    und eine tasteneingabe simulieren. die hatte auch ein poti, so konnte man die eingabegeschwindigkeit regeln.

    ursprünglich erstellte ich damals den prototypen für einen wdr mitarbeiter, der eine tasteneingabe simulieren und filmen wollte. so konnte man so tun als ob man den text schreiben würde und die tastatur war aber abgeklemmt.

    Helmut Proxa axorp (HP.)
    proxa computer
    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

    5 Mal editiert, zuletzt von axorp (4. September 2022 um 03:06)

    Zitat von RoSchmi

    Hallo,

    ich habe vor einige Zeit mal ein paar technische Zeichnungen zur Olympia ES100 eingescannt.

    Falls jemand Interesse hat: https://github.com/RoSchmi/ES100.

    Ich habe damals in den 1980ern auch das Eprom der ES100 teilweise per Hand disassembliert und den Code etwas abgeändert, um die Maschine als Computertastatur und Drucker verwenden zu können. Falls es Interessierte gibt, könnte ich die Listings mal einscannen.

    Ganz herzlichen Dank für die Infos, sie sind möglicherweise auch für meine ES110 und ES180 wertvoll

    DOS, from the people who brought you EDLIN

    Hallo zusammen,

    so nach über 2 Jahren Pause aus familiären Gründen komme ich wieder dazu mich mit dem CP3f zu beschäftigen.

    Dank Gnatz habe ich zwei CP3F CPUs (die M380 Version von SGS) und bei S&H hatte ich tatsächlich damals noch

    zwei IO-Bausteine (LP 1010) ergattert.

    Damit hatte ich dann angefangen ein Board aufzubauen, als "Gegenstück" nehme ich ein "Godil" Modul

    mit einem Spartan3 (Oho-Elektronik).

    Das hatte ich dann bis zum "NOP" Generator aufgebaut, dann musste ich pausieren.

    So sah es vor mehr als zwei Jahren aus:

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

    Mit Python habe ich mir auch einen einfachen Assembler programmiert: https://retrocpu-cp3f.net/cp3f_board/index.html

    Jetzt habe ich es wieder auf dem Basteltisch, erstmal sehen ob es noch funktioniert.

    Ich hoffe das ich es am VCFE dann vorstellen kann.....

    Man sollte so ein Projekt nicht über zwei Jahre ruhen lassen:

    - Änderungen auf der Lochrasterplatine nicht dokumentiert :wand:

    - Eine kalte Lötstelle hat mehrere 4066 abrauchen lassen ....

    - Nach mehreren Windows sowie Linux Updates geht das Xilinx-Impakt nicht mehr.

    und die Software für den China-Logicanalyzer muss ich auch neu installieren.

    - auf der Pegelwandlerplatine hatte ich falsche Widerstände eingelötet, au wurden die heisssss

    Aber es gibt auch positives zu Berichten:

    + Es hat sich jemand die Mühe gemacht und den CP3F Befehlssatz in seinen Assembler eingebaut

    http://john.ccac.rwth-aachen.de:8000/as/cpulist.html

    + Und der Pegelwandler hat überlebt:

    Ich sehe den +5V -12V Takt für die CPU:

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

    Der "schöne" Aufbau des Pegelwandlers

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

    Und der "Plan" (nicht von mir, habe einen Analogexperten gefragt), wer mag kann ja den Fehler finden ...

    Zitat von otto

    geht das Xilinx-Impakt nicht mehr.

    Wenn du die Installationssoftware brauchst sag Bescheid.

    Sonst gibt's die ISE14.7 für Win10. Da ist die ISE in einer virtuellen Maschine verpackt.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

    Zitat von funkenzupfer
    Zitat von otto

    geht das Xilinx-Impakt nicht mehr.

    Wenn du die Installationssoftware brauchst sag Bescheid.

    Sonst gibt's die ISE14.7 für Win10. Da ist die ISE in einer virtuellen Maschine verpackt.

    Danke für das Angebot, mittlerweile funktioniert der Downloader (Impact) wieder,

    ich habe einen älteren Computer mit Win 7 da geht der Impact noch! (Gut das ich alte Rechner aufhebe...)

    Im neuesten Ubuntu und auch auf Win11 mag der Impact nicht mehr starten.

    Das ISE-Zeugs läuft nun endlich auch in einer VM , ich kann also weitermachen.

    Dank des Assemblers von Alfred Arnold kann ich mich auf die Hardware konzentrieren,

    mein Fädelboard ist wieder repariert -> und ein erster Erfolg - der CP3F hat schon eine kleine Loop ausgeführt.

    Aaber nun muss ich mich doch nochmal mit dem Levelshifter (der für den +5-12V Takt und den Reset)

    beschäftigen, da "brandelt" noch was, einer der Transistoren schmort nach kürzester Zeit

    und riecht dann seltsam .... :cry2:

    Hi, ich hoffe wir sehen uns auf dem VCFE - wie der Zufall es will, bin ich dort am Samstag Vormittag, um mit den Machern des Steckschweins einen Podcast aufzuzeichnen. Ich würde mir den aktuellen Stand des Projektes liebend gern mal anhören / anschauen.

    Hallo, ja hoffe auch das wir uns dort sehen, im Moment bin ich noch mit der Hardware fürs VCFE beschäftigt.

    Zitat von mwo Golem

    Hi, ich hoffe wir sehen uns auf dem VCFE - wie der Zufall es will, bin ich dort am Samstag Vormittag, um mit den Machern des Steckschweins einen Podcast aufzuzeichnen. Ich würde mir den aktuellen Stand des Projektes liebend gern mal anhören / anschauen.

    Die Hardware selbst funktioniert soweit, das Problem bei dem Levelshifter war das ich einen von vier Transistoren falsch eingelötet hatte...

    Der CP3F läuft auch soweit, ich kann schon LEDs blinken lassen über dem IO-Baustein LP1010.

    und weil mich das Fädelboard doch etwas nervt (liegt an meinen Löt"künsten"), hab ich mir nun ein Board erstellt und auch schon bestellt.

    Und ich versuche grade den Zugriff des CP3F aufs externe RAM zu verstehen :grübel:

    Da war mal was, ist aber sehr lange her. Vom System her war anfangs nur eine "DSE" 128 Byte RAM und 1 I/O_Port geplant. (Das System war ja für "Calculator-Printer" geplant. Dann kamen schon nach kurzer Zeit noch elektronische Schreibmaschinen und wenig später Textautomaten dazu. Damit stieg der RAM-Bedarf. Ich selbst habe am Konzept einer DSE2 mit 4K RAM mitentwickelt. Das waren aber nur Arbeitsspeicher für die Ablage von Daten - nicht von Programmcode. Weil aber das Brennen vom PROMs bei der Softwareentwicklung zu ömmelig wurde, haben wir mit relativ wenig externer Logik es geschafft, ein RAM als Datenspeicher in 256-Byte Blöcken (wegen des 8 Bit Adressregisters) zu beschreiben, 8 Blöcke davon dann aber als den typischen 2KByte Programmcode ablaufen zu lassen. Mal sehen, was ich davon immer noch an Unterlagen habe - dauert aber einige Zeit. Ich war garnicht lange bei Olympia, aber damals ging die Weiterentwicklung rasant voran und aus dem einfachen System wurde schon bald eine Rechnerarchitektur, was anfangs so nicht geplant war. Die Firma Pantron Instruments in Braunschweig hatte damals sogar auf dem CP3F ein eigenes Entwicklungssystem auch für externe Kunden geschrieben. Die Programmentwicklung bei Olympia lief dagegen auf einem IBM /370 Großrechner und nur der HEX-Code wurde in die RAMs der Entwicklungsboards heruntergeladen oder in PROMs gebrannt.

    Gruß Günter

    Hallo Günter,

    mit dem CP3F RAM-Zugriff bin ich nun weitergekommen, im FPGA habe ich die Hardware mit dem Q- und dem Z-Register wie im Bild implementiert.

    Und ich kann via das Z-Register (und der Moduladresse im X-Register) Daten ins RAM schreiben und wieder lesen:

    Der Code sieht dann so aus:

    Code
    lal 1            ; lade 1 in den Akku
sax              ; 1->X-reg (=RAM-im Modul 1 untere 256 Bytes)
lal adresseimram ; addresse -> Akku
szx              ; akku -> Z-register ins Modul 1 (RAM)
; Und dann lesen und schreiben mit:
lix              ; (X-Reg ,Z-Reg) -> akku (Z-reg im RAM ist Zeiger)
six              ; Akku -> (X-Reg ,Z-Reg)

    Umständlich aber: Hurra - ich kann lesen und schreiben !

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

    Aber eine Frage hätte ich an den Experten, kann ich das Z-Register auch lesen?

    Hallo "otto",

    ich habe die Abläufe mal etwas breiter (für eventuell andere Interssierte) dargestellt. Hier mein Text:

    Ich musste tief in alten Unterlagen (und meinem Gedächtnis) kramen, um mehr über die Datenablage bei dem CP3F Mikroprozessor herauszufinden. Hier ein Überblick: Ich verwende die damalige Zählweise 1 bis 8 für die Benennung der einzelnen Bits eines Bytes (heute ist 0 bis 7 entsprechend der Wertigkeit üblicher). Auch nutze ich die deutschen Bezeichnungen für die Befehle und Bausteine (SGS und General Instruments haben dafür teilweise in ihren Datenblättern englischsprachige Begriffe eingeführt).

    Der Adressumfang des CP3F war 16KByte groß entsprechend 14 Adressbits. In jedem Systembaustein waren der Programmzähler Q, der Stack mit den Rückkehradressen RA und RB und das Datenregister Z enthalten. Bei einem Unterprogrammaufruf wurden die Adressen wie folgt abgelegt: RB -> Z, RA -> RB, Q -> RA. Dann wurde das Adressregister Q mit der Sprungadresse geladen. Der Befehl SUP (Sprung ins Unterprogramm) führte somit zum Verlust des Inhaltes des Datenregisters Z. Beim Rücksprungbefehl RSP war der Ablauf in umgekehrter Richtung RA -> Q, RB -> RA, Z -> RB.

    Der Adressbereich war in Blöcke der Größe 2KByte aufgeteilt und umfasste 8 Blöcke. Der Adressbus der RSE (Rechensteuereinheit = CPU) war 6 Bit breit, die obersten 3 Bit betrafen die Auswahl des jeweiligen Blocks, die unteren 3 Bit entsprachen den oberen 3 Bit der Adressierung in dem jeweiligen 2K Block. Das ist wichtig, um die RAM- und Tabellenadressierung zu verstehen.

    Im internen Arbeitsspeicher der RSE waren 2 Register für die Adressierung von besonderer Bedeutung. Es waren das Y-Register (Adresse 15) und das X-Register (Adresse 14). Die unteren 6 Bit dieser Register wurden für die Adressierung der externen Bausteine benötigt, die höheren der 6 Bit für die Blockauswahl und die unteren 3 Bit für die Adressierung einer der 8 je 256 Byte großen Pages im 2K Block. Die Adressierung innerhalb der Page erfolgte über die unteren 8 Bit des Z-Registers, die mit den Befehlen SZX oder SZY geladen wurden (je nach Befehl erfolgte die Auswahl des jeweiligen Z-Registers über das X bzw. Y Register).

    Der Befehlsablauf für einen Datenzugriff war folgendermaßen:

    LTK1, LSK6 (oder LSK7). Damit wurde das X- (oder Y-) Register ausgewählt.>

    LAL Wert, der in das Register für die Adressierung geschrieben werden sollte

    SZX (SZY) der Wert (untere 8 Adressbits) wird in das Z-Register geladen

    mit den Befehlen LIX (LIY) wird ein Datenbyte aus dem Speicher in den Akku geladen oder

    mit dem Befehl SIX wird der Akkuinhalt in das RAM gespeichert.

    Das Y-Register muss dabei mit Vorsicht benutzt werden, da die Bits 4 bis 6 für die Auswahl des jeweiligen 2K Blockes bei einigen Sprüngen genutzt wird und so eventuell falsch gesprungen wird, wenn das Y-Register für einen Datenzugriff genutzt werden soll. Deshalb wurde der Befehl LIY meist genutzt, um Tabellen im Programm-ROM auszulesen und so macht naturgemäß auch ein möglicher Befehl SIY (speichern ins ROM) wenig Sinn.

    Wie du siehst, habe ich den Befehl "SAX" nicht genutzt, weil der mir gerade nicht "über den Weg gelaufen" war. Es gibt halt mehrere Möglichkeiten, den Zugriff zu gestalten.

    Das Z-Register selbst kann man (nach meiner Erinnerung) nicht lesen, ebenso wie die unteren Bits des aktuellen Programmcounters. Man sollte den Inhalt deshalb vor dem Setzen als Kopie in einer der RAM-Zellen in der CPU ablegen. Aber ich werde da noch einmal nach Ostern nachforschen. So allmählich macht mir der CP3F-Prozessor wieder richtig Spaß. Ich kenne ja auch einige Erweiterungstricks, mit denen man den so richtig "aufblasen" kann. Im Konzept war ja viel mehr angedacht, was aber damals in den Chips (noch) nicht untergebracht werden konnte. Und weil die Konzernmutter AEG damals in finanzielle Schieflage gekommen war, fehlt das Geld für diese Weiterentwicklungen.

    Ich wünsche dir und allen anderen Lesern frohe Ostern.

    Günter

    Hallo Günter,

    "Wie du siehst, habe ich den Befehl "SAX" nicht genutzt, weil der mir gerade nicht "über den Weg gelaufen" war. Es gibt halt mehrere Möglichkeiten, den Zugriff zu gestalten."

    Den Befehl hatte ich aus der Doku welche du mir gegeben hast, Ich lese mich grade durch die Beispiele und versuche die zu verstehen...

    ab Seite 165: https://retrocpu-cp3f.net/SGS_38_cp3f_cpu_ocr.pdf

    Es hat auch wenig gedauert bis ich meinen Verilog-Code im FPGA soweit hatte das ich über das Z-Register

    die Daten aus dem ROM lesen konnte, die Logik ist nach diesem Vorbild aufgebaut:

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.


    Und darüber bin ich auch gestolpert:

    "Bei einem Unterprogrammaufruf wurden die Adressen wie folgt abgelegt: RB -> Z, RA -> RB, Q -> RA. Dann wurde das Adressregister Q mit der Sprungadresse geladen. Der Befehl SUP (Sprung ins Unterprogramm) führte somit zum Verlust des Inhaltes des Datenregisters Z."

    Und auch umgekehrt, wenn man im dritten Unterprogrammlevel das Z-Register benutzt um Daten aus dem ROM zu lesen, ist "natürlich"

    die oberste Rücksprungadresse weg und die CPU landet nach dem 3 "ret" im Nirgentwo...

    --> :prof: also Z-Register ins ROM nur im 2 Unterprogrammlevel ändern!


    Weil meine Fädelei zu wackelig war, habe ich mir nun Platinen gemacht und die sind frisch vom Fertiger und ich habe von einem Chiphändler noch ein paar IO-Bausteine LP1010 bekommen

    Hallo "Otto",

    Du hast die Benutzung des Z-Registers genau verstanden. Aber noch ein Hinweis: Wenn das Z-Register geladen wurde, führt natürlich jeder Unterprogrammsprung - egal aus welcher Ebene - dazu, dass der Registerinhalt verloren geht. Man musste also bei der Programmerstellung die Register im Hinterkopf behalten - und das übrigens auch bei dem F8-Mikroprozessor von Faichild. Deshalb mochte ich die Assembler-Programmierung. Da hatte man alle Register im Zugriff und konnte Impulse mikrosekundengenau ausgeben (wenn man Interrupts gesperrt hat).

    Bei der objektorientierten Programmierung hat man noch nicht einmal mehr Kontrolle darüber, welches Objekt in welcher Reihenfolge abgearbeitet wird. Bei unserer TomTom-Navi wird bei schneller Fahrt die Entfernung zu Kreuzungen oft ungenau angegeben. Wenn man dann langsamer wird, stimmt die Entfernung wieder. Da kommen sich halt die einzelnen Objekte für Positionsbestimmung, Mapmatching, Erzeugung der Fahrempfehlung und deren Ausgabe in die Quere und man merkt die Task-Umschaltzeiten des Betriebssystems. Und das ist nicht die einzige Falle bei der objektorientierten Programmierung. Bei embedded-Systemen mit begrenztem RAM, wird dieses (ähnlich wie eine Festplatte) fragmentiert. Wenn dann das Betriebssystem wegen hoher Systemauslastung das Defragmentieren nicht mehr schafft, scheitert der Aufruf eines großen Objektes daran, dass nicht genügend zusammenhängender Speicher mehr vorhanden ist. Es gibt dann eine Exception - oftmals ein Reboot. Das habe ich mal selbst erlebt, als eine mit modernsten Programmiermethoden vertraute Gruppe uns "Alten" mal zeigen wollte, wie man richtig programmiert. Das Programm lief etwa 45 Minuten, dann kam ein Absturz gefolgt von einem Neustart und das Spiel wiederholte sich. Mein (richtiger) Hinweis auf die mögliche Ursache wurde abgetan nach dem Motto: "Wir haben schon so viel objektorientiert programmiert und wissen genau, wie man das macht." Sie kriegten das Gerät nicht zum Laufen und der Kunde zog seinen Auftrag zurück. Arroganz und Ignoranz gehen oft Hand in Hand. In seinem Buch "Inside C#" (Microsoft Press) beschrieb Tom Archer später genau dieses Problem bei objektorientierter Programmierung von embedded Systemen.....

    Viele Grüße
    Günter