Top-Themen:
- Umbau der EPROM-Module M028 (M006) und M040 zu EEPROM-Modulen mit Autostart-Funktion
- Schaltkreis-Tester am KC85
- Transfer von Programmen und Grafiken zwischen verschiedenartigen Computern
Ein paar Worte zur Einleitung
von Frank Dachselt und Guido Speer
Da die Zeit mal wieder drängt, kommen wir ohne Umschweife zum wichtigsten Termin des Jahres: unser diesjähriges Clubtreffen. Es findet diesmal an einem neuen Ort und zu einer etwas anderen Terminlage
vom 17. bis 19. März 2006 in Schönwalde
in der Nähe von Berlin statt. Die lokale Organisation liegt in den Händen von Guido Speer. Im Ortsteil Pausin von Schönwalde werden wir uns in der Waldschule Pausin treffen, die in einem ausgebauten Bauerngehöft untergebracht ist. Zur Übernachtung stehen in der Waldschule etwa 28 Schlafplätze in 2...4-Bettzimmern zur Verfügung. Die Zimmer sind relativ groß, so dass “Notbetten“ oder Übernachtungen per Schlafsack bei Bedarf noch zusätzlich möglich sind. Für das Treffen selbst werden die vorhandenen Gemeinschaftsräume genutzt. Für alle, die die Situation der Vorjahre vor Augen haben: Es wird diesmal reichlich Platz zur Verfügung stehen!
Die sonstigen Bedingungen sind ähnlich denen der letzten Jahre. Tagesgäste können an den gemeinsamen Mahlzeiten (Mittagessen, Abendessen) in der Waldschule teilnehmen. Unabhängig davon gibt es eine weitere Verpflegungsmöglichkeit in der nahegelegenen Gaststätte.
Ort des Treffens:
Waldschule Pausin, Dorfstraße 16, 14621 Schönwalde OT Pausin
Preis:
1 × Übernachtung mit Frühstück 17...20 EUR
Wegbeschreibung zur Anreise (siehe Bild 1):
Zunächst Anreise bis zur A10 (Berliner Ring). Auf der A10 westlich um Berlin herumfahren, bis zur Anschlussstelle 28 Falkensee (AS 28). Nach dem Verlassen der Autobahn in Richtung Falkensee weiterfahren und an der Weggabelung nach links in Richtung Schönwalde/Pausin abbiegen. Im Ort in die zweite Einmündung nach rechts abbiegen (Dorfstraße). Auf dieser weit nach hinten fahren. Die Waldschule ist ein ausgebautes Bauerngehöft. Die Fahrtzeit von der A10 bis zum Ziel beträgt etwa 8 Minuten.
Achtung! Auf der A10 lauern hier einige Fallen. Der Ort Falkensee ist (von Süden kommend) an mehreren Abfahrten mit ausgeschildert. Deshalb auf die AS-Nummer (AS 28) achten.
Zum Be- und Entladen kann der Hof befahren werden, danach bitte wieder Platz für die nächsten Teilnehmer machen. Auf der Dorfstraße stehen ausreichend Parkmöglichkeiten bereit.
Wer eine Mitfahrgelegenheit sucht, wende sich bitte an die Organisatoren. Wir werden versuchen zu vermitteln. Wer mit der Bahn anreist und von einem der umliegenden Bahnhöfe abgeholt werden möchte, sollte sich ebenfalls mit den Organisatoren in Verbindung setzen.
Anmeldung:
Das Anmeldeformular liegt dieser News-Ausgabe bei und sollte möglichst bald abgeschickt werden. Wir bitten auch Tagesgäste, sich vorher anzumelden. Die Anmeldung kann auch telefonisch, per E-mail oder online über unsere Homepage erfolgen. Bei Veränderungen an der angemeldeten Teilnahme bitten die Organisatoren ebenso um eine kurze Mitteilung.
Als Rückblick zeigt das Titelbild die Teilnehmer des Clubtreffens 2005 und auf den nächsten Seiten gibt es den spannenden Bericht von Steffen Gruhn.
Also dann viel Vergnügen beim Lesen dieser Ausgabe.
Bild 1: Anreise zum Clubtreffen in Schönwalde.
11. KC-Clubtreffen in Pechtelsgrün
von Steffen Gruhn
Nun schon zum 4. Mal fand das alljährliche Clubtreffen in Pechtelsgrün statt. Es sollte mal wieder ein interessantes Wochenende werden.
Die Vorstellung, einen C-One zu sehen, einen Vortrag über die Numerikrechner zu hören und einen KC87 in Vollausstattung zu sehen, war viel versprechend.
So begann es auch. Gut gewappnet mit einer Kiste Schwarzbier trat ich den Weg an. Die Navigationstante im Auto überraschte mich dieses Jahr mit ganz neuen, einfachen Wegen nach Pechtelsgrün.
Also wie jedes Jahr erst mal die Technik die unzähligen Stufen zur Pension “Sonnenblick“ rauf und einen guten Platz sichern. Alles anschließen und siehe da, das System will nicht. Aufschrauben und Fehlersuche. Anscheinend verhinderte eine “kalte“ Lötstelle den Bootvorgang von Diskette und meiner CF-Card. Also alles Wichtige nachlöten, zusammenbauen und geht.
Schon am Freitag wurde es ganz schön eng im Raum. So viele waren schon lange nicht mehr da. Auf die Frage, wer ohne PC oder Laptop angereist war, musste ich schon fast mit Bedauern als einziger mit “Ich“ beantworten, da ich meinen Laptop schlicht zu Hause vergessen hatte. Es wurden die neusten KC-Errungenschaften gezeigt und gefachsimpelt, so dass der Freitag schnell vorüber war. Meine Neuerungen waren ein paar neue Modulblenden, deren Vorlagen ich jedem auf der nächsten Beilagendiskette zur Verfügung stellen werde.
Die Nacht war wie immer auf einem Treffen viel zu schnell vorbei. Der Samstag sollte sehr interessant werden, bei dem ein C-One leider nur einen kurzen Auftritt hatte, dazu aber später. Auch habe ich die wichtigsten Momente auf einer Videokamera festgehalten und das kann als Video-CD entweder als Beilage zu den KC-News mit verschickt, als Download oder auf Anfrage bei mir bezogen werden. Das wird noch abgeklärt.
Die KC-Umbauwerkstatt wurde kurzerhand nach draußen verlegt, so dass das Brummgeräusch der Entlötpumpe dieses Jahr gar nicht zu hören war.
Der erste Vortrag kam von Sebastian über die Robotrontechnik und ihre Entwicklung. Auch stellte er seinen mitgebrachten Robotron K8924 vor.
Die Vorstellung des C-One von Klaus Finke erwies sich schon schwieriger. Nach eigenen Angaben lief Tags zuvor noch alles bestens und er verstaute alles in seinem Auto. Die kalten Temperaturen ließen aber anscheinend Kondenswasser im Netzteil entstehen, so dass es am nächsten Tag beim Einschalten in Pechtelsgrün erst einmal dunkel wurde. Der FI leistete ganze Arbeit. Auch ein zweiter Versuch scheiterte. Guido, der sich den Computer anschauen wollte, sah nur noch einen Funken im Netzteil. Das war hin. Hoffentlich hat der C-One nichts abbekommen. Dietmar erwies sich als Retter in der Not, da er sich bereit erklärte, mal schnell nach Hause zu fahren, um ein neues ATX-Netzteil zu holen. Neues Netzteil, neues Glück. Wieder einschalten und der Bildschirm blieb grau. Ach du Schreck – hat er doch was abbekommen? Klaus Finke wurde schon ganz unruhig. Aha, der Monitorstecker war nicht richtig drauf. Jetzt konnte man ein Menü sehen, in dem man unter den verschiedenen Computern wählen konnte. C64, Schneider CPC464, Schneider CPC128. Es wird laut C-One-Forum sogar schon an einem KC85/3...4 Emulator gearbeitet.
Erklärung: Was ist ein C-One? Der C-One ist eine erweiterte Version des Commodore 64 - des meistverkauften Computers überhaupt (Guinness-Buch der Rekorde). Während fast alle Funktionen des Commodore 64 beibehalten wurden, besitzt der C-One zusätzlich moderne Funktionen, Schnittstellen und Möglichkeiten und füllt eine für lange Zeit klaffende Lücke im Heimcomputermarkt.
Die Krönung bei der Vorführung war aber der abgebrochene Flashvorgang des BIOS-Chips. Durch einen ungewollten, dummen Zufall kam jemand auf die BIOS-Flash-Auswahl. Auch ein schnelles Ausschalten war schon zu spät und gerade das Verhängnis. Auch ein neu Flashen am PC mittels Willem-Programmer brachte den C-One nicht mehr zum Laufen. Ich will nur hoffen, dass man das wieder hinbekommt, zumal der C-One mit einem Preis von 270 Euro nicht gerade ein Schnäppchen ist.
Der Vortrag von Rüdiger Kurth über die PRG-Rechner von NUMERIK war sehr umfangreich und wirklich interessant. Ich wusste gar nicht, dass die in so vielen Versionen hergestellt worden sind.
Bild 3: Clubtreffen 2005 – Schwere Technik: Rüdiger Kurth brachte aus seiner Sammlung wieder einige seltene Rechner mit. So erfuhren wir diesmal etwas aus der Geschichte der PRG-Rechner von NUMERIK.
Das absolute Highlight an diesem Tag war die Vorstellung eines Eigenbau-KC87 mit Vollgrafik von Ulrich Zander. Ich hatte zwar schon mal gelesen, dass es den KC87 mit Floppydisk gegeben hat, doch nun stand er sogar mit Vollgrafik und 16 Farben vor mir. Und das alles noch im Eigenbau! Hut ab kann ich da nur sagen. Auch wenn die Grafik noch ein paar “Macken“ hatte, war es erstaunlich, was man aus dem Computer rausholen konnte. Selbst ein angepasstes CP/M lief auf ihm. Da es nicht so viele Fans für den KC87 gibt, musste Ulrich Zander alles allein entwickeln und programmieren.
Bild 2: Clubtreffen 2005: Der KC87 ist eine etwas vernachlässigte Spezies der Kleincomputer, doch völlig zu unrecht, wie uns Ulrich Zander mit seinen zahlreichen Erweiterungen eindrucksvoll demonstrierte. Das Gerät in der Mitte ist als KC87 kaum noch zu erkennen.
So ging auch ein Aufruf an alle KC87-Besitzer und interessierten User, sich doch mit Ulrich Zander in Verbindung zu setzen, da er nicht mehr alleine am KC87 basteln und entwickeln will. In der Gemeinschaft macht es wesentlich mehr Spaß. Also mich hat er sehr beeindruckt. Heißen wir ihn in unserer KC85-Gemeinde herzlich willkommen und hoffen, dass wir noch mehr von ihm hören und sehen werden.
Beim obligatorischen Gruppenbild fehlte dieses Mal nur leider das Poster des Treffens. Auch wurde gleich über den Ort des 12. KC-Clubtreffens abgestimmt. Die Wahl viel auf Berlin. Das ist aber noch nicht 100-prozentig sicher und wird zu gegebener Zeit bekannt gegeben.
Mario Müller programmierte an seinem selbstgebauten Schaltkreistester und am dazugehörenden Chiperkennungsprogramm für den KC. Verschiedene 74-er Typen wurden schon richtig erkannt.
Beim Abendessen konnte man, wenn man sich zum Essen raus gesetzt hatte, sehen, woher die Pension ihren Namen hat: Schönes Frühsommerwetter.
Guido Speer hatte seine mobile Werkstatt wieder dabei, in der es dieses mal weniger um den KC ging. Er baute zu Erstaunen vieler aus einer “alten“ Oszilloskopröhre eine Retrouhr. Auf der Röhre wird statt der normalen Kurve eine Uhr dargestellt, die sogar über einen Sekundenzeiger verfügt.
Auch dieses Jahr hatte Göran Heinze kein Glück. Gleich zwei D004 verweigerten den ordnungsgemäßen Dienst. Schon im letzten Jahr ging auf dem Treffen ein D004 von ihm kaputt.
Zum Schluss noch eine ganz wichtige Zahl: die Anzahl der Gäste auf dem Treffen: 39. Das ist fast Rekord!
Bild 4: Clubtreffen 2005 – Noch einmal schwere Technik: Zu den Rechnern, die allein durch ihre Größe und ihr Gewicht für Aufsehen sorgten, gehörte auch dieser K8924.
Umbau der EPROM-Module M006/M028 und M040 zu EEPROM-Modulen mit Autostart-Funktion
von Frank Dachselt und Mario Leubner
Wenn in einem EPROM-Modul die Software gewechselt werden soll, dann ist einiger Aufwand notwendig: Modul aufschrauben und EPROM ausbauen, EPROM löschen und neu programmieren, EPROM wieder einsetzen und Modul zusammenschrauben. Man braucht zudem ein EPROM-Löschgerät und ein EPROM-Programmiergerät.
Wesentlich bequemer läuft diese Prozedur dagegen ab, wenn eine moderne Variante des EPROMs, nämlich ein EEPROM (elektrisch löschbarer EPROM), verwendet wird. Diese Speicherschaltkreise können mit entsprechenden Steuersignalen sowohl gelöscht als auch beschrieben (programmiert) werden, ohne dass zusätzliche Hardware wie Löschgerät und Programmierschaltung oder die von EPROMs bekannten Programmierspannungen notwendig sind. EEPROMs können byteweise beschrieben werden, wobei das vorherige Löschen des betreffenden Bytes automatisch erfolgt. Diese Speicher verhalten sich also fast wie statische RAMs mit dem Vorteil, dass sie ihren Speicherinhalt beim Ausschalten der Betriebsspannung nicht verlieren. Es muss lediglich beachtet werden, dass der Schreibzyklus gegenüber statischen RAMs wesentlich länger dauert (abhängig vom Hersteller sind das bis zu 5 ms).
Nach außen hin sind EEPROMs im wesentlichen pin- und funktionskompatibel zu den statischen RAMs gleicher Kapazität, bezüglich des Lesens also auch zu den entsprechenden PROMs und EPROMs. Sollen EEPROMs anstelle von EPROMs eingesetzt werden, muss lediglich noch das Schreibsignal an den zugehörigen Steuereingang gelegt werden. Dieser Eingang ist bei EPROMs im Normalfall nicht beschaltet, da er nur im Programmiermode Verwendung findet.
Die nachfolgend beschriebenen Umbauten machen aus Modulen M006/M028 und M040 jeweils ein 16-KByte-EEPROM-Modul. Anstelle der EPROMS von Typ 2764 (27C64) bzw. der PROMs vom Typ 2364 werden je zwei EEPROMs vom Typ 28C64 oder 28C65 eingesetzt.
Umbau des Moduls M006/M028
Das Originalmodul ist wahrscheinlich nur als M006 (BASIC (BM 600) und HC901-CAOS (BM 601) bzw. HC-CAOS 3.1 (BM 604)) mit zwei eingelöteten PROMs bekannt. Der Schaltplan des Originalmoduls ist in Bild 6 zu sehen. Der Umbau beginnt mit dem Auslöten der PROMs und dem Einbau von zwei 28-pol. Fassungen. Die Steuersignale werden wie folgt neu verschaltet:
- Die /CS-Dekodierung funktioniert bereits bei Lese- und Schreibzugriffen, da weder /WR noch /RD berücksichtigt werden, und braucht deshalb nicht verändert werden.
- In die /OE-Dekodierung des Originalmoduls geht das /RD-Signal nicht mit ein. Achtung: Die EPROMs können deshalb nicht zwischen einem Lese- und Schreibzugriff unterscheiden. Bei einen Schreibzugriff in das Modul treiben die Ausgänge der EPROMs gegen den Datenbus des Prozessors. Hier ist bei der Entwicklung des Moduls offenbar sehr gespart worden.
- Vom Pin 13 des D02.4 wird deshalb das invertierte PRSEL abgetrennt und das Signal RD (von Pin 4 des D09.2) angelegt. Damit wird /OE nur bei Lesezugriffen in das Modul aktiv.
- Das Signal WR (von Pin 6 des D09.4) wird anstelle von PRSEL an die Pins 1 und 2 von D01.1 gelegt. Damit bekommen die (E)EPROMs an Pin 27 ein undekodiertes Schreibsignal (also bei allen Schreibzugriffen). Dies ist ausreichend, da das /CS-Signal vollständig dekodiert wird. Es würde ebenso ausreichen, das /RD-Signal direkt an den /OE-Eingang zu legen.
- Die Pins 1 der (E)EPROMs werden von der Spannung UPRG abgetrennt, bleiben aber zusammengeschaltet. Die Pins 1 können unbeschaltet bleiben oder zur Sicherheit mit einem Pull-Up-Widerstand nach +5V gelegt werden. Optional lässt sich hier auch eine LED mit Vorwiderstand nach +5V schalten. Einige EEPROMs generieren an Pin 1 das /BSY-Signal (als Open-Collector-Ausgang) und die LED fungiert dann als Schreibanzeige.
Die notwendigen Veränderungen sind in Bild 7 dargestellt.
Das Modul funktioniert auch nach dem Umbau wahlweise mit EPROMs oder den originalen PROMs. Die Schreibanzeige per LED funktioniert bei EEPROMs vom Typ 28C65. Auch beim Schreiben einzelner Bytes leuchtet die LED kurz sichtbar auf. Bei EEPROMs vom Typ 28C64 ist Pin 1 dagegen unbeschaltet. Werden ältere NMOS-EPROMs (2764) in das Modul gesteckt, dann kann in das Pin 1 bereits im normalen Lesebetrieb ein so hoher Strom fließen, dass die LED ständig leuchtet. Dies bleibt aber ohne Einfluss auf die Funktion der EPROMs.
Umbau des Moduls M040
Das Originalmodul enthält vier Steckplätze, die mit vier 2-KByte-, vier 4-KByte- oder zwei 8-KByte-(EP)ROMs bestückt werden können, so dass sich ein 8-KByte- oder 16-KByte-(EP)ROM-Modul ergibt. Der Schaltplan des Originalmoduls ist in Bild 8 zu sehen. Für das 16-KByte-EEPROM-Modul müssen die Lötbrücken bzw. Jumper so geschaltet werden, wie es der Bestückung mit zwei 8-KByte-(EP)ROMs entspricht. Die Steuersignale werden wie folgt neu verschaltet:
- Im Pfad der /CS-Dekodierung wird das /RD-Signal von Pin 12 des D11.4 abgetrennt und Pin 12 mit Pin 11 verbunden. Damit funktioniert die /CS-Dekodierung sowohl bei Lese- als auch bei Schreibzugriffen.
- Aus dem Signal an Pin 9 von D14.2 werden wie in Bild 7 gezeigt mit Hilfe eines zusätzlichen 74LS00 bzw. DL000 die Lese- und Schreibsignale für die EEPROMs erzeugt. Der zusätzliche Schaltkreis kann “Huckepack“ auf den D14 (DL074) gesetzt werden. So lassen sich die Pins 2, 7, 9 und 14 direkt mit dem darunterliegenden Schaltkreis verbinden und der neue Schaltkreis bekommt einen festen Sitz. Die restlichen Verbindungen werden in Freiverdrahtung realisiert.
- Anstelle des originalen /OE-Signals (Pin 8 von D14.2) wird das neue Lesesignal an die Pins 22 der EEPROMs geschaltet.
- Die Pins 27 der EEPROMs werden von +5V abgetrennt und mit dem neuen Schreibsignal verbunden.
- Die Pins 1 der (E)EPROMs werden von +5V abgetrennt, bleiben aber zusammengeschaltet. Die Pins 1 können unbeschaltet bleiben oder zur Sicherheit mit einem Pull-Up-Widerstand nach +5V gelegt werden. Optional lässt sich hier auch eine LED mit Vorwiderstand nach +5V schalten. Einige EEPROMs generieren an Pin 1 das /BSY-Signal (als Open-Collector-Ausgang) und die LED fungiert dann als Schreibanzeige.
Die notwendigen Veränderungen sind in Bild 9 dargestellt. Diese Umbauvariante ist erprobt und liefert die gewünschten Ergebnisse. Nach unseren Überlegungen ist auch eine noch einfachere Variante möglich, die keinen zusätzlichen Schaltkreis benötigt. Die Punkte 1 und 5 der obigen Beschreibung bleiben unverändert. Die Lese- und Schreibsignale der EEPROMs werden wie folgt gewonnen:
- Anstelle des /OE-Signals (Pin 8 von D14.2) wird das /RD-Signal von Pin 3 des D03.1 direkt an die Pins 22 der EEPROMs geschaltet.
- Die Pins 27 der EEPROMs werden von +5V abgetrennt und mit dem (bisher unbenutzten) /WR-Signal von Pin 6 des D01.1 verbunden.
Sollte jemand diese einfache Variante ausprobieren, dann sind die Autoren sehr an einem Erfahrungsbericht interessiert.
Autostart-Funktion mit Strukturbyte 01
Befindet sich beim Einschalten (oder beim Drücken der RESET-Taste) des KC85 im Schacht 08 ein Modul mit dem Strukturbyte 01h, dann wird dieses Modul vom Betriebssystem automatisch auf der Adresse 4000h online geschaltet und die darin enthaltene Software nach Abschalten des RAM4 durch einen Sprung auf die Adresse 4000h gestartet. Damit ist es also möglich, Anwendersoftware ohne weiteren Bedienaufwand zu starten, was besonders bei automatischen Anwendungen oder für nicht KC-kundige Nutzer von Bedeutung sein kann.
Beim M040 ist das Strukturbyte in einem weiten Bereich, der auch den Wert 01h umfasst, frei wählbar. Wie die Lötbrücken bzw. Jumper für das Strukturbyte 01h geschaltet werden müssen, kann der Tabelle in Bild 8 entnommen werden.
Das M006 ist dagegen nur für die Strukturbytes F8h und FCh vorgesehen. Soll dieses Modul das Strukturbyte 01h senden, dann sind die folgenden Änderungen notwendig:
- Öffen der Lötbrücke RB01
- Abtrennen des Datenbus DB0 von Pin 8 des D03.3
- An den Ausgang Pin 8 von D03.3 werden fünf Schottky-Dioden (z.B. BAT43) wie in Bild 7 gezeigt zu den Datenbusleitungen DB3...7 geschaltet.
Bild 5 zeigt ein M006, das nach dieser Beschreibung zu einem EEPROM-Modul mit Schreibanzeige und Autostart-Funktion umgebaut wurde.
Alle Schalt- und die dazugehörigen Bestückungspläne (zum Auffinden der genannten Schaltkreise) sind als PDF-Dateien im Archiv EEPROM.ZIP enthalten.
Bild 5: Umgebautes M006 mit EEPROM und Autostart-Funktion. In der oberen Fassung steckt hier der EEPROM 28C65, während sich in der unteren noch der originale PROM U2364 befindet. Das Modul funktioniert auch bei gemischter Bestückung. Oben links ist die zusätzliche LED für die Schreibanzeige zu erkennen. Oberhalb des Elkos befinden sich die fünf Schottky-Dioden, deren Kathoden auf der Leiterseite mit Pin 8 von D03.3 verbunden sind.
(volle Größe)
Bild 6: Schaltplan, Bestückungsplan und Stückliste des originalen Moduls M028 (M006).
(volle Größe)
Bild 7: Umbau des Moduls M028 (M006) zum EEPROM-Modul mit Autostart-Funktion.
(volle Größe)
Bild 8: Schaltplan, Bestückungsplan und Stückliste des originalen Moduls M040.
(volle Größe)
Bild 9: Umbau des Moduls M040 zum EEPROM-Modul.
Schaltkreis-Tester am KC85
von Mario Müller und Göran Heinze
Schaltkreise halten eigentlich einiges aus, doch auch in unserem KC geht schon mal einer in die “ewigen Jagdgründe“ ein. Nun steht man meistens mit dem defekten KC da und versucht, die Fehlerquelle einzukreisen: Man fängt an, den ersten verdächtigen Schaltkreis auszulöten. Und nun? Ist der defekt? Meistens hat man Ersatz da, doch manche hat man eben nicht. Um die ausgelöteten ICs zu prüfen, habe ich deshalb diese Schaltung entwickelt. Die Idee kam beim vorletzten Clubtreffen und beim letzten Mal war schon mein erster Prototyp zu sehen.
Was kann der Schaltkreis-Tester? Er kann Schaltkreise auf ihre logische Funktion prüfen. Zwar kann er nicht zwischen ICs mit gleicher Funktion (z.B. 74LS04 und 74LS14) unterscheiden, kann aber auch solche mit Open-collector- und Tristate-Ausgängen prüfen. Zur Zeit sind etwa 40 ICs in der Datenbank, die jedoch von mir noch erweitert wird, sobald ich entsprechende ICs zum Vergleichstest da habe. Leider war das bis jetzt noch nicht bei allen der Fall. Einige ICs sind im Programm mit einem Stern hinter dem Namen gekennzeichnet. Diese sind ungeprüft in die Datenbank gewandert und die Prüfmuster könnten noch fehlerhaft sein.
Zur Schaltung: Eigentlich ist das Schaltungsprinzip aus einem alten Funkamateur. Dort war die Schaltung allerdings in einen freien Adressbereich direkt am CPU-Bus eingebunden (ich glaube für den AC1). Ersten ist das schlecht realisierbar (da der KC vollen Speicherausbau hat) und zweitens wäre das Gerät nicht so universell einsetzbar.
Am KC ist die Schaltung an einem M001 angeschlossen, wobei nur die PIO genutzt wird. Der Kanal A wird zur Datenein- und -ausgabe, Kanal B zur Steuerung verwendet. IC1 wird zur hardwaremäßigen Selektion genutzt. IC2...4 dienen der Datenpufferung und IC5...7 lesen die Informationen zurück. Mein erster Prototyp war mit TTL-ICs bestückt. Das hatte den Nachteil, dass nur TTL-ICs geprüft werden konnten. Deshalb habe ich mich entschlossen, alle ICs durch HCT-Typen zu ersetzen, wodurch auch eine geringere Stromaufnahme erreicht wird.
Zur Funktion: Das Prinzip ist einfach. Man legt über Widerstände Pegel (z.B. überall H-Pegel) an den Prüfling und dieser stellt am Ausgang je nach Funktion einen anderen Pegel ein (z.B. L-Pegel bei NAND-Gatter). Dieser wird dann über IC5...7 zurückgelesen und ausgewertet. Damit sind wir aber schon beim Hauptproblem einer solchen Schaltung: Das sind die Widerstände an den Ausgängen von IC2...4. Die haben die Funktion der Strombegrenzung, wenn ein Pin des Prüflings ein Ausgang ist, und sollten deshalb nicht zu niedrig sein. Das ist relativ einfach zu meistern. An einem Eingang des Prüfling liegt dieser Widerstand aber in Reihe im Eingangsstromkreis und sollte deshalb nicht zu hoch sein (insbesondere bei L-Pegel). Für LS-TTL-Schaltkreise habe ich einen Wert von 1 kΩ verwendet und es haben bis jetzt fast alle getesteten ICs damit funktioniert. Für CMOS-ICs geht das nicht, denn dort wird der Ausgangsstrom durch die Betriebsspannung des ICs begrenzt. Bei 5 V und 1 kΩ Widerstand waren keine sauberen Pegel zu erreichen (ca. 2,4 V stellten sich am Ausgang ein). Deshalb habe ich alle Widerstände auf einer separaten Leiterplatte untergebracht, die einfach ausgetauscht werden kann. Für CMOS-ICs sollte der Wert nicht unter 3 kΩ liegen, ich habe 4,7 kΩ verwendet, wobei ich sagen muß, dass ich nur drei CMOS-Typen zum Testen (4000-Serie) hatte.
Im Schaltbild sieht man eine 24-polige Testfassung, ich habe allerdings eine 40-polige verwendet, um eventuell den IC-Tester noch auszubauen (von Enrico kam der Vorschlag, 28-polige SRAMs zu testen).
Über die DIP-Schalter wird der Prüfling mit Spannung versorgt, je nach dem, an welchem Pin die 5 V Betriebsspannung anliegen soll. DIP10 ist standartmäßig umgelegt (für Masse). Über das Relais wird die Betriebsspannung eingeschaltet.
Es gibt ein paar Ausnahmen: Wenn ein 74090 oder 74093 (DL090/DL093) getestet werden soll, muß dieser entgegengesetzt eingesetzt werden und DIP 1 und 9 umgelegt werden (DIP 10 ausschalten!). Diese ICs sind im Programm mit einem Ausrufezeichen gekennzeichnet. Also vorher Menüpunkt “Liste“ aufrufen und nachschauen.
Noch ein Wort zur Stromversorgung. Die erste Schaltung – mit LS-TTL-ICs aufgebaut – nahm etwa 200 mA Ruhestrom ohne die beiden LEDs auf. Mit HCT-Typen liegt der Wert bei etwa 10 mA (mit LED etwa bei 30 mA). Ich habe mein M001 umgebaut und einen Massekontakt (erster oben neben A0) geopfert, um die 5 V Betriebsspannung herauszuführen. Bei einigen BUS-Treibern (8212) brach die Spannung zusammen, aber das war noch mit den alten TTL-IC. Deshalb hole ich die Spannung über die alte Tastaturbuchse (da meine Tastatur am M053 angeschlossen ist). Außerdem habe ich noch eine Sicherung eingebaut (dieser Vorschlag kam von Enrico) und habe erst mal eine für 800 mA eingesetzt.
Zur Software: Zur Zeit belegt sie den Speicherbereich 0200h...1FFFh, wobei da noch einige Reserven vorhanden sind. Das Programm ist in zwei Teile gegliedert. Ab 0200h (bis etwa 0A00h belegt) liegt die eigentliche Steuersoftware und ab 1000h die Daten für die einzelnen ICs. Deshalb habe ich das Programm in zwei Assembler-Dateien zerlegt. Erwartet bitte aber keinen “Supercode“ im Programmteil – aber er geht!
Der Datenteil ist ähnlich wie eine Datenbank aufgebaut und muß immer auf Startadresse 1000h übersetzt bzw. geladen werden. Es ist darauf zu achten, dass das Programm immer das erste M001 (also höchstpriorisierte) einschaltet. Findet es kein M001, kommt es zu einer Fehlermeldung und das Programm kehrt ins CAOS zurück. Auch zum Programmtest muß immer ein M001 gesteckt sein. Wenn jemand noch weitere Informationen für den Datenbank braucht, um selbst ICs aufzunehmen, dann kann er mich kontaktieren.
Zum Abschluß: Der IC-Tester funktioniert mit vielen IC-Familien (TTL, LS-TTL, HCT, HC, CMOS4000), aber ich kann nicht garantieren, dass man alle ICs damit prüfen kann (die mit externer Zusatzbeschaltung sowieso nicht). Manche ICs bereiten Probleme, meisten an den Eingängen, wenn der Strom bei L-Pegel zu gering ist (z.B. alte TTL-IC oder S-Typen). Aber dadurch, dass die Widerstände herausnehmbar sind (Adapterplatine), erschließen sich auch andere Anwendungen, z.B. über einen Adapter als Kabeltester. Man könnte auch DIP-Schalter auf die Adapterplatine setzen, um die Widerstände überbrücken zu können. Auch eine Adapterplatine mit Dioden und Pull-Up-Widerständen wäre möglich. Enrico wollte gleich wieder eine “eierlegende Wollmilchsau“ daraus machen, aber vielleicht haben auch andere noch Ideen, was verbessert werden könnte. Göran Heinze hat schon ein Leiterplattenlayout entworfen. Wenn genug Interessenten da sind, kann man das auch als Bausatz zusammenstellen. Man könnte noch zwei zusätzliche ICs verwenden (am Dekoder sind noch zwei Ausgänge frei) und käme auf 32 Pins (oder vier ICs mit einem zusätzlichen Decoder zum Beschalten aller Pins einer 40-poligen Fassung).
Also meldet Euch bei mir oder Göran, damit wir bis zum nächsten Clubtreffen schon mehr sagen können.
Bild 10: Der Prototyp des IC-Testers, wie er auf dem Clubtreffen 2005 zu sehen war.
Bild 11: Layout-Entwurf für den IC-Tester.
(volle Größe)
Bild 12: Schaltplan des IC-Testers.
Transfer von Programmen und Grafiken zwischen verschiedenartigen Computern
von Thomas Rademacher
In der Zeit vor der Marktherrschaft der Windows-PCs gab es mehrere Dutzend verschiedene Heimcomputer unterschiedlicher Hersteller, zu einigen davon sind heute noch Clubs aktiv. Der folgende Artikel soll sich damit befassen, welche Möglichkeiten es gibt, trotz zunächst bestehender Verständigungsprobleme einen Datenaustausch zwischen diesen Oldies zu ermöglichen.
Mein Startcomputer war der KC compact, eine nichtautorisierte Weiterentwicklung des Amstrad CPC. Das Gehäuse hatte er vom Bildungscomputer A 5105 übernommen, eine Drittverwendung dieses Gehäuses ist die Komforttastatur D005 als Ersatz für die ursprüngliche Tastatur des KC 85.
Der Bildungscomputer A5105
Mit dem Bildungscomputer sollten die DDR-Schulen flächendeckend ausgestattet werden, als Komplettgerät war es ein CP/M-Computer mit 5,25-Zoll-Diskettenlaufwerk, jedoch mit dreikanaligem Sound über acht Oktaven und mit sechzehn Farben. Zwar ging das über die üblichen Eigenschaften von CP/M hinaus, doch war zu dieser Zeit anderswo die Verdrängung dieses 8-Bit-Betriebssystems durch DOS und später Windows bereits im vollen Gange.
Der BIC war auch unter der Bezeichnung K1505 bekannt und das separat betreibbare Grundgerät wurde unter dem Namen ALBA-PC auch exportiert.
In die Entwicklung des BIC sind offenbar Erfahrungen aus der Arbeit mit verschiedenen anderen Computern, die es davor gab, eingeflossen. So sind zum Beispiel (wie beim C64) Text- und Grafikbildschirm in unterschiedlichen Speicherbereichen abgelegt und können sich nicht gegenseitig störend beeinflussen. Einen Grafikbildschirm der Breite 640 Pixel kenne ich vom CPC und Commodore 128. Auch der Screen-Editor und das Auslösen häufig benötigter Funktionen durch F-Tasten, die man auch selbst neu belegen kann, scheint vom C64 inspiriert zu sein. Die Möglichkeit, für Grafikanweisungen Makros anzuwenden, erinnert mich wiederum an die Turtle-Grafik von DR-Logo auf CP/M-Computern. Wie der Sinclair ZX Spectrum durch das Interface I netzwerkfähig wird, ist der BIC von Haus ebenfalls auf die Arbeit in einem lokalen Netzwerk vorbereitet. Daß bereits das Basic Befehle für die Arbeit mit
Direktzugriffsdateien bereitstellt, kenne ich vom Mallard Basic des Amstrad PCW. Ein ROM-Basic hatten auch noch die ersten mit DOS laufenden IBM-PCs. In allen Punkten bringt der BIC aber auch Verbesserungen mit sich, so verfügt er über einen 40- und einen 80-Spalten-Textmodus (beide können je nach Wunsch auch mit zusätzlichem Abstand zwischen den Textzeilen genutzt werden) und über drei verschiedene Grafik-Modi.
Allerdings kannte ich vom BIC jahrelang nur den Artikel, der ihn in einer Elektronikzeitschrift (Mikroprozessortechnik 10/1988) vorstellte. Es sollte bis 1999 dauern, daß ich den Computer bei einem Tag der offenen Tür an einem hiesigen Gymnasium einmal zu Gesicht bekam, arbeiten sah ich ihn zum ersten Mal auf einer Commodore-Party Anfang Mai 2004 in Hohenstein-Ernstthal, wohin Ralle sein wohl frisch erworbenes Modell mitgebracht hatte.
Torsten Pauls KC-Emulator
Vor ein paar Wochen entdeckte ich, daß Torsten Pauls KC-Emulator mittlerweile auch den BIC emulieren kann.
 |
 |
