Hallo, guten Tag. Muss man das Register A bitte immer neu belegen oder reicht es zum Anfang nur einmal ? PS : out (c),0 funktioniert nicht. Danke. ld a,0 out (c),a ld a,0 out (c),a ld a,0 out (c),a ld a,0 out (c),a
Einmal Belegen reicht wen kein Interrupt dazwischen funkt und das A Reg ändert.
:
Bearbeitet durch User
Patrick L. schrieb: > wen kein Interrupt dazwischen funkt und das A Reg > ändert. Da hilft dann auch das mehrfache Laden nicht dagegen. Ein Interrupt muß alle verwendeten Register sichern.
Peter B. schrieb: > PS : out (c),0 funktioniert nicht. Befehle die es nicht gibt funktionieren auch eher selten. Georg
Peter D. schrieb: > Ein Interrupt muß alle verwendeten Register sichern Ja nur tun das die Programmierer nicht Immer, weil es gerne Vergessen geht. und der Z80 wie die Meisten µP's machen dies nicht automatisch. ;-) In der regel wird nur SR automatisch gesichert und bei einem (RETI) wieder hergestellt.
:
Bearbeitet durch User
Patrick L. schrieb: > Ja nur tun das die Programmierer nicht Immer, weil es gerne Vergessen > geht. Daher wurden Compiler erfunden, die sich um sowas kümmern. Niemand quält sich heutzutage noch mit Assembler ab.
Peter D. schrieb: > Da hilft dann auch das mehrfache Laden nicht dagegen. > Ein Interrupt muß alle verwendeten Register sichern. Das ist zu unpräzise. Genauer wäre: "Der Interrupt-Handler muss alle Register sichern, die nicht für seine exklusive Verwendung bestimmt sind, aber trotzdem durch ihn verändert werden. Vor dem Verlassen des Interrupt-Handlers müssen die ursprünglichen Inhalte dieser Register wiederhergestellt werden." Die durchaus halbwegs verbreiteten ARM-Prozessoren haben z.B. einige eigene Register für den FIQ-Handler. Diese müssen natürlich im Allgemeinen nicht gesichert werden, damit deren Inhalte ggf. für den nächsten Aufruf zur Verfügung stehen.
Peter D. schrieb: > Niemand quält sich heutzutage noch mit Assembler ab. Ähm da gibt es aber hier im Forum noch einige (Herr Niemand) die sich das "Quälen" antun ;-)
Ich habe den Z80 praktisch nur in Assembler programmiert. Schöne CPU... Das hier funktioniert übrigens:
1 | ld a, 0h |
2 | out (0ch), a |
3 | out (0bh), a |
Patrick L. schrieb: > Peter D. schrieb: >> Niemand quält sich heutzutage noch mit Assembler ab. > > Ähm da gibt es aber hier im Forum noch einige... Laß mal, dem Peter D. hängen diese Trauben nur zu hoch. Also erklärt er sie für zu sauer. Peter B. schrieb: > out (c),0 funktioniert nicht Und was - bittesehr - funktioniert da nicht? Mir ist klar, daß es bei der zu verwendenden Schreibweise da je nach verwendetem Assembler diverse Unterschiede geben kann. Aber in deinem Falle frage ich dich, ob es einen tieferen Grund gibt, weswegen C nicht mit der Adresse geladen wird. W.S.
W.S. schrieb: > Und was - bittesehr - funktioniert da nicht? Es gibt OUT (Portadresse), Akku und OUT (Portadresse im C-Register), Registerwert andere Varianten sind nicht vorgesehen.
Georg G. schrieb: > andere Varianten sind nicht vorgesehen Mir ist das klar, allerdings erinnere ich mich, auch schon mal einen Assembler gesehen zu haben, bei dem das im Mnemonik unterschieden war: OUT Adresse OUTC W.S.
Beitrag #6800320 wurde vom Autor gelöscht.
W.S. schrieb: > Mir ist das klar, allerdings erinnere ich mich, auch schon mal einen > Assembler gesehen zu haben, bei dem das im Mnemonik unterschieden war: > OUT Adresse > OUTC Dann handelt es sich nicht um die offizielle Assembler-Definition, wie sie durch den Prozessorhersteller vorgegeben ist.
Georg G. schrieb: > Es gibt > OUT (Portadresse), Akku > und > OUT (Portadresse im C-Register), Registerwert > andere Varianten sind nicht vorgesehen. Falsch! Es gibt noch OUTD, OTDR, OUTI, OTIR und die entsprechenden IN für die Gegenrichtung. Bemerkenswert ist: obwohl es sich um 8-Bit Operationen handelt, ist genau definiert, was auf den obereren Adressbits (A8-A15) passiert. Man kann so mit einem Befehl 24 Bits geziehlt setzen.
Andreas S. schrieb: > W.S. schrieb: >> Mir ist das klar, allerdings erinnere ich mich, auch schon mal einen >> Assembler gesehen zu haben, bei dem das im Mnemonik unterschieden war: >> OUT Adresse >> OUTC > > Dann handelt es sich nicht um die offizielle Assembler-Definition, wie > sie durch den Prozessorhersteller vorgegeben ist. Beim Z80 ist es allerdings weit verbreitet, dass verschiedene Assembler jeweils ihren eigenen Dialekt der Syntax verwenden.
Route_66 H. schrieb: > Es gibt noch OUTD, OTDR, OUTI, OTIR Das sind Varianten des "OUT (C), Registerwert" mit der Einschränkung, dass als Registerwert immer (HL) genommen wird. Die vom TO versuchte Variante "OUT (C), Immediate" gibt es nicht. Der Z80 hat noch diverse nicht dokumentierte Befehle. Aber um die geht es hier nicht. Denn es ist nicht sicher, dass die von allen Herstellern implementiert wurden.
Wer sich heute immer noch! mit Assembler abquält, der wird es in diesem Leben auch nicht mehr schaffen. Für ihn wurden ja eh die "Hochsprachen" erfunden, so dass auch er in wenigen Tagen seine rote LED zum Blinken bringen kann :-) Gruß Rainer
Philipp Klaus K. schrieb: > Beim Z80 ist es allerdings weit verbreitet, dass verschiedene Assembler > jeweils ihren eigenen Dialekt der Syntax verwenden. Der Grund dafür war, dass Intel sich Mnemonics schützen liess. Notgedrungen mussten andere Hersteller dann eigene Namen erfinden. Das führte zu diversen Kuriositäten. Speziell Siemens muss hier erwähnt werden. Beispiel Kellerspeicherzeiger, abgekürzt SP.
Peter B. schrieb: > out (c),0 funktioniert nicht. Ganz vergessen: Das ist die einzige Ausnahme, die es doch gibt. Der Opcode ist 0xed, 0x71.
Der Begriff Kellerspeicher ist weit älter als die Z80. Was hältst du von "Bringe" statt "Move"? Telefunken Assembler. Rest ähnlich.
:
Bearbeitet durch User
Georg G. schrieb: > Speziell Siemens muss hier erwähnt > werden. Beispiel Kellerspeicherzeiger, abgekürzt SP. Siemens hatte aber auch bei den klassischen Prozessrechnern, z.B. R10, eine sehr spezielle Ausdrucksweise. Ich rätselte mal beim Lesen der Dokumentation wochenlang herum, was denn eine Prozesssignalformersteuerung sein sollte. . . . . . . . Spoiler . . . . . . . Interface
Georg G. schrieb: > Speziell Siemens muss hier erwähnt > werden. Beispiel Kellerspeicherzeiger, abgekürzt SP. Wobei das mit dem Kellerspeicher aber schon vom deutschen Erfinder der Stackdatenstruktur F.L. Bauer selbst kam. Damals war noch nicht ganz soviel denglifiziert...
Die echten Z80-Profis wissen aber auch, dass ein OUT (C),A das komplette BC-Register auf den Adressbus legt. Falls Mann mal mehr als 256 IO-Ports braucht...
... schrieb: > Falls Mann mal mehr als 256 IO-Ports braucht... Jep und das wurde bei Synthesizern auch genutzt ;-) Herlich diese Dinger. Neben dem 65C02 65SC802, 65SC816 und dem leider nur als Muster verfügbaren WDC 65C832 waren die Z80 und Z280 meine Lieblings CPU's. Beim Z80 liebte ich dass die Gesamten Register doppelt vorhanden sind. Leider gab es kein direkten Befehl um festzustellen welches Registerset grad das aktive war. So musste man tunlichst darauf achten den "Überblick" zu behalten. Ich habe dann in Unterprogrammen/Interrupt's immer das 2te Set verwendet und konnte viel Zeit sparen, weil ich sie nicht Sichern und Wiederherstellen musste. Lang ist's heer....
:
Bearbeitet durch User
Patrick L. schrieb: > Beim Z80 liebte ich dass die Gesamten Register doppelt vorhanden sind. > Leider gab es kein direkten Befehl um festzustellen welches Registerset > grad das aktive war. Nö! Vielleicht meinst du die IX-Register. Aber wenn du diese vorher benutzt hast, mußt du die auch sichern.
michael_ schrieb: > Patrick L. schrieb: >> Beim Z80 liebte ich dass die Gesamten Register doppelt vorhanden sind. >> Leider gab es kein direkten Befehl um festzustellen welches Registerset >> grad das aktive war. > > Nö! > Vielleicht meinst du die IX-Register. > Aber wenn du diese vorher benutzt hast, mußt du die auch sichern. Patrick hat recht, michael_ schreibt Stuss. Es gibt 2 Registersätze mit BC,DE,HL die per EXX umgeschaltet werden. Ausserdem gibt es IX und IY, aber nur jeweils einfach, da wird nichts umgeschaltet. Gruss
Das sind aber nicht alle Register. Im Interrupt muß man die trotzdem sichern.
Also...Register muß man immer sichern...das war so, das ist so und das wird auch immer so bleiben. Das der oder der da Konstrukte eingebaut hat, die das erleichtern ist doch auch nix neues. Warum also diese Discussion??? Um all die alten Dinosaurier mal kurz wachzurütteln? Dazu schaut man sich heute Granddad der Simpsons an... :-) Gruß Rainer
Rainer V. schrieb: > Also...Register muß man immer sichern...das war so, das ist so und das > wird auch immer so bleiben Selbstverständlich muss eine ISR nur die Register sichern und wiederherstellen, die in der ISR benutzt werden, und keineswegs alle. Georg
Wikipedia zeigt eine ganz schöne Graphik wo man darin sieht welche Register doppelt vorkommen. https://de.wikipedia.org/wiki/Zilog_Z80 (Poste jetzt nicht alle Bilder sondern direkt den Link dort hin) Auch wird dort auf die Undokumentierten Befehle hingewiesen, welche die 16 Bit Index Register nur die obere bzw. untere Hälfte von IX bzw. IY als 8-Bit-Register zu verwenden. Diese Funktionen wurden im legendären ZX81 auch im "BIOS" verwendet, um den Bildaufbau zu realisieren, was bei den ersten Z80 Emulatoren zu Problemen führte da die Undokumentierten Befehlen nicht emuliert wurden.
:
Bearbeitet durch User
Georg schrieb: > Selbstverständlich muss eine ISR nur die Register sichern und > wiederherstellen, die in der ISR benutzt werden, und keineswegs alle. > > Georg Kannst du den Eimer Wasser jetzt endgültig mal auskippen??? Rainer
Beitrag #6800754 wurde von einem Moderator gelöscht.
Ich liebe das Arduino-System. Hier eine Z80 Library dafür: https://github.com/MohammedRashad/ArduZ80 Endlich darf man Z80 Assembler ohne Hindernisse auf dem Arduino ausführen ;-)
Und hier noch einen ZX-Spectrum Emulator auf einem STM32F407: STECCY. Der kann auch alle undokumentierten Opcodes des Z80. :-)
>Und hier noch einen ZX-Spectrum Emulator auf einem STM32F407: >STECCY. Der kann auch alle undokumentierten Opcodes des Z80. :-) Tja ... github wäre nicht schlecht ... wget https://www.mikrocontroller.net/svnbrowser/steccy/?view=tar -O steccy.tgz --2021-08-26 10:47:15-- https://www.mikrocontroller.net/svnbrowser/steccy/?view=tar Auflösen des Hostnamens www.mikrocontroller.net (www.mikrocontroller.net) … 2606:4700:20::681a:cfa, 2606:4700:20::ac43:462c, 2606:4700:20::681a:dfa, ... Verbindungsaufbau zu www.mikrocontroller.net (www.mikrocontroller.net)|2606:4700:20::681a:cfa|:443 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found 2021-08-26 10:47:15 FEHLER 404: Not Found.
Markus schrieb: > wget https://www.mikrocontroller.net/svnbrowser/steccy/?view=tar -O > steccy.tgz Keine Ahnung, wie Du auf die alte Adresse zum Download kommst. Steht die noch irgendwo im Artikel? Der Source ist schon seit längerem auf github: https://github.com/ukw100/STECCY EDIT: Habs gefunden, werde die Stelle im Artikel aktualisieren. EDIT2: Installationsanleitung ist nun an github angepasst.
:
Bearbeitet durch Moderator
>Keine Ahnung, wie Du auf die alte Adresse zum Download kommst. Steht die >noch irgendwo im Artikel? Ja, steht im Artikel. Hier wäre es vielleicht gut, die Installationsanleitung aus dem Artikel zu nehmen und auf das GitHub Verzeichnis zu verlagern. Dann ist die Chance höher, dass sie aktuell bleibt.
Markus schrieb: > Hier wäre es vielleicht gut, die > Installationsanleitung aus dem Artikel zu nehmen und auf das GitHub > Verzeichnis zu verlagern. Die Installationsanleitung (für Linux) war schon seit Anfang an im Readme.md auf Github. Dort war auch eine korrekte Github-Download-URL angegeben. Von daher ist alles in Ordnung :-)
Apropos .. Ich habe mir gerade mal die CPU angeschaut: https://github.com/ukw100/STECCY/blob/main/src/z80/z80.c Über 8000 Zeilen Code ... ganz schön viel. Wenn ich mir eine Bemerkung zum Interface der CPU erlauben dürfte: Ich finde es gut, wenn die Module sehr lose gekoppelt sind. Hier finde ich zu viele Abhängigkeiten der CPU von den anderen Modulen wie RAM, IO usw. Wenn man die Komponenten via Call-Back anmelden würde, wäre die CPU ziemlich transportabel. In deinem Beispiel könnte man sich dann das #define für den STM32 sparen und die CPU für beliebig andere Projekte verwenden.
Markus schrieb: > Hier finde ich zu viele Abhängigkeiten der CPU von den anderen Modulen > wie RAM, IO usw. Ja, das stimmt. Es ging mir halt um die Emulation eines ZX-Spectrum und nicht unbedingt um die Emulation eines nackten Z80. > Wenn man die Komponenten via Call-Back anmelden würde, wäre die CPU > ziemlich transportabel. Ja, ich weiß, man könnte z80.c noch weiter abspecken und das ganze Wissen rund um die Peripherie (Screen, RAM, ZX-ROM-Hooks, Snapshots, Tape-IO, Serial-IO usw.) eines ZX Spectrum auslagern. Mache ich mal, wenn ich ganz viel Zeit habe :-) Aber das wird Offtopic hier. Es gibt einen STECCY-Thread: Beitrag "STECCY - ZX-Spectrum-Emulator mit STM32"
:
Bearbeitet durch Moderator
Rainer schrieb: >Wer sich heute immer noch! mit Assembler abquält, >der wird es in diesem Leben auch nicht mehr >schaffen. Für ihn wurden ja eh die "Hochsprachen" >erfunden, so dass auch er in wenigen Tagen seine >rote LED zum Blinken bringen kann :-) Gruß Rainer Nicht alle prozessoren bringen GBytes Speicher so man .net, java oder irgendwelches anderes Bloatware nutzen kann. Millonen Microprozessoren haben so wenig speicher daß man nicht mal im C alles machen kann. Denkt an alle die 8051 (Unkraut vergeht nicht) basierten Geräten rum herum. Die "oprimizing C compiler" die dafür gibt sind ja meh, willst du nicht wissen wie schlecht die sind, abgesehen von der Idee dafür ein C compiler zu machen... wenn jedes Zyklus zählt or Zent dann Assembly ist der Weg. Nur weil es 2¢ kostet pro > 1M anstatt 3¢, manchmal sind nicht die Kosten des Kernes aber der Speicherblöcke und fläche...
Alex schrieb: > Millonen Microprozessoren haben so wenig speicher daß man nicht mal im C > alles machen kann. Sapperlot. Aber LED-Blinken geht ja "Gott sei Dank"... Gruß Rainer
Rainer V. schrieb: > Sapperlot Naja - ich hatte mal einen jungen Kollegen, der bei einem kleinen PIC10 meinte "ich wüßte nicht, warum ich den nicht in C programmieren sollte". Tja, so sind die Leute heute. Hier auch: Peter D. schrieb mal, daß man zum setzen eines Portpins eine Bibliotheksfunktion bemühen sollte (und nicht das poplige Bit selber setzen). W.S.
> > Nicht alle prozessoren bringen GBytes Speicher so man .net, java oder > irgendwelches anderes Bloatware nutzen kann. > Millonen Microprozessoren haben so wenig speicher daß man nicht mal im C > alles machen kann. Denkt an alle die 8051 (Unkraut vergeht nicht) > basierten Geräten rum herum. Die "oprimizing C compiler" die dafür gibt > sind ja meh, willst du nicht wissen wie schlecht die sind, abgesehen von > der Idee dafür ein C compiler zu machen... wenn jedes Zyklus zählt or > Zent dann Assembly ist der Weg. Nur weil es 2¢ kostet pro > 1M anstatt > 3¢, manchmal sind nicht die Kosten des Kernes aber der Speicherblöcke > und fläche... Da geht es weniger um Speichergröße, mehr um die Architektur. Wenn die Architektur gut für C geeignet ist, spricht nichts dagegen, selbst sehr kleine µC in C zu programmieren. Man betrachte den Benchmark Dhrsystone 2.1, mit SDCC kompiliert, einmal für einen STM8 (ATM8AF5288 bei 16 MHz), einmal für MCS-51 (C8051F120 bei 98 MHz). Da ist der Score des STM8 fast doppelt so hoch wie der des MCS-51, während die Codegröße des STM8 etwa die Hälfte derer des MCS-51 ist.
Peter B. schrieb: > out (c),0 funktioniert nicht. Es gibt keinen OUT IMMEDIATE Befehl auf dem Z80. Du brauchst irgendein Register für den Wert, das muss nicht A sein, und das C Register für die Portadresse. https://www.cpcwiki.eu/index.php/Z80_-_undocumented_opcodes ABER: Es gibt undokumentierte Befehle in der Original Z80, darunter OUT (C),0 ED 71 Output 0 to port Eine 0 kann man also ausgeben ohne das A-Register zu verwenden. Ob das auf den ganzen Nachfolge-Z80, wie EZ80 funktioniert, ist zweifelhaft. http://www.z80.info/z80undoc.htm
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.