Z80 OUT (C) mit Register A belegen.

Einmal Belegen reicht wen kein Interrupt dazwischen funkt und das A Reg 
ändert.

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 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.

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

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.

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.

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...

... 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....

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

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.

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

Und hier noch einen ZX-Spectrum Emulator auf einem STM32F407: 
STECCY. Der kann auch alle undokumentierten Opcodes des Z80. :-)

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.

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 :-)

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"

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

>
> 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.