Warum sind nicht alle Z80 Befehle im CPC anwendbar?


  • oobdoo
  • 1014 Views 12 replies

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Warum sind nicht alle Z80 Befehle im CPC anwendbar?

    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: k1.spdns.de/Vintage/Schneider%…C%20Systembuch/z180.htm#A

    HTML Source Code

    1. LDI LDD ! 5 !
    2. CPI CPD ! 4 !
    3. INI IND OUTI OUTD ! 5 ! nicht sinnvoll anwendbar
    4. LDIR LDDR ! 6 / 5 !
    5. CPIR CPDR ! 6 / 4 !
    6. OTIR OTDR INIR INDR ! ----- ! Block-I/O-Befehle nicht anwendbar !!
    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? ?(
    :verehr: Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
  • 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.
    PLAdvanced+ - The all in one PLA replacement!
    PLAdvancedA1060 - Amiga Sidecar A1060 replacement!
  • androSID wrote:

    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.
    In der Tat geht es wohl auch um die Registernutzung:


    Interessant 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. :rolleyes:
  • JeeK wrote:

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

    Source Code

    1. ld b, $f5 ; warte auf VSync
    2. ?0: in a, (c)
    3. rra
    4. jr NC, ?0
    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:

    Source Code

    1. ld b, $20 ; eigentlich Bytezähler!
    2. ld c, $70 ; eigentlich Portadresse!
    3. ld hl, $2000 ; Adresse auf Speicher
    4. inir
    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.
    :verehr: Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:

    The post was edited 1 time, last by oobdoo ().

  • 4LEX wrote:

    der CPC wird mir immer unsympathischer... welchen Sinn macht ein solcher Umgang mit Adressbytes ?!? Luxus ??? :D
    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.
    :verehr: Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
  • ogd wrote:


    oobdoo wrote:

    4LEX wrote:

    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.
    Der 64er ist auch mehr dem Atari XL nachempfunden und der CPC dem Sinclair Spectrum.
    :verehr: Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
  • oobdoo wrote:

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