Der Emulator befindet sich zwar noch im Beta-Stadium, hat z.B. noch keine Soundfunktionen und kann Disketten(-abbilder) nur lesen, das “Beschreiben“ mußte ich deswegen mit einem Hex-Editor realisieren. Trotzdem nutzte ich die Gelegenheit, den BIC auf diesem Wege endlich etwas näher kennenzulernen.
Über den Autor
Nun wird es langsam Zeit, daß ich mich erst einmal vorstelle. Ich bin ein Computerhobbyist, der zur Wende 31 Jahre jung war, in der Schule oder in AGs also Computer nicht mehr kennengelernt hatte.
Ein Schwerpunkt meiner Freizeitbeschäftigung wurde im Laufe der Zeit BasiCode, eine Entwicklung niederländischer Computerenthusiasten, die Basic-Programme auf andere Computer übertragbar und dort nutzbar werden läßt.
Hierdurch (und möglicherweise auch zur Kompensation der Computerlosigkeit meiner Jugendjahre) befaßte ich mich nach und nach auch mit anderen Computern, zunächst als Hardware, aber zunehmend auch als Emulation unter DOS oder Windows.
Was ist BasiCode?
Dieses Thema haben zwei Hobbykollegen und ich bereits in den KC-News 1/99 vorgestellt. BasiCode ist kurz gesagt eine gemeinsame Bedienoberfläche für unterschiedliche Computer. Von daher liegt ein Vergleich mit CP/M nahe (Software-Pool für Computer mit unterschiedlichem Hardwareaufbau), jedoch ist das ursprüngliche Speichermedium die Kassette, vor zwanzig Jahren waren Disketten für Heimcomputer noch die Ausnahme und sehr teuer. Heutzutage können BasiCode-Programme selbstverständlich auch per Diskette übertragen werden, ebenso wie die Nutzung nicht auf 8-bit-Oldies beschränkt, sondern auch unter DOS oder Windows möglich ist.
Version 3C für BIC
Was lag für mich also näher, mich ein wenig mit dem (emulierten) BIC vertraut zu machen, als mir einmal seine Umsetzung von BasiCode (siehe Bild 14) anzusehen? Hier überraschte mich ein Konzept, wie ich es bisher noch auf keinem anderen Computer gesehen hatte: menügeführt wird man bis zum lauffähigen Programm (Bild 14 rechts unten) geleitet.
Für mich waren beispielsweise die Menüpunkte O (zum Einlesen des Programmlistings von der Diskette, Bild 14 oben) und G (zur Komplettierung durch die Bascoderroutinen, Bild 14 links unten) von Belang. Interessant hierbei ist, daß Funktionen, die vom Programm (genauer: vom übertragbaren Teil ab Zeile 1000) nicht benötigt werden, im Bascoderteil weggelassen werden. Verwendet ein Programm beispielsweise keine Soundausgabe, gibt es im computerspezifischen Teil (unterhalb der Zeile 1000) auch keine Subroutine 450. Das ist auf alle Fälle sinnvoller als pauschal alles zu linken, was zur Verfügung steht, egal, ob es tatsächlich gebraucht wird, wie man es von Compilern schon aus der CP/M-Zeit kennt und wie es heute in Form von Dynamic Link Libraries (DLLs) unter Windows allzu bekannt ist.
 |
 |
 |
 |
