Moin,
Ist der NanoSwinSID auch für die CBM II Geräte (CBM 610 - 720) einsetzbar ?
Zur Erinnerung: Die laufen mit 2 MHz.
Hallo Besucher, der Thread wurde 3,6k mal aufgerufen und enthält 14 Antworten
letzter Beitrag von Diddl am
Nano SwinSID für CBM II ?
- Toast_r
- Erledigt
-
Ich das Timing ist dann für den Atmel zu schnell!
Es Reicht ja nur für Schreibzugriffe auf dem C64 @1Mhz , für Lesezugriffe ist der Atmel schon zu langsam.
Einfach mal Probieren, Kaputt gehen kann eigendlich nichts, aber ich denke zu 99% wird es nicht Funktionieren...
-
Moin,
Ist der NanoSwinSID auch für die CBM II Geräte (CBM 610 - 720) einsetzbar ?
Zur Erinnerung: Die laufen mit 2 MHz.Der SID auch? Laut Datenblatt ist für den bei 1MHz Schluss.
-
Wäre schön wenn da mal jemand mit entsprechender Hardware testen könnte, da ja immer noch der SwinSID auf 8515 Basis auf den C16 Plus4 nicht läuft, evtl. wäre der Nano ein neuer Versuch wert.
-
Ich das Timing ist dann für den Atmel zu schnell!
Es Reicht ja nur für Schreibzugriffe auf dem C64 @1Mhz , für Lesezugriffe ist der Atmel schon zu langsam.
Könnte man das Schreibtiming für den SwinSID nicht etwas entschärfen indem man Adress- und Datenleitungen zum SID vor dem Anschluss an den Atmel jeweils durch ein Latch führt welches vom _CS-Signal getriggert wird? Damit liegen die Daten bis zum nächsten Zugriff an und nicht nur die 500ns (im C64) oder 250ns (bei 2MHz). Damit hat der Atmel mehr Zeit die Daten zu übernehmen.
Das klappt natürlich nur, wenn es an der Datenübergabe hakt und nicht generell an der Rechenleistung.
-
Ok, damit ist klar, dass es ohne Modifikationen nicht geht.
Jetzt die Frage ob jemand die Idee mit den Latches ausprobieren kann.
-
Ja, der läuft in diesen Rechnern außerhalb der Spezikation, das ist serienmäßig so.
Man kann deswegen die Register nicht auslesen.
Auslesen kann man die auch auf dem C64 nicht. -
Ein paar schon. OSC3 und ENV3 kannst du auslesen, behauptet jedenfalls das Datenblatt zum SID.
-
Ja ein Latch wäre sowieso gut, dann ist der Atmega nicht so zeitkritisch. Ein GAL oder ein kleiner CPLD ...
-
ich würde es erstmal nur mit einem latch,
für die datenleitungen D0-D7, versuchen. -
Man könnte ggfs. nicht nur die Datenleitungen, sondern auch die betroffenen Adressleitungen latchen. Und den Schreibimpuls sowie CS per Monoflop verlängern. Für die Schreibzugriffe sollte das reichen. Für Lesezugriffe auf OSC3, ENV3 und die Joysticks hilft das natürlich nicht. Und ob der Aufwand lohnt...
-
Ja ein Latch wäre sowieso gut, dann ist der Atmega nicht so zeitkritisch. Ein GAL oder ein kleiner CPLD ...
Da reichen die Pins nicht (du musst 8 Daten und 5 Adressleitungen, also 13 Leitungen latchen, also 26 Pins) und sollten nicht 2 74HCT574 plus 1 Inverter (Der 574 übernimmt bei LOW -> HIGH, die interessante Flanke von CS ist aber HIGH -> LOW) den Job billiger erledigen können?
Mit einem Latch in diesen Leitungen müsste der Swinsid auch bei 2MHz Systemtakt noch mitkommen, also im 710 funktionieren.
Kann ja mal jemand mit der passenden Hardware zum Test auf einem Zwischensockel aufbauen.
@jssr67:
Ich dachte der SwinSID kann sowieso keine Lesezugriffe? Die Adressleitungen musst du ebenso wie die Datenleitungen latchen, sonst liest der SwinSID zwar die korrekten Daten, aber zu diesem Zeitpunkt haben die Adressleitungen schon einen anderen Wert => Daten woanders als sie sollen, kein brauchbarer Sound.
R/_W sollte man nicht latchen müssen, ebenso sollte _CS keine Verlängerung brauchen. Ich nehme mal an, dass _CS einen IRQ/NMI auslöst und das nicht über Polling gelöst ist, also ist die Pulslänge nur insofern wichtig, dass sie zur Auslösung des IRQ/NMI reicht.
-
Man könnte ggfs. nicht nur die Datenleitungen, sondern auch die betroffenen Adressleitungen latchen.
Man muss nicht alle Adressleitungen latchen, nur die Registerselect, wenn man die Firmware etwas anpasst ...
