So richtig glücklich war ich damit auch nicht. Ich muss am Ende mal sehen, was ich mir aus der noch übrig gebliebenen Logik bauen kann.
Beiträge von cbmhardware im Thema „1 SPI-Bit am Expansionport lesen ?“
-
-
Ich habe es nochmal überdacht. Bei 8Mhz Takt braucht man sowieso nicht über irgendwelche Längen nachdenken, daher habe ich den OC-Treiber kurzerhand wieder entfernt.
Im Moment ist als zweite Taktquelle noch Phi2 angegeben. Da habe ich noch eine kleine Unsicherheit mit Pin 1 (Shift) vom 74LS165, ob dann da auch währende der Takfreigabe immer passend High (Schreiben) anliegt. Das muss evtl. noch besser dekodiert werden.
SPI-Slave 1 wird ein 64kx8 E²prom, auf das man seine eigene Software speichern kann. Und dann bei Bedarf mit einem kleinen Bootloader wieder in den Speicher laden. Spart eine Menge Platz und Leitungen auf der Platine.
Das Default-Device für Slave0 wird ein MCP3202 (2 x ADC 12Bit) als Messgerät, Sound-Digitizer ... was auch immer. Der Rest der Platine wird dann Breakoutboard (Raster) für eigene Ideen oder Erweiterungen.Bitte melde dich an, um diesen Anhang zu sehen.
Ist im Moment immer noch Planspiel. Habe die Bauteile für einen etwas konkreteren Test noch nicht da.
-
Ja, das war mir mittlerweile auch schon aufgefallen. Das muss ich dann tatsächlich nachlesen oder prüfen. Entweder haben die Pullups oder ich muss noch welche einplanen. Kann ich im Moment noch nicht sagen.
Edit: btw, da ist noch eine Hälfte Counter: 500khz ginge auch noch. Ist dem Schaltungsaufwand aber nicht besonders zuträglich.
-
Ah, shit, richtig, so habe ich den erst richtig in Hi-Z geschaltet. Kommt dann natürlich direkt an SR, das jetzt ein 74hc595 ist.
Bitte melde dich an, um diesen Anhang zu sehen.
Danke für Deine Hilfe !
-
Den Eingang ohne definierten Pegel kann man mir aber nur zur Last legen wenn nichts angeschlossen ist.
Ich habe eben einen Pullup drauf gelegt.Tja, für diese "SlowClock" lasse ich mir etwas einfallen: entweder lege ich den Treiber direkt auf den Ausgang oder mal sehen ...
-
Ich habe es dahingehend geändert und einen 7432 (or) eingesetzt. Und natürlich meinen "kleinen" Fehler korrigiert.
Bitte melde dich an, um diesen Anhang zu sehen.
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.
-
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.
-
"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.Bitte melde dich an, um diesen Anhang zu sehen.
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 ?
-
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. -
Ok, danke, ich hatte zeitgleich meinen Edit erweitert.
Ich werde mal sehen, was da so geht. -
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.
-
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.
-
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.

-
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.
Bitte melde dich an, um diesen Link zu sehen.
-
Ich frage mich, ob mein Ansatz richtig ist :
Bitte melde dich an, um diesen Anhang zu sehen.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 = SchreibenDas 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 ?