Hardware – Tips

von Josef Zeller

Meiner Meinung nach ist es unsinnig, über Fragen zu schreiben, die zwar irgendwo in der Luft stehen, aber sonst keinen Leser interessieren. Um das Nascom-Journal so informativ wie möglich zu machen, wäre es für mich wichtig zu wissen, was Sie – die Leser – wissen wollen. Der folgende kurze Artikel über die Fehlersuche wurde auch dadurch angeregt, daß verschiedene Leser etwas ähnliches wünschten. Also lassen Sie mich wissen, welche Wünsche Sie haben. Ich werde gerne Datenblätter besorgen, andere Zeitschriften nach Quellen absuchen etc., aber nur wenn sicher ist, daß solche Informationen auch ihre Leser finden. Sollte zum Beispiel mein Artikel über den DMA-Einsatz Resonanz finden, würde es mir Spaß machen, mehr über diesen Baustein zu schreiben.

Aber nun zur Praxis!

Fehlersuche

Die im Juli Journal auf Seite 19 gemachte Aussage, daß seltsame grafische Zeichen auf eine defekte CPU zurückzuführen sind, muß nicht unbedingt immer richtig sein. Aus eigener Erfahrung kann ich berichten, daß auch ein defektes Decodier-IC diesen Fehler verursachen kann,(wie z.B. in meinem Fall IC 45).

Hegt man den Verdacht, daß eines der Decodier-ICs defekt ist, kann man dieses durch einen Trick und ohne große Hilfsmittel finden.

Um mit Hilfe eines Voltmeters das defekte IC zu ermitteln, schaltet man den Nascom aus. Nun verbindet man den WAIT-Eingang der CPU mit Masse und schaltet den Nascom wieder ein. Die CPU führt nun einen Op-Code Fetch Zyklus (M1 Zyklus) aus, in dem aus der Speicherzelle 0000 der OP-Code 31H geholt wird. Da die CPU beim zweiten Takt des M1 Zyklus den WAIT-Eingang abfragt und dieser nun 0 ist, führt die CPU dauernd WAIT Zyklen aus; d.h. alle Adress-und Datensignale wie auch die Steuerleitungen (MREQ, RD und M1 sind 0 V) bleiben in dieser Zeit stabil. Nun nimmt man sich den Schaltplan zur Hand und überlegt sich, wie die Signale durch die ICs logisch verknüpft werden. Da die Signale stabil bleiben, kann man verglichen, ob die am Nascom gemessenen Signale auch mit den theoretisch überlegten Werten übereinstimmen.

Natürlich kann man auch testen, ob die CPU noch in Ordnung ist. Der Adreßbus muß den Wert 0000H, die Datenleitung den Wert 31H aufweisen. Von den Steuerleitungen sind nur MREQ,​RD und M1 low.

* * * * *

Schnelle Bildschirmverwaltung beim Nascom 1 durch Einsatz eines Z-80 DMA

Problem

Das Bildschirmscrolling beim Nascom 1 erledigt die CPU, indem sie den Bildschirmspeicher um 0370h Bytes verschiebt. Dadurch ist die CPU beim Listen (Tabulatebefehl oder Assemblerlisting) die meiste Zeit damit beschäftigt, den Bildschirmspeicher zu verschieben. Eine Verlängerung von Programmlaufzeiten ist die unangenehme Folge. Um nun die CPU vom „stupiden“ Bildschirmscrollen zu entlasten, wird einem Z-80 DMA Baustein diese Aufgabe übertragen.

Dazu wird der DMA von der CPU programmiert und übernimmt dann die Kontrolle über den Bus. Die CPU wird, während der DMA aktiv ist, abgeschaltet, verschiebt den Bildschirmspeicher und gibt dann die Kontrolle des Busses an die CPU zurück, Der Vorteil des DMA Einsatzes liegt in einer wesentlichen Verkürzung der Zugriffszeiten auf den Bildschirmspeicher, Der DMA benötigt für das übertragen eines Bytes 4 Taktzyklen, während die CPU dafür 21 Taktzyklen benötigt (LDIR Befehl). Daraus ist ersichtlich, daß sich für das Scrolling und Löschen des Bildschirmspeichers eine Verfünffachung der Arbeitsgeschwindigkeit ergibt. Beim Tabulatebefehl (wenn der Bildschirmspeicher oft verschoben wird) verkürzt sich mit DMA Einsatz die Programmlaufzeit um den Faktor 2. Der DMA wird also immer dann eingesetzt, wenn größere Mengen von Daten übertragen werden sollen: entweder um eine Maximierung der Geschwindigkeit bei Programmen oder Datenübertragungen zu erreichen oder dann, wenn die CPU für die Datenübertragung zu langsam ist (z.B. bei Hard Disk).

Hier soll nur ein Anwendungsfall gezeigt werden. Es ist natürlich möglich, den DMA neben der Bildschirmverwaltung auch noch für