Hallo Besucher, der Thread wurde 4,4k mal aufgerufen und enthält 18 Antworten

letzter Beitrag von Zaadii am

Wie kann der CSG4510 nur ein CSG65CE02 mit 2 CIA in einem Gehäuse sein, wenn er mehr ASM-Kommandos kennt?

    Hallo, mal an die Experten,


    es gibt da eine Ungereimtheit bein C65 die immer Merkwürdiger wird je tiefer ich mich da reingrabe:


    Im Wiki steht ja zu dem CSG4510 (Prozessor des C65):
    "The 4510 is a system in package (SiP) variant of the 65CE02 that includes two 6526 CIA I/O port controllers."


    Gut, jetzt hab ich mir mal das Datenblatt vom 65CE02 geholt:
    https://en.wikipedia.org/wiki/CSG_65CE02


    OK, der hat tatsächlich alle Befehle des C65.... bis auf MAP.
    Das macht auch irgendwie Sinn, denn das MAP ist der Befehl fürs BANK-Switching und das kann der 65CE02 ja nicht.


    Der CSG4510 macht das mit Hilfe dieser CIAs --- nur die interpretieren für Ihn ja nicht die Befehle die aus dem Speicher geholt werden.



    Ich hab mal nachgaschaut um irgendwelche komischen Hacks auszuschließen: MAP hat tatächlich eine eigene Bitfolge (C5).



    Mir ist absolut nicht klar wie das funktioniert. ?(



    Hat mir da mal jemand ne Erklährung --- oder noch besser hat jemand einen "Schaltplan" vom CSG4510. Ich habe den Verdacht, dass da außer dem 65CE02 und den zwei CIAs noch etwas mehr Logik drauf ist. Ich habe zwar die Pinouts von allen beteiligt ICs, aber das reicht für ein Revese-Engineering nicht aus...

    Interessant.


    Also etwas mehr als ein 65CE02 und zwei CIAs kann er schon...


    Laut meiner Dokumentation ist der 4510:
    - 65CE02 (verwendet auf der Amiga Mehrport-Serialkarte)
    - 2x CIA 6526
    - UART mit universal baud Generator
    - 4 unabhängige 16-bit universal timer
    - 2x 24 Stunden Tagestimer mit unabhängigem Alarm
    - MEMORY MAP Funktion - bis 1 MB
    - 2 8 bit Shift Register
    - 30 programmierbare I/O Funktionen ("Lines" - wie heißt das Deutsche Wort? Pins? Ein/Ausgänge?)


    Wenn der FAST SERIAL MODE aktiviert ist, verändern sich ein paar Funktionen (-> CNTA, SPA, FLAGA "lines")



    Was mich eher interessiert wäre, ob mein CSG 4510 von 1992 Verbesserungen gegenüber den 4510 von 1991 im C65 aufweist, oder nicht. Aber das rauszufinden wird wohl keiner schaffen... Auf jeden Fall ist es die letzte mir bekannte Stufe/Produktion des 4510 in diesem Sonnensystem.

    Hm...
    ja dass er mehr kann ist mir schon klar.
    Aber das alles hier:

    • UART mit universal baud Generator
    • 4 unabhängige 16-bit universal timer
    • 2x 24 Stunden Tagestimer mit unabhängigem Alarm
    • 2 8 bit Shift Register
    • 30 programmierbare I/O Funktionen

    Sind direkt Funktionen, die von den CIAs übernommen und durchgeführt werden.


    Nur das mit dem MAP ist merkwürdig.
    Wie soll man sich das vorstellen? :


    Also die DatenPins des Gehäuses müssen mehr oder weniger direkt mit den Daten Bits des eingebetteten 65CE02 verbunden sein.
    So.
    Jetzt wird der nächste Befehl geholt und es kommt eine C5 an. Der 65CE02 erkennt das nicht als Befehl.


    Vielleicht hat Commodore hier aus den Illegal OpCodes des C64 gelernt und alle unbekannten Muster auf NOP gemapped.


    OK.


    Dann macht der 65CE02 nix und ne andere Logik, die auch auf den Datenpins mithört könnte was tun.


    Nun ist es aber so, dass MAP intesiev mit den Internas des 65CE02 arbeitet.
    Immerhin werde die Inhallte von X-, Y-, und Z-Register benötigt.
    Diese werde aber bei einem NOP nicht nach aussen gelegt.
    Ausserdem hat MAP noch andere interne Auwirkungen. z.B. werden Interrupts zurückgehalten.


    Wie gesagt, ohne internes Schaltbild vom CSG 4510, oder einer Erklährung von nem Experten komme ich hier nicht weiter ...

    Vermutlich hat sich Paul Gardner-Stephen (Highlander hier im Forum) für seine C65 FPGA-Implementierung damit schon auseinander gesetzt, daher könnte man einfach mal in den Quellen schauen: https://github.com/MEGA65/mega65-core bzw. https://github.com/gardners/c65gs

    Zitat von computercollection

    - 30 programmierbare I/O Funktionen ("Lines" - wie heißt das Deutsche Wort? Pins? Ein/Ausgänge?)

    Warum nur 30? Eine CIA hat doch jeweils 16, und wenn das Teil C64-kompatibel sein soll, kommt auch noch der CPU-Port hinzu.


    Zitat von Zaadii

    Jetzt wird der nächste Befehl geholt und es kommt eine C5 an. Der 65CE02 erkennt das nicht als Befehl.

    Das naheliegendste wäre doch, daß man den CPU-Kern um diesen Befehl und dazugehörige Register erweitert hat, die dann mit der Adressierungslogik in Verbindung stehen.

    Beim 65CE02 sind alle 256 Opcodes mit Befehlen belegt, aber einer davon, nämlich $5c, tut nichts. Der ist "reserved for future expansion" und heißt offiziell "AUG".
    Beim 4502 wurde dieser Opcode dann für MAP verwendet, und die NOP-Instruktion hat eine zweite Funktion als "EOM" (end of mapping) bekommen, um nach einer MAP-Instruktion wieder alle Interrupts zu erlauben.

    Einen zusätzlichen Opcode in die Decodermatrix/ den Microcode zu quetschen ist nun wirklich kein Aufwand, wenn man schonmal dabei ist, einen 'System-Chip' aus mehreren Komponenten zusammenzubauen. Ähnliche Modifikationen hat CBM ja schon beim 6502-Kern gemacht; 6508 mit Zusatz-RAM, 6509 mit (krudem) Bank-Switching, 6510ff. mit IO-Port... und zumindest der 6509 hat Eingriffe in den Befehlsdecoder gebraucht.

    OK, danke für die Infos. :thnks:
    Ich habe auch noch das in ner 65CE02 doku gefunden:
    "
    The operation of the MAP, SEE and CLE instructions are unknown, as well as the operation of the RTS instruction with an immediate operand. It might modify the status register or pull additional bytes from the stack before returning (compare i8086 RET)."
    Der "65CE02" im C65 ist also nicht wirklich der 65CE02 - was die Verwendung dessen Doku auch probleatischer macht.




    ...sorry, in meiner Naiven Vorstellung dachte ich in der Tat, man könne sich nen 4510 mit nem 65CE02 und zwei CIAs nachbauen.


    Es war mich auch nicht klar, dass es damals so einfach war in men Prozessor nochmal kurz ein paar Befehler zu ergänzen.

    Zitat von Zaadii

    Ich habe auch noch das in ner 65CE02 doku gefunden:
    "
    The operation of the MAP, SEE and CLE instructions are unknown, as well as the operation of the RTS instruction with an immediate operand.

    Solche Formulierungen qualifizieren die Quelle wohl kaum als "Doku". Das 65CE02-Datenblatt von MOS erklärt SEE (SEt stack pointer Extend disable), CLE (CLear stack pointer Extend disable) und RTN# sehr wohl.
    CLE: schaltet auf 16-Bit Stackpointer.
    SEE: schaltet zurück auf 8-Bit Stackpointer.
    RTN#: RTS mit Stackkorrektur.
    Unabhängig von CLE/SEE kann der Stack in jede Page gelegt werden.


    Zu MAP steht in dem Dokument natürlich nichts, aber die eine neue Instruktion ist in den C65-Helpfiles erklärt.

    Zitat von Mac Bacon

    Solche Formulierungen qualifizieren die Quelle wohl kaum als "Doku". Das 65CE02-Datenblatt von MOS erklärt SEE (SEt stack pointer Extend disable), CLE (CLear stack pointer Extend disable) und RTN# sehr wohl.CLE: schaltet auf 16-Bit Stackpointer.
    SEE: schaltet zurück auf 8-Bit Stackpointer.
    RTN#: RTS mit Stackkorrektur.
    Unabhängig von CLE/SEE kann der Stack in jede Page gelegt werden.


    Zu MAP steht in dem Dokument natürlich nichts, aber die eine neue Instruktion ist in den C65-Helpfiles erklärt.

    Naja,
    da es so wenig gibt nehme ich grad halt alles was ich bekommen kann.
    Jenes war aus:
    http://www.commodore.ca/manual…ments/chipdata/65ce02.txt
    ich konnte dem Dokument auch einige hilfreiche Hinweise entnehmen.


    Zitat von mc71

    Ich halte es für denkbar, daß der MAP-Befehl von Anfang an Teil des Konzeptes war und nur beim CE02 nicht aktiv ist- mangels Adreßraum, ähnlich wie beim WDC 65802.

    Ich denke auch dass es von Anfang an vorgesehen war - denn dass man nacher noch so was rein bekommt ohne dass es vorher vorbereitet war, wäre doch mit sehr viel Glück verbunden.

    Zitat von mc71

    Ich halte es für denkbar, daß der MAP-Befehl von Anfang an Teil des Konzeptes war und nur beim CE02 nicht aktiv ist

    Zitat von Zaadii

    Ich denke auch dass es von Anfang an vorgesehen war

    Das wird durch die verfügbare Doku eindeutig widerlegt. Beim 65CE02 war die AUG-Instruktion ein "4-byte NOP reserved for future expansion". Der Opcode war also ein Platzhalter für zukünftige vier-Byte-Instruktionen - vielleicht als Präfixcode gedacht, so wie es sie beim Z80 und x86 gibt.
    Die MAP-Instruktion beim 4502 hingegen ist ein Ein-Byte-Befehl mit impliziter Adressierung; sämtliche Parameter für die Mapping-Operation müssen vorher in die Prozessorregister A/X/Y/Z geladen werden.

    Zitat von Zaadii

    denn dass man nacher noch so was rein bekommt ohne dass es vorher vorbereitet war, wäre doch mit sehr viel Glück verbunden.

    Nein, das ganze Adress-Mapping-Gedöns ist ja eine zusätzliche Erweiterung, die von außen an den Prozessorkern angeflanscht wurde. Abgesehen von dem einen MAP-Opcode weiß der Prozessorkern ja überhaupt nichts davon, der kennt weiterhin nur seinen 16-Bit-Adressraum. Man hätte das Mapping ebensogut wie beim 64er (Prozessorport) oder 128er (externe MMU) erledigen können, da "weiß" der CPU-Befehlssatz ja auch nicht, dass im Adressraum mal ROM und mal RAM und mal I/O eingeblendet wird.

    Zitat von Mac Bacon

    Das wird durch die verfügbare Doku eindeutig widerlegt. Beim 65CE02 war die AUG-Instruktion ein "4-byte NOP reserved for future expansion". Der Opcode war also ein Platzhalter für zukünftige vier-Byte-Instruktionen - vielleicht als Präfixcode gedacht, so wie es sie beim Z80 und x86 gibt.Die MAP-Instruktion beim 4502 hingegen ist ein Ein-Byte-Befehl mit impliziter Adressierung; sämtliche Parameter für die Mapping-Operation müssen vorher in die Prozessorregister A/X/Y/Z geladen werden.

    Nein, das ganze Adress-Mapping-Gedöns ist ja eine zusätzliche Erweiterung, die von außen an den Prozessorkern angeflanscht wurde. Abgesehen von dem einen MAP-Opcode weiß der Prozessorkern ja überhaupt nichts davon, der kennt weiterhin nur seinen 16-Bit-Adressraum. Man hätte das Mapping ebensogut wie beim 64er (Prozessorport) oder 128er (externe MMU) erledigen können, da "weiß" der CPU-Befehlssatz ja auch nicht, dass im Adressraum mal ROM und mal RAM und mal I/O eingeblendet wird.

    Welche der genannten Möglichkeiten über 64 KB hinaus zu gelangen, erscheinen Dir die geeignetsten für ein 8-Bit System zu sein, wie es die 6502-Rechner nun mal sind?


    bin mir selber da im ungewissen.
    Das 6509-Prinzip beim CBM II erscheint mir unstrittig das unausgegorenste, umständlichste.
    Beim C128 hat man Löcher im Adressraum unten (Port 0/1 als C64-"Hinterlassenschaft") sowie oben ($FFxx MMU-Register sowie bei $Dxxx)
    Beim C64 schafft man mit dem Banking zwar Platz unter dem ROM, aber dann stösst man schon an Grenzen.
    Mit der 1750-REU ist man zwar flexibel, muss aber viel Aufwand betreiben (Kopieren / Swappen).


    Welches Banking-Prinzip in der 8 - bit Welt und bei 6502 mag das einfachste, genialste, eleganteste sein?

    Zitat von Stephan

    Welches Banking-Prinzip in der 8 - bit Welt und bei 6502 mag das einfachste, genialste, eleganteste sein?

    Chameleon. Da kann man frei Blöcke mit Byte-genauen Offsets in den Adressraum der CPU einblenden und so auf die gesamten 32 MB zugreifen. Lediglich die Größe der Blöcke ist vom Core fest vorgegeben.

    hmm-. und wenn man aus so einem Block mit RTS zurückspringt ins Hauptprogramm in einer anderen Bank, wie erfährt der "Prozessor" (bzw. sein Emulator) dann, in welcher Bank sich dieses befindet?


    Die Meinungen von mc71, Zaadi und von anderen würde mich ebenfalls interessieren!

    Das mit dem Banking ist auf dem C65 schon eine spannende Sache (Lustiger Weis bin ich in meiner Trainingsvideos grad a diesem Thema (Lseeon8)).


    Der C65 schaltet nicht den ganzen 64KB-Block um. Es gibt in Basic zwar den BANK-Befehl, der so tut als sei das so, aber in Wirklichkeit is man hier im wesentlichen auf BANK 0 wo der Basic Code ist und wenn ein Befehl kommt der Bank-Relevant ist, schaltet das OS kurz für den Befehl einen Teil der 64 KB um, führt den Befehl aus und schaltet wieder zurück.


    In Wirklichkeit und auch, wenn man selber in assembler programmiert sieht das ganze anders aus. Und zwar so:
    Es werden zwei 32-bit-offsett-Adressen angegeben (wobei die untersten 8 bit konstant 0 sind). Eine Offset-Adresse wird zu Adressen für das obere 32-Bit segment hinzuaddiert, die andere für das untere Segment. Zudem gibt es für jedes 4 KB-Segment noch ein Bit, das anzeigt ob der Offset überhaupt verwendet werden soll, oder ob die Adresse in real (also auf Bank 0) genommen werden soll. Da der Offsett nicht auf 64KB alinged sein muss kann der obere und der unter 32KB-Bereich also über 2 Bänke verteilt sein. Dazu können einige 4KB-Teile die Bank 0 anzeigen.
    Man kann also Teile von bis zu 5 Bänken gleichzeitig sehen.
    Somit hat man die Möglichkeit und aber auch die komplette Verantwortung den aktuell relevanten Teil des Execution Codes immer im sichbaren Bereich zu halten. Umgekehrt könnte es Möglich sein, eine Art Jump hin zu bekommen, indem man zu richtigen Zeit die Bank-Konstellation verändert - ohne im Code einen jmp zu haben, was im Kombination mit der DMA zu wildesten RetroTricks führen kann/hätte können/wird - worauf ich mich schon freue.