Hello, Guest the thread was called5.8k times and contains 23 replays

last post from cbmhardware at the

TCBM-Bus Analyse ?

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


    http://www.cbmhardware.de/floppy/vc1551/251860.gif


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

  • 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: http://www.zimmers.net/anonftp…re/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: ftp://www.zimmers.net/pub/cbm/…ew/1551/paddle-251925.png

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


    http://yape.homeserver.hu/download/C1551.ASM




    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 ?

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



    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.

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

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

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

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


    http://www.floodgap.com/retrobits/ckb/secret/264memory.txt



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

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

  • 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 ..?

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