Nun entdeckte ich auch gleich ein Projekt, an dem ich mich im Zurechtkommen mit der Programmierung testen konnte: der Bascoder war auf dem Stand der Version 3, enthielt noch nicht die zusätzlichen Funktionen des 1991 vorgestellten Standards 3C. Zwar gibt es vielleicht nur ein halbes Dutzend Programme, die die Möglichkeiten der Farbversion nutzen (zu schnell ebbte nach der Maueröffnung bei den meisten das Interesse an den Oldies ab, man kam jetzt an AMIGAs, ATARIs und sogar PCs – auf SEGA und Nintendo will ich an dieser Stelle mal nicht eingehen – und an deren leistungsfähigere Software heran), doch wenn der BIC einmal Farben kann, ist es doch einen Versuch wert.
Die neuen Funktionen der Version 3C von BasiCode sind in BASC3C.ASC beschrieben: es stehen jetzt acht Farben zur Verfügung, beim Zurücklesen aus dem Bildschirm kann jetzt zwischen Groß- und Kleinbuchstaben unterschieden werden.
Außerdem besteht die Möglichkeit, bei der Tastaturabfrage die F-Tasten zu erkennen, doch das halte ich für wenig zweckmäßig. Oft sind diese Tasten bereits mit Funktionen belegt und daher gar nicht z.B. für die Auswahl aus Menüs oder sonstige Verwendung verfügbar. Da viele der Oldie-Computer gar keine F-Tasten haben, steht es obendrein im Widerspruch zum angestrebten Ziel der Übertragbarkeit der Programme. Deswegen habe ich auf die Umsetzung dieser Funktion verzichtet.
Das Resultat ist die Datei INITCOLO.URS. Das gewünschte Programm (z.B. OTHELLOC.ASC) wird in gewohnter Weise vorbereitet und, wenn es sich um ein Farb-Programm handelt, vor dem Starten lediglich INITCOLO.URS hinzugeMERGEt.
Stilgerechter wäre gewesen, die neuen Funktionen entsprechend dem bisherigen Konzept mit in BACD3BIC.RMC hineinzuarbeiten, doch dafür fehlt mir als Neuling auf diesem Gerät natürlich die Programmiererfahrung.
In der derzeitigen Version des Emulators stimmen noch nicht alle Farben, ich habe sie so programmiert, daß sie auf der Originalhardware (hoffe ich jedenfalls) richtig dargestellt werden und bin zuversichtlich, daß es mit einer späteren Version des Emulators dann auch auf der virtuellen Maschine stimmen wird. Interessieren würde mich einmal die Arbeitsgeschwindigkeit des Originalgerätes – auf dem emulierten BIC zieht sich so eine Reversi-Partie über mehrere Stunden hin, was allerdings auch damit zusammenhängen kann, daß mein Notebook schon etwa zehn Jahre alt ist...
HRG-Transfer
Ermutigt von dem Erfolg nahm ich gleich das nächste Projekt in Angriff. Dieses kann als Ergänzung zu BasiCode gesehen werden, ist ihm zumindest vom Ansatz her sinnverwandt.
Seine Wurzel hat es mehr oder weniger in einem Tool, das 2001 spontan auf einem CPC-Treffen in Erlangen entstand, die Geschichte wurde schon in den KC-News 2/01 erwähnt. Auch in Erlangen war Ralle zugegen. Eine Grafik, die ich (damals noch als Binärdatei) von einer Diskette des Plus/4-Clubs auf den CPC übertragen hatte, gefiel ihm so gut, daß er sie unbedingt auf dem KC haben wollte. So knobelten wir auf die Schnelle eine Möglichkeit aus, sie auf Diskette abzuspeichern und von dieser Diskette in seinen KC einzulesen.
Die damalige Spontanlösung war äußerst umständlich, aber inzwischen habe ich die Methode optimiert und verfeinert und auch noch auf diversen anderen Computern nutzbar gemacht.
 |
