Dieses Programm
ist für alle, die einen Sharp-Pocketcomputer der
Serie PC-140x
und Zugriff auf einen IBM-kompatiblen PC oder AT
haben. Es dient
zur Dateiübertragung zwischen den beiden Rechner-
typen. Damit
kann man Programme auf dem PC mit seinem Lieblings-
editor schreiben
und hinterher über Kabel zum Sharp übertragen.
Oder umgekehrt
lassen sich Programme vom Sharp zum PC schicken
und dort ausdrucken.
Oder einfach auf der Festplatte oder Disket-
te archivieren.
Oder ...
Voraussetzung
ist ein kompatibler PC oder AT mit mindestens einer
freien parallelen
Schnittstelle und ein (selbstgelötetes) Kabel.
Ein Schaltungsvorschlag
folgt weiter unten in dieser Dokumenta-
tion.
Eine kurze Bemerkung
im voraus: ALLE Zahlenangaben in diesem Text
sind Hexadezimalzahlen,
auch wenn sie nicht ausdrücklich als
solche markiert
sind. Erscheinen irgendwo dezimale Zahlen, so
sind sie ausdrücklich
als solche gekennzeichnet.
Außerdem
ist darauf zu achten, daß der Sharp PC-1403 auch kleine
Buchstaben beherrscht.
Besitzer der "älteren" Sharps, die nur
Großbuchstaben
kennen, müssen beim Eingeben der Programme selbst
darauf achten,
daß in Kommentaren (REM-Zeilen) und Textstrings
keine Kleinbuchstaben
vorkommen. Bei den Basic-Befehlen selbst
spielt die Graphie
keine Rolle.
Wenn Daten an
den Sharp übertragen werden (Menüpunkt zwei), so
produziert das
Programm unerbittlich seine Tonfrequenzen, auch
wenn gar kein
Sharp angeschlossen ist. Man kann diesen Vorgang
nicht einmal
mit dem "Affengriff" unterbrechen. Das liegt daran,
daß während
des Sendens alle Interrupts gesperrt sind. Leider
läßt
sich das nicht verhindern, da sonst nicht sichergestellt
werden kann,
daß das Timing exakt eingehalten wird. Beim Empfan-
gen von Daten
(Menüpunkt zwei) gilt übrigens ähnliches, jedoch
wird dort nach
spätestens 5 Sekunden mit einem Timeout abgebro-
chen, wenn kein
gültiges Signal vom Sharp gelesen werden kann.
Die Sache mit
dem gesperrten Interrupt hat übrigens auch noch den
Nebeneffekt,
daß die Systemuhr im PC hinterher ein paar Minuten
nachgeht, da
sie direkt vom Timerinterrupt abhängig ist.
Das Programm
benutzt zum Senden von Daten an den Sharp eine Va-
riable, die
die benötigte Zeitkonstante enthält. Diese Variable
ist mit einem
Standardwert, der für den "normalen" Sharp berech-
net wurde, initialisiert.
Bei jedem Ladevorgang wird diese Zeit-
konstante anhand
des Synchronisationssignals neu berechnet. Wer-
den also zuerst
irgendwelche "Dummy"-Daten vom Sharp zum PC über-
tragen (der
Vorspann reicht schon aus, danach darf BREAK gedrückt
werden), so
wird die Zeitkonstante neu berechnet und behält bis
zum Programmende
ihre Gültigkeit.
Typ
¦ speichern/laden z.B. mit
-------------------+-------------------------------------------------
Basic
¦ CSAVE
CLOAD
¦ CSAVE "NAME"
CLOAD "NAME"
Basic mit
Password ¦ CSAVE ,"PASWORD"
CLOAD
¦ CSAVE "NAME","PASWORD" CLOAD "NAME"
Binärdateien
¦ CSAVE M;Startadresse,Endadresse
¦ CSAVE M"NAME";Startadresse,Endadresse
¦ CLOAD M
CLOAD M"NAME"
¦ CLOAD M;Ladeadresse CLOAD M"NAME";Ladeadresse
Datendateien
¦ PRINT #Variable
PRINT #"NAME";Variable
¦ INPUT #Variable
INPUT #"NAME";Variable
Noch einige Anmerkungen dazu:
Datendateien
können nur sehr eingeschränkt benutzt werden, da mir
das genaue Dateiformat
nicht bekannt ist. Konkret heißt das, daß
beim PRINT#-Befehl
keine Variablenliste angegeben werden kann,
sondern nur
eine einzige Variable. Konstrukte mit Sternchen (z.B.
"PRINT #B*")
sind allerdings erlaubt. Für Hinweise zu diesem
Thema bin ich
natürlich dankbar.
Die Syntax
einiger der aufgeführten Befehle ist (glaube
ich)
nicht korrekt.
So merkwürdig sich das anhört: ich selbst bin kein
Besitzer eines
Sharp-Rechners; daher kann ich für die korrekte
Syntax der Befehle
nicht garantieren.
Mit Microsoft-Programmen:
cl /c /AS /Ox /Gs sharp.c
masm /Mx sharplow;
link sharp+sharplow;
Oder einfach:
make sharp
Mit den Borland-Produkten:
tcc -c -ms -I\tc\include sharp.c
tasm /Mx sharplow
tlink \tc\lib\c0s sharp sharplow, sharp,, \tc\lib\cs
Oder auch:
tcc -c -ms sharp.c sharplow.asm
Oder ganz einfach
automatisch mit dem Borland-Make:
make
Für die
intergrierte Entwicklungsumgebung von Turbo-C gibt es
eine Project-Datei
(SHARP.PRJ), die über den Menupunkt
Pro-
ject/Project
name eingeladen werden sollte; danach sollte ein
einfaches
Compile/Make EXE file ausreichen, um das
fertige
Programm zu
generieren.
Voraussetzung
ist natürlich, das sich C-Compiler und -Assembler
im Suchpfad
befinden, und daß die Borland-Bibliotheken
und
Inlcude-Dateien
wirklich im Verzeichnis "\tc\lib" bzw.
in
"\tc\include"
stehen. Andernfalls müssen Sie TLINK und TCC die
entsprechenden
Verzeichnisse mitteilen. Die Warnungen des
C-
Compilers können
ignoriert werden.
Falls später
mal jemand eigene Forschungen betreiben will: Werden
die Routinen
"holesharp (&Header)" und "sendesharp (&Header)" mit
Header.Dateityp
= S_DUMP aufgerufen, so werden die Daten vom/zum
Sharp übertragen,
ohne daß Header, Prüfsummen etc. interpretiert
werden. Aber
Vorsicht: bei allen Bytes wurden nach dem Empfang
Low- und High-Nibble
vertauscht!
Pin ¦ Richtung ¦ Bedeutung
+-------------
----+----------+-------------
¦ on
1 ¦ ?? ¦ ??
1 --¦ +-+ +---------
2 ¦ --- ¦ Vcc
(+6V) 2 --¦ ¦ ¦ ¦
3 ¦ --- ¦ Ground ( 0V)
3 --¦ +-+ ¦ > CSAVE¦
4 ¦ out ¦ Busy
4 --¦ off ¦ _ _
5 ¦ out ¦ Data out
5 --¦ +-----------
6 ¦ in ¦ Load
6 --¦
7 ¦ out ¦ Save
7 --¦ +---+ +---+ +---
8 ¦ in ¦ Data in
8 --¦ +---+ +---+ +--
9 ¦ in ¦ Ack
9 --¦ +---+ +---+ +-
10 ¦ --- ¦ n.c.
10 --¦ +---+ +---+
11 ¦ --- ¦ n.c.
11 --¦ +---+ +--
¦ +---+
Relevant für
die Datenübertragung vom/zum PC sind die Leitungen
Ground (3),
Load (6) und Save (7). Beim PC wird die Drucker-
schnittstelle
als universeller I/O-Port mißbraucht. Sie ist übri-
gens hervorragend
geeignet für einfache Steuerungsaufgaben mit
ihren (je nach
Beschaltung und Programmierung) bis zu 12 Aus- und
9 Eingängen.
In diesem Fall wird nur je ein Ein- bzw. Ausgang
benötigt.
Diese Funktion übernehmen die Pins D0
(Datenbit 0,
Pin 2) als Ausgang
und Strobe (Pin 1) als Eingang. Die Masse kann
man z.B. an
Pin 18 entnehmen.
Da im Sharp
CMOS-Bauteile, im PC aber meist TTL-IC's stecken,
sollte man zum
Schutze des Sharp (und seiner dünnen Knopfzellen)
die Leitungen
nicht direkt verbinden. Mein Schaltungsvorschlag
sieht folgendermaßen
aus (ich hoffe, der IBM-Zeichensatz gibt ge-
nug Grafiksymbole
her...):
PC
Sharp
Signal
Pin
Pin Signal
BC548 oder
Strobe
1 --------------+ BC238
C \¦_____+-------+_______ 7 Save
/¦ B +-------+
E¦ 47 kOhm
Ground
18 -------------------------------------- 3 Ground
Data 0
2 __________+-------+___________________ 6 Load
+-------+
ca. 10 kOhm
(Das soll mir
mal einer nachmachen, im Textmodus einen Schaltplan
zu zeichnen.
Zugegeben, der Transistor läßt etwas zu wünschen üb-
rig, aber er
ist doch ganz gut zu erkennen...)
Ich glaube, ich
bin einigen Leuten noch eine kleine Erklärung
schuldig. Einem
aufmerksamen Leser wird wohl nicht entgangen
sein, daß
"Strobe" eigentlich ein Signal vom PC zum Drucker ist
und nicht umgekehrt.
Das ist im Prinzip richtig. Aber in IBMs
paralleler Schnittstelle
ist diese Leitung als Open Collector
ausgeführt
(die es betrifft, wissen jetzt bescheid), mit einem
eingebauten
Pull-Up-Widerstand von 4,7k. Diesen Ausgang kann man
über einen
anderen Portbaustein zurücklesen. Wird nun die Strobe-
Leitung auf
5V gelegt (der interne Transistor sperrt), so kann
man mit einem
externen Schalter/Transistor/Schalttransistor (eben
den BCsowieso
von oben) gegen Masse den Pegel der Leitung ändern,
ohne irgendwelchen
Schaden anzurichten. Dieser so eingestellte
Pegel läßt
sich dann über oben genannten Port auslesen.
Im Laufe
der Zeit hat sich herausgestellt, daß das
Interface
nicht an allen
parallelen Schnittstellen arbeitet, die im Umlauf
sind.
An den "alten" Ports, die noch
aus TTL-Bausteinen
kompatibel aufgebaut
sind, sollte das Interface problemlos seinen
Dienst tun.
Allerdings gibt es Probleme mit einigen
dieser
neumodischen
Druckerkarten, die, vielleicht sogar in Kombination
mit einer CGA-
oder Herkuleskarte, aus integrierten Gate-Arrays
aufgebaut sind.
Ich habe die Ursachen nicht näher untersucht.
Vielleicht fehlt
es diesen Karten an den Pull-Up-Widerständen bei
den Steuerleitungen?
Ist man (un)glücklicher Besitzer einer
solchen Karte,
kann man sich notfalls damit helfen, daß man die
Leitungen direkt,
das heißt ohne Transistor und Widerstände,
miteinander
verbindet (also Pins 1 -- 7, 18 -- 3 und 2 -- 6).
Dann sollte
man aber den Sharp nicht tagelang am PC angeschlossen
lassen, sondern
nur für die Dauer der eigentlichen Übertragung.
Vielleicht bin
ich etwas übervorsichtig, aber neue Batterien für
den Sharp sind
ja auch nicht ganz billig.
Bit¦ der Sharp sendet
---+----------------------
0 ¦ 4 Perioden zu 2000 Hz
1 ¦ 8 Perioden zu 4000 Hz
Angenommen, das
zu übertragende Byte sei `hgfedcba', wobei a das
Bit 0 und h
das Bit 7 ist. Dann produziert der Sharp folgenden
Bit-Brei:
H-Typ: Nicht verdreht
0abcd10efgh11...
mit 0--------------- 1 Startbit
-abcd----------- 4 Datenbits (unteres Nibble)
-----1---------- 1 Stopbit
------0--------- noch ein Startbit
-------efgh----- 4 Datenbits (oberes Nibble)
-----------11... 2 bis 5 Stopbits
D-Typ: Low- und High-Nibble vertauscht
0efgh10abcd11...
mit 0--------------- 1 Startbit
-efgh----------- 4 Datenbits (oberes Nibble)
-----1---------- 1 Stopbit
------0--------- noch ein Startbit
-------abcd----- 4 Datenbits (unteres Nibble)
-----------11... 2 bis 5 Stopbits
Wo welcher Typ
mit wieviel Stopbits erscheint, werde ich in den
nächsten
Kapiteln jeweils mit angeben.
Ein `Name' sieht dabei so aus:
Byte¦ Typ ¦ Funktion
----+-------+------------------------------------------
00 ¦ H-Typ ¦ Dateiname, 7. Buchstabe
01 ¦ H-Typ ¦ Dateiname, 6. Buchstabe
...¦ ... ¦ ...
05 ¦ H-Typ ¦ Dateiname, 2. Buchstabe
06 ¦ H-Typ ¦ Dateiname, 1. Buchstabe
07 ¦ D-Typ ¦ Kennung für das Ende des Namens (immer
5F)
08 ¦ D-Typ ¦ Prüfsumme über die Bytes 00 bis 07
Der Dateiname
wird immer auf sieben Zeichen gestreckt oder ge-
kürzt.
Ist der Name kürzer, so wird er mit Nullen (das ASCII-Zei-
chen NUL, keine
"0") aufgefüllt. Das gilt auch, wenn kein Name
angegeben wird,
er besteht dann aus sieben Nullen. Das Feld für
das Password
existiert nur, wenn es im Dateityp vermerkt ist,
sonst wird es
weggelassen. Folgende Dateitypen sind mir bis jetzt
bekannt:
Typ ¦ Bedeutung
----+----------------------------
70 ¦ Basic-Programm
71 ¦ Basic-Programm mit Password
74 ¦ Datendatei
76 ¦ Binärdatei
Im Header sendet
der Sharp übrigens hinter jedem Byte 5, in Wor-
ten: "fünf",
Stopbits.
In Assembler läßt sich das z.B. so in Befehle fassen:
Pruefsumme
DB 0
; hier landet die Prüfsumme
; ...
Pruefe
PROC
; Das Byte,
das `geprüft' werden soll, ist in AL
mov ah, al ; rette
eine Kopie
mov cl, 4
shr ah, cl ; AH enthält
das High-Nibble
and al, 0Fh ; und AL das
Low-Nibble
add Pruefsumme, ah ; addiere High, Überlauf im Carry
adc Pruefsumme, al ; und Low-Nibble mit Übertrag
ret
Pruefe
ENDP
Dabei ist zu
beachten, daß die Prüfsumme über die "echten" Daten
gebildet wird.
Das spielt eine Rolle bei Bytes des `D-Typs'
(siehe oben),
bei denen der Sharp die Nibbles verdreht. Die Prüf-
summe wird erst
nach dem "Entknoten" des Bytes berechnet (oder
vor dem Verdrehen,
wenn man selbst die Daten sendet).
Bei den Prüfsummen
im Header muß man darauf achten, daß das erste
Byte (der Dateityp)
nicht mit überprüft wird. Es wird nur die
Quersumme über
den Namen und das Password (wenn vorhanden) gebil-
det, wobei sie
vor letzterem natürlich wieder auf Null gesetzt
wird. Das Passwordfeld
im Header gilt als eigenständiger "Daten"-
Block.
Der Aufbau der
eigentlichen Daten nach dem Header hat so seine
Tücken.
Mir ist nur die Struktur eines Basic-Programms einiger-
maßen
bekannt, zu den anderen Datentypen kann ich keine näheren
Angaben machen.
Also zum Basic-Programm. Alle Bytes in einem Ba-
sicprogramm,
die nach dem Header kommen, sind übrigens vom "D-
Typ", auch
die Prüfsummen. Außerdem reduziert der
Sharp die
Anzahl der Stopbits
in den Daten auf zwei.
Allgemein gilt,
daß nach jeweils 120 (dezimal!) Datenbytes des
Basic-Programms
eine Prüfsumme eingefügt wird. Ein Basic-Block
ist also
120 Bytes lang. Nach jedem Block wird die Prüfsumme
wieder auf Null
zurückgesetzt. Am Ende des Programms stehen 2 FF-
Bytes, von denen
das erste eigentlich noch zum Programm gehört.
Nach den beiden
Eff-Effs steht noch eine abschließende Prüfsumme,
in der alle
Bytes dieses letzten Blocks, bis einschließlich das
erste FF-Byte,
enthalten sind - das letzte FF ist nicht mit drin.
Da ich mit diesen
Regeln beim Überprüfen der Prüfsummen am Ende
eines Programms
einige Schwierigkeiten hatte, will ich den Vor-
gang noch einmal
anders formulieren: Es muß zuerst das gesamte
Programm eingeladen
werden. Dann werden die Datenblöcke solange
"normal" in
einer Schleife überprüft (Prüfsumme alle 120 Bytes),
bis noch genau
3 Bytes über sind. Man nehme das erste davon (es
muß ein
FF sein) und nehme es mit in die Prüfsumme hinein. Dann
nehme man das
zweite (es muß ebenfalls FF sein) und ignoriere es.
Dann nehme man
das dritte und letzte und vergleiche es mit der
berechneten
Prüfsumme. Sie müssen übereinstimmen, sonst
stimmt
bei Ihrem Programm
was nicht. Diesen Aufwand muß man (leider)
treiben, da
man sonst Probleme bekommt, wenn der letzte Daten-
block ungefähr
120 Bytes lang ist (119 oder 120 Bytes).
Übrigens:
Das Programm darf (soll!) sich jeder kopieren, den es
interessiert.
Die Dateien sollten nur alle zusammen bleiben, denn
ich weiß
aus eigener Erfahrung, wie schmerzhaft es ist,
wenn
plötzlich
eine Datei fehlt (wenn es auch nur eine Header-Datei
ist ...).
Dieses Programm
soll auch nicht das absolute Produkt darstellen;
jeder soll
sich frei fühlen, selbst Verbesserungen
und Er-
weiterungen
vorzunehmen. Ich hoffe, die Quelltexte sind einiger-
maßen
lesbar und verständlich.
Norbert Unterberg,
Köhlerstr. 12c,
D-5802 Wetter 2