USB-Stick am KC85/4
Idee:
Im ELV-Journal 5/2007 (erschienen Oktober 2007) wurde ein USB-Stick-Interface „STI 100“ vorgestellt, mit dem sich durch relativ einfache Befehle auf einen USB-Stick zugreifen lässt. Abgedruckt war bereits auch der Großteil der Steuerbefehle. Das weckte in mir die Neugier und den Wunsch, das vom KC aus zu steuern!
Mit Spannung wartete ich auf Teil 2 dieses Artikels im ELV-Journal 6/2007 (Dezember). Doch leider erfüllten sich nicht alle Erwartungen, die ich mir wünschte: größter Nachteil ist die serielle Schnittstelle mit TTL-Pegel, die als einziges herausgeführt ist. Der Preis der Schaltung bei ELV ist 37,95 € - also eine durchaus machbare Angelegenheit.
Vinculum:
Kernstück der ELV-Schaltung ist ein Chip mit der Bezeichnung VNC1L der Firma Vinculum. Im Internet unter http://www.vinculum.com gibt es weitere Informationen zu diesem Chip und dessen Anwendungen. Der Chip bietet auch eine parallele Schnittstelle, die am KC wesentlich einfacher zu bedienen ist. Direkt von Vinculum werden so genannte Prototyping Module (Entwicklermodule) angeboten, die relativ einfach zu handhaben – da auf einen normalen IC-Sockel aufsetzbar sind.
Es gibt die beiden Varianten VDIP1 und VDIP2.
VDIP1 hat nur einen USB-Anschluss für den USB-Stick und alle Schnittstellensignale (seriell und parallel) herausgeführt. Ein zweiter USB-Port ist an der Steckerleiste verfügbar.
VDIP2 hat zwei USB-Anschlüsse und noch weitere Signale herausgeführt. Dafür ist das Modul wesentlich größer - 40polig - und auch höher wegen der senkrechten USB-Anschlüsse.
Eine Recherche im Internet ergab, dass der Baustein VDIP1 sogar in Deutschland zu beziehen ist: bei SEGOR-Elektronik in Berlin http://www.segor.de für 39,00 € zuzüglich Versandkosten (Stand: November 2007). Also fast der gleiche Preis wie bei ELV, aber am KC besser geeignet! So habe ich mir das Teil Ende November 2007 bestellt. Die ersten Versuche damit habe ich dann Ende Dezember 2007 (nach Fertigstellung von NC 0.3) begonnen.
Hardware:
Zur Nutzung der Parallelschnittstelle war zunächst klar, dass der Anschluss am M001 erfolgen wird. Hier stehen zwei PIO-Ports zur Verfügung und Kanal A kann auch bidirektional arbeiten – also Daten empfangen und senden. Kanal B muss dazu im Bitbetrieb arbeiten und kann so für die Bedienung der Statussignale herangezogen werden.
Zunächst galt es die Signalspiele beim Lesen und Schreiben von Daten zu analysieren, also das Handshake zu begreifen. Der Vinculum-Chip zeigt an zwei Pins seinen Status an, zwei weitere Pins dienen als Steuersignale:
RXF# geht auf Low sobald Daten abgeholt werden können
TXE# zeigt mit Low an, dass Daten geschrieben werden können
RD# ein Low-Impuls liest ein Datenbyte
WR ein High-Impuls schreibt Datenbyte ein
Dieses Signalspiel eignet sich leider nicht, um die 4 Signale direkt mit den Strobe- und Ready-Leitungen einer Z80-PIO zu verbinden und diese damit direkt bidirektional zu betreiben. So musste ich die Handshake-Signale an PIO-Port B legen und programmiertechnisch abfragen. Um den bidirektionalen Kanal A von Eingabe auf Ausgabe umzusteuern, ist es erforderlich, die PIO-Anschlüsse A-Strobe und B-Strobe zu beschalten. Dies übernimmt ein zusätzlicher DL000 (74LS00), der von den Leitungen RD# und WR mitgesteuert wird und so automatisch die passende Datenrichtung freigibt.
- Dazu ist es ausreichend ASTB zu beschalten - dann wird bereits das PIO- Ein/Ausgaberegister umgeschalten. So könnte BSTB zur Interrupt-Auslösung genutzt werden wenn Daten verfügbar sind. Eine direkte Anschaltung von RXF# auf BSTB funktioniert aber nicht, auch nicht mit Negation. Denn BSTB muss zwingend Low sein, damit die Daten bei der Eingabe auch im Eingaberegister übernommen werden. BSTB kann jedoch auch Interrupts auslösen, und zwar mit der L/H-Flanke (!) mit dem Hintergrund dass die Eingabedaten damit im Eingaberegister verfügbar sind. So habe ich die ursprüngliche Schaltung dahingehend modifiziert, dass sowohl bei der Eingabe BSTB Low ist, als auch das Signal "Daten verfügbar" einen L/H-Wechsel verursacht wenn neue Daten verfügbar sind, RXF# also auf Low geht (und nicht gerade eine Eingabe läuft).
Software:
Die ersten Tests erfolgten mit dem KC-Debugger TEMO, der Bestandteil von CAOS ab Version 4.3 ist. Durch direkte Ein- und Ausgabebefehle konnte ich schließlich die allerersten Bytes aus dem Modul entlocken und Byte für Byte dei erste Statusmeldung decodiert!
Inspiriert von den Abbildungen im ELV-Journal brauchte ich nun zunächst ein Terminalprogramm für CAOS. Es muss Ausgaben zum VDIP1 senden und die Rückgaben am Bildschirm darstellen können. So entstand Schritt für Schritt das Programm VDIPx.KCC (Edas-Quelltext VDIPx.ASM) in vier Varianten:
VDIP1.KCC: Hier arbeitet PIO-A bidirektional und PIO-B im Bitbetrieb. Da PIO-B in dieser Konfiguration nicht in der Lage ist Interrupts auszulösen, verwende ich den CTC im M001 um den Status abzufragen und darauf zu reagieren (Bedienung Terminal-Fenster)
VDIP2.KCC: Hier arbeiten beide PIO-Kanäle im Bitbetrieb. Bit 0 von PIO-B löst Interrupt aus sobald dieses Bit auf 0 geht, also Daten zur Abholung anliegen. Für die Ausgabe von Daten wird PIO-A auf Ausgabe uminitialisiert.
VDIP3.KCC: Umstellung auf Schaltplan Version 1.1, das heißt, PIO-A arbeitet jetzt bidirektional, PIO-B arbeitet im Bitbetrieb und ermöglicht die Abfrage der Status-Signale. BSTB löst Interrupt aus und steuert das Terminalfenster. EPROM-tauglich wie VDIP4.KCC
VDIP4.KCC: wie VDIP1.KCC - jetzt EPROM-tauglich! Das Programm muss also später in einen EPROM-Bereich von CAOS oder ein E(E)PROM-Modul um ohne D004 den USB-Stick sofort nutzen zu können.
CAOS TerminalprogrammVDIP12.KCC: Weiterentwicklung bezüglich Zusammenarbeit mit CAOS 3.1 bis CAOS 4.4.
Enthalten sind inzwischen die CAOS-Programme LOAD und SAVE, die genau wie die Original(Kassetten-)routinen arbeiten und direkt den USB-Stick verwenden. Außerdem gibt es das Kommando TEST, das wie LOAD die Daten vom USB-Stick liest, jedoch nicht in den RAM des KC abspeichert - gedacht für Testzwecke, z.B. Ermittlung der Transfergeschwindigkeit. Das Programm gibt es hier: CAOS-Terminalprogramm zum USB-Stick und den dazugehörigen EDAS-Quelltext ebenfalls: EDAS-Quelltext von VDIP12.KCC
Nächste Herausforderung war CP/M: Hier sollte ein Programmpaket entstehen, das einen ähnlichen Funktionsumfang wie die MTools bzw. WTools hat. So sind diese Programme von mir als „UTools“ getauft worden. Grundlage ist ein spezieller Treiber, der den Zugriff auf den VDIP1 über das M001 steuert. Dieser Treiber enthält nur die Funktionen zur Initialisierung/Deinitialisierung, Zeichenein- und ausgabe sowie die Statusabfrage. Die restlichen Funktionen übernehmen die CP/M-Programme. Die UTools bestehen aus:
USB11.DRV der USB-Treiber über M001 zu Schaltplan V1.1
USB.COM Direkte Befehle zum VDIP1 senden
UDIR.COM komfortable Verzeichnisanzeige
UGET.COM Datei(en) zum USB-Stick senden
UPUT.COM Datei(en) vom USB-Stick empfangen
Ausblick:
Eine Nachnutzung der Variante mit dem M001 ist relativ schnell möglich. Zu beachten ist dabei dass ein Pin des M001-Steckers von Masse auf +5V gelegt werden muss um die Stromversorgung der angeschlossenen Schaltung zu ermöglichen - ansonsten ist ein Extra-Netzteil nötig. Ein Schaltplan des M001 findet Ihr bei Bedarf ebenfalls im Downloadbereich: Schaltplan M001
Eine Leiterplatte habe ich nicht entworfen, da alles auf einer Lochrasterplatine großzügig aufgebaut wurde, siehe Foto:
Entwicklung eines eigenständigen KC-Moduls, bei dem das VDIP1 eingebaut ist und nur die USB-Anschlusbuchse(n) herausgeführt ist.
CAOS-Software im USER-EPROM, Ebene F (bisher Forth)