Hallo Besucher, der Thread wurde 1,7k mal aufgerufen und enthält 27 Antworten

letzter Beitrag von cbmhardware am

1 SPI-Bit am Expansionport lesen ?

    Ich frage mich, ob mein Ansatz richtig ist :



    Der obere Dekoder baut aus I/O2 eine Adresse. Ist in diesem Fall I/O2 +$00 und nur symbolisch zu sehen. Der andere Teil des Dekoder soll mir Read und Write erzeugen:


    Phi2: 1 = CPU ist dran
    R/W: 1 = Lesen
    R/W: 0 = Schreiben


    Code
    1. PHI2 R/W
    2. 1 0 = y1 ; Schreiben
    3. 1 1 = y3 ; Lesen



    Das Schreiben ins Register sollte so klappen (?). Nun möchte ich aber ein Bit (D3) lesen. Ich stelle mir das so vor: die SPI-Kommunikation wird wie üblich gestartet, also CS=0 und die Anfrage ($adr+r,$register) in das Device clocken. Danach kann man dann seinen Wert dann bitweise heraus-clocken. Nach der ersten SPI-Clock-Phase liegt also mein erstes Bit an SO.
    Das separate Flipflop soll den Wert beim Lesen übernehmen und von dort auch auf den CPU-Bus übernommen werden. Ob das beim ersten Lese-Zugriff so klappt ?


    Oder sollte man besser die SPI-Clock phasenverschoben (Inverter) für das Flipflop verwenden ?

    Nein, der Ansatz ist falsch weil du den Ausgang des Flipflops nicht tristaten kannst. Damit liegt dessen Ausgang Q immer auf D3 an und der C64 wird nicht laufen.


    Du brauchst statt dem Flipflop (oder danach) noch einen Tristate-Treiber. Zu finden z.B. im 74LS125.


    Nachtrag: Wenn du etwas am Expansionport an die Datenleitungen hängst musst du immer dafür sorgen, daß dieses Gerät nur dann Pegel auf die Leitungen legt wenn es das auch darf (also über sein Freigabesignal angesprochen wird). Zu allen anderen Zeiten müssen seine Ausgangstreiber inaktiv sein. Daher der Bedarf für Tristate-Treiber. Bei fertigen I/O-Chips ist die ganze Logik schon integriert, deshalb vergisst man dieses Detail beim Selbstbau gerne.

    Ja, richtig, jetzt wo Du es schreibst. :) Ich lege so natürlich D3 fest.


    Da wurde es auch mit einem 74125 gemacht, um die Konfigurations-Bits auch Lesen zu können.


    http://www.cbmhardware.de/c128…80/c128_comal80_logic.jpg

    Ja, genau, das liegt sowieso am Ausgang. Ich hatte da viel zu kompliziert gedacht. Ein 139er-Dekoder für Adresse und Signale, ein 74125 und ein 74174 6-Bit-Register, dann hat man alles für zwei SPI-Bus-Systeme zusammen.


    Ich brauche manchmal etwas Auffrischung, dann kommt es langsam wieder zurück. ;)

    Das wäre nicht so gut. Man kann es nur bitweise beschreiben, daher fände ich den Aufwand zum Lesen eines ganzen Byte etwas zu viel. Wenn, dann möchte man dann auch ein ganzes Byte schreiben und dann kommt man in den Bereich "umfangreiche Logik", die man dann besser mit PLD aufbauen sollte, wie es beim MMC64 gemacht wurde.


    Ich bin im Moment sowieso noch nicht ganz schlüssig, was ich damit mal bauen möchte. Vielleicht mal ein Lern-Cart mit ROM und etwas "Blingbling". Dann sind ein paar Hürden gar nicht so schlecht.

    Es gibt einige Schieberegister mit Parallelzugriff. Schau mal nach "shift register parallel accesss".

    Die Videologik hat das, was mir dann fehlen würde: das Clocking. Wenn man auch das parallele Register mit einem Byte lädt, braucht man imo danach noch 8 Taktphasen um es dem SPI-Device dann zu verbimmeln. Andersherum wird es genauso aussehen.


    Edit: Oder man muss sich einen Oszillator mit drauf bauen. Evtl. könnte man die Dotclock runter teilen.

    Zitat von cbmhardware

    Die Videologik hat das, was mir dann fehlen würde: das Clocking


    Am Expansionsport liegt auch das Dotclock-Signal an, welches praktischerweise genau um den Faktor 8 schneller ist als der CPU-Takt. Dazu noch ein Zähler um genau 8 Takte davon abzählen zu können um mittels AND-Gatter nur genau diese 8 Pulse an SCK weiterzugeben während das ebenfalls davon getaktete Schieberegister 8 Bits raus+reinschiebt und der grösste Teil wäre geschafft. Natürlich könnte man das alles in einen PLD packen, aber mit etwas Kreativität sollte das auch in akzeptabler Chipanzahl diskret machbar sein.

    Zitat von Unseen

    Dazu noch ein Zähler um genau 8 Takte davon abzählen zu können um mittels AND-Gatter nur genau diese 8 Pulse an SCK weiterzugeben während das ebenfalls davon getaktete Schieberegister 8 Bits raus+reinschiebt und der grösste Teil wäre geschafft.


    Ich habe im Moment drei TTLs und einen recht großen Port-Expander drauf. Dazu würden dann noch zwei Shift-Register, ein Counter und wenigstens zwei TTL für die Anpassungen kommen. Das mag wohl irgendwie gehen, aber das Cartridge ist damit dann voll.
    Da shifte ich dann doch lieber per Software. Ich muss nicht auf möglichst hohe Geschwindigkeit bauen, wie das beim Pollen von MMC-Karten sicher sinnvoll ist.

    "Ich muss die Leiche nochmal aus dem Keller holen." :)


    Ich hatte die alte Idee doch nochmal aufgegriffen und zwischendurch beim Käffchen immer mal etwas mit Eagle getüftelt. Jetzt ist die Dot-Clock für das Shiften ganzer Bytes schaltbar. Ich habe es über einen Counter gelöst, der nach 8 Taktphasen mit einem 74125 die Clock abklemmt. Über ein Register lässt sich das dann immer wieder aktivieren: also Byte über "Port" hinlegen und 8 Takte aus der Dotclock raussprudeln lassen. Zwischen Lesen und Schreiben kann man auch mit einem Bit hin- und her schalten. Das Lesen funktioniert dann ähnlich: Lesen aktivieren, 8 Takte und Byte abholen.
    Für einzelne Takte habe ich ein Register-Bit reserviert. Da würde eine Dotclock mit Auswertung nur den Schaltungsaufbau wachsen lassen, deshalb die zusätzliche "Slowclock".
    Zwei Register sind dann noch für zwei separate Slaves vorgesehen.



    Es braucht bei diskretem Aufbau schon ein paar Bauteile. Könnte trotz zu erwartender Latenzzeiten übers Programm für den C64 immer noch schaurig abgehen. :)


    Werde das mal auf einem Steckboard aufbauen und mit Signal-Generator meine Theorie überprüfen. Aber vielleicht sieht ja jemand auch so noch einen Fehler ?

    Vorsicht, der 74xx125 schaltet den Ausgang in Tristate wenn du das Freigabesignal entfernst. Damit hängt CLK in der Luft. Geht zwar meist, aber bei CMOS-ICs sollte man das nicht machen.


    Das kann man mit einem 74xx32 besser lösen. Einer der Eingänge eines OR-Gatters ist die Freigabe und der andere ist CLK. CLK erscheint nur dann am Ausgang wenn die Freigabe LOW ist. Ist sie HIGH, dann ist der Ausgang immer HIGH.


    Alternativ geht das auch mit einem 74xx08, dort wird das Signal durchgereicht wenn die Freigabe HIGH ist, ansonsten ist der Ausgang immer LOW.

    Bei der Clock würde ich da jetzt keine Probleme erwarten. Aber bevor ich da Pullup oder Pulldowown zusätzlich verbauen muss, ist Deine Idee bestimmt sicherer.


    Ich habe aber dennoch einen groben Fehler drin: der 125 muss vor dem Counter die Dotclock abschalten, sonst ist der sehr schnell einmal rum, um wieder bei 0 zu beginnen.

    Das Problem mit offenen CMOS-Eingängen ist, daß die erste darauf folgende CMOS-Stufe im IC dann beide Transistoren gleichzeitig freischalten kann. Mit entsprechenden Folgen für Funktion und Wärmeentwicklung.


    Man befindet sich hier in einem undefinierten Bereich und sowas will man bei Digitalschaltungen um jeden Preis vermeiden. Die soll schliesslich immer funktionieren (oder bei Fehler gar nicht), aber auf keinen Fall hin und wieder nicht.

    Ich habe es dahingehend geändert und einen 7432 (or) eingesetzt. Und natürlich meinen "kleinen" Fehler korrigiert.



    So werde ich es mal mit einer geringen Taktung testen, damit ich mit dem Logiktester alles überprüfen kann.


    Edit: Mit einem 74HC595 könnte ich noch ein Bauteil einsparen.