TCBM-Bus Analyse ?


  • cbmhardware
  • 1866 Views 23 replies

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • TCBM-Bus Analyse ?

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

    cbmhardware.de/floppy/vc1551/251860.gif

    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) -
  • 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: zimmers.net/anonftp/pub/cbm/firmware/drives/new/1551/README
  • 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: zimmers.net/pub/cbm/schematics…ew/1551/paddle-251925.png
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
  • 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:
    Images
    • paddle_reparatur.gif

      78.93 kB, 1,138×1,401, viewed 58 times
  • 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:

    yape.homeserver.hu/download/C1551.ASM


    Brainfuck Source Code

    1. ;--------- Start of 1551 ROM program
    2. S_C022 LDA V_4000 ; read data from computer
    3. CMP V_4000 ; port stable?
    4. BEQ B_C02D ; if yes, then jump
    5. JMP L_EABD ; otherwise back to main wait loop
    6. ;
    7. B_C02D AND #$0F ; lowest 4 bits only
    8. ASL A ; * 2
    9. TAY ; Y = A, make it an index
    10. LDA V_C046,Y ; look up address of subroutine
    11. STA zp6E
    12. LDA V_C046 + 1,Y
    13. STA zp6E+1 ; $6E/$6F
    14. LDA V_4002
    15. AND #$F7
    16. STA V_4002 ; ACK handshake
    17. JMP ($006E) ; *** Indirect jump to TCBM bus command handler
    Display All


    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) -
  • 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) :

    Brainfuck Source Code

    1. P/4 1551
    2. -------- | ---------
    3. <- ACK_1
    4. DAV ->
    5. <- BYTE
    6. $0d
    7. DAV ->
    8. BYTE->
    9. <- ACK_0



    Source Code

    1. ;
    2. ;$C14E -------- Data goes to computer
    3. ;
    4. B_C14E LDA V_4002
    5. BMI B_C14E ; wait for DAV handshake from plus/4
    6. LDA #$FF
    7. STA V_4003 ; set TIA port A to all outputs
    8. ...


    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) -
  • 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:

    Source Code

    1. V_C046 DB $66,$C0 ; $C066: N/A
    2. DB $71,$C0 ; $C071: Command w/ dev nr coming (TALK/LISTEN/UNTALK/UNLISTEN)
    3. DB $D6,$C0 ; $C0D6: Command w/ sec addr. coming (0x60, 0xE0, 0xF0)
    4. DB $F6,$C0 ; $C0F6: Data comes to the drive (filename, command, data etc.)
    5. 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) -
  • 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.
  • Gerrit wrote:

    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:

    Source Code

    1. ; Main wait loop
    2. ;
    3. L_EABD INC zp61 ; count
    4. BNE B_EAC4 ; if not zero, skip next call
    5. JSR S_EADC
    6. B_EAC4 LDA V_4000 ; read I/O port from computer
    7. BPL B_EACC ; 7th bit set?
    8. JSR S_C022 ; yes, then jump
    9. B_EACC LDA V_0255 ; waiting for command?
    10. BEQ L_EABD ; no...
    11. LDA #$00 ; yes
    12. STA V_0255 ; clear command flag
    13. JSR S_C230 ; analyze and execute command
    14. JMP L_EABD ; back to main loop
    15. ;
    Display All



    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) -
  • 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) -
  • 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. :)

    floodgap.com/retrobits/ckb/secret/264memory.txt

    Source Code

    1. $FDE0-FEBF: not mapped (but may be slots for additional drives not supported
    2. by the 1551)
    3. $FEC0-FEFF: TIA mappings for 1551 disk drives #9 and #8
    4. $fec0-fedf TIA 6523A if you have a CBM 1551 as device #9
    5. then the TIA located in the paddle of
    6. you drive will appear at this location
    7. for details see $fee0-feff
    8. $fee0-feff TIA 6523A if you have a CBM 1551 as device #8
    9. then the TIA located in the paddle of
    10. your drive will appear at this location
    11. $fee0 TIA PORT A (DATA)
    12. $fee1 TIA PORT B (STATUS)
    13. $fee2 TIA PORT C (HANDSHAKE)
    14. $fee3 TIA PORT A data direction register
    15. $fee4 TIA PORT B data direction register
    16. $fee5 TIA PORT C data direction register
    17. $fee6 not connected
    18. $fee7 not connected
    19. $fee8-feef TIA copy
    20. $fef0-fef7 TIA copy
    21. $fef8-feff TIA copy
    Display All
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -


  • 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) -
  • 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) -
  • 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:


    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) -
  • Gerrit wrote:

    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.