Die Drucker-Modelle K6311, K6312, K6313 und K6314 haben eine baugleiche
Interface-Kassette.
Sie unterscheiden sich im wesentlichen durch
ihre ROM- und RAM-Bestückung.
Als Exportvariante gab es diese Drucker unter der Bezeichnung
Präsident Printer 6320, 6325 usw.
Diese Drucker gab es mit folgenden Interface-Kassetten, soweit ich weiß:
IFSP - svw. Centronics, aber mit 3x13pol. Steckverbinder
Keine Dokumentation vorhanden, obsolet
Centronics - mit 2x18pol. Amphenol-Buchse, Exportvariante,
Schaltplan und Fotos vorhanden
IFSS - serielle Stromschnittstelle mit Optokopplern,
Fotos und Schaltplan im Vektorformat vorhanden
Seriell V.24 (svw. RS232) mit 2x13pol. Steckverbinder
Schaltplan vorhanden
Seriell RS232 mit 25-pol. SubD-Stecker (idiotisch, 9-pol. Buchse ist
viel praktischer, weil dann ein Verlängerungungskabel reicht!),
Exportvariante,
Schaltplan und Fotos vorhanden,
die Leiterplatte weist an der
SubD-Buchse eine DDR-Bestückungsvariante auf
Serielle Commodore-Schnittstelle, Export-Variante
Keine Dokumentation vorhanden
Will man mit der Zeit gehen und eine USB-Interfacekassette entwickeln,
stellt sich die Frage,
ob man mit einem heutigen Mikrocontroller die Z80-PIO einsparen kann,
d.h. den Mikrocontroller direkt am Z80-Bus betreiben kann.
So ein Z80-Bus ist ja verglichen mit heutigen Mikrocontrollern
„quasistatisch“, und die Drucker liefen IMHO mit U880B,
also max. 2,5 MHz Taktfrequenz.
Da dauern Lese- und Schreibzyklen (mit 3..4 Takten) über 1 µs,
kein Problem mehr.
Ein ATmega32U4, etwa auf einem Board „Pro Micro“ erscheint schnell genug,
und es sind auch genug Pins verfügbar.
Er kann sich dediziert um den Z80-Bus kümmern,
da die USB-Seite hardware-unterstützt ist.
Auf der USB-Seite wird man wohl die Drucker-Klasse (inklusive PnP)
und/oder die CDC-Klasse (serielle Schnittstelle) implementieren.
Auch eine PIC, etwa PIC18F25K50
bietet sich zur Implementierung an,
da es diesen Chip im bastelfreundlichen Durchsteckgehäuse gibt,
der das Zwischenboard auf der Lochrasterplatine erspart
und keinen (!) Quarz benötigt.
16- und 32-Bit-Controller machen sich hier nicht so gut,
weil es keine Typen mit 5-V-E/A-Spannungen gibt.
Folgende Signale sind abzugreifen:
Busleitung
Richtung am µC
Bedeutung
Portlesen
Portschreiben
Intvektor lesen
Int-Ende
Reset
D7..D0
bidirektional
Datenbus
out
in
out
in (ED-4D)
Z
CS
Eingang
Chipselect
L
L
x
x
x
C/D
Eingang
Adressbit 1
auswerten
x
x
x
B/A
Eingang
Adressbit 0
auswerten
x
x
x
M1
Eingang
Befehlslesen (Opcode)
H
H
L
L
x
IORQ
Eingang
Ein-/Ausgabeanforderung
L
L
L
H
x
RD
Eingang
Lesen
L
H
L
L
x
RESET
Eingang
Rücksetzen
H
H
H
H
L
C
entfällt
Takt
x
x
x
x
x
IEI
Eingang
Interruptfreigabeeingang
x
x
H
H
x
IEO
Ausgang
Interruptfreigabeausgang
IEI & (internes) INT
H
INT
Ausgang (L oder Z)
Interruptanforderung
je nachdem
H
Z80-Bussignale, die auszuwerten sind
RESET kann man demnach rotzfrech mit dem Reset-Eingang
des Mikrocontrollers verbinden und spart so ein Pin sowie die Auswertung.
Das ergibt folgende in Software zu implementierende Kombinatorik:
Signal
D7..D0
CS
C/D
B/A
M1
IORQ
RD
IEI
Daten-Ausgabe
anlegen
L
auswerten
H
L
L
x
Daten-Eingabe
auslesen
L
auswerten
H
L
H
x
Interruptvektor-Ausgabe
anlegen
x
x
x
L
L
L
H
Interrupt-Ende (1)
0xED
x
x
x
L
H
L
H
Interrupt-Ende (2)
x
x
x
x
H
H
H
H
Interrupt-Ende (3)
0x4D
x
x
x
L
H
L
H
Kombinatorik; INT ist davon unabhängig
Am schwierigsten macht sich die Auswertung der Interruptgeschichten.
Während die Standardzyklen überall im Web publiziert sind,
findet es sich schlecht für die
Interruptannahme
und erst recht für das Interruptende.
In beiden Fällen darf der Mikrocontroller nur bei IEI = H aktiv werden.
Da hier IEO nicht verwendet wird
(d. h. das Interface-Modul ist das letzte Glied der Interruptprioritätskette)
kann man dieses Signal einsparen.
Da die Interruptanforderung INT bereits bei Ausgabe des Interruptvektors
zurückgenommen werden kann und IEO nicht benötigt wird,
kann man sich das Dekodieren von RETI sparen.
Der Mikrocontroller benötigt somit exakt 16 „normale“ Pins für die Buskommunikation.
Da reicht der „Pro Micro“ aus, und man hat sogar noch RxD und TxD frei.
Es ist zu vermuten, dass die RETI-Dekodierlogik
bei jeder Z80-Peripherie durcheinanderkommt,
wenn ein Mehrbytebefehl ohne Datenlesephase mit 0xED
(beispielhaft CB-ED = SET 5,L) endet
und danach ein Befehl 0x4D (= LD C,L) kommt.
Die Hauptarbeit ist dann nur noch die Emulation
der Z80-PIO (aka U855D) in der Firmware des ATmega32U4
oder PIC18F25K50.
Wie man sieht genügt eine ISR,
die pegelgetriggert mit IORQ = L
oder flankengetriggert mit IORQ = ↓
aufgerufen wird.