|
 |
|
 |
Die Grafikdaten werden in eine Textdatei umgewandelt, ein Buchstabe verschlüsselt jeweils vier benachbarte Pixel (Bild 15 oben). Binärdateien würden im Vergleich zu ASCII-Dateien zusätzliche Probleme bei der Übertragung bringen. Diese Textdatei wird auf dem Zielcomputer eingelesen und dort wieder zurückgewandelt.
Auf den meisten Computern repräsentiert das höchstwertige Bit eines Bytes aus dem Grafikspeicher den am weitesten links liegenden Punkt einer Gruppe benachbarter Pixel.
Unterschiedlich ist jedoch die Reihenfolge dieser Bytes, am schwersten überschaubar nebenbei bemerkt auf dem KC 85/3.
Auf dem BIC ist es umgekehrt – die Byte-Reihenfolge ist unkompliziert (einfach wie beim Lesen und Schreiben, von oben nach unten zeilenweise von links nach rechts), aber hier ist die Zuordnung der Pixel zu den Bits gegenläufig, das höchstwertige Bit steht für den am weitesten rechts liegenden Punkt einer Pixelgruppe.
Außerdem gehören mehrere Bits zu einem Pixel: welche gesetzt oder nicht gesetzt
sind, entscheidet über die Farbe, in der der Punkt am Ende auf dem Monitor sichtbar wird.
Daher rührt, daß der BIC im SCREEN 5 sechzehn Farben darstellen kann, wenn alle vier Bits gesetzt sind, ist die Farbe weiß (Bild 15 unten links). In SCREEN 3 gehören zu jedem Punkt zwei Bit, deswegen sind hier nur vier Farben darstellbar (Bild 15 unten rechts). Ich habe in beiden Grafikbetriebsarten jeweils alle Pixel gesetzt.
In SCREEN 3, der Grafikbetriebsart mit 640 Pixeln Breite, stellt der Emulator leider noch nicht die rechte Hälfte des Bildschirms dar, hierfür mußte ich das Programm geringfügig abändern (und die beiden Hälften auf dem PC nebeneinanderstellen).
Bild 16: Grafik in der Grafikbetriebsart SCREEN 3, auf dem PC zusammengesetzt.
Vorläufig realisiert das Programm HRGIMPRT.ASC nur das Einlesen von Grafiken in den BIC, die umgekehrte Richtung kann ich auf dem virtuellen Gerät nicht testen, solange das Schreiben auf Disketten noch nicht emuliert wird. Wer, vielleicht auf der Originalhardware, den Export programmieren möchte, der hat freie Bahn, ich stelle es jedem frei, das Programm zu vervollkommnen.
Der Aufbau einer .HRT-Datei ist in den REM-Zeilen kurz skizziert, ausführlichere Informationen und mehr umgewandelte Bilder kann man im WWW finden.
Auf dem KC 85/3 und /4 bin ich mit diesem Programm schon weiter, möchte ihm vor einer Veröffentlichung aber noch den letzten Schliff geben, vielleicht klappt es ja schon bis zur nächsten Ausgabe der KC-News.
Die besprochenen Programme stehen hier einzeln zur Verfügung, sind aber auch alle im Teledisk-Abbild BASICODE.DUMP enthalten, so daß sie unter der Emulation oder nach Übertragung auf eine reale 5,25-Zoll-Diskette auf dem Originalgerät ausprobiert werden können.
Dateien
Im Archiv TRANSFER.ZIP sind unter anderem die folgenden Dateien zu finden:
BACD3BIC.RMC
Der beim BIC-Download fehlende Maschinencode zum Bascoder
INITCOLO.URS
Das Farb-Update zu BasiCode-3, bei Farbprogrammen (sonst aber auch nicht schädlich) vor RUN hinzuzuMERGEn
HRGIMPRT.ASC
Der Grafik-Transfer, jetzt für drei Formate
BIC?.BMP
Screenshots des BIC-Emulators mit je einem der Formate. Das 640-Pixel-Breite-Format wird leider (ich denke, ein Bug der Noch-Beta-Version des Emulators) nur in der linken Hälfte angezeigt, daher habe ich den Emulator ein zweites Mal gestartet und zwei Kommandos eingefügt, um (auf der linken Seite) auch die rechte Hälfte sehen zu können. Ich bin gespannt, ob es auf der Originalhardware funktioniert, auf die Dauer, ein Bild zu laden (hat vor allem für BIC3.BMP Stunden gedauert, was aber auch an der Betagtheit meines Notebooks liegen kann).
BASICODE.DUMP
Abgewandelte Systemdiskette (Teledisk-Abbild) Ich hoffe, mit Teledisk läßt sich daraus eine echte 5,25“-Diskette bespielen...
Änderungen:
-
- Systemdatei in USER 1 verschoben (mit Hex-Editor – Emulator kann bisher nur lesen), damit Computer im RBASIC bleibt
- AUTOEXEC.BAS lädt BASICODE.BAS
- Directory umsortiert, BasiCode-Sachen sind vornedran, Grafik-Transfer-Sachen am Ende
Weiterführende Informationen:
- DDR-Computer-Oldies: https://www.robotrontechnik.de/
- KC-Emu: https://kcemu.sourceforge.net/
- PDFs zum BIC: http://www.sax.de/~zander/bic/bc_bedal.pdf u.a.
- Wikipedia-Artikel: http://de.wikipedia.org/wiki/BASICODE
- Website: http://www.basicode.de/
- YAHOO-Forum: http://groups.yahoo.com/group/basicode
- Grafiktransfer, weitere HRT-Dateien in unterschiedlichen Formaten: https://www.joyce.de/software/grafik/grafik.htm
Zur Seite geschaut: Der Bildungscomputer A5105 und der Lerncomputer LC80
von Ralf Däubner
Der Bildungscomputers A5105
Der BIC ist einer der wenigen aus dem Hause Robotron, der von allem etwas hatte, aber nie richtig kompatibel war. Da dieser vorrangig für dem Informatik-Unterricht an den Schulen entwickelt wurde, war dies aber auch nicht notwendig. Für die Ausbildung zum CNC-Programmierer und zum Umgang mit WORDSTAR und DBASE war dieser völlig ausreichend, fanden sich an dem zukünftigen Arbeitsplätzen in dem Betrieben doch andere Computer (PC1715 usw.). Immerhin war er nach heutigen Gesichtspunkten virenresistent, weil SCP und RBASIC im ROM fest eingebaut waren.
SCP und RBASIC ist fest eingebaut, unabhängig ob die DSE (Diskettenspeichereinheit) vorhanden ist oder nicht. Das SCP wird mit einem 0-Byte-File gestartet. Sollte sich keines auf der Diskette finden oder ist keine Diskette vorhanden, so wird das RBASIC gestartet. Die parallelen Schnittstellen sind im BASIC sehr gut dokumentiert. Es gibt Grafik- und Sound-Befehle. Das BASIC ist aber mehr für das Erstellen von Datenbanken geeignet. Als Besonderheit findet sich ein ONSREEN EDITOR (c64 basic v2; c128 basic v7). Da das BASIC auch gleichzeitig als Oberfläche verwendet wird, sind einige Disketten-Befehle vorhanden. Zum Beispiel entspricht FILES dem bekannteren DIR (KC compact: CAT). Im gewissen Umfang wird auch der Grafik-Chip durch das BASIC unterstützt.
Der Computer bildet eine mechanische Einheit mit der Tastatur. Als Umhüllung findet sich ein nicht gerade unbekanntes Gehäuse (D005, KC compact). Als Serien-Erweiterung kam eine DSE zum Einsatz, deren Gehäuse aus Stahlblech besteht. In dieser DSE waren neben dem Netzteil diverse Hardware-Erweiterungen (PIO 2, SIO, FDC nebst Floppy, Netzwerkkarte und CTC) untergebracht. Als Monitor kam ein Standard-Bildschirm zum Einsatz, ein zweiter Farbmonitor konnte parallel betrieben werden. Herausgeführt wurden 2 PIO, 2 SIO, Floppy, AV-Ausgang, Mono und der Rechnerbus. Mechanisch war der Computer mit der DSE mit Hilfe von zwei Schienen fest verbunden. Im Rechner selbst fanden sich zwei Custom-Chips, um dem Platzbedarf zu verringern, sowie der Grafik-Chip (allerdings meist als eine der “West-Varianten“). Das Netzteil, das auch den Monitor mit 12 V versorgt, nahm in der DSE den meisten Platz ein.
Bild 17: Dieses Exemplar des Bildungscomputers A5105 war auf dem Clubtreffen 2005 zu sehen.
Da dieser ungewöhnliche Computer für Sammler interessant ist, soll es noch einige Bemerkungen meinerseits geben. Ungewöhnlich für Ostrechner ist der ONSCREEN-Editor (eine sonst nur auf Commodores zu findende Geschichte), der Befehlsumfang reicht weit über die Hardware hinaus (Soundbefehl). Die PIO-Schnittstellen sind kompatibel zum KC87 aus dem gleichen Hause. Offensichtlich war noch eine Sounderweiterung geplant. Als Konkurrenz zur der sich inzwischen etablierten KC-Reihe aus Mühlhausen war dieser nicht geplant. Gegen das offene Konzept der Mühlhausener hatten es aber alle kleinen ROBOTRONer schwer. Vielleicht war es auch der Versuch, sich gegen die Intershop-Computer (C=, Atari) zu behaupten, so finden sich doch einige Merkmale diverser West-Computer wieder. Obwohl der Grafik-Chip nie richtig ausgenutzt wurde, lassen sich doch einige anspruchsvolle Demos schon in RBASIC programmieren. Da dieser Chip so selten ist, gibt es leider sehr wenige Anwendungen. Der AY-Chip war auch erst zu Wende-Zeiten einigermaßen greifbar, so daß zur SOUND-Erzeugung auf bewährtes zurückgegriffen werden mußte. Das bestand im wesentlichen aus einem R-2R-AD-Wandler an einer PIO; benutzt wurden fünf Bit. Das führte aber immerhin zu einer Extra-Dokumentation des Soundbefehls. Dank Herrn Zander und dem Internet kann man nicht nur Dokus sondern auch RBASIC-Programme downloaden.
Technische Daten BIC A5105:
Der Lerncomputer LC80
“Der Lerncomputer LC80 ist ein Einkarten-Mikrorechner auf der Basis des Mikroprozessorsystems U880 (Z80). Er dient in erster Linie dem gründlichen Kennenlernen der Bausteine und dem Erlernen der Programmierung im Maschinencode.“
Eine bessere Einführung habe ich bis jetzt in keiner Anleitung gelesen. Ich selbst bin im Besitz eines LC80, der immerhin mit dem Original-Netzteil und den zwei dazugehörigen Anleitungsheften (das Zitat stammt aus der Bedienungsanleitung) relativ vollständig ist.
Also, was ist der LC80? Gut, da haben wir erst mal ein Netzteil, bei dem kein Steckplatz verloren geht. Intern ist das eigentlich nur ein einfacher Trafo ohne Gleichrichter. Das Gehäuse hat halt noch eine Steckdose auf der Oberseite. Der LC80 ist sehr schlicht aufgebaut. Als Gehäuse dient ein brauner Kunstleder-Umschlag, der zum Betrieb geöffnet werden muß, da die Tastatur und die Ausgabeanzeige (3 mal VQE 23 und 2 Status-LED) sonst nicht sichtbar bzw. bedienbar wären.
Hardwaremäßig gab es offensichtlich einige Varianten. Bei meinem Gerät wird die 5V-Betriebsspannung mit einer Grätz-Brücke und einem 7805 aufbereitet, die Takterzeugung paßt noch auf die Hauptplatine. Weiterhin unterscheiden sich die Geräte bei der Bestückung mit einem oder zwei EPROMs. Dieses wird sogar in der Bedienungsanleitung erwähnt wird. Es können aber noch drei EPROMs vom Typ 2716 hinzugefügt werden (ab Adresse 5000h). Ähnlich verhält es sich mit der Ausstattung des Arbeitsspeichers: Meist mit einem KByte ausgestattet, konnten drei KByte (je nach Verfügbarkeit) dazugelötet werden. Generell vorhanden waren zwei PIOs und ein CTC, die allerdings nur mit Einschränkungen frei genutzt werden konnten. Die erste PIO wurde nur für systeminterne Aufgaben genutzt, vier Bits der zweiten PIO ebenfalls, so daß nur 12 Bit vom Nutzer frei verwendet werden konnten. Die Tastatur besteht aus dem Oberteil eines Taschenrechners (MR-Serie SR1), bei dem die LCD-Öffnung mit einer bedruckten Alu-Platte abgedeckt ist. Die Tasten selbst sind nicht bedruckt, dafür die Alublende.
Die Software beschränkt sich auf das wesentliche, BASIC und andere Hochsprachen sind unbekannt. Die Programmierung erfolgt durch die direkte Eingabe des Maschinencodes. Im Handbuch finden sich entsprechende Programme zum Experimentie- ren. Das Betriebssystem ist typisch gut dokumentiert, es gibt sogar richtige Sound-Unterprogramme. Wofür die Startadresse der Begrüßungsmelodie wichtig ist, habe ich noch nicht herausgefunden. Es gibt tatsächlich Anwendungsprogramme und Spiele, als Massenmedium finden Kassette und EPROM Verwendung. Anfang der 90-er Jahre des vorigen Jahrhunderts wurde sogar ein neues Betriebssystem geschrieben.
Literatur über den LC80 ist sehr spärlich, es gibt drei Broschüren zu diesem Thema. Dagegen findet man im Internet genügend Informationen und Programme für den LC80. Immerhin gibt es nicht nur virtuelle Nachbauten, sondern auch real existierende. Auf diesen Seiten kann man sich auch lustige Anekdoten zur Entwicklung des LC80 zu Gemüte führen.
Fazit: Für Sammler ist der LC80 ein interessantes Stück Technikgeschichte. Man sollte drauf achten, daß die zwei Anleitungen dabei sind. Das Original-Netzteil ist, falls vorhanden, ein Glückstreffer, ansonsten geht jedes Netzteil mit 1 A bei etwa 12 V AC/DC. Für Bastler bietet sich schon durch dem einfachen Aufbau ein interessanter Einblick in die Mikrorechentechnik.
Technische Daten LC80:
BASIC-Programme
von Henning Räder
Alles um die DNS
Vor kurzem sah ich ein interessantes BASIC-Programm aus dem Jahr 1986 von Dr. Herren. Mit der ZX-Grafik wurde damit die Struktur der Desoxyribonuklein-Säure (DNS, engl. DNA) dargestellt. Erfreut stellte ich fest, dass schon sehr früh und immer wieder gern der ZX81 in der Naturwissenschaft eingesetzt wurde. Wie es der Zufall wollte, bekam ich fast gleichzeitig ein KC85/4-Programm in die Finger: “Molekulare Genetik“. Mit diesem kann man nach allen Regeln der Kunst verschiedene Eiweiße aus Bausteinen entstehen lassen und diese in die DNS einarbeiten. Das KC85/4-Programm ist recht lang – fraglich, ob es für den ZX81 umgeschrieben werden kann. Das habe ich aber geplant. Beim ZX81-Programm gab es bei der Bildschirmdarstellung ein Problem. Nach der Abbildung in einem meiner Lexika passte da einiges nicht zum Computerbild. Deshalb wandte ich mich an Dr. Herren. Er schickte mir freundlicherweise eine neue Version des Programms DNS, das das richtige Ergebnisbild brachte.
LINKS1.SSS ist das niederländische Originalprogramm. In INKS 1DT.SSS und NKS 1DT1.SSS wurden die Texte zum größten Teil ins Deutsche übertragen. Vor der Ausführung ist der Basicoder BAC854-C.SSS zu laden.
Weibull-Verteilung mit dem KC85
Bei der statistischen Auswertung von Messwerten und Daten aus Physik, Chemie, Medizin usw. spielen Verteilungsfunktionen eine wichtige Rolle. So ist zum Beispiel die Gauß-Normalverteilung mit ihrem Bild als symmetrische Glockenkurve sehr bekannt. Eher weniger geläufig sind spezielle Verteilungsfunktionen, wie z.B. die nach einem schwedischen Ingenieur benannte Weibull-Verteilung. Diese ist durch die Funktion
F (x) = 1 − e−(x/a)b
gegeben, wobei x ≥ 0 und a und b einzusetzende Parameter sind.
Vor längerer Zeit hatte ich bereits durch einen Fachartikel [1] Kenntnis von der Anwendung dieser Funktion im Bereich der Hochspannungskeramik, jedoch keine Computeranwendung gefunden. Aktuell kam mir der Zufall zu Hilfe, dass in [2] eine wunderbare Anwendung im Instandhaltungsbereich von technischen Anlagen beschrieben ist, die ich auf dem ZX81 umsetzen wollte. Dank der sehr wichtigen Hilfe von Thomas Rademacher am ZX81 und Elmar Klinder am KC85 war ich in der Lage, damit zu arbeiten. An beide mein bester Dank.
Im Einzelnen ist die Problematik in [2] genau beschrieben. Im Programm TAB1.SSS (entspricht dem Programm TABELLE in [2], statt EETAP und EETAH werden die Variablennamen ET und EH verwendet) muss der Formparameter b, der Skalenparameter a, die mittlere prophylaktische Erneuerungsdauer ED, die mittlere Havarie-Erneuerungsdauer ET und die Tabellenschrittweite H eingegeben werden. Dort, wo der Vorzeichenwechsel ist, liegt der Bereich des optimalen Erneuerungsintervalls. Das Programm NEWTON errechnet daraus das optimale Erneuerungsintervall TAU, während das Programm DAUERV die Dauerverfügbarkeit in der Nähe des optimalen TAU berechnet.
Die Programme NEWTON und DAUERV sind nicht auf der Beilagendiskette enthalten, ihre Listungs sind in [2] zu finden.
Literatur
- Heuschkel/Nadler: Festigkeit und Festigkeitsprüfung keramischer Werkstoffe, Institut für Rationalisierung der Elektrotechnik/Elektronik, Institutsteil Dresden, 1979.
- Kleinstrechner-Tips, Heft 9 S. 44–52, Berechnung optimaler Erneuerungsintervalle für die vorbeugende Instandhaltung mit Hilfe des Bürocomputers A5120, 1988.