VIA shift register bug

  • Wer immer schon mal wissen wollte, warum genau die Commodore Disk Laufwerke so langsam waren - hier ein technischer Deep Dive:


    Did you ever wonder why exactly the Commodore disk drives for the VIC-20 and the C64 were so slow?

    In this video I'm going into a deep dive on the VIA shift register bug that caused all this: https://youtu.be/6cwVQahVCdc

    #8bit #mos6502 #Commodore

  • das unglaublichste ist, dieses Zeug wurde jahrelang so produziert... und gekauft! 8|


    Damals gab es tausend verschiedene "Floppy Speeder".

    Ich bin mal gefragt worden, ob ich einen zum Laufen bekommen könnte.

    Um zu verstehen wie das funktioniert, habe ich erstmal das Kabel analysiert.

    Wow. 8 Datenbits.

    Aber - keine GND-Verbindung. Sowas kann funktionieren, mit "etwas Glück".

    Ja, das ist Commodore... :wegmuss:

  • Naja vor allem beim C64 wäre ja das Problem behoben gewesen weil der ja CIA statt VIA verwendet.


    Und doch hat man den Burstload da nicht implementiert.

    Sonst würde man zumindest mit den 1571 und 1581 Laufwerken schnell laden können.


    Tja Commodore halt...


  • Die waren aber alle nicht von Commodore.


    In der Dokumentation steht jeweils drin, dass man die Parallelverbindung nur zusätzlich zur seriellen Verbindung nutzen kann. Sonst geht es eh nicht, auch nicht mit Masseverbindung, weil das Protokoll so aufgebaut ist. Das ganze war insgesamt eine wackelige Sache, weil es ja nach Flach oder Rundkabel mal ging oder nicht. Masseverbindung machte es ggfs. eher schlechter, Stichwort Brummschleife. Über geerdete Floppy und nicht geerdeten C64 und eingeschlepptes Potential über Antennenbuchse vom TV. Viel Spass.


    Bei der CMD HD konnte man auch nur mit dem Parallelkabel laden. Da war das aber auch vorgesehen und die Masseverbindung vorhanden.

    Zuletzt repariert:

    10.11. defektes µT RAM im Apple //e ersetzt

    10.11. defektes µT RAM im Atari 130XE ersetzt

    12.11. VC20 mit black screen: defekter Videotransistor ersetzt

  • In this video I'm going into a deep dive on the VIA shift register bug that caused all this:

    Vorab: ich kann Videos nicht ab. Werde es mir dennoch ansehen um etwas zu dem Thema zu erfahren! Gibt nicht viele Themen die mich dazu bringen ;)

    Zuletzt repariert:

    10.11. defektes µT RAM im Apple //e ersetzt

    10.11. defektes µT RAM im Atari 130XE ersetzt

    12.11. VC20 mit black screen: defekter Videotransistor ersetzt

  • ich kann Videos nicht ab.

    Bei (tiefgehenden) technischen Erklärungen finde ich Videos auch meist schlecht geeignet.

    Beim Lesen bestimme ich selbst die Geschwindigkeit, und lese Abschnitte die mir nicht sofort klar sind, direkt nochmal.

    Vor allem, wenn die verwendete Sprache nicht meine Muttersprache ist, erleichtert das das Verständnis ungemein.

  • Warum der Burst-Load beim C64 nicht - wie tatsächlich geplant - implementiert wurde: bei der Produktion des C64 boards wurden vom Produktionshaus, ohne Wissen des Designers, die für den Burst-Mode nötigen Leitungen wieder weggelassen. Ansonsten hätte die 1541 nämlich auch einen 6526 mit funktionierendem Shift register bekommen. Dave McMurtrie stellt das sehr schön dar: https://www.youtube.com/watch?v=kaeFV0oZaps


    Ich hatte damals tatsächlich meinen C64 damit umgebaut, und in meinem "BDOS" zum Burst load der MFM Floppies der 1571 genutzt. (siehe irgendwo als Projekt des Monats in der 64er)

  • ich kann Videos nicht ab.

    Bei (tiefgehenden) technischen Erklärungen finde ich Videos auch meist schlecht geeignet.

    Beim Lesen bestimme ich selbst die Geschwindigkeit, und lese Abschnitte die mir nicht sofort klar sind, direkt nochmal.

    Vor allem, wenn die verwendete Sprache nicht meine Muttersprache ist, erleichtert das das Verständnis ungemein.

    Beim Aufnehmen ist das nochmal schlimmer ;)


    Ich versuche das mal auf meinem Blog zusammenzuschreiben.

    Zusammen mit einer Beschreibung des schnellen Transfers, den ich jetzt auch mit einer VIA kann :)


    Es kam halt zusammen dass Dave auch gerade an einem Video über das gleiche Thema gearbeitet hat, und wir das dann gemeinsam - jeder seinen Teil - veröffentlichen wollten.

  • Was ich nicht verstehe: man hätte doch einfach 2 Leitungen auf die Floppy Platine löten können?


    Solche Improvisation findet man doch später auch in so einigen c64?


    Es ging doch nur um den ersten Schwung der produzierten Platinen?

  • In Daves Video wird das erläutert.


    Die 1541 sollte ursprünglich auch einen 6526 bekommen und dann schnelles IEC bus Protokoll können.


    Aber bei den C64 boards wurden ohne Wissen des Designers die beiden nötigen Leitungen entfernt. Leider fiel das erst nach Produktion von 10000 boards auf, und das Management hat dann entschieden das so zu lassen.


    Die 1541 ist daraufhin dann eine 1540 mit neuem ROM geworden....

  • In Daves Video wird das erläutert.

    Also dein Video habe ich gestern angeschaut :) Aber Dave musste ich abschalten, da bräuchte ich einen passenden Einstiegspunkt ;)


    Sind eure Testprogramme denn öffentlich verfügbar? Würde bei Gelegenheit gerne mal die erwähnten 65C22/65SC22 prüfen, wenn ich die irgendwo finde. Glaube in den 1570/71 Laufwerken habe ich die öfters schon gesehen.


    Ich weiß nicht was ich von den vergessenen Leitungen halten soll. Hätte das dann funktioniert? So ganz ohne Treiber und ohne Richtungsumschaltung? Im C128 haben sie dann doch einigen Aufwand getrieben, siehe FSDIR Signal zur Umschaltung der Treiber.

    Zuletzt repariert:

    10.11. defektes µT RAM im Apple //e ersetzt

    10.11. defektes µT RAM im Atari 130XE ersetzt

    12.11. VC20 mit black screen: defekter Videotransistor ersetzt

  • Das 1541 Video geht weiter...

    ich mag die MSD SD-2 in seinem Regal ;)


    Einer meiner VC20 hat eine sehr alte GTEµ G65SC22PI-2 VIA Datecode 8428. Das muss ich dann mal testen!



    Rockwell R65NC22 habe ich leider keine, Aber "neue" R6522AP die sich etwas seltsam verhalten. Vielleicht einen Test wert. (Verhalten sich laut dem mb-audit 1.42 aus der Apple Welt wie W65C22, allerdings fallen dort meine echten W65C22N schon vorher durch ... Ich verstehe aber auch den Sourcecode nicht so gut, auf den bei der Testdokumentation verwiesen wird). GitHub - tomcw/mb-audit

    Zuletzt repariert:

    10.11. defektes µT RAM im Apple //e ersetzt

    10.11. defektes µT RAM im Atari 130XE ersetzt

    12.11. VC20 mit black screen: defekter Videotransistor ersetzt