TCBM-Bus Analyse ?

Es gibt 23 Antworten in diesem Thema, welches 12.375 mal aufgerufen wurde. Der letzte Beitrag (30. Januar 2017 um 07:18) ist von cbmhardware.

  • Wurden die Protokoll-Abläufe für den TCBM-Bus eigentlich jemals analysiert ?

    Bitte melde dich an, um diesen Link zu sehen.

    Das sieht nach 8 Datenbits (muss es auch wohl sein), einigen bidirektionalen Steuerleitungen und einem Reset-in aus.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Bisher hat das noch keiner gemacht, aber eines kann ich schonmal sagen...

    Die Leitung 'DEV' wird gebraucht um den 6523T im Modul an eine andere Adresse zu legen wenn sich die Device-ID der Floppy ändert. Diese Leitung ist mit der PLA (251641-03) im Modul verbunden.

    Es sieht auch aus als wenn 'Status 1' auf Computerseite ein Eingang ist da dort ein Pullup zu finden ist. Das gleiche dürfte für 'Status 0' in der Floppy gelten. Dann kann man noch ein bisschen was aus den Namen der beiden anderen Signale ableiten: DAV = Data valid und ACK = Acknowledge.

    Der Datenbus zwischen 264 und 1551 ist 8 Bit breit und damit müsste ein reiner Software-Speeder ziemlich trivial zu implementieren sein.

    Nachtrag: Hier gibts noch was: Bitte melde dich an, um diesen Link zu sehen.

  • Das scheint recht simpel aufgebaut. Da muss man dann nur mal herausfinden wie das genau abläuft. Ich werde mal einen Blick ins ROM-Listing werfen. Da wird man sicher darauf kommen, wie die zu dieser Langsamkeit bei dem Bus kamen. :) Es gibt einen Fastloader aus Ungarn der auch sehr schnell laden kann.

    Erstaunlich dass da noch niemals jemand einen AVR-Cardreader dran gehängt hat. Sieht gar nicht so schwierig aus.

    Edit: Paddle Schematic ist hier: Bitte melde dich an, um diesen Link zu sehen.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Der Grund wird der gleiche sein wie bei IEC, der Code muss immer funktionieren. Mit Feintuning wird auch der serielle IEC deutlich schneller.

    Achja... Der 6510T in der 1551 läuft mit 2 MHz und die einzige IRQ-Quelle ist ein 555 der als Oszillator geschaltet ist. Alles andere, auch der Datentransfer, kommt ohne IRQ aus.

    Und hier noch was man tut wenn der 6523T im Paddle defekt ist und man keinen auftreiben kann:

  • So wie es aussieht ist ACK die Bestätigung von der 1551 und DAV vom P/4. Etwas ähnliches hatte ich schon mal mit einem CBM und AVR aufgebaut und 20KB/s erreicht. Also 10KB/s muss da mit etwas optimiertem Code blind machbar sein. :)

    Da kann man schon einiges herauslesen:

    Bitte melde dich an, um diesen Link zu sehen.


    Was könnte das denn sein ?

    Bin in Moment noch auf der Suche wie der P/4 die Übertragung initialisiert. Ob es das schon ist ?

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Ich nehme an DAV und ACK wechseln die Richtungen, je nachdem wer mit wem reden will.

    Das schöne ist, daß DAV auf beiden Seiten Bit 7 ist, das kann man mit einem BIT-Kommando und nachfolgendem BPL/BMI sehr einfach und schnell auswerten wenn man auf Zyklen optimieren will.

  • Hier sieht es aber eher danach aus, dass der P/4 DAV auch beim Empfangen schaltet.

    Das lese ich da raus ... ? (ohne Status und Error-Handling) :

    Code
    P/4         1551
    -------- | ---------
                   <- ACK_1
    DAV -> 
                   <- BYTE
                     $0d
    DAV ->
    BYTE->
                   <- ACK_0


    Code
    ;
    ;$C14E  -------- Data goes to computer
    ;
    B_C14E	LDA V_4002
    	BMI B_C14E	; wait for DAV handshake from plus/4
    	LDA #$FF
    	STA V_4003	; set TIA port A to all outputs
    ...

    Ach, wenn man einen ordentlichen Logik-Analyzer hätte.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Ich muss mit Linux immer darauf achten, dass der auch von Software unterstützt wird. Würde mir aber gern mal einen zulegen.

    Da der P/4 die Reset-Leitung der 1551 übernehmen kann, sieht es wohl danach aus, dass dieser vor dem Ansprechen der Floppy diese einfach kurz resetet, um den ROM-Code neu zu starten:

    Code
    V_C046	DB $66,$C0	; $C066: N/A
    	DB $71,$C0	; $C071: Command w/ dev nr coming (TALK/LISTEN/UNTALK/UNLISTEN)
    	DB $D6,$C0	; $C0D6: Command w/ sec addr. coming (0x60, 0xE0, 0xF0)
    	DB $F6,$C0	; $C0F6: Data comes to the drive (filename, command, data etc.)
    	DB $4E,$C1	; $C14E: Data goes to computer

    Der sendet dann auf 4 Bit den lookup für die Tabelle und die Floppy kennt ihren Einsprung zur passenden Routine.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Nein, das tut er nicht, die Reset-Leitung ist die vom Plus/4 und kommt nicht von einem Portbit.

    Ausserdem würde dann der Motor bei jedem Zugriff kurz anlaufen auch wenn das Laufwerk selbst gar nicht gebraucht wird.

    Das muss über die IRQ-Routine laufen oder er hat eine Pollschleife irgendwo.


    Was anderes, wenn man keine 6523 oder 6525 mehr bekommen kann, müsste es eigentlich möglich sein sich die reine Funktionalität des 6523 aus zwei Stück 6522A mit passender Würfelung der Adressleitungen zu stricken. Meines Wissens wird der 6523/6525 als reiner Triport-Adapter benutzt, also 3x Datenregister und 3x Richtungsregister, keine Sonderfunktionen wie IRQs oder sowas.

    Der 68B21 geht leider nicht.

  • Nein, das tut er nicht, die Reset-Leitung ist die vom Plus/4 und kommt nicht von einem Portbit.

    Richtig, das war ja gar kein Portbit. Habe es nun gefunden:


    Wenn das 7te Bit gesetzt ist, springt die 1551 in die Auswertung, um dann den 4bit-ofset für die Tabelle umzurechnen. Danach erfolgt dann der Sprung in die passende Routine.

    Zwei 6522A ist aber schon etwas deftig. Könnte aber machbar sein.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Ich hätte auch gerne 2 x 68B21 benutzt, aber das geht nicht weil dort Datenregister und Richtungsregister über ein internes Registerbit umgeschaltet werden. Dann müsste man den Code umschreiben...

  • Mit Code-Umschreiben ist dann auch ein 6522A machbar. Wenn man einen AVR anschließen möchte, braucht man auch einen 6523A-kompatiblen Triport. Oder man nimmt ein intaktes Paddle, wenn man die Kernal-Routinen nicht patchen möchte. Das Interface ist so verwurschtelt, dass man Probleme beim Nachbilden bekommt. :)

    Das ganze PLA scheint doch nur da zu sein, um den Paddle im Speicher einzublenden ?

    Edit: Wenn man enorm auf Schmerzen steht, könnte man einen 8255 mit umfangreicher Logik davor anpassen. :)

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Die PLA braucht man nur um den 6523T im Speicher einzublenden. Wobei das Fenster 32 Byte groß ist und die Adresse sich je nach Unit # der 1551 ändert.

    Mit zwei Stück 6522 sollte man sich das Umschreiben des Codes sparen können...

    Ein 8255 hat keine bitweisen Datenrichtungsregister, da sehe ich gewisse Probleme. Deshalb die Idee mit den 2 x 6522A, die sind noch gut zu bekommen und man kann sich das Umschreiben des Codes sparen wenn man die Register passend in den Speicher bekommt.

  • Weißt Du ab welcher Adresse der P/4 das Paddle sieht ? - Dann könnte man mal ein bisschen Analyse über eigenes Programm treiben.

    Edit: hat sich erledigt - gefunden. :)

    Bitte melde dich an, um diesen Link zu sehen.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Bitte melde dich an, um diesen Anhang zu sehen.

    Wenn man davon ausgeht, dass PC6 und 7 von PortC in der Richtung festliegen, müsste auch obiger Ansatz funktionieren. Ich habe jetzt eine Adresse dekodiert, die normalerweise vom PLA generiert wird. PortC sind dann einfach zwei Flipflops, mehr braucht man dann eigentlich nicht.
    Für Port A und B muss dann ein 6522A verwendet werden und die Flipflops werden nur über A0, A1, R/W, etc. dekodiert. DDRC wird also ins Leere geschrieben, da das sowieso schon feststeht.

    Alles unter dem Vorbehalt, dass die beiden Handshake-Leitungen nicht bidirektional verwendet werden !

    Fehlt im Bild natürlich sehr umfangreiche Dekodierung. Und noch etwas um das eingehende Bit in High-Z zu schalten, wenn die Adresse nicht selektiert ist.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Leider zählt da nicht nur der Code im KERNAL, sondern auch der der existierenden Speeder die mit der 1551 funktionieren.

    Nachtrag: Als Dekoder hätte ich jetzt eher einen 74LS133 plus Kleinkram erwartet.

  • Letztlich hat man so oder so einen riesigen Bauteil-Verhau. Sinnvoller wäre wohl ein CPLD und ein 6522. Oder gleich ein passend großer programmierbarer Stein, in den alles rein passt.

    Aber ein Paddle am AVR könnte klappen. Mal sehen, ist vielleicht was für die Zukunft.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Es könnte mit TTL und einem 6529B vielleicht doch klappen. Die beiden Status-Bits muss man eigentlich auch nur lesen (?)

    Ich habe diesen Port diesmal mit Dekodierung dargestellt:
    Bitte melde dich an, um diesen Anhang zu sehen.

    Die anderen beiden Flipflops wären dann für die Handshake-Leitungen, sofern die auch wirklich unidirektional sind. Die bidirektionale Datenport wäre dann der 6529B. Der funktioniert schon über R/W, man kann dann also alle Datenrichtungsregister über die Klippe schicken.

    Damit könnte man dann vielleicht zumindest ein Paddle für eine 1551 nachbilden. Vielleicht müssen die P/4-Nutzer sich dann allerdings einen neuen Fastloader dafür schreiben, wenn der einzige Modulfastloader da nicht mitmacht. :)

    Wäre gesamt vielleicht mal das Experiment wert ..?

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Bisher hat das noch keiner gemacht

    Wie kommst du darauf? Ist allerdings schon 25 Jahre her, und ich müßte mich erst wieder einlesen (Tip: Das ROM-Listing von Ch. Q. Spitzner ist _etwas_ besser als das aus der Commodore-Sachbuch-Reihe...)

    Kurz gesagt ist das recht genau das IEC-Protokoll. Es gibt den 8-Bit-Datenbus, zwei Kontroll-Leitungen (eine von der Floppy, eine vom Rechner) sowie ATN (vom Rechner) und EOF (von der Floppy). Die Daten werden genau wie beim IEC übertragen, also: ATN setzen, Geräteadresse schicken (da werden ein paar Kontrollbits draus gebraucht, ich weiß nicht was die Floppy macht wenn da eine andere Adresse als ihre eigene ankommt- was ja eigentlich nicht gehen sollte...) Sekundäradresse schicken, ATN wieder zurücknehmen. Dann Daten schicken. Für jedes Datenbyte wird a) das Byte auf den 8-Bit-Bus gelegt, b) DAV umgedreht, c) die Floppy nimmt es an und d) kippt ihrerseits ACK. (Es kann sein, daß ACK und DAV nicht die im Schaltplan bezeichneten Leitungen sind)

    Zudem gibt es ein spetzielles Protokoll für die Umkehr der Datenrichtung, wenn die Floppy Daten senden soll. DAV/ACK tauschen dabei ihre Rollen, d.h. die Datenrictung auf den Kontroll-Leitungen bleibt gleich. Hat die Floppy fertig, signalisiert sie EOF mittels der letzten Steuerleitung. Der Computer muß dazu, IIRC, ein spezielles Kommando-Byte mit ATN übertragen - anders als beim IEC, wo auch der Computer eine ATN-Bedingung in das letze Datenbyte einflechten kann. Das ganze Gestrüpp müßte ich aber wirklich erstmal nachlesen.

    ...und dann gibts noch DEV, die Device-Steuerleitung von der Floppy. Die schaltet, wie schon ganz richtig gesagt, nur den Interface-Chip im Adreßraum des Computers um.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.