Zusammenfassung
- Alan R. Katz dokumentierte im September 1981 ein laufendes Programm, das gespeicherte Rapicom-450-Faxdaten in ein einfarbiges Bitmap übersetzte. Ein gespeicherter Datensatz war noch keine sichtbare Seite.
- Datenbytes, ausgewählte Kopffelder und Längenwörter für schwarze oder weiße Strecken hatten unterschiedliche Umkehrregeln. Blockköpfe halfen nach Verlusten bei der Fortsetzung; RFC 797 gab dem Ergebnis einen einfachen Zehn-Byte-Bildkopf.
Das Faxgerät konnte seinen Teil erledigt haben, während der Bildschirm weiterhin ratlos blieb. Ein ordentlich gespeicherter Datenblock enthielt eben noch keine Punkte, die ein fremdes Programm sofort zeichnen konnte. Alan R. Katz' RFC 798 vom September 1981 führt durch die Übersetzung der Rapicom-450-Daten in ein Bitmap. Die gleichzeitig erschienene RFC 797 schlägt dafür ein kurzes Dateiformat vor. Die Seite musste erst aus ihrem Geräte-Dialekt heraus, bevor sie reisen konnte wie ein Bild.
Katz schrieb den Decoder in L10 als Teil von NLS auf TOPS20. Zwischen Faxgerät und Computerterminal saß eine mikroprozessorgesteuerte Schnittstelle namens FAXIE. Sie sammelte seriell eintreffende Bits zu Acht-Bit-Bytes. Schon hier kehrte sich eine vertraute Zuordnung um: MARK und SPACE hatten beim Rapicom die entgegengesetzten logischen Werte wie bei RS232. FAXIE komplementierte die Bits. Beim Speichern wurden die Bits der Datenbytes zusätzlich in umgekehrter Reihenfolge abgelegt und komplementiert. Der Decoder musste diese Behandlung rückgängig machen. Die Längen- und Befehlsbytes blieben davon ausgenommen.
Wer alles gedankenlos umdreht, dreht auch das Türschild um.
Ein Geräteblock hatte 585 Bits. Sieben angehängte Nullen machten daraus 74 Datenbytes; mit Länge und Befehl war ein gewöhnlicher Dateisatz 76 Bytes lang. Befehle kennzeichneten Einrichtung, Nutzdaten und Ende. Das war eine brauchbare Verpackung für die Übertragung. Über die Lage der schwarzen Punkte auf der Papierseite sagte sie noch wenig aus. Dazu musste der Decoder die Kodierung der Scanlinien verstehen.
Katz beschrieb eine typische Seite mit ungefähr 2100 Zeilen und 1726 Bildpunkten je Zeile. Fine Detail kodierte jede Zeile, Quality jede zweite, Express jede dritte. Fehlende Zeilen wurden bei der Anzeige wiederholt. Das Gerät fasste zwei Zeilen zusammen: Jede Spalte konnte weiß-weiß, weiß-schwarz, schwarz-weiß oder schwarz-schwarz sein. Wechsel zwischen diesen vier Zuständen bekamen Bitfolgen unterschiedlicher Länge. Lange einfarbige Abschnitte hatten Zählerwörter von zwei bis sieben Bits. Ein Bit war damit keineswegs einfach ein Pixel, das nur noch auf seinen Auftritt am Monitor wartete.
Die verschiedenen Arten des Umdrehens waren die eigentliche Falle. Die gespeicherten Datenbytes unterlagen der Byte-Regel. Im inneren Blockkopf waren die Bits des gültigen Datenzählers, der horizontalen Position und der schwarzen und weißen Lauflängenfelder jeweils in umgekehrter Reihenfolge gesendet. Folgenummer und aktueller Zustand waren es nicht. Auch die Längenwörter im Bilddatenstrom mussten feldweise rückwärts gelesen werden. Katz hob hervor, dass ein n-Bit-Feld anders umgekehrt wird als ein ganzes Byte, dessen Bits zusätzlich komplementiert werden. Ein einziger Befehl „alles spiegeln“ hätte sehr zuverlässig das Falsche getan.
Der Blockkopf lieferte zugleich einen neuen Anfang, falls etwas fehlte. Der 585-Bit-Block enthielt Synchronisationscode, 37-Bit-Kopf, 512-Bit-Datenbereich und Prüfsumme. Der Datenzähler bestimmte, wie viel von den 512 Bits tatsächlich galt; bei null fiel der Block weg. Lag die neue horizontale Position weiter vorn, füllte der Decoder die Lücke weiß. Lag sie zurück, ersetzten neue Daten den überlappenden Teil. Die Folgenummer lief durch 0, 1, 2 und 3; ein Sprung zeigte einen fehlenden Block an.
Bei jedem neuen Block übernahm das Programm Zustand, Lauflängenbreiten und Position aus dessen Kopf, selbst wenn das vorherige Blockende etwas anderes nahelegte. So konnte das Bild danach weitergehen, ohne dass verlorene Striche wundersam zurückkehrten.
Nach dieser Arbeit wirkte RFC 797 fast angenehm langweilig. Vier Bytes Breite, vier Bytes Höhe, je ein Byte für horizontalen und vertikalen Schritt; ab Byte elf die Pixel. Die Zeilen laufen von links nach rechts und oben nach unten, am rechten Rand bei Bedarf mit Nullen auf volle Bytes ergänzt. Ein vertikaler Schritt von eins, zwei oder drei entsprach den drei Rapicom-Modi; die Anzeige konnte gespeicherte Zeilen passend wiederholen. Ein Bildprogramm brauchte dann Maße und Pixel, nicht die Geheimnisse des Faxgeräts.
Katz nannte auch den Preis in Rechnerzeit: Ein durchschnittliches Fine-Detail-Dokument erforderte auf einem DEC KL10 mit TOPS20 ungefähr zwei CPU-Minuten. Das Bitmap mit etwa 1726 mal 2100 Punkten belegte rund 204 Plattenseiten. Ein HP-Grafikterminal zeigte Ausschnitte und konnte hineinzoomen; das ganze Blatt passte nicht auf einmal. Aus einer zugestellten Datei war endlich ein betrachtbares Bild geworden, und keine der nötigen Umkehrungen hatte sich von selbst erledigt.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten





