jetzt habe ich schon mal in den Threads reingeschaut,
fand zwar interessante Sachen, leider nichts von dem was ich suche.
Vielleicht noch was für den 6502 oder 65s02, oder 8086, (Z80)? Die Haupt-sache es ist einfach. Er braucht auch nicht besonders schnell zu sein.
Ich brauche einen STACK, je ein X und Y-Register, Statusregister für die Flags.
Aber auch einen passenden Emulator der CPU auf einen anderen Computer.
Interessant wäre noch, wie der Akkumulator von innen arbeitet; - alles in der CPU sollte sichtbar sein.
Es stehen aber auch fragen an, wie der Assembler funktioniert.
Es reicht mir nicht, dass ich ein Assembler-Programm habe, z.B. beim 8086; - und ich möchte, d.h. muss auch wissen, wie der Assembler arbeitet.
(Es steht in meinem Buch nicht drin. - "Es ist Rede von Direktiven?"
Ich verstehe einfach nicht, wie eine Assemblerliste funktionieren kann,
wenn er auf dem Bildschirm steht. Es müssen doch Prog.-Routinen da sein,
die das bewerkstelligen; das muss man doch auch sehen können.
Folgende Sätze sind nicht - "Anstößig gemeint" - gemeint.
Ich möchte einen "nackten, jungfräulichen" Computer haben,
der nichts hat, - um damit es, - beim weiteren Lernen nicht stört.
Es sollte aber schon die nötigen Programme haben.
Es soll ein Experimentier-Computer werden.
(Er braucht nicht mit dem Internet verbunden zu sein)
Der passende Emulator mit Zusatzprogrammen zB. Assembler mit Zubehör sollte wohl auf einem anderen Computer laufen.
Mehr möchte ich, -für den Anfang- nicht fragen.
Habt Ihr bitte Vorschläge für mich?
Schöne Grüße Enk.
Ohne Loetkolben, mit Assembler, ohne Kosten. Ich hatte damals am Junior-Computer angefangen (die Lehrbuecher kann man heute im Internet finden oder, natuerlich, den Zaks). Und ja, die DDR gabe es auch noch (schon ganz schoen lange her, ich habe den Junior in Deutsche Mark bezahlt).
Wenn es einfach sein soll, nimm einen 8051 oder AVR. Für beides gibt es Simulatoren und Debugger.
Mit einem Simulator kannst Du Assembler oder C-Programme auf dem PC laufen lassen und Die jedes Register und Ports anschauen.
Mit einem Debugger kannst Du das gleiche auf einem richtigen Chip machen.
Für die 8051 von Silicon Laboratories kannst Du Dir kostenlos die komplette Keil IDE runterladen.
Man baute heutzutage keine Computer mehr mit den klassischen 8 Bit Mikroprozessoren, denn es gibt inzwischen darauf basierende Mikrocontroller, die neben der CPU auch das RAM, das ROM und Peripherie enthalten. Das ROM ist überlicherweise direkt über USB oder einem Programmieradapter mehrfach programmierbar.
Da diese Kombination schon für 1€ zu haben ist, sind die klassischen 8 Bit Mikroprozessoren praktisch ausgestorben.
Vielleicht gefallen dir diese Webseiten zum Thema:
Ich möchte einen "nackten, jungfräulichen" Computer haben,
der nichts hat, - um damit es, - beim weiteren Lernen nicht stört.
Es sollte aber schon die nötigen Programme haben.
RP2040 als Raspberry Pi Pico.
Der hat nicht nur nen BootRAM und Fließkommabibliotheken, da kannste auch gleich einen Interbräter wie damals das C64-Basic V2 draufschieben.
Außerdem gibt es für den jede Menge Schulbildungskompatible Dokumentation.
Ich musste damals vor 30 Jahren die ganzen Steuersignale von zwei Mikroprozessoren auswendig lernen, doch nach der Prüfung habe ich das nie wieder gebraucht. Bei heutigen Mikroprozessoren ist das auch gar nicht mehr so detailliert dokumentiert, wie damals. Es bleibt ein Geheimnis des Herstellers.
Es gibt da einen online Emulator für den 6502, der zeigt den Chip so wie er unter einem Mikroskop aussieht und visualisiert in dem Bild sämtliche Signale.
Benutze mal einen in Kombination mit der Doku des Befehlssatzes, dann wirst du vermutlich am schnellsten begreifen, wie er funktioniert.
Im Grunde genommen übersetzt er Text zu Zahlen. Mein fiktiver Prozessor kennt folgende Befehle:
Addiere A mit A (= verdoppele A)
ADD A,A
Addiere A mit B
ADD A,B
Addiere A mit C
ADD A,C
Multipliziere A mit A (= A hoch 2)
MUL A,A
Multipliziere A mit B
MUL A,B
Multipliziere A mit C
MUL A,C
Wenn wir in Assembler programmieren, schreiben wir Befehle in so einer Textform, die sowohl wir Menschen als auch die Maschine lesen kann. Die Maschine übersetzt das in numerischen Code, der mittels Programmieradapter in den Programmspeicher des Mikrocontrollers abgelegt wird. Der Mikrocontroller führt das Programm aus.
Wenn der Programmspeicher die Zahlenfolge 4 2 6 enthält, führt der Mikroprozessor die Befehle aus:
4 ist MUL A,A
2 ist ADD A,B
6 ist MUL A,C
Oder in mathematischer Schreibweise:
A = (A x A) + B) x C
Im Gegensatz zu Assembler sind die Compiler von Hochsprachen (wie C) imstande, solche mathematischen Ausdrücke zu verstehen und in eine geeignete Sequenz von Prozessor-Befehlen zu übersetzen.
RP2040 als Raspberry Pi Pico.
Der hat nicht nur nen BootRAM und Fließkommabibliotheken, da kannste
auch gleich einen Interbräter wie damals das C64-Basic V2 draufschieben.
Du hast dThema vollkmmenversnd. Er will auf unterster Ebene die Dinge verstehen und sehen. Da sind Bibliotheken und Basic vollkommen fehl am Platze ...
vor knapp zwei Jahrzehnten (bin ich wirklich schon so alt?) habe ich
sowas ähnlichea an der Uni als Praktikum in VHDL gemacht.
Anfangs gabs dazu nicht einmal einen Assembler, da wurde direkt binär
mit OpCodes programmiert.
es war ein einfacher RISC Prozessor mit einer Handvoll Befehlen, ALU, 16
Registern.
Die genauen Details, Speicher, Displaysteuerung weiß ich leider nicht
mehr.
Hab ich vor ca. 15 Jahren an der FH als Kurs auch gemacht, war bei Reichardt & Schwarz. Die haben dazu auch ein Buch geschrieben, wo der Prozessor beschrieben war... (VHDL-Synthese: Entwurf digitaler Schaltungen und Systeme)
Unsere Aufgabe war es, den Prozessor zu erweitern, haben einen OP-Code bekommen und dann unsere Funktion intergriert - Multiplier und Addierer. Dazu dann noch ein FIR Filter Programm geschrieben...
Oder er schaut ins Datenblatt vom 74181 damit habe ich angefangen.
Und das war vor 51 Jahren ;-)
Wer gewoehnt ist, mit abstrakten Dingen wie einer Wahrheitstabelle
zu arbeiten, kann sich das ganze auf gedanklicher Ebene visualisieren.
Das scheint dem TO aber abzugehen, d.h. er braucht da eine staerkere
Dosis.
Er koennte aber an einen 74181 einige LEDs und Schalter anschliessen.
Oder, wenn er wirklich Langeweile hat, einen 74181 aus Einzelgattern
zusammenbauen. Dann koennte er noch viel mehr LEDs zum leuchten
bringen.
Mein Tipp fuer den TO: Schaff dir einen C128(D) an.
Der hat den "6502" (o.ae. :), ein A, X, Y und sogar ein SP-Register,
und am wichtigsten: ein Monitorprogramm zum Zugucken ist auch eingebaut.
Edith:
Auf einen richtigen Assembler kannst du am Anfang auch verzichten.
Das eingebaute Monitorprogramm kann auch "zeilenweise" assemblieren.
Interessant wäre noch, wie der Akkumulator von innen arbeitet; - alles
in der CPU sollte sichtbar sein.
Wenn du mit "sichtbar" mit bloßen Auge sichtbar meinst, dann musste einen alten aus Gatter-IC, Transistoren oder so geschmiedeten Rechner nehmen. PDP-10 oder so, da zeigen noch Lämpcchen an, welche Instruction gerade vercodet ist.
Hallo Leute,
erst schonmal vielen Dank für die vielen Antworten,
es war wirklich interessantes dabei.
Ich melde mich nochmal dazu.
Also bis später, - dann gehe ich auf einige Botschaften ein.
Tschüss, und noch eine gute Zeit.
Es ist herrlich, was man heute (2024) an Technologie hat: Ein 3EUR-Controller (stm32f401) hat genug Ompf, um die o.g. Rechner zu simulieren. Und 3D-Drucker sind mittlerweile auch schon sehr gut geworden.
All das waere nicht moeglich ohne die Arbeit von Bob Supnik, der in seiner Zeit bei DEC die CPUs selbst entwickelt hat und jetzt, als Pensionaer/Rentner, ein Opensource-Project ueber die Simulation der DEC-CPUs fuehrt:
Hat einen Assembler und einen Simulator, welchen man in Single-Step betreiben kann. Dabei werden jeweils alle Register und Flags angezeigt.
So etwas kann man zum Beispiel bei der Arbeit zuschauen.
Es wäre zielführend wenn man wüsste was das Lernziel sein soll.
Im Moment kann das irgendwie alles sein, entsprechend unterschiedlich fallen die Antworten aus:
Ist das Ziel:
Einen Prozessor in Assembler zu programmieren und entsprechende Techniken wie Schleifen, Adressierungsarten, Operatoren etc. zu lernen/vermitteln
Verstehen wie ein Assembler funktioniert
Verstehen wie ein Prozessor aufgebaut ist, wie Register und die ALU funktionieren, wie Addressierung gemacht wird, wie Assemblerbefehle codiert sind und decodiert werden.
Ausserdem müsste man wissen; Wer soll das lernen, welche Vorkenntnisse sind vorhanden. Bis auf welche Tiefe soll das Wissen vermittelt werden.
Im Moment sieht es (für mich) nach einem "Ich will alles lernen" Ansatz aus.
Das bedeutet eigentlich ein halbes Informatik Studium mit diversen Vertiefungsrichtungen.
Wenn der Thread für den TO also mehr brauchbare Informationen bringen soll, sollte er seine Frage präzisieren.
Für mich auch. Er will die ganze Entwicklung der IT bis zu Gegenwart
nachvollziehen. Nur denke ich, dass das bei der Menge nicht mehr geht.
Jene Generation, die von 6502 bis heute alles mitbekommen hat, geht innerhalb der nächsten 10 Jahre in Rente. Unsereiner hat die Entwicklung aber über zig Jahre verteilt mitbekommen. Ob das mit Druckbetankung auch funktioniert?
Zumal es immer weniger bringt, seit auch die Embedded-Szene mit den Mikrocontrollern immer mehr auf Abstraktion in Form von Libraries setzt, statt auf Bits und Register. Nicht nur bei den Arduinos.
Ob das mit Druckbetankung auch funktioniert?
Zumal es immer weniger bringt
So wie wir (die 70er bis 80er Jahre Generation) das gelernt haben, geht es nicht mehr. Wir hätten uns mit so tollen visuellen Simulatoren wie im Paradies gefühlt. Jetzt gibt es das, ist aber zu spät.
Ich bin sicher, dass die Generationen nach uns ganz hervorragende Entwickler werden können, ohne jedes Bit mit Namen zu kennen oder gar (zumindest theoretisch) eigene Prozessoren entwickeln zu können. Wir brauchten das damals noch, aber das ist Vergangenheit.
Hallo Norbert und alle,
ich hatte hier schon geschrieben, und auf einmal ist alles weg.- Nun wiederhole ich. - Das ist ja PRIMA! DANKESCHÖN!Ich sehe, sogar das Status-Register ist dabei. Es ist zwar etwas anders, als wir es in der Schule hatten, immerhin ich sehe den IRQ und den NMI. Dann werde ich ja bald loslegen können.
Die angezeigten Begriffe sind im Englischen besser zu verstehen,
obschon ich sonst nur sehr wenig Englisch kann.
Die 8-Zeilen-Routine, ist das die für den Singlestep (Einzelschritt)?
Ja, auch wenn Assembler dabei ist, wäre es ja interessant, mal selber einen zu schreiben, ebenso einen Dissassembler. - Nun habe ich schon mal gehört, dass beim Dissassembler, kein OP-Code angezeigt wird; gerade der OP-Code ist ja so interessant und so lernt man besser Maschinensprache zu verstehen.
Nur, muss ich erst mal mit kleinen Programmen anfangen. Zum Beispiel ein Uhrenprogramm, nur das Uhrenprogramm, noch ohne Synchronisation zum DCF77; (... später, dann wohl.).
Nun ich sprach von Schule, das war noch in den 80ern, und ich bin im 80. Lebensjahr. (Meine Kinder u. junge Jugendzeit-21 war grausam, darüber schreibe ich nichts weiter.)
Ich melde mich auch nochmal zu dem Herrn aus der ehemaligen DDR, mit seinem Junior-Computer hatte, der noch mit DM bezahlt wurde. - Der RODNEY ZAKS schrieb auch Bücher über den 6502, -hier in diesem Falle ist es der Z80.
Also, bestimmt bis später
L. Gruß Elk.
Nun ich sprach von Schule, das war noch in den 80ern, und ich bin im 80.
Lebensjahr.
Verschwende deine wenige verbleibende Zeit nicht an Mikroprozessoren und Software, die nur noch in Museen zu bewundern sind. Schau dir lieber mal an, was Arduino so zu bieten hat. Arduino ist eine völlig andere Herangehensweise, aber sie funktioniert, ist billig und macht Spaß. Und man kann damit ernsthaft benutzbare Sachen bauen.
Genau das ist doch die primäre Aufgabe des Disassemblers.
Nun soll es aber Dissasembler geben, die das eben nicht können.
Wenn ich den Nächsten, bzw. den Ersten, habe, der das kann, ist es ja gut.
Ich bin gespannt was werden wird.
LG Enk
Ich stelle mir vor, ich wäre 80 und würde meinen Urgroßenkeln meine eigenen selbst gebauten Computer präsentieren, aus 50 Jahre alten Bauteilen, mit komplett selbst geschriebener Software.
Und dann kommt mein 12 jährige Urenkel und sagt: Opa, das ist langweilig. Schau dir mal meine 3D Simulation von der Drachenhöhle an. Man kann gegen Drachen kämpfen und die Prinzessin befreien.
Ich melde mich auch nochmal zu dem Herrn aus der ehemaligen DDR
In der DDR war der Z80 (U880) recht populär, damit habe ich auch angefangen.
Später kamen dann mit dem U881..886 (Z8) die µC. Als Entwicklungsversion gab es davon den UB8841, wo man extern 4kB EPROM anflanschen konnte.
Den 6502 habe ich komplett verpaßt, Spielekonsolen waren nicht so mein Ding.
Nur, muss ich erst mal mit kleinen Programmen anfangen. Zum Beispiel ein
Uhrenprogramm, nur das Uhrenprogramm, noch ohne Synchronisation zum
DCF77; (... später, dann wohl.).
Sowas macht man aber nicht mehr mit einfachen CPUs, sondern mit µCs, wo bereits alles in einem Chip sitzt, inklusive Flash Speicher und Bootloader.
Richtig angefangen mit Basteln habe ich dann mit dem AT89C2051. Erst in Assembler, später in C.
Nun soll es aber Dissasembler geben, die das eben nicht können.
Das kann es nicht geben, denn wie schon geschrieben, ist es die "einzige" Aufgabe, Maschinencode, also Zahlen, in verständliche mnemotechnische Anweisungen zu übersetzen. Könnte ein Disassembler das nicht, wäre er kein Disassembler! ;-)
Den 6502 habe ich komplett verpaßt, Spielekonsolen waren nicht so mein
Ding.
Commodore und Spielkonsolen waren auch nicht mein Ding, aber die ersten 6502 hatten noch nichts damit zu tun. https://de.wikipedia.org/wiki/AIM-65 ohne Gehäuse und Netzteil, die waren Selbstbau.
Ansonsten kann ich nur den Tipp wiederholen, einen modernen Prozessor bzw. uC zu verwenden. Auch diesen kannst Du in Assembler programmieren.
Ich denke, in Verbindung mit den Dokus zu dem uC kommst du schon sehr nah an die Hardware heran. Da wird jedes Register, jeder Befehl auf unterster Ebene beschrieben.
Arduiono ist da halt schon a Stückle weit weg von der "Hardware"(*).
ciao
Marci
(*) Ihr wisst schon, was ich mit "Hardware" meine.
es geht mir darum, wie die Schaltung im Inneren funktioniert.
3D ist da auch schon interessant ja sogar begeiserungswert.
Dann muss man sich mit den Pixeln beschäftigen (wirklich schwer).
Doch im Kleinen, kommt das auch auf mich zu; Pixel für die Buchstaben.
Ja Buchstaben, Ziffern, und Zeichen.
LG Enk
Die 8-Zeilen-Routine, ist das die für den Singlestep (Einzelschritt)?
Kann man auch durchlaufen lassen. Aber im Singlestep sieht man wie Y heruntergezählt und im Akku addiert wird. Auch wie das Z-Flag gesetzt und die Schleife beendet wird.
Ja, auch wenn Assembler dabei ist, wäre es ja interessant, mal selber
einen zu schreiben, ebenso einen Dissassembler. - Nun habe ich schon mal
gehört, dass beim Dissassembler, kein OP-Code angezeigt wird; gerade der
OP-Code ist ja so interessant und so lernt man besser Maschinensprache
zu verstehen.
Da im Speicher kein Unterschied zwischen Maschinencode, Zahlen, Zeichen, usw. gemacht wird, kann ein einfacher Dissassembler das durchaus auch mal falsch interpretieren. Da muss der Mensch dann eingreifen.
Beispiel:
Im Speicher steht 4c
das kann der Beginn eines JMP in Maschinencode sein.
Kann auch die Zahl 76 sein.
Kann auch der Buchstabe ›L‹ sein.
Hallo Marci W.
Das es nur "mnemotechnische Anweisungen" machen würde, nur als mnemo,
kann ich mir schon vorstellen, dass es das gäbe,
es wäre mir nur zu wenig nützlich.
Also brauche ich mir darum auch keine Gedanken zu machen,
wenn die Wirklichkeit sowieso besser aussieht.
LG. Enk.
Richtig angefangen mit Basteln habe ich dann mit dem AT89C2051.
Willkommen im Club. Die Grundlagen habe ich mit Z80 und 8051 gelernt, meine eigenen Konstruktionen begannen jedoch ebenfalls mit AT89C2051. Zum Lernen ist der gar nicht schlecht, weil er vom Aufbau her sehr nahe an den 8-Bit Lerncomputern ist. Nur halt alles in einem Chip wo man nicht rein gucken kann (man muss der Doku glauben).
Der TO sollte sich schon ueberlegen, ob er sich den Assembler/Disassembler selbst antun will: Zum einen gibt es gute Produkte (auch fuer umsonst), zum andern ist lexikalische Analyse auch nicht so prickelnd.
Die einfachen Disassembler sind auch (meistens) dumm wie ein Stueck Brot: Suchen den OP-Code aus der Liste raus, analysieren die Operanden und korrigieren den PC zum naechsten Schritt. Eine richtige Code-Analyse macht kaum ein Programm (ghidra ist nicht so schlecht), trotzdem noch eine ziemliche Keulerei. Vielleicht wird das jetzt mit KI besser werden; ich sehe nur nicht, dass jemand viel Hexcode zum lernen sammelt.
Mir ist das Endziel der Frage nicht klar: Computer-Architektur ist ein weites Feld, und ich glaube nicht, dass die Entwicklung und Aufbau eines Rechners (damit er die Blinkenlights bekommt) zielfuehrend ist (dazu ist das Feld viel zu weit).
Ich wuerde dann so etwas wie Arduino (ist auch billig, selbst wenn Du die Orginalteile nimmst) oder Raspberry Pi benutzen. Der TO hatte auch geschrieben, dass er deutsch zum Lesen bevorzugen wuerde. Dann waere ein Arduino (z.b. der Arduino R4 mit Wifi und Blinkenlights) fuer einen 30Euroschein nicht so schlecht. Wie Uebliche, Debugging ist schlecht geloest.
Wenn es nur das Look-and-Feel sein soll, reicht auch ein PiDP-11: Ein
Nachbau der PDP-11 (grosses Problem waren die schoenen Taster/Schalter).
Das erinnert mich an die alten Zeiten wo man bei Diskussionen mit den DEC Leuten Papier und Bleistift bereit halten musste, um Oktal in Hex und umgekehrt umzurechnen. ;-)
Da im Speicher kein Unterschied zwischen Maschinencode, Zahlen, Zeichen,
usw. gemacht wird, kann ein einfacher Dissassembler das durchaus auch
mal falsch interpretieren. Da muss der Mensch dann eingreifen.
Beispiel:
Im Speicher steht 4c
das kann der Beginn eines JMP in Maschinencode sein.
Kann auch die Zahl 76 sein.
Kann auch der Buchstabe ›L‹ sein.
Ist das bei der Harvard-Architektur auch so?
Oder kann man eine Nebenspeicherung machen,
für den Fall, dass man selber das Programm ändern möchte?
Oder bei der Firmware?
Das erinnert mich an die alten Zeiten wo man bei Diskussionen mit den
DEC Leuten Papier und Bleistift bereit halten musste, um Oktal in Hex
und umgekehrt umzurechnen. ;-)
Mich an Kollegen, die für IBM Host in 5cm dicken Hex Dump Papierstapeln Fehler gesucht und gefunden haben, und die Korrektur dann per Hotfix in eine Patch Area geschrieben und den Sprung dahin in den Code gehackt haben.
Bei laufender Maschine und Programm wohlgemerkt.
Beispiel:
Im Speicher steht 4c
... Ja damals hieß das auch 4c ...
Ist das bei der Harvard-Architektur auch so?
Oder kann man eine Nebenspeicherung machen,
für den Fall, dass man selber das Programm ändern möchte?
Oder bei der Firmware?
Wenn ich mir eine Liste mache, für den Speicherraum
auf dem zusätzlich das (selbstgeschriebene Assembler)
für den Disassembler als (eigene "Firmware")
oder mit Sonder-REM-Befehlen ausstatte?
Geht das oder gibt es das?
Mit "Nebenspeicherung" meine ich,
Dass wenn ich zB. selbst ein Programm schreibe,
dass ich dann nebenbei auf anderer Stelle Zeichen setze,
(Natürlich passend in der Reihenfolge an anderer Stelle)
welche natürlich im laufenden Programm nicht gebraucht werden,
zum disassembeln aber wohl(wird wohl jeweils in 1 Byte passen).
Und schon somit vielleicht sogar Fehler gefunden, andererseits
gibt es die Möglichleit (was aber nicht sollte) selber weitere Fehler zu machen.
Ich glaub bei Linux gibt es sowas ähnliches, kann aber noch kein Linux.
Zum Lernen was da in so einem Computer passiert, und was die einzelnen Ebenen von Hardware bis zum Betriebssystem so machen, kann ich 'From NAND to Tetris' (https://www.nand2tetris.org/) empfehlen. Das Buch dazu heisst 'The Elements of Computing Systems: Building a Modern Computer from First Principles'.
Da passiert genau das was der Titel sagt: man fängt mit einfachen NAND-Gattern an, baut sich dann kompliziertere Dinge, eine ALU, und dann eine CPU. Die programmiert man sich dann in Maschinensprache, bevor man sich einen Assembler, einen Compiler und ein OS baut, um an Ende was zu haben wo eigene Programme drauf laufen (Tetris wird übrigens nicht erklärt...).
Das ganze arbeitet allerdings nicht auf echter Hardware, sondern in einem Simulator. Wenn man will, kann man das aber trotzdem in einen FPGA giessen, es gibt einen Reihe von Projekten die das vorgemacht haben.
Man muss auch Englisch können. Der Assembler und der Compiler werden in einer Sprache der eigenen Wahl geschrieben, man sollte also programmieren können.
Vorteil: man wird didaktisch vernünftig durch die ganzen Stufen geführt, und muss sich nicht alles selber erarbeiten oder rausbekommen wo man welche Informationen bekommt.
sorry, ich verstehe nur Bahnhof. Vielleicht kann jemand anderes die
Frage beantworten.
I habe das so verstanden das es eine (Maschinen)Sprache gibt (geben sollte) die unbenutzten Platz benutzt (Bits,Bytes), der bei Ausführung überlesen wird und durch irgendwelche Informationen für einen Disassembler gefüllt werden kann.
Wäre vielleicht theoretisch möglich bei einer CPU die mehrere Codes als NOP interpretiert.
So etwas ist mir bisher noch nicht untergekommen und den Sinn dahinter erschließt sich mir auch nicht ...
Entschuldigt bitte.
Zwar gibt es das Wort Nebenspeicherung nicht, - aber selbsterklärend gemeint.
Wenn man ein Programm scheibt, gibt es ja die REM-Befehle. - So kann ich ja, nebenbei an anderer Stelle "paralell" an einem anderen Stelle aufschreiben, welche Daten-Art es ist.
Ich vermute, dass das irgendjemand versteht; - ich selbst bin ja noch lange nicht so weit, um Programme zu schreiben.
LG. Enk.
Entschuldigt bitte.
Zwar gibt es das Wort Nebenspeicherung nicht, - aber selbsterklärend
gemeint.
Wenn man ein Programm scheibt, gibt es ja die REM-Befehle. - So kann ich
ja, nebenbei an anderer Stelle "paralell" an einem anderen Stelle
aufschreiben, welche Daten-Art es ist.
Ich vermute, dass das irgendjemand versteht; - ich selbst bin ja noch
lange nicht so weit, um Programme zu schreiben.
LG. Enk.
Du meinst Kommentare ?
Was hat das aber mit parallel und nebenbei zu tun ?.
Parallel und Nebenläufig sind feste Begriffe in der Informatik.
vielen vielen Dank, für die guten Tipps.
Ich melde mich wieder, wenn ein Computer zu diesem Zweck läuft.
Vermutlich wird es ein 6502, Z80 oder ein 8086 sein,
vielleicht sogar mit 64 Bit.
Ja klar das muss heute schon sein. In der Überschrift schreibst du von einfacher CPU und nun kommst du mit 64 Bit um die Ecke. Ich glaube dir kein Wort mehr.
eine bastelfreundliche 64bit CPU im 40pol DIL Gehäuse. Vielleicht noch mit Fenster, dann wäre alles sichtbar und man könnte ihr bei der Arbeit zuschauen ...
3D ist da auch schon interessant ja sogar begeiserungswert.
ich dachte, Du würdest gerne die Grundlagen der Prozessortechnik und deren Programmierung lernen?! Bis zu 3D ist da von den ersten Schritten aber schon ein relativ weiter Weg. Und solche Sachen wirst Du dann sicher nicht mehr auf Assemblerebene programmieren (wollen).
Was mir noch eingefallen ist: zur Mikroprozessorprogrammierung gehören z.B. auch Kenntnisse der binären Logik und Kenntnisse der Programmierung allgemein. Da wäre dann ein möglichst ausführliches Tutorial und ein Einstiegsbuch in die Assemblerprogrammierung (evtl. auch HW-unabhängig) geeignet. Und dazu die Doks der jeweiligen Architektur, dann bist Du gut gerüstet, und kannst ne ganze Menge lernen und ausprobieren. ;-)
Ich melde mich wieder, wenn ein Computer zu diesem Zweck läuft.
Computer?
Vermutlich wird es ein 6502, Z80 oder ein 8086 sein,
Also ich finde, der Z80 hat die übersichtlichste Struktur und Befehle und die einfachste HW-Struktur nach außen. Aber da bin ich voreingenommen: war mein 1. Bastelprozessor.
vielleicht sogar mit 64 Bit.
Abgesehen davon, dass es die von dir genannten Prozessoren (alle aus den Siebzigern und Achtzigern, also urururalt!) selbstverständlich nicht in 64-Bit gibt, würde es auch absolut keinen Sinn machen, mit einem 64-Bitter anzufangen.Und ob man für die Prozessoren Entwicklerboards kriegt, wage ich auch stark zu beweifeln (jedenfalls nicht neu). Oder willst Du Dir so ein Prozessorboard selbst entwickeln?
Jetzt mal Butter bei de Fische: WAS willst du nun eigentlich genau machen?
Das passt alles nicht mehr zusammen, was Du schreibst.
Und aus welchem Metier kommst Du denn beruflich? Hast Du technische/elektrische/elektronische Vorkenntnisse?
Was hat das aber mit parallel und nebenbei zu tun ?.
Günter meint wohl, dass man Kommentare NEBEN den Befehl schreiben kann!? Aber seine Aussagen lassen ahnen, dass er doch noch ziemlich am Anfang steht.
Vllt. warten wir mal, bis er unsere Postings kommentiert hat.
Ich bin sicher, dass die Generationen nach uns ganz hervorragende
Entwickler werden können, ohne jedes Bit mit Namen zu kennen
Nö. Die Allermeisten sind oberflächliche Sciptkiddies die weder wirklich Ahnung noch Erhgeiz haben, was wirklich Gutes zu erschaffen. Da werden nur monströse Frameworks zusammengewürfelt und Java oder ander Quark reingerührt.
Hervoragende Leute sind damals wie heute eine sehr kleine Minderheit. Das ist schon rein definitionsgemäß so. Im Club der Millionäre ist nur der Milliardär herausragend.
Ja, auch wenn Assembler dabei ist, wäre es ja interessant, mal selber
einen zu schreiben, ebenso einen Dissassembler. - Nun habe ich schon mal
gehört, dass beim Dissassembler, kein OP-Code angezeigt wird;
Dann ist es kein DISassembler sondern nur ein Hexeditor!
gerade der
OP-Code ist ja so interessant und so lernt man besser Maschinensprache
zu verstehen.
Aber nicht in erster Linie mit dem Disassembler.
Ich melde mich auch nochmal zu dem Herrn aus der ehemaligen DDR, mit
seinem Junior-Computer hatte, der noch mit DM bezahlt wurde. - Der
RODNEY ZAKS schrieb auch Bücher über den 6502, -hier in diesem Falle ist
es der Z80.
Vergiss den ollen Kram! Nimm was ANSATZWEISE aktuelles. AVR wure schon genannt, würde ich auch empfehlen. Einfach, leistungsfähig, weit verbreitet.
Entschuldigt bitte.
Zwar gibt es das Wort Nebenspeicherung nicht, - aber selbsterklärend
gemeint.
Wenn man ein Programm scheibt, gibt es ja die REM-Befehle. - So kann ich
ja, nebenbei an anderer Stelle "paralell" an einem anderen Stelle
aufschreiben, welche Daten-Art es ist.
Du meinst wohl einen Kommentar? Das ist nur Text, der nicht im Controller landet, den filtert der Compiler/Assembler raus.
Ich vermute, dass das irgendjemand versteht; - ich selbst bin ja noch
lange nicht so weit, um Programme zu schreiben.
Und wirst es vermutlich nie sein. Mein ernstgemeinter Rat. Laß es. Geh ins Museeum, ggf. HNF oder andere und schau dir die Dinge an, schwärme und träume. Aber verplemper nicht deinen Lebensabend mit einer Sache, die man in dem Alter nicht mehr wirklich lernt oder gar genießen kann.
Wir hatten hier schon mehrere Leute in ähnlicher Situation, die von großen Projekten und Programmierung schwärmten, aber meistens nur über ihre eigenen Füße gestolpert sind. Ich weiß es, ich hab mehr als einmal (viel zu lange) mitgemacht.
Ja klar das muss heute schon sein. In der Überschrift schreibst du von
einfacher CPU und nun kommst du mit 64 Bit um die Ecke. Ich glaube dir
kein Wort mehr.
Aber verplemper nicht deinen Lebensabend mit einer Sache,
die man in dem Alter nicht mehr wirklich lernt oder gar genießen kann.
...
Wir hatten hier schon mehrere Leute in ähnlicher Situation, die von
großen Projekten und Programmierung schwärmten, aber meistens nur über
ihre eigenen Füße gestolpert sind. Ich weiß es, ich hab mehr als einmal
(viel zu lange) mitgemacht.
...
Ein alter Bär lernt keine neuen Kunststücke mehr. Ist leider so.
Hallo Falk,
Das kann ich aber pauschal so nicht stehen lassen !!!
Ja, man wird im Alter langsamer, müder und vergesslicher.
Dafür ist ja kein Chef oder Kunde mehr da der einem antreibt. Nur der eigene Wille und den kannst du keinem absprechen.
Wer gelernt hat zu lernen und sich weiter zu bilden, kann das ein Leben lang.
Aber verplemper nicht deinen Lebensabend mit einer Sache,
die man in dem Alter nicht mehr wirklich lernt
Autsch, du begibst dich auf seeehr dünnes Eis! Denkst du im Ernst, die älteren Leute könnten sowas nicht mehr lernen?
Ich hoffe jedenfalls, dass ich im Alter noch fit genug sein werde, um so nen Pipifax noch in mein Hirn zu kriegen...
Also, ich habe eine Z80, und einen 6502 Junior-Computer.
In den Z80 Micro-Professor I, hatte ich im Op-Code ein Programm abgetippt.
Es ist ein Uhren-Programm, und das funktionierte.
Bei jedem Sekundentakt klackte der Lautsprecher;
in der 6-Stelligen Display-Anzeige, erschien die zu dem Progamm gehörende Uhrzeit und wurde auf diesem Wege hochzählend angezeigt.
Die Uhrzeit zählt in Sekunden, Minuten und Stunden hoch.
Diesen Computer habe ich zur Zeit nicht hier.
Es hat nur 72 Speicherplätze, die ich Byte für Byte eingegeben hatte;
also die Programmspeicherplätze.
Eine Periferie hat der Computer noch nicht.
An einem anderen Ort, liegt er in eine Kiste.
Morgen hole ich ihn zurück.
Weil das Progamm so klein ist, könnte man das auch
von Hand Disassemblieren.
In dem Buch von Rodnay Zacks, sind alle Befehle aufgeführt.
Aber leider nicht in der Zahlenfolge der Hexadezimalen Zahlen.
Der erste Eintrag lautet: "21", das müsste ein Befehl sein.
Leider finde ich den Befehl nicht.
Ach noch was, da habe ich ein Buch für ds wirden 8086.
Für ihn, habe ich Lehrprogramme.
Aber leider, habe ich die Funktion -im Ganzen- auch noch nicht verstanden.
Es wird geschrieben, dass man das Programm nur in den Editor laden braucht.
Da muss aber noch mehr sein; also der eigentliche Assembler selbst.
Leider verstehe ich den Begriff: "Direktive" nicht;
das sind Anweisungen an den Assembler.
Also wo, wird -genau- wohin, etwas angewiesen?
Daher war meine Frage nach einen "nakten" Computer.
Nur so, kann man das alles verstehen lernen.
In dem Buch von Rodnay Zacks, sind alle Befehle aufgeführt.
Aber leider nicht in der Zahlenfolge der Hexadezimalen Zahlen.
Der erste Eintrag lautet: "21", das müsste ein Befehl sein.
0x21 ist LD HL, nnnn. Vor 45 Jahren habe ich per Hand assemblieren muessen.
Ach noch was, da habe ich ein Buch für ds wirden 8086.
Für ihn, habe ich Lehrprogramme.
nun dann würde ein XP aufsetzen (heute vermutlich in einer VM)
Da gibt es ein nettes Programm debug. Damit kannst du kleine Assemblerprograme in 8086 asm code eingeben, laden und speichern. Da ist ein kleiner Zeilen-Assembler, ein Lister (Disassembler) und diverse andere Hilfsfunktionen dabei.
Danach kannst dann mal den TASM von Borland probieren. Der ist inzwischen frei downloadbar und es existiert auch eine 32 Bit Version die man unter W10 aufrufen kann. Die Handbücher von Borland sind super aber halt auf Englisch.
Die sind im Internet Archiv abrufbar.
Direktiven sind Steueranweisungen für den Assembler (.ORG,.EQU, usw)
Dein Z80 0x21 bedeutet LD HL,<xxxx> beim 8085 wäre es LXI H,<xxxx>
wie eine Assemblerliste funktionieren kann,
wenn er auf dem Bildschirm steht. Es müssen doch Prog.-Routinen da sein,
die das bewerkstelligen;
Und woraus sollen die Programm Routinen bestehen?
ASM ist die unterste Verarbeitungsebene.
ASM ist direkt in Hexcodes übersetzbar.
Der (Makro) Assembler macht es nur dem Menschen ein wenig ansehnlicher und kennt ein paar grundlegende Vereinbarungen damit man nicht nur mit 'magic numbers' und kryptischen Speicheradressen arbeiten muss, die keiner versteht der den Code sieht.
Du kannst aber den ASM Code auch anhand der Befehlsreferenz in die Hex Zahl übersetzen und direkt in die Speicherstelle schreiben.
So habe ich in der Lehre mein erstes 8085 System programmiert.
Dipschalter an A0-15 und D0-7 und eine /WR Taste.
Geht, ist aber maximal ineffizient und vollkommen unwartbar.
Darunter kommt nur noch Hardware.
Befehl aus Speicher holen, Befehl dekodieren, Befehl ausführen.
Befehl ausführen besteht meist aus weiteren Speicherzugriffen, dem herumschieben in Register und auslösen einer Hardwareaktion.
'NOP' z.B. setzt einfach den Programmcounter einen hoch und wartet auf den nächsten 'Befehl holen' Zyklus.
Ein 'ADD A,B' addiert unter zuhilfename des Akkumulator und eines Hilfsregisters die zwei Werte und speichert das Ergebniss im Akku'
Ein 'Jump 0x1234' besteht aus dem Befehl 'Jump' der die Hardware anweist das die nächsten zwei Speicherstellen in den Programm Counter geladen werden und dort weitergemacht wird.
Ein 'conditional JMP' macht das Srungergebnis von einem Zustand abhängig.
Das kann z.B. der Status des Carry Bits sein, das den Überlauf der vorrangegangenen Rechenoperation enthält. Z.B. das oben erwähnte 'Add a,b'
Steht alles im Detail in der Befehlsübersicht der jeweiligen CPU.
Moderne CPU sind weit ausgefuchster. Die willst Du nicht im Detail verstehen müssen.
Es steht in meinem Buch nicht drin. - "Es ist Rede von Direktiven?
Google: Direktive = Anweisung.
WELCHES Buch?
Irgendsoein verstaubter Schinken aus dem Pleistozän, geschrieben von einem verkopften Hochschulprofessor der einfach Dinge äußerst kompliziert beschreiben kann?
Autsch, du begibst dich auf seeehr dünnes Eis! Denkst du im Ernst, die
älteren Leute könnten sowas nicht mehr lernen?
Es sollte allgemein bekannt sein dass die Lernfähigkeit des Gehirns ab 25-30 Jahren steig abnimmt.
D.h. es geht nicht um können oder nicht können sondern darum wie leicht oder schwer es ist, etwas Neues zu lernen.
Also, ich habe eine Z80, und einen 6502 Junior-Computer.
Na bitte, die Hardware hast du doch schon.
Es hat nur 72 Speicherplätze, die ich Byte für Byte eingegeben hatte;
also die Programmspeicherplätze.
Ein Wort zum Sprachgebrauch: ein Programm hat keine "Programmspeicherplätze". Der Prozessor hat die und zwar für die von dir genannten Typen in externem Speicher, entweder ROM (unveränderlich) oder RAM (veränderlich aber dafür flüchtig - Strom weg, Daten weg).
Ein Programm besteht aus Instruktionen, auf niedrigster Ebene ist das Maschinencode. Und natürlich hat ein Programm dann auch eine Länge. Und zwar wahlweise in Bytes (Maschinencode) oder in Anzahl an Instruktionen.
Die Übersetzung von Instruktionen (wahlweise auch "Befehle", "Anweisungen", "Mnemonics" etc. genannt) in Maschinecode ist ein vergleichsweise sturer Vorgang, den man im Regelfall einem dafür gemachten Programm überläßt: dem Assembler. Normalerweise ist diese Codierung 1:1, so wird "LD HL, #1234H" immer in "21 34 12" (alles Hexadezimal) übersetzt. Tricky wird es bei Sprüngen, wahlweise absolut oder relativ. Absolute Sprünge brauchen eine absolute Adresse, man muß also wissen an welcher Stelle im Speicher der Zielbefehl steht. In einem Assember-Programm verwendet man dazu Sprungmarken (auch "Label"), von Hand wird das wie gesagt etwas aufwendig.
Eine Instruktion wird idR. in mehrere Bytes übersetzt. Die Länge eines Programms in Bytes ist also idR. größer als die Anzahl an Instruktionen.
Da muss aber noch mehr sein; also der eigentliche Assembler selbst.
Leider verstehe ich den Begriff: "Direktive" nicht;
das sind Anweisungen an den Assembler.
Also wo, wird -genau- wohin, etwas angewiesen?
Eine Direktive erzeugt meist keinen Maschinencode, sondern steuert den Übersetzungvorgang. Z.B. haben Z80 Assembler eine Direktive "ORG nnnn". Der Assembler wird damit angewiesen, den Maschinencode für die nächste Instruktion auf die Adresse nnnn zu codieren. Eine andere häufig gebrauchte Direktive ist "DB" ("data byte"). Die kann man benutzen, um Daten wie z.B. Strings in den Maschinencode zu schreiben. Beipiel:
DB "Hello World", 13H, 10H, 0
erzeugt die Bytes 48 65 6c 6c 6f 20 57 6f 72 6c 64 0d 0a 00. Für einen gebrauchsfähigen nullterminierten String mit CRLF Zeilenende. Dessen Adresse kann man dann in ein Register laden und die Routine für die Bildschirmausgabe aufrufen. Beipiel:
Daher war meine Frage nach einen "nakten" Computer.
Nur so, kann man das alles verstehen lernen.
Dazu brauchst du keinen nackten Computer. Ein Emulator auf dem PC tuts auch. Und etwas Infrastruktur darf der gerne mitbringen. Z.B. um Ein- und Ausgaben zu machen. Ein C64 Emulator für den 6502 oder ein CPM-Emulator für den Z80 sind z.B. als Spielwiese sehr gut geeignet.
Meine Empfehlung an den TE wäre: Lernen wie grundsätzlich ein Rechner funktioniert. Und zwar mir einem akademischen Micro/Tiny Rechner für den es einen winzigen Assembler gibt. Mit einfachstem Stromlaufplan. Da gibt es ein paar. Ich müsste die konkret aber erst raussuchen.
Damit kann man relativ einfach lernen, wie überhaupt aus Elektronik ein Rechner entsteht der ein Programm ausführen kann.
Das ganze an einem echten, wenn auch alten, Rechner zu machen ist unnötig aufwendig.
wie eine Assemblerliste funktionieren kann,
wenn er auf dem Bildschirm steht. Es müssen doch Prog.-Routinen da sein,
die das bewerkstelligen;
Und woraus sollen die Programm Routinen bestehen?
ASM ist die unterste Verarbeitungsebene.
ASM ist direkt in Hexcodes übersetzbar.
Damit ignorierst Du alle Arbeiten von Maurice Wilkes, der 1951 das Konzept des Microprogramming entwickelt hat. Und fast alle CPUs, die Du heute als Mikroprozessor bezeichnen wuerde, sind mikroprogrammiert (ausser der 6502, die hat ein direktes Steuerwerk).
Und Du hast schon das Elend mit den Meltdown, Spectre, Retbleed vergessen oder verdraengt? Die "Loesung" war ein Patch des Microcodes, nicht des Betriebsystemes.
Bei unserer VAX780 wurde das Microprogramm beim Boot in die CPU geladen, unter der Console durch eine PDP11 :-).
Und fast alle CPUs, die Du
heute als Mikroprozessor bezeichnen wuerde, sind mikroprogrammiert
Tatsächlich sind heutige Mikroprozessoren nicht im klassischen Sinn mikroprogrammiert, ausser sie sind aus dem Pleistozän übrig. Nur bei Microcontrollern mag das noch signifikant sein.
Die x86 haben zwar noch ein Mikroprogramm, das wird aber nur für sehr komplexe oder sehr seltene Befehle genutzt. RISCs wie ARM nutzen keines - das war ja gerade der Sinn der Sache.
Also, ich habe eine Z80, und einen 6502 Junior-Computer.
In den Z80 Micro-Professor I, hatte ich im Op-Code ein Programm
abgetippt.
Es ist ein Uhren-Programm, und das funktionierte.
Da hast Du doch genau das was Du suchst. Der MicroProfessor ist ein super Lernsystem, wenn es um die absoluten Grundlagen geht, und wird genau dafür heute noch eingesetzt. Das Ding stammt aus den '80ern, wurde aber bis vor ein paar Jahren noch hergestellt.
https://de.wikipedia.org/wiki/Microprofessor_Ihttps://micro-professor.org/
Besorg Dir die original Anleitungsbücher und arbeite die durch. Da sind die Grundlagen erklärt, wie man mit Strom zwei Zustände darstellen kann ("an" und "aus"), wie man mit mehrmals zwei Zuständen Informationen codieren kann, die Architektur eines Mikroprozessors, Maschinenbefehle, und schlußendlich auch die Möglichkeiten sich das Leben einfacher zu machen (höhere Programmiersprachen, BASIC).
Vom Fernlehrinstitut Christiani gab es Lehrgänge, die auf dem MPF-1 basieren. Die sind nochmal ausführlicher und einfacher erklärt als das originale Handbuch. Vielleicht findet man die auch irgendwo online.
Na Stefan, jetzt im neuen Namen annonym unterwegs?
Wieso anonym? Ich nutze den Account seit 4 Jahren.
Interessant. Der Monk alias Stefan F alias Whoever wird "enttarnt", neudeutsch "exposed" und schon ist sein Account deaktivert oder gar gelöscht, sodaß seine Beiträge nicht mehr als angemeldeter Teilnehmer sondern nur noch als Gast erscheinen. Was sagt uns das?
Dass man den Kollegen, sofern es einen interessiert, doch auch sehr einfach ohne "deine Enttarnung" hier erkennen kann, egal mit welchem und wie altem oder ganz neuen Alias.
Aber was bringt einem das?
Schmeichler ;-), 83 begann die Entwicklung, vertrieben wurde die Mappe ab 1984. Ich erinnere mich noch an die spitze Bemerkung eines Kurators der Technischen Sammlungen Dresden (damals "Polytechnisches Museum") mit der dieser den "Neuzugang" seinen Besuchern vorstellte - das war nämlich auch 1984. Also gleich aus der Entwicklung in das Museum - wegweisend für die DDR-Elektronikproduktion. ;-)
Wobei der Kurator übersah, das technische Ausstellung auch einen Bildungsauftrag neben der Vermittlung von Historie haben und das es durchaus Sinn macht, einen Experimentiercomputer in die Sammlung aufzunehmen.
Die Bezeichnung Homecomputer im Vergleich zum C64 oder Atari ST ist da natürlich fehl am Platz.
Und damit gleich ein Hinweis auf die Alt-Computerausstellung VCFB dieses Wochenende in Berlin: https://vcfb.de/2024/
Überholen ohne Einzuholen! ;-)
Ja, der Klassiker realsozialistischer Logik. In Abwandlung dazu " Wo wir sind ist vorn. Und wenn wir hinten sind, ist hinten vorn !!!" ;-)
... ich frage mich, wer da von wem mal wieder kopiert hat?
Naja. Das Konzept wurde sicherlich kopiert. Aber Konzepte sind für sich nicht geschützt. Daß die DDR eine eigene Hardware (sowohl die Platine als auch die Chips darauf) gebaut hat lag auch daran, daß zumindest die Chips dem Technologie-Embargo (CoCom-Liste) unterlagen. Und daß der U880 erst 1983 in nennenswerter Stückzahl für ein Spielzeug wie den LC80 verfügbar war.
Zeitgleich mit dem LC80 kam auch der Poly880 [1] auf den Markt. Den halte ich für die angedachte Verwendung als Lernsystem für noch besser. Und der hatte AFAIK kein westliches Pendant.
Daß die DDR eine eigene Hardware (sowohl die Platine
als auch die Chips darauf) gebaut hat lag auch daran, daß zumindest die
Chips dem Technologie-Embargo (CoCom-Liste) unterlagen.
Nein, diese 8 bit Chips standen nicht auf der Embargoliste, die konnte man bequem in West-Berlin kaufen und über die Grenze bringen. Oder sich verbaut in einen C64 von Oma mitbringen lassen. Auf der Liste damals standen 32 bit Prozessoren, die aber geliefert werden durften, wenn auf dem pcb der datenbus nur in Hälfte (32 bit) ausgeführt war.
Und daß der U880
erst 1983 in nennenswerter Stückzahl für ein Spielzeug wie den LC80
verfügbar war.
Das passt schon eher, wobei die U880 Produktion (Z80-Clone) schon erheblich gestreckt wurde und für Bastler Ausschuß-Exemplare sogenannte bastlertypen aussortiert wurden.
Zeitgleich mit dem LC80 kam auch der Poly880 [1] auf den Markt.
"Im Jahr 1984 betrug der Neupreis 3.449 Mark."
Autsch! Für so einen Murks satte 4 Monatsgehälter auf den Tisch legen. Naja, mangels größerem Angebot kam wohl kaum eine Privatperson in die Versuchung, dafür Geld auszugeben. Der C64 kam 2 Jahre vorher im NSW für um die 1400 Westmark auf den Markt und hatte um Welten mehr zu bieten! Ein reichliches Jahr später gab's den für unter 1000 DM! Da funktionierte die Konsumgüterproduktion nicht nur auf dem Papier!
Naja, Gott sei Dank ist mir durch die Gnade der späten Geburt diese Mangelwirtschaft als junger Erwachsener erspart geblieben. Ich wär vermutlich abgehauen oder in Bautzen gelandet . . .
Dass man den Kollegen, sofern es einen interessiert, doch auch sehr
einfach ohne "deine Enttarnung" hier erkennen kann, egal mit welchem und
wie altem oder ganz neuen Alias.
Das auch aber das ist gar nicht wesentlich. Wie es scheint, hat der gute Stefan ein Problem damit, mit eindeutigem Namen, und sei es nur ein Pseudonym, aufzutreten. Wie es scheint, steht er nicht zu seinen Worten bzw. ist ihm der Gegenwind, der bisweilen entsteht, zuviel.
Naja, Gott sei Dank ist mir durch die Gnade der späten Geburt diese
Mangelwirtschaft als junger Erwachsener erspart geblieben. Ich wär
vermutlich abgehauen oder in Bautzen gelandet . . .
Auch Amerikanische Computerprogrammierer haben Software hinter Gittern erstellt, Apple's frühe Textverarbeitung ist wohl in einer solchen "Besserungsanstalt" entstanden: https://en.wikipedia.org/wiki/EasyWriter#History
Vor 45 Jahren habe ich per Hand assemblieren
muessen.
Hi Thomas, bei mir ist es noch nicht ganz so lange her. Habe mir ein einfaches Z80-System gebastelt. Und die Möglichkeit, Maschinenbefehle (also Opcodes, keine Assemblerbefehle!) einzugeben und auszuführen, habe ich per Hand codiert und bei einem befreundeten Entwickler in ein EPROM gepackt. Also quasi das BIOS ;-) Waren zwar nur ca. 200 Befehle. Dennoch ein Wunder, dass das funktioniert hat. Und ja, nach dem Ausschalten war das eingegebene Programm natürlich weg. :-)
Mann, das waren noch Zeiten...
Soll aber nicht weniger schlimm gewesen sein. Im Gegenteil.
Hat ja auch Keiner behauptet. Jugendwerkhof war schon ne "Drohkulisse" für die junge Generation, da wollte keiner freiwillig rein.
Nur "Schwedt" hatte einen noch übleren Ruf, aber das betraf Zivilsten eher nicht.
Der erste Eintrag lautet: "21", das müsste ein Befehl sein.
Leider finde ich den Befehl nicht.
Ein Buch brauche ich dafuer nicht. :)
Das "21" steht fuer LD HL, mit literaler 16 bit Konstante.
Die Konstante steht in den folgenden 2 Bytes.
Ich auch! Das gehoert alles in die Schublade "Unnoetiges Wissen"
Das ist so nicht richtig. Weil:
Das gehoert in die Schublade "Historisches Wissen".
Historisches Wissen huelft, Dinge einzuordnen und zu bewerten.
Fehlt es, ist der Betreffende im einfachsten Fall nur unorientiert,
und tritt auch unorientiert auf.
Der LC80 war fuer den "Endkundenmarkt". Teuer genug war er trotzdem. :)
Der Poly880 war fuer "Bildungseinrichtungen". Der Preis war fuer das
Gebotene unverschaemt.
Der LC80 war fuer den "Endkundenmarkt". Teuer genug war er trotzdem. :)
Der Poly880 war fuer "Bildungseinrichtungen". Der Preis war fuer das
Gebotene unverschaemt.
Das war im NSW nicht anders. Die Geräte für die Schülerversuche kamen hier von Phywe oder Leybold Heraeus Didactic, und da wäre das gleiche Gewicht in Gold meist billiger gewesen.
Der LC80 war fuer den "Endkundenmarkt". Teuer genug war er trotzdem. :)
Der Poly880 war fuer "Bildungseinrichtungen". Der Preis war fuer das
Gebotene unverschaemt.
Das war im NSW nicht anders. Die Geräte für die Schülerversuche kamen
hier von Phywe oder Leybold Heraeus Didactic, und da wäre das gleiche
Gewicht in Gold meist billiger gewesen.
So manches (Demonstrations-)Utensil war bei meiner Schule wohl "vererbt"
worden. Die mechanische Ausfuehrung legte es jedenfalls nahe.
Das tat ihrer Nuetzlichkeit natuerlich keinen Abbruch.
Manches haette es in "Neu" vielleicht auch gar nicht gegeben.
Vieles war aber auch erkennbar neu: Ein Demonstrationsoszillograf
und ein dickethaler Zeitmesser fuer fuesikalische Fallversuche.
Der Markt regelt das heute auf die Weise:
"Verlangt wird, was der Markt geradso hergibt."
Wenn es ueberhaupt einen "Markt" gibt. :)
Edith:
Im Rahmen der Studienorientierung gab es auch Besuche bei Hochschulen.
Mit Besichtigung von echter Rechentechnik!
Einen Commodore SR110NC hatte ich da aber schon. :)
0x21 ist LD HL, nnnn. Vor 45 Jahren habe ich per Hand assemblieren
muessen.
Hochachtung!
Mit allergrößtem Respekt sehe ich diese Leistung!
Ich habe nur noch gestaunt; das ist wirklich hervorragend!
Nun fahre ich in die Stadt. - D.h.:
ich komme gerade aus der Stadt zuück,
und habe nun den Computer: Micro-Professor µP AN EYE TO THE FUTURE
MPF-1B
POWER 9 Volt Eingangsspannung.
Jetzt habe ich ja noch das Buch: RODNAY ZAGS
Programmierung des
Z80
RODNAY ZAKS
vom SYBEX Verlag.
ISBN 3-88745-006-X
Auflage 1982
Auflage 1982
Auflage 1983
(C) 1982, SYBEX-Verlag GmbH., Düsseldorf
Vorne-an ist ein: Dankwort.
Leider fehlen hier einige Seiten
zwichen 1 und 6 und habe als 1. Seite 7 vorliegen;
ab dort sind Inhaltsverzeichnisse.
Ich gehe zu TH-Bibliothek, um mehr zu erfahren.
Hier sind zwar Zeichnungen drin wo etwas der ALU oder Akumulator
übergeben wird aber nicht genau; bin nur Elektriker(Elektroniker).
Also sind mir logische Schaltungen auch ein Begriff.
Darum fand ich es auch garnicht schlecht, auf Relais-Schaltungen
zu verweisen. - Denn da, liegt ein springender Punkt. - Wie bei TTL.
Auf Seite 591 Anhang E - : Der Befehlssatz des Z80. Aber nicht sortiert.
Also, das Uhren-Programm läuft. Habe es wohl nicht wiederholt.
Das wird man vermutlich wunderbar an einem Ablauf-Diagramm darstellen können. Vielen Dank auch an alle, ich habe noch nicht alles gelesen. :-)
LG. Enk - Ich schaue gleich weiter rein.
Du schriebst ja:
" Habe mir ein
einfaches Z80-System gebastelt. Und die Möglichkeit, Maschinenbefehle
(also Opcodes, keine Assemblerbefehle!) einzugeben und auszuführen, habe
ich per Hand codiert und bei einem befreundeten Entwickler in ein EPROM
gepackt. Also quasi das BIOS ;-) Waren zwar nur ca. 200 Befehle. Dennoch
ein Wunder, dass das funktioniert hat. Und ja, nach dem Ausschalten war
das eingegebene Programm natürlich weg. :-)".
Inwichen gibt es ja Möglichkeiten, das es nicht mehr weg ist.
Ich muss hier noch lernen, wie man richtig editiert.
ich melde mich nochmal deswegen, geht das?
Im Anhang eine (Hexa-)Tabelle der einfachen und der extended (ED)
Befehle des Z80.
Bitbefehle (CB) und Indexregisterbefehle (DD,FD) muesstest du im
Buch nachschlagen.
Auf den Seiten 1-6 vom "Zaks - Programmierung des Z80" stehen nur
Verlagsinformationen und ein Dankwort an jene, die Verbesserungen
am Buchinhalt vorgeschlagen haben.
Das Inhaltsverzeichnis ist ab Seite 7.
Den Gang zur Bibliothek kannst du dir getrost sparen. :)
Vielleicht noch was für den 6502 oder 65s02, oder 8086, (Z80)?
Die Haupt-sache es ist einfach. Er braucht auch nicht besonders schnell zu sein.
Ich brauche einen STACK, je ein X und Y-Register, Statusregister für die
Flags.
Aber auch einen passenden Emulator der CPU auf einen anderen Computer.
Interessant wäre noch, wie der Akkumulator von innen arbeitet;
Vielleicht wäre diese moderne Board das Richtige für Dich, die eine
Prozessorarchitektur verwendet, die auch heute noch millionenfach
produziert wird:
Hallo Christoph M. vielen Dank für die Botschaft. So Modern die Risk-Architektur auch ist, ich las da Sachen, die etwas zu Modern sind. -
Da las ich etwas über dem Einsatz von KI und rechtlichen Ansprüchen auf den Prozessor. Aber zum Basteln kann es für mich interessant werden oder sein.
Vieleicht werde ich es mal für Schaltungssteuerungen brauchen.
Auf jeden Fall, noch mal vielen Dank. Der Schriftsteller des Buches läst schreiben:
"Scot W. STevenson programmiert seit Tagen von 8-Bit.Prozessoren wie dem 6502, in Assembler. Vom Bytegeschiebe konnten ihn weder sein Medizinstudium, ein Graduirtenkolleg Jornalismus, mehr als zwei Jahrzehnte als nachrichtenredakteur noch ein Blog über die USA abbringen. Er behauptet trotzdem damit aufhören zu können."
Na, den Schluss von dem Vers, find ich ein bisschen lustig.
Ich erinnere mich, auch etwas von einem 65s02 usw. gelesen zu haben.
Das Buch heist: Einführung in die moderne Assembler-Programmierung.
Habe aber inzwischen auch noch andere gute Sachen gelesen.
LG. Enk
"nur", da muss man sich ja auch noch Gedanken machen,
was die Befehle für die Geräte und was an den Geräten gemacht werden muss.
Also, ich melde mich nochmal,
Aber ich
assoziiere das eher mit einer Einführung in moderne Pferdekutschen.
Wenn du mal extrem zeitkritische Aufgaben mit Controllern lösen musst, dann wirst du das anders sehen... Außerdem hilft einem das Verständnis von Assembler bei vielerlei Compiler-Bockmist...
ich komme gerade aus der Stadt zuück,
und habe nun den Computer: Micro-Professor µP AN EYE TO THE FUTURE
MPF-1B
Dann kann es ja losgehen.
Jetzt habe ich ja noch das Buch: RODNAY ZAGS
Programmierung des
Z80
RODNAY ZAKS
vom SYBEX Verlag.
Das sollte man auch haben, aber das ist eher ein Nachschlagewerk. Für den Einstieg würde ich die Anleitung des MPF-1 durcharbeiten, oder einen der zahlreichen Lehrgänge, die auf dem Gerät basieren. Das Ding war damals zu Ausbildungszwecken sehr verbreitet, bis weit in die '90er Jahre hinein, als wir alle schon "richtige" PCs hatten.
Außerdem hilft einem das Verständnis
von Assembler bei vielerlei Compiler-Bockmist...
Assemblerkenntnisse sind nicht schlecht, um mal einen Blick hinter die Kulissen von C zu werfen.
Es hilft, besser einzuschätzen, welche Operationen besonders teuer sind. Man kann dann vermeiden, sie unnötig häufig aufzurufen und damit kostbare CPU-Zeit zu verplempern.
Man kann aber auch staunen, welche Tricks und Kniffe der Compiler kennt, um effektiver und sparsamer als der weitaus größte Teil der Assemblerfraktion zu coden.
Ab einem bestimmten Leidensdruck, d.h. Anzahl und Größe der Projekte, wird aber irgendwann jeder die Vorteile von C nutzen wollen, um sich nicht mehr mit Nebensächlichkeiten, wie Push, Pop, RAM-Zuweisungen, Pointerberechnungen usw. abplagen zu müssen.
Man kann aber auch staunen, welche Tricks und Kniffe der Compiler kennt,
um effektiver und sparsamer als der weitaus größte Teil der
Assemblerfraktion zu coden.
Wobei es dabei eher um die Kenntnis der Maschinenbefehle und der Mikroarchitektur geht. Man muss dazu nicht in der Lage sein, in Assembler ordentlich zu programmieren.
Und wenn es dann nicht mehr um 6502 oder Z80 geht, sondern Prozessoren mit langer Pipeline und Schlimmerem, hat die Kenntnis der Mikroarchitektur eine entscheidende Bedeutung.
Ab einem bestimmten Leidensdruck, d.h. Anzahl und Größe der Projekte,
wird aber irgendwann jeder die Vorteile von C nutzen wollen, um sich
nicht mehr mit Nebensächlichkeiten, wie Push, Pop, RAM-Zuweisungen,
Pointerberechnungen usw. abplagen zu müssen.
In solchen Fällen wird man Assembler auf Codestücke beschränken, die für die Performance entscheidend sind. Und diese möglicherweise als Inline-Assembler in den C-Quelltext direkt einbauen, nicht als separaten Assembler-Quelltext pflegen.
Und wenn man das durch hat, stellt man anschliessend fest, dass man sich das hätte sparen können :), weil der Compiler schon Intrinsics für in C nicht abbildbare Maschinenbefehle hat. Etwa für die SIMD-Erweiterungen SSE/AVX.
Und wenn es dann nicht mehr um 6502 oder Z80 geht, sondern Prozessoren
mit langer Pipeline und Schlimmerem, hat die Kenntnis der
Mikroarchitektur eine entscheidende Bedeutung.
Ja, Pipelines und Busse. Stete Quelle von Freude.
Ich habe in von einem Compiler generierten Code da schon
Zugriffsverletzungen gesehen. Ein einfach indirekter Ladebefehl
wurde nicht ausgefuehrt, stattdessen wurde eine "0" geladen.
Vermutlich war der Bus ueber den der Zugriff laufen sollte,
einfach nur belegt. Der Compiler sollte das eigentlich erkennen.
Ich habe dann ein kurzes Stueck aus dem Compilat als Inlineassembler
eingegefuegt, und vor dem scheinbar kritischen Zugriff ein NOP
platziert. Das funktionierte dann. :)
Schwierig war nur die Stelle des "Fersagens" zu finden.
Wenn Du auf Seite 2 des Datenblatts der CPU guckst, siehst Du das Programmiermodell der Z80. 8-bit-Akku A, die Flags F, und HL, BC und DE als 16-Bit-Register. Die Z80 hat ein alternativen Registersatz, mit einem Kommando umgeschaltet werden kann (sehr hilfreich).
IX und IX als Index-Register, Stack als Stackpointer.
Das steht in der Dokumentation der CPU. HL ist das Ziel-Register, es hat
16 Bit.
Also, verstehe ich kaum.
Also aus der Speicherstell ...
Moment, um das richtig zu erklären:
Ich habe hier ein Programm mit 72 Speicherplätzen.
Es geht von: 1800 bis 1847.
Es ist ein Uhrenprogramm.
Der 1. Befehl lautet demnach:
Der Maschinenbel 21 sagt:
"Lade die Werte:"0800" in die Register H und L.
Nun steht im 16-Bit-Register 0800.
Der nächste Befehl lautet: 0E. Nun werde ich in der Dokumentation suchen ...
LG. Enk
Natuerlich fehlt der Startup-Code, oder wohin soll der CALL zurueckfinden? Ist alles aus dem Microprofessor Handbuch (ich muss sagen, 1983 hat man sich noch richtig Muehe gegeben verstaendliche Handbuecher zu schreiben. Ohne KI. Vielleicht deswegen).
Bitte, dann würde ich das mal gerne in Linux ausprobieren.
Kann man das in Windows 10 laden, und auf einen Stick oder SD-Karte legen?
(Oder unter Linux aufrufen.)
Doch ich sehe es schon kommen, ich muss mich erstmal, richtig in die einzelnen Befehle hineinknien muss, um das zu verstehen, was da abläuft.
Und das lehrt auch der Kurs von Christiani nicht gründlich genug.
Es ist die Art und Weise, - wie, man das Wissen beibringt. - .
(Ja, meiner Erinnerung nach, hat Christiani einen guten Namen also Ruf.)
Und es ist auch nicht schlecht.
Ich müsste einfach nur anfangen zu lernen, die einfachsten Strukturen
die sich zwischen Speicher und Prozessor ergeben, stattfinden zu lassen. Dann ist man schon wirklich sehr - damit beschäftigt. Ich glaube wohl,
dass ich es danach, besser verstehe.
Und es ist tatsächlich so, die vielen Bilder von einfachen Schaltungen,
sind im Grunde genommen nichts anderes als heute mit vielen Schaltungen.
Um das zu verstehen, hat es natürlich seine Grenzen.
Nur würde ich gerne "sehen" können, wie, was da schaltet.
D.h.: Man muss es sich vorstellen können; - und das geht.
Ich könnte mir auch vorstellen, dass es für die Uhr,
gute Ablauf-Diagramme gäbe. Und nur für die Uhr,
wäre man dann schon für einige Seiten beschäftigt.
Übrigens, die Uhr, ist aus dem Christiani-Lehrgang.
Ja, ich war auch schon mit einem Buch beschäftigt für den 8086.
Assembler Programmierung Studienausgabe, - nur sie Software
passt nicht zum Betriebssystem. Das wird natürlich geändert.
Danach, weiß ich dann auch mehr.
LG. Enk
Und das lehrt auch der Kurs von Christiani nicht gründlich genug.
Du brauchst keinen Kurs, du brauchst noch nicht mal einen Disassembler. Was du brauchst sind ein paar Blatt kariertes Papier, einen Bleistift, ein Radiergummi und das Z80-Buch von Rodnay Zaks. Da steht nämlich drin was jeder einzelne Befehl genau bewirkt und wie er im Arbeitsspeicher kodiert ist.
Und dann nimmst du den Assembler-Quellcode, führst jeden Befehl 'per Hand aus' und notierst dir nach jedem Befehl welche Speicherstellen und Prozessorregister welche Daten/Werte beinhalten.
Nur würde ich gerne "sehen" können, wie, was da schaltet.
Was würdest du gerne sehen? Wie die einzelnen Transistoren des Prozessors hin und her schalten? Oder wie sich nach jeden Befehl die Speicherinhalte ändern?
Günter, ich habe den Eindruck, dass du zu viel gleichzeitig lernen willst. Oder wie man so schön sagt: Man tanzt auf zu vielen Hochzeiten gleichzeitig.
Wenn ich von deinen vielen Fragen mal die herauspicke die ich verstehe, scheinen sich die meisten auf den Befehlssatz der CPU und den Assembler/Disassembler zu beziehen. Dort scheint dein Haupt-Interesse zu liegen, also konzentriere dich darauf.
Lerne zuerst, welche Register die CPU hat und welchem Zweck sie dienen. Danach solltest du dich (wie bereits begonnen) schrittweise mit der Dokumentation des Befehlssatzes befassen. Welche Befehle gibt es, was ist die Quelle, was ist das Ziel, was macht die Operation damit?
Solange zu damit nicht fertig bist, solltest du dich am besten gar nicht mit dem Schaltplan beschäftigen. Der ist für das Verständnis der CPU und ihrer Programmierung fast vollkommen irrelevant. Natürlich ist die Schaltung nötig, damit die CPU überhaupt arbeitet, aber als Programmierer muss man sie nicht kennen.
So wie man als Autofahrer auch keine Ahnung davon haben muss, wie das Auto funktioniert. Man muss nur wissen, wie man das Auto richtig benutzt. Kenntnisse über die Hardware helfen natürlich schon, diverse Eigenschaften besser zu verstehen (z.B. warum kann ich nicht lenken, wenn die Hinterräder rutschen?). Aber das sind Spezialfälle mit denen man sich besser später befasst.
Ich kann auch nur dringend davon abraten, sich mit mehreren CPU Architekturen gleichzeitig zu befassen. Damit verwirrst du dich nur selbst. Sogar wenn du noch aktiv arbeiten würdest, wäre es nicht wichtig, viele CPU Architekturen zu kennen. Eine reicht erst mal. Danach (nicht gleichzeitig!) kann man sich schnell in andere einfinden.
In unser Gehirn passt viel rein, aber die Einfüllöffnung ist im sehr eng und hat eine lange Leitung. Druckbetankung funktioniert nicht.
Nur würde ich gerne "sehen" können, wie, was da schaltet.
Vergiss das. Da passiert so viel gleichzeitig und schnell nacheinander, das kann kein normaler Mensch durchblicken. Schau dir dieses winzige Beispiel für den 6502 an, dann siehst du was ich meine.
http://www.visual6502.org/JSSim/expert.html
1
0xa9, 0x00, // LDA #$00
2
0x20, 0x10, 0x00, // JSR $0010
3
0x4c, 0x02, 0x00, // JMP $0002
4
5
0x00, 0x00, 0x00, 0x00,
6
0x00, 0x00, 0x00, 0x40,
7
8
0xe8, // INX
9
0x88, // DEY
10
0xe6, 0x0F, // INC $0F
11
0x38, // SEC
12
0x69, 0x02, // ADC #$02
13
0x60 // RTS
Das Programm hat nur 9 Befehle. Jeder Klick auf den Pfeil nach rechts entspricht einem einzigen Taktimpuls.
Ein Programmierer muss nicht wissen "was da schaltet", sondern wo die Eingaben her kommen, wo die Ausgaben hin gehen, und was die Befehle dazwischen bewirken. Wie das technisch umgesetzt ist (mit Mikrochips, klappernden Relais oder heißer Luft) soll dem Programmierer ziemlich egal sein. Die elektrischen Vorgänge werden erst bei der Peripherie relevant (Schalter, LEDs, serielle Schnittstellen, ...).
Nehmen wir mal an dir gelingt es, die internen Abläufe eines alten Mikroprozessors zu durchblicken. Was hast du davon? Wie viel davon kannst du wohl bei einem aktuellen Mikrocontroller gebrauchen, deren Innenschaltung stets geheim ist und aus 100 oder gar 1000 mal so vielen Transistoren besteht? Gar nichts! Aber wenn du programmieren gelernt hast, dann hast du etwas, dass du auch auf aktueller Hardware anwenden kannst. (Andere Architekturen haben zwar andere Befehle, aber sie funktionieren sehr ähnlich, so dass man sich da wie gesagt schnell einarbeiten kann).
Nur würde ich gerne "sehen" können, wie, was da schaltet.
Was würdest du gerne sehen? Wie die einzelnen Transistoren des
Prozessors hin und her schalten? Oder wie sich nach jeden Befehl die
Speicherinhalte ändern?
Ja, beides, auch wie der Akkumulator und die ALU angesprochen werden.
Ob Teile vom BIT-Muster vom Byte auf die Leitungseingänge wirken, natürlich auch, wie sich nach jeden Befehl die Speicherinhalte geändert haben, zB. der Stack und das Statusregister mit seinen Flags. In dem Buch von Christiani sehe ich die im µP nicht. Und in dem Buch von Zaks sind mehrere
Obj-Code angegeben, ich brauch doch nur einen pro Befehl.
Günter K. schrieb:
Ja, ich war auch schon mit einem Buch beschäftigt für den 8086.
Ich würde den 8086 für den Anfang nicht empfehlen.
Ja.
rhf
Hallo Roland F.
Du hast sehr gut geantwortet. Ja, Sherlock Du auch,
und habe Eure wirklich gut gemeinten Worte verstanden,
und bin darüber erfreut.
Nun, ja, das Buch zum 8086 war bzw. ist schon sehr Verheißungsvoll,
und es beginnt damit, ein Zeichen auf den Bildschirm zu bringen.
Leider habe ich nicht das Betriebsystem dazu;
das gleiche für GW-BASIC und DOS:
Wolfgang Link (Passender Name zum Assembler :-) )
Zum Buch liegt eine CD und da sind fertige Programme drauf.
Professional Assembler Programmierung
Studienausgabe Ungekürzte Originalausgabe
(... Der Deutschen National-Bibliothek ... http://dnb.ddb.de abrufbar.)
(C) 2004 Franzis Verlag GmbH, 85586 Poing ...DTP-Satz A. Kugge München
ISBN 3-7723-7014-4
Aber erst mal zurück zum Z80; - denn man möchte ja erstmal,
seine eigenen Erfolge sehen.
Und richtig, heute Morgen nach dem Aufstehen dachte ich noch:
"Man müsste erst mal Ablauf-Diagramme Zeichnen.)
Kann der Computer das nicht auch schneller?
Gibt es Computer-Programme zum Zeichnen von Ablauf-Diagramme?
Zurück zum Buch: Programmierung des Z80 von RODNAY ZAKS
Leider ist dessen Leimung sehr alt und die Blätter lösen sich.
Und irgendwo las ich einen Hinweis auf ein anderes Buch von ihm,
dem Prozessor selber betreffend. Ich finde es nicht mehr, will
aber jetzt weitermachen.
LG enk
Wenn ich mich zurück erinnere, was das früher für ein Krampf war mit den Assemblieren (schon Editieren) größerer Files, dann wird mir wieder bewußt wie schön und einfach die Welt mit den modernen Computern ist.
Hier mal ein Beispiel, wie man mit zmac (Z80 Assembler) und z80dasm (Z80 Disassembler) umgeht.
Das Workdir enthält nur einen Assembler-Quelltext. Drin steckt eine kleine Routine zum schnellen Löschen eines Text-Framebuffers mit 25 Zeilen zu je 40 Zeichen an Adresse 0xE000 (so war das auf dem https://de.wikipedia.org/wiki/Z9001).
1
~/Work/zmac $ls
2
clrscr.z
3
4
~/Work/zmac $cat clrscr.z
5
scrpos EQU 0E000h ;start of screen buffer
6
scrlen EQU 40*25 ;screen dimensions
7
8
org 1000h
9
10
;fast clear screen
11
12
clrscr: push bc ;save registers
13
push de
14
push hl
15
16
ld hl,scrpos
17
ld d,h
18
ld e,l
19
inc de ;DE = scrpos + 1
20
ld bc,scrlen-1
21
ld (hl),' '
22
ldir
23
24
pop hl ;restore registers
25
pop de
26
pop bc
27
28
ret
Wir assemblieren das File; dabei entstehen ein Listing und defaultmäßig ein Binärfile mit dem erzeugten Code:
Das Listing zeige ich jetzt mal nicht, das kannst du dir selber ansehen :)
Wir verwenden jetzt z80dasm um das Binärfile zu disassemblieren. Da ein Binärfile keine Startadresse enthält, müssen wir die Startadresse mit "-g 0x1000" angeben.
1
~/Work/zmac $z80dasm -g 0x1000 clrscr.bin
2
; z80dasm 1.1.3
3
; command line: z80dasm -g 0x1000 clrscr.bin
4
5
org 01000h
6
7
push bc
8
push de
9
push hl
10
ld hl,0e000h
11
ld d,h
12
ld e,l
13
inc de
14
ld bc,003e7h
15
ld (hl),020h
16
ldir
17
pop hl
18
pop de
19
pop bc
20
ret
21
Warning: Code might not be 8080 compatible!
Und - voila! - hier ist unser Code wieder. Labels und symbolische Konstanten fehlen natürlich. Aber im Prinzip können wir den Code so wie er ist wieder durch zmac jagen und erhalten das gleiche Binärfile:
Nun, ja, das Buch zum 8086 war bzw. ist schon sehr Verheißungsvoll,
und es beginnt damit, ein Zeichen auf den Bildschirm zu bringen.
Leider habe ich nicht das Betriebsystem dazu;
das gleiche für GW-BASIC und DOS:
Deshalb nochmal mein Tipp: Arbeite mit einer vereinfachten Architektur für die es einen Simulator gibt.
Also ehrlich, meine innere Stimme sagt, daß der "Günter" entweder ein wild gewordener Chat-GPT Bot ist oder ein schon deutlich verwirrter, alter Mann, der tonnenweise Fachbegriffe raushaut, ohne aber sich auf was konzentrieren zu können oder wollen.
Also ehrlich, meine innere Stimme sagt, daß der "Günter" entweder ein
wild gewordener Chat-GPT Bot ist oder ein schon deutlich verwirrter,
alter Mann, der tonnenweise Fachbegriffe raushaut, ohne aber sich auf
was konzentrieren zu können oder wollen.
Das ist richtig. Und dann kommt dazu dass plötzlich jeder C64-Opa hier meint, jetzt sei die Stunde irgendwelchen Kruden Details oder Anekdoten zu Assembler rauszuhauen. Wie hilft das dem TE?
Vielleicht sollte der TE auch nochmal klarstellen was genau sein (Lern)Ziel ist.
Rechnerarchitektur vom Transistor bis zu hochoptimierten Architekturen wird an Hochschulen meist in 2 Semestern gelehrt. Dazu gibt es sicher auch genügend Online-Skripte. Dazu die Standardbücher welche Grundlage solcher Vorlesungen sind.
Nun, ja, das Buch zum 8086 war bzw. ist schon sehr Verheißungsvoll,
und es beginnt damit, ein Zeichen auf den Bildschirm zu bringen.
Leider habe ich nicht das Betriebsystem dazu;
Also ehrlich, meine innere Stimme sagt, daß der "Günter" entweder ein
wild gewordener Chat-GPT Bot ist oder ein schon deutlich verwirrter,
alter Mann, der tonnenweise Fachbegriffe raushaut, ohne aber sich auf
was konzentrieren zu können oder wollen.
Ich denke da irrst du dich. Ich kann mit ihm 100% mitfühlen, denn als ich vor 30 Jahren in der Ausbildung war, wollte ich Computer ebenso detailliert verstehen, wie er. Ich wollte immer zu viel gleichzeitig erforschen, habe mir dabei selbst im Weg gestanden.
Ich hatte allerdings einen guten Ausbilder, der meinen Fokus auf die Sachen gerichtet hat, die ich zum jeweiligen Zeitpunkt begreifen konnte.
Dann schau mal, ob es für dein Linux das Paket 'z80dasm' gibt.
Ja, das werde ich machen.
Ich wollte es für die "Tik Tak Uhr" von Christiani einsetzen.
Es ist aber richtig, was die anderen Kollegen sagen,
Ich muss erstmal näher zu den Befehlen.
Also die Zahlen und das Rechnen kenne ich, auch die Komplementärsubstaktion.
Der Sinn der Offset-Speicherung schon weniger, aber ich gehe davon aus, dass
es funktioniert. Na ja, dann ist es gut so.
Und das hexadezimale Zahlensystem ist sowieso das Bessere.
Befehle: Rollen und Schieben ist auch klar.
Lade-Befehl: LD Ziel, Quelle ist auch ok. (Auch wenns verdreht ist.) OK.
Zum Laden von Regiserinhalten steht auch die indizierte Adressierung zur Verfügung. - Ja, damit das was irgendwo steht geladen werden kann, ist auch zu verstehen. - Weiter lesen abwarten.
LG. Enk
Und das hexadezimale Zahlensystem ist sowieso das Bessere.
Verstehe ich nicht!
Für mich ist das Hex Dingen nur eine von vielen möglichen
Repräsentationen/Darstellungen von Daten.
Na ja, beim Hexadezimalen macht beim Addieren, bei jedem Bit
einen Überlauf (Wenn es dran ist, d.h. 1+1).
Im BCD-Code muss man aber bei der 9+1, 6 hinzuzählen um 10 zu erhalten.
Sehr umständlich. Da werden knapp 30% "verschenkt".
Zum Glück, passen diese Zeichen in den 7-Segment-Code.
LG. Enk
Also ehrlich, meine innere Stimme sagt, daß der "Günter" entweder ein
wild gewordener Chat-GPT Bot ist oder ein schon deutlich verwirrter,
alter Mann, der tonnenweise Fachbegriffe raushaut, ohne aber sich auf
was konzentrieren zu können oder wollen.
Ich denke da irrst du dich. Ich kann mit ihm 100% mitfühlen, denn als
ich vor 30 Jahren in der Ausbildung war, wollte ich Computer ebenso
detailliert verstehen, wie er. Ich wollte immer zu viel gleichzeitig
erforschen, habe mir dabei selbst im Weg gestanden.
Vielleicht bist du ja auch ein wild gewordener Chat-GPT Bot und weisst es nur nicht?
Na ja, beim Hexadezimalen macht beim Addieren, bei jedem Bit
einen Überlauf (Wenn es dran ist, d.h. 1+1).
Im BCD-Code muss man aber bei der 9+1, 6 hinzuzählen um 10 zu erhalten.
Sehr umständlich. Da werden knapp 30% "verschenkt".
Zum Glück, passen diese Zeichen in den 7-Segment-Code.
Auch wieder eine super zielführende Diskussion jetzt.
Und das hexadezimale Zahlensystem ist sowieso das Bessere.
Verstehe ich nicht!
Für mich ist das Hex Dingen nur eine von vielen möglichen
Repräsentationen/Darstellungen von Daten.
Und wenn man die Opcodes von 8080/Z80 studiert, ist man Oktal oft besser
bedient als Hexadezimal. Auch die Codierung von PDP11 und 68000 zeigte
das.
Ja, auch interssant.
Und die Kinder bräuchten das 1x1 nur bis 64 lernen. :-))
Der Nachteil, die Ziffernketten bei den Zahlen würden viel länger.
LG. Enk
Und die Kinder bräuchten das 1x1 nur bis 64 lernen. :-))
Der Nachteil, die Ziffernketten bei den Zahlen würden viel länger.
Da die 8080 keine relative Sprünge kennt, kann man darin vergleichsweise einfach direkt in Oktal programmieren, wenn einem Assembler zu abstrakt ist. Bei 6502 und Z80 geht das nicht so einfach.
Nun, ja, das Buch zum 8086 war bzw. ist schon sehr Verheißungsvoll,
und es beginnt damit, ein Zeichen auf den Bildschirm zu bringen.
Leider habe ich nicht das Betriebsystem dazu;
Lustig! Ich nehme an es an es ist ein Scherz. :-))
Die Programme zu diesem Buch werden zwar geladen,
laufen aber nicht, weil das Windows-Betriebsystem zu hoch ist.
Vermutlich unter DOS. Das kann WINDOS 10 nicht mehr.
Und wenn durch das Assembler (Also nicht der eigentliche selbst s.u.)
Ein Zeichen auf den Bildschirm gebracht werden soll,
dann darf an dieser Stelle auf dem Bildschirm nichts anders stehen.
Doch auch sich das nur vorzustellen.
Ist da die Rede von "Direktiven" (Anweisungen an den Assembler).
Inzwischen ist mir klar.
Die Assemblerliste alleine kann gar nicht assemblieren,
denn es braucht ja noch ein Programm das Assembliert,
also den eigentlichen *Assembler.
Eigentlich müsste das *Assemblerprogamm müsst vor der Assemblerliste gehängt werden, damit man sich vorstellen kann, wie der *Assembler Assembliert hat,
und könnte mir ebenso vorstellen, dass dieser Assembler Fehler findet.
LG. Enk
Und die Kinder bräuchten das 1x1 nur bis 64 lernen. :-))
Der Nachteil, die Ziffernketten bei den Zahlen würden viel länger.
Da die 8080 keine relative Sprünge kennt, kann man darin vergleichsweise
einfach direkt in Oktal programmieren, wenn einem Assembler zu abstrakt
ist. Bei 6502 und Z80 geht das nicht so einfach.
Interssant, bin mal gespannt was da noch kommt.
Ja gerade Assembler ist mir am wenigsten abstrakt.
wagen. Und dann wieder zurück zum Know-How-Computer. Dann bestellst du dir mal ein paar Breadboards und Logik-Bausteine vom Typ 74xx00P und für jeden einen 10nF-Kondensator, ein 5-Volt-Netzteil, ein paar Jumperkabel, ein paar 1k-Widerstände, ein paar rote LEDs und ein paar Taster, und schon ist es elektronisch. Die ersten "CPUs" waren genauso aufgebaut.
Wenn du dann irgendwann bereit bist fürs "echte Leben", hast du schonmal eine Spannungsversorgung, Breadboards und Jumperkabel. Und dann kaufst du dir einen µC, also so einen super winzigen Chip, zum Lernen ohne Tamtam auf einem Breakout-Board wie diesem hier:
Der Unterschied zwischen Maschinensprache und Assembler ist so gut wie keiner, außer dass viele Assembler Makros unterstützen. Zum Beispiel gibt es in Assembler (egal für welchen Proz) keine Schleifen, sondern nur Sprunganweisungen. Assembler und Maschinencode sind (wie gesagt, bis auf Makros) 1:1. Assembler unterscheiden sich nur in der Schreibweise und sind architektur-abhängig. Bei manchen Prozessoren heißt ein unbedingter Sprungbefehl JP, beim nächsten JMP, beim nächsten JUMP. Das ist so, wie ein Apfel auf Englisch Apple und auf Spanisch Manzana heißt, aber immer noch ein malus domestica ist.
Und weil Assembler so architektur-abhängig sind, hat man Programmiersprachen erfunden, etwa die Sprache "C" (https://de.wikipedia.org/wiki/C_(Programmiersprache)). Die meisten C-Compiler beherrschen die Fähigkeit, auch Assemblercode zu verstehen.
Modernere Programmiersprachen wie etwa Python, Java, C# etc sind dazu da, Probleme abstrakter lösen zu können, am besten so, dass sie eben nicht nur auf einem speziellen µP lösbar sind, sondern auf egal welchen. Hierzu gibt es dann so genannte "Runtimes", die dies ermöglichen.
Software-Entwicklung heutzutage geht eben nicht mehr so: "Ich möchte, dass der Pin 2 vom µC xyz auf 5V geht", sondern so: "Ich möchte, dass das Licht hier im Raum je nach Uhrzeit mit kälterer oder wärmerer Lichttemperatur an geht, und mein Lieblingssong soll auch gespielt werden!"
So gesehen ist das Verstehen von Bauteilen, vom Widerstand bis zu einer GPU, wichtig, eine Grundlage. Darum bin ich ja auch hier, weil ich so viele analoge Bauelemente eher anschaue wie "Hä? Wer bist du denn, und was machst du da??" ^-^
Lustig! Ich nehme an es an es ist ein Scherz. :-))
Eigentlich nicht.
Doch, das ist ein Scherz. Mit einem modernen OS hat das sicher nichts zu tun. Es liest sich wie von einem alten Herrn, der Class D-Verstärker für Teufelszeug hält und nachts mit einer Röhre kuschelt.
oh, da hast Du Dir ja wirklich große Mühe gegeben, dem Günter (und vermutlich nicht nur dem) den Weg und die entsprechenden Ressourcen zu zeigen. Klasse!
Aber erst mal zurück zum Z80; - denn man möchte ja erstmal,
seine eigenen Erfolge sehen.
Wie gesagt Papier, Bleistift, Radiergummi besorgen und dann Kapitel für Kapitel im Z80-Buch durcharbeiten.
Oder du besorgst dir einen Z80-Simulator (z.B. https://www.heinpragt-software.com/z80-processor-ide/). Das hat den Vorteil, das du dir direkt ansehen kannst was du da so programmiert hast. Und konzentriere dich für den Anfang auf das Assemblerprogramm, welcher Hex-Code daraus letztlich vom Assembler erzeugt wird ist erstmal unwichtig.
Der Unterschied zwischen Maschinensprache und Assembler ist so gut wie
keiner, außer dass viele Assembler Makros unterstützen.
So ein Käse! Maschinensprache sind reine (HEX)zahlen! Assembler sind menschenlesbare Befehle, wenn gleich meist abgekürzte, englische Worte.
Auch wenn Assembler praktisch 1:1 in Maschinensprache übersetzt wird, liegen Welten dazwischen. Auch eben weil das Programm "Assembler" viele nützliche bzw. notwendige Hilfskonstruktionen bereitstellt, sei es zur Definition von Variablen oder diverse Assemblerdirektiven!
Lustig! Ich nehme an es an es ist ein Scherz. :-))
Eigentlich nicht
Ok,meine Antwort war in der 5. Zeile. ">> Lustig! ... "
Ich hatte es nur flüchtig überflogen.
Und eben gründlich durchgelesen. - Tatsächlich wäre das, wirklich zuviel für mich.
Allerdings finde ich es von Vorteil, dann bei mehreren Prozessoren
wenn andere Prozessoren etwas tun, wenn man dadurch, - andere Programme, evtl. einfacher zu gestalten kann.
Allerdings bin ich ja noch nicht am Anfang angekommen.
Ich weiß zwar schon einiges, ist aber lange noch nicht ausreichend.
LG Enk.
PS.:
Jetzt lese ich erst mal die nächsten Beiträge durch,
und dann möchte ich noch auf einen, den mit dem Progrämmle
vom Manual eingehen. Ich kann zwar kein Englisch oder nur sehr schlecht;
das werde ich (vielleicht) - irgendwie auch noch hinkriegen.
Aber auch einen passenden Emulator der CPU auf einen anderen Computer.
Interessant wäre noch, wie der Akkumulator von innen arbeitet; - alles
in der CPU sollte sichtbar sein.
Auch der Intel 4004 ist ein schönes Studierprojekt.
Auch die Computergeschichte hilft weiter.
Assembler sind einfach nur Merkwörter für Opcodes. Beim Intel ist auch toll, wenn die Jump-Befehle (Hexcodes) 7B(Jump if Lower) oder 7E (Jump bei Gleichheit) oder 7A (Jump wenn drüber) oder 7C (Jump bei 0 oder "JL" oder wie auch immer) usw. heißen.
Ein Sprung ist einfach, Schritte im Programmcounter nach vorne zu überspringen, oder eben rückwärts ein oder mehrere Schritte zurückspringen
Assemblerdirektiven sind einfach eine Formatregelung, die kann man vergleichen mit: auf welchen Papier man schreiben soll. A5, A4, Schönschrift, Gedruckt usw.
Nur eben bezogen auf eine voreingestellte Programmstruktur.
Intern werden fertige (geschriebene) Programme in einen flüchtigen Speicher geschrieben bzw. dahinein übersetzt, und dann werden die schrittweise mit einem internen Programmzähler abgearbeitet.
Interrupt-Listen beim 8086 sind einfach nur Links zu einem komplexeren Unterprogramm, teilweise zu Treibern, oder zu grundlegenden oder wichtigen Betriebssystemfunktionen.
Man kann sich das in etwa so vorstellen: Jemand hat ein ganzes großes Hochhaus für sich alleine, und fängt von unten an, sich eine Etage höher zu arbeiten. Auf Jeder Etage werden die Lichter für die Fenster nach draußen individuell eingestellt.
Was man dann sehen kann, sind verschiedene Lichtbilder am Hochhaus. Sehr viel anders als die echten Schaltungen in den Schaltkreisen sind die auch nicht. Und eine große Hilfe diesbezüglich sind auch (binäre) Wertetabellen.
Einen 6502 Emulator habe, ne hatte ich mal auf dem Handy - (in Java geschrieben) - würde aber nicht sagen, dass das so für sich so toll ist. Bringt irgendwie nicht viel, wenn man die Originalzeiten, und Hardware, Zeitschriften usw. nicht um sich hat.
Ein C64-Konsole (auf dem Handy) ist so für sich auch nicht unbedingt so der Bringer.
Man versteht das ganze auch viel besser, wenn man vorher schon mal ein paar komplexere Platinen hergestellt oder verlötet hatte.
Günter K. (enk)
Hallo Thomas W.
ist das das Progrämle aus dem MP-1?
1
18.10.2024 17:38
Hallo Thomas W.
ist das das Progrämle aus dem MP-1?
Ich werde langsam Müde,
bei der Beantwortng einiger Beiträge habe ich mich verhäddert.
Danke Euch allen, ich melde mich wieder; - da sind aber noch
wirklich gute Ratschläge von Euch, die ich wirklich noch
bearbeiten möchte - DANKESCHÖN
Aber erst mal zurück zum Z80; - denn man möchte ja erstmal,
seine eigenen Erfolge sehen.
Wie gesagt Papier, Bleistift, Radiergummi besorgen und dann Kapitel für
Kapitel im Z80-Buch durcharbeiten.
... usw.
Nochmal, vielen Dank Euch allen,
ich hatte mich schon bei der Beantwortung der Fragen verheddert.
Erstmal gute Nacht, morgen habe ich viel Hausarbeit.
Ich melde mich wieder.
VIELEN DANK auch für die VIELEN GUTEN RATSCHLÄGE!
Es sind wirklich gute neue interssante Sachen dabei!
Derzeit bin ich hin und hergerissen, ob ich ein System mit 68000 aufbaue. Tatsächlich habe ich aber keine wirkliche Verwendung dafür. Aber wollen würd' ich schon gerne.
Allerdings gibt es dort kein X,Y,A ...
Ansonsten könnte ich mir für den TO auch ein 8032 -mit externem ROM und RAM- vorstellen. Damit kann man sowohl von-Neumann-Architektur, als auch Harvard-Architektur, sogar gemischt oder umschaltbar, betreiben.
Vorteil: Timer und UART sind schon an Board.
Was auch helfen kann, ist sich Lernvideos auf Youtube anzuschauen.
Hier ist eines: https://www.youtube.com/watch?v=_J4ahkWtNYw
In Deutsch scheint es allerdings weniger Videos zu geben.
Derzeit bin ich hin und hergerissen, ob ich ein System mit 68000
aufbaue. Tatsächlich habe ich aber keine wirkliche Verwendung dafür.
Aber wollen würd' ich schon gerne.
Allerdings gibt es dort kein X,Y,A ...
Ich hatte mir auch mal ueberlegt, ein 68020-System zu bauen (32bit muss sein). Dann wurde mir klar, dass der Verdrahtungsaufwand schon recht heftig ist bei einem 32bit System. Deswegen habe ich es gelassen.
Aber: 68008 gibt es ja auch, und sogar einen Bausatz:
Assembler sind einfach nur Merkwörter für Opcodes.
Ja, ganz einfach weil sich normale Menschen Wörter deutlich besser merken können als reine Zahlen. Erst recht, wenn sie sich an natürlicher Sprache orientieren, denn die behrrscht der Mensch schon.
Bei Autisten ist das anders.
Man versteht das ganze auch viel besser, wenn man vorher schon mal ein
paar komplexere Platinen hergestellt oder verlötet hatte.
Unsinn! Um Digitaltechnik zu lernen und zu verstehen muss man nicht VORHER Hardwerker werden. Man wird es bestenfalls HINTERHER.
Man versteht das ganze auch viel besser, wenn man vorher schon mal ein
paar komplexere Platinen hergestellt oder verlötet hatte.
Voraussetzung ist die Fähigkeit zu prozeduralem Denken, also in klar definierten Abläufen. Manche Menschen sind darin sehr gut. Anderen kannst du eine blitzsaubere Anleitung vorsetzen, und sie schaffen es nicht, sie Schritt für Schritt abzuarbeiten, sondern fangen mitten drin an und springen wild drin herum.
Keine generelle Voraussetzung ist jedoch, sich die Vorgänge in realen Elementen wie schaltenden Transistoren und leuchtenden LEDs vorzustellen. Das ist nur bei jenen Menschen nötig, denen die Fähigkeit zur Abstraktion schwach ausgeprägt ist. Denen es hilft, sich das in realen Vorgängen vorzustellen.
"Da die Zahlenwerte der Opcodes schwierig zu merken sind, verwenden Assemblersprachen leichter merkbare Kürzel, sogenannte mnemonische Symbole (kurz Mnemonics)."
