letzter Beitrag von mc71 am
Auch wenn sich die Frage mehr auf den CPC bezieht, vielleicht kann ein Kenner der Z80 CPU mir folgendes Erklären.
Aus dem CPC Systembuch: https://k1.spdns.de/Vintage/Sc…C%20Systembuch/z180.htm#A
Nicht sinnvoll anwendbar kann ich mir noch halbwegs erklären. Aber gar nicht anwendbar? Die Befehle sind ja in der CPU vorhanden, wieso sind die dann nicht benutzbar? 
Im CP/M-Forum wird man das sicher beantworten können.
Hier nachzulesen:
https://k1.spdns.de/Vintage/Sc…0CPC%20Systembuch/z52.htm
Bissl' Dekodierlogik zuviel eingespart....
Und den Teil habe ich nicht verstanden. 
Ohne Gewähr auf Korrektheit:
Die haben beim CPC die Adressleitungen A8-A15 dafür benutzt um das #Chipselect der Peripheriebausteine
zu erzeugen. Die Selektion des Periphreibausteins erfolgt durch 0-setzen des entsprech3enden
Bits in der Adresse.
Bei der Verwendungen des Block Befehls ist dann mehr als ein Bit LOW; d.h. es werden mehrere Bausteine
angesprochen.
Alles anzeigenOhne Gewähr auf Korrektheit:
Die haben beim CPC die Adressleitungen A8-A15 dafür benutzt um das #Chipselect der Peripheriebausteine
zu erzeugen. Die Selektion des Periphreibausteins erfolgt durch 0-setzen des entsprech3enden
Bits in der Adresse.
Bei der Verwendungen des Block Befehls ist dann mehr als ein Bit LOW; d.h. es werden mehrere Bausteine
angesprochen.
In der Tat geht es wohl auch um die Registernutzung:
ZitatInteressant wird es aber, wenn man sich die verwendeten Adressbits anschaut: Alle (!) im CPC verwendeten Bausteine werden mit Adressleitungen aus dem oberen Byte angesprochen. Das untere Adressbyte ist (bis auf eine Ausnahme) immer völlig ohne Belang. Da hätte man ebensogut auch beim unteren Adressbyte,
und damit beim Standard-Verhalten der Z80 bleiben können. So hat man sich aber unter Anderem die Möglichkeit von Block-I/O-Transfers verbaut: Die benutzen nämlich das C-Register als Portadresse und das B-Register als Zähler. Und dass man dann mit dem B-Register nichts auf den oberen Adressleitungen anfangen kann, ist nur
zu offensichtlich.
Register B wäre der Zähler und C hätte den Wert, aber die reale Dekodierung braucht das High-Byte der impliziten 16-Bit-I/O-Adressierung (das ein OUT (C),C implizit aus Register B nimmt).
Also ich war überrascht, über dieses Konstrukt und diverse andere Konstrukte (tolle Referenz), die von einer Standard-Z80-Umgebungen abdriften. Das hat meine Vorstellung eines klar aufgebauten CPC, für den ich den bislang immer gehalten habe, schwer erschüttert - was vielleicht nur einer alten, verklärten Sicht aus frühen Tagen, einer Illusion, der man sich ungefragt hingibt, geschuldet ist. 
Das hat meine Vorstellung eines klar aufgebauten CPC, für den ich den bislang immer gehalten habe, schwer erschüttert - was vielleicht nur einer alten, verklärten Sicht aus frühen Tagen, einer Illusion, der man sich ungefragt hingibt, geschuldet ist.
Nicht alles was glänzt kann immer nur Gold sein. 
Der CPC hat einige Merkwürdigkeiten. Einmal das von mir erwähnte CPU Problem, dann das fehlende 8. Bit beim Druckerdingsanschluss.
Gibt bestimmt noch mehr. Aber das dürfte bei jedem Retrosystem so sein.
Ne weitere Antwort von M.J. habe ich noch im Postfach liegen. Wenn er sein Ok gibt, dann schreibe ich es hier rein.
Nachtrag: Antwort von M.J.
Ich könnte mir aber vorstellen, daß die Befehle aus dem Grunde für den CPC ungeeignet sind, weil die Dekodierung des Ports anders vonstatten geht als in herkömmlichen Z80-Systemen. Die Befehle an sich sind natürlich vorhanden und könnten auch ausgeführt werden, aber die Wirkung bestände wohl in den meisten Fällen aus einem Systemabsturz.
Hier mal ein klassischer Code zum Warten auf den Vertical Retrace
Man sieht, daß beim CPC das B-Register den Port angibt. Der Inhalt von C ist im grunde genommen irrelevant. Der Befehl INIR setzt aber voraus, daß die gültige Portadresse in C steht und B als Zähler fungiert. Würde man diesen Befehl also beim CPC anwenden, würde folgendes passieren:
Die Portadresse in C würde ignoriert werden. Dafür würde zunächst der Wert von B ($20) als Port interpretiert und ein Byte von dort gelesen und nach (hl) geschrieben werden. Im nächsten Schritt würde dann ein Wert vom Port $1f gelesen und geschrieben werden usw. bis der Bytezähler den Wert 0 erreicht. Das ist beim CPC sicherlich nicht das, was man will. Aus diesem Grunde sind diese Befehle auf dem CPC wohl nicht anwendbar, obwohl de facto in der CPU vorhanden.
der CPC wird mir immer unsympathischer... welchen Sinn macht ein solcher Umgang mit Adressbytes ?!? Luxus ??? 
der CPC wird mir immer unsympathischer... welchen Sinn macht ein solcher Umgang mit Adressbytes ?!? Luxus ???
Wenn ich es richtig verstanden habe, dann hat man es gemacht um Decodier-Logik einzusparen.
Wahrscheinlich haben die damit ein paar Pfennig als IC eingespart. Einen Sparzwang gab es also nicht nur bei Commodore.
Einen Sparzwang gab es also nicht nur bei Commodore.
Die Entwicklung der Spezialchips zum Beispiel im C 64 hat sich Commodore schon was kosten lassen. Im Gegensatz zu den vielen Bausteinen von der Stange im CPC.
Die Entwicklung der Spezialchips zum Beispiel im C 64 hat sich Commodore schon was kosten lassen. Im Gegensatz zu den vielen Bausteinen von der Stange im CPC.
Der 64er ist auch mehr dem Atari XL nachempfunden und der CPC dem Sinclair Spectrum.
Der 64er ist auch mehr dem Atari XL nachempfunden und der CPC dem Sinclair Spectrum.
Ja, die Atari-8-Bitter waren bestimmt auch kostenintensiv in der Entwicklung. Und der Specci im Endeffekt auch nur eine CPU mit Framebuffer, also mit einem Videochip ohne Eigenintelligenz, Nicht mal ein Soundchip war ihm vergönnt.
16-Bit-IO-Adressen sind beim Z80 nur halbherzig implementiert; den Haupt-Select beim CPC auf das obere Adressbyte zu legen war sehr kurzsichtig. Soweit d'accord. Aber welcher IO würde denn einen Blocktransfer mit Höchstgeschwindigkeit überhaupt vertragen? Selbst beim Disk-Controller würde man doch nach der Übertragung eines Blocks eh warten, bis die Daten geschrieben sind. Und die Jungs von comp.os.cpm haben mal ausgetüftelt, daß eine handcodierte Schleife mit den alten 8080-Befehlen sogar schneller ist als eine mit Z80-Befehlen oder gar ein Block-IO.
MAW: Kein Verlust, nur eine geplatzte Werbeblase von Zilog...
