|
CPD5 ist ein CP/M Einplatinencomputer, der keinen separaten FLASH-ROM-Speicher mehr benötigt. Beim Erststart des Computers übernimmt ein Mikrocontroller das Initialisieren des Z80-Codes im Z80-Computer. Die enge Symbiose aus Z80-Computer und Mikrocontroller verleiht dem Gesamtsystem eine neue Qualität mit beeindruckenden Möglichkeiten. Programme und Daten werden in einer batteriegepufferten RAM-Floppy gespeichert. |
Warum kommt nach CPD3 gleich CPD5 (wo ist CPD4)? CPD4 gab es nur eine kurze Zeit als Konzept. Dann habe ich parallel dazu das Konzept von CPD5 entwickelt, das sich schon in dieser Phase als besser herausstellte. Somit ist CPD4 nie weiter entwickelt worden.
Äußerlich betrachtet sieht CPD5 nicht viel anders aus als sein Vorgänger CPD3. Aber das Aussehen täuscht. Auf dieser kleinen Leiterplatte werkeln 1 Z80-Mikroprozessor und 2 Mikrocontroller (ATMEGA 1284P als Bus-Controller und ATMEGA 162 als Adress-Extender) ständig vor sich hin. Das macht das Gesamtkonzept äußerst flexibel.
Der erste Grund für eine Änderung des Konzeptes von CPD2 und CPD3 war (das schon bei CPD3 beschriebene) Problem der schlechten Verfügbarkeit des FLASH-EEPROMs AM29F040. Zudem benötigt man für die Programmierung des AM29F040 ein spezielles Programmiergerät.
Die neue Idee war, den Code für den Z80 (BIOS, BDOS, CCP) aus dem FLASH-Speicher eines Mikrocontrollers lesen. Das hat einige Vorteile:
ein Mikrocontroller lässt sich über ein modernes Programmiergerät (wie z.B. mySmartUSB light von der Laser & Co. Solutions GmbH aus Löbau, das ich gern verwende) in wenigen Sekunden programmieren
dazu muss kein Spreicherschaltkreis aus der Fassung gehoben werden (das ist sehr umständlich)
der Mikrocontroller bildet gleichzeitig die Schnittstelle zum PC (RS232 über USB)
der Mikrokontroller verwaltet zusätzlich den RAM (Adressen A16 bis A18 = RAM-Floppy)
Das Konzept ist so flexibel, dass man mit dieser Hardware auch ein CP/M 3 oder CP/M Plus-Sytem mit einem umschaltbaren RAM (Banking) umsetzen kann (bisher noch in Arbeit).
Was anfänglich noch nicht absehbar war, ist die beeindruckende Geschwindigkeit des Gesammtsystems im Betrieb mit der RAM-Floppy. Auch die Batteriepufferung hält mit einer Batterie aus einem alten PC bereits mehrere Wochen (Stromverbrauch etwa 200µA).
Z80-Computer mit 512 KB RAM (nur 64 KB von Z80 direkt ansprechbar)
die Verwaltung des RAMs über 64 KB erfolgt durch den Mikrocontroller
der RAM über 64 KB wird als RAM-Floppy genutzt
damit die Daten auf der RAM-Floppy nach dem Abschalten des CPD5 nicht verloren gehen, wird der RAM durch eine kleine Batterie gepuffert
ist die RAM-Floppy noch nicht initialisiert, wird sie nach dem Erststart mit den Programmen "POWER.COM" und "RT.COM" (Ramtest vom Autor) initialisiert, so dass DIR bereits etwas anzeigt
das Erstladen weiterer Programme und Daten auf die RAM-Floppy kann über die PC-Schnittstelle erfolgen (separates Laufwerk)
zusätzlich kann jedes Z80-Programm (Beginn beliebig in den Quelltext integrierbar) über einen WAIT-Tracer mitgeschnitten weden (300 Maschinenbefehle)
die so gespeicherten Trace-Daten können in Einzelschritt-Modus in der CONSOLE auf dem PC vorwärts und rückwärts in der PRN-Datei des Quelltextes betrachtet werden
Im folgenden Blockschaltbild wird das Zusammenspiel der Hauptkomponenten dargestellt.
Für die Ansteuerung aller 19 Adressleitungen (A0..A18) des SRAMs musste eine Lösung gefunden werden. Grundsätzlich kann man das natürlich auch mit diskreten Buspuffern (wie z.B. 74244 oder 74255 siehe auch Projekt VGAGEN2) realisieren. Aber eigentlich schwebte mir eine Umsetzung nach dem Vorbild meiner FLASH-RAM-Floppy RAMFL vor. Genutzt wird hier ein ATMEGA 162 als anwendungsspezifische integrierte Schaltung (ASIC). Der AdressExtender kann in mehreren Betriebsarten programmiert werden:
LOAD_ADRESS - laden einer neuen Adresse
INC_ADRESS - Inkrement der geladenen Adresse
ADRESS_TRISTATE - Adressbus auf Tristate setzen
WAIT_Z80ToBuf - Wait Z80-Bus to AE-Buffer
WAIT_BufToBC - Wait AE-Buffer to Bus-Controller
Mit diesen Betriebsarten sollten alle Anforderungen abgebildet werden können.
Der BusController wird durch einen ATMEGA 1284P oder einen ATMEGA 644P (beide sind weitgehend PIN- und Softwarekompatibel) umgesetzt. Er ist der physische Hauptcontroller des CPD5-Systems. Auf dem 128 MB Flash-Speicher sind alle Z80 Programme untergebracht (BIOS, BDOS, CCP). Der BC übernimmt die Initialisierung der Z80 nach dem Start und übergibt danach die logische Kontrolle an den Z80-Computer. Benötigt das CP/M-System eine BIOS-Schnittstelle (CONIN, CONOUT, READ und WRITE), so wird dies ebenfalls durch den BC realisiert.
Der eigentliche Z80-Computer auf dem das CP/M läuft, ist ein Minimalsystem bestehend aus Z80 CPU, 2 x Z80 PIO und dem 512 KB RAM. Es hat eine sehr enge Bindung an das Mikrocontroller-Gespann BusController und AdressExtender. Für spezielle Aufgaben wird die Kontrolle an den BusController übergeben.
Entsprechend einer alten Entwicklerrichtlinie - halte die Hardware möglichst einfach und setze die Aufgaben dann besser in Software um - besteht das Gesammtsystem CPD5 nur aus 8 Schaltkreisen (wenn man die TRACE-Logik und eine PIO weglässt, so läuft alles auch bereits mit 6 Schaltkreisen).
Die Verbindung zum PC (soweit mit der CONSOLE gearbeitet werden soll) erfolgt mit einem Conrad Mini-USB zu UART Konverter.
Schaltplan des CPD5 Z80 als Eagle-Datei: CPD5.sch
Schaltplan des des CPD5 Z80 als PDF-Datei: CPD5.pdf
Unter 3. Das Konzept von CPD5 wurden die einzelnen Komponenten bereits kurz beschrieben. Iin den folgenden Abschnitten werden die Softwarepakete für die einzelnen Komponenten beschrieben.
Beginnen wir mit der einfachsten Komponente. Für die Ansteuerung der Z80 und des RAMs werden viele Adressleitungen benötigt. Der BusController hat zwar 40 PINs, das reicht aber nicht für alle erforderlichen Daten-, Adress- und Steuerleitungen. Die Lösung den AdressExtender mit dem ATMEGA 162 zu realisieren, bietet sich an, da er vielen frei verfügbaren IO-Ports besitzt (35 statt 32 bei anderen uCs). Grundsätzlich kann aber auch ein ATMEGA 16 oder ein ähnlicher Controller genutzt werden. Da der ATMEGA 162 aber nicht pinkompatibel zum ATMEGA16/32 ist müsste sowohl die Hardware als auch die Software geändert werden.
Die Software wurde mit dem RONPAS-Compiler geschrieben. Der RONPAS-Compiler kann unter RONPAS - AVR© PASCAL-Compiler im Bereich "Programmier-Projekte Lazarus / Free Pascal" herunter geladen werden. Da es sich hier noch um eine Beta-Version handelt, kann keinerlei Garantie über den Erfolg der Nutzung gegeben werden (siehe Lizenzbedingungen).
Quelltext des AdressExtenders (AE) für RONPAS-Compiler: CPD5_AE.ZIP
Wesentlich komplexer als der AdressExtender (AE) ist das Programm zum BusController (BC). Der BC ist die zentrale Steuereinheit, wobei die Z80 und das CP/M-System nach der Anfangsinitialisierung die Regie übernehmen. Dann führt der BC nur noch die Anweisungen des Z80 CP/M-BIOS aus.
Die Software wurde mit dem RONPAS-Compiler geschrieben. Der RONPAS-Compiler kann unter RONPAS - AVR© PASCAL-Compiler im Bereich "Programmier-Projekte Lazarus / Free Pascal" herunter geladen werden. Da es sich hier noch um eine Alpha-Version handelt, kann keinerlei Garantie über den Erfolg der Nutzung gegeben werden (siehe Lizenzbedingungen).
Das Hauptprogramm beginnt ab Zeile 2207. In 2211 wird die Word-Variable UBRR0 für die serielle Schnittstelle erzeugt. 2216 Initialisierung der Ports des BC (Ein- und Ausgange). 2218 Initialisierung des Zeigers für das Daten_Array, danach weitere Grundeinstellungen.
2235 10 ms warten bis alle Pegel stabil sind. 2237 Abfrage der Funktion "RF_leer" (RAM-Floppy ist leer? - Funktion auf 2175). Bei "RF_leer" werden dei letzten beiden Bytes der RAM-Floppy abgefragt, ob sie das Füllbyte "E5H" enthalten (die RAM-Floppy ist im Leerzustand damit initialisiert). Ist die Rückmeldung wahr, dann ist die RAM-Floppy in Betrieb (sauber durch Batterie gepuffert) und muss nicht initialisiert werden. Ist die Rückmeldung falsch, so wird die RAM-Floppy mit "RAM_loeschen" gelöscht und mit "E5H" beschrieben. Danach wird mit "COPY_DISK_TO_RAM" das DiskImage "DISK.INC" in die RAM-Floppy copiert. Die RAM-Floppy enthält dann die Programme "POWER.COM" und "RT.COM" (selbst geschriebener RAM-Test).
2248 bis 2251 Einstellen des Zeiges auf das Daten_Array CPD5_ARR (das sind die Binärdaten des Z80 BIOS). Mit "COPY_ARRAY_TO_RAM" wird das BIOS aus dem ARRAY CPD5_ARR in den SRAM auf der Platine geladen. Die Lade-Adresse ist 0000H (Parameter $00 ist der High-Teil der Ladeadresse).
2259 Der BC hat nun alles vorbereitet und kann die Regie an den Z80 übergeben. Mit "starte_Z80" zieht er sich schrittweise zurück. Die Steuerleitungen des BC werden abgeschaltet und der AdressExtender (AE) gibt mit "ADRESS_TRISTATE" den Adressbus für die Z80 frei. Danach wird ein RESET an der Z80 ausgelöst und die Z80 beginnt mit der Abarbeitung des Programms ab Adresse 0000H.
Sehr wichtig !!!
An dieser Stelle beginnt ein Regiewechsel zwischen BC und Z80. Die Initialisierung des Systems hat der BC durchgeführt. Die Z80 wurde mit BUSRQ abgeschaltet. Von nun an übernimmt die Z80 mit dem CP/M die Regie und fungiert als Master. Der BC geht in eine Warteschleife und wartet auf Anweisungen von der Z80. Kommt eine Anweisung (z.B. CONOUT - Ausgabe eines Zeichens) so wird diese Anweisung ausgeführt und die Kontrolle wird wieder zurück an die Z80 gegeben.
2263 Abfrage der seriellen Schnittstelle, ob ein Zeichen eingetroffen ist (läuft hier über Pollen des Registers im ATMEGA). Sollte ein Zeichen empfangen worden sein, so wird dies in die Variable "Zeichen" geschrieben. 2265 bis 2267 Hier werden die weiteren Zeichen gelesen bis das Zeilenende (CR und LF erreicht ist - eine andere Kommunikation wird nicht unterstützt).
2269 "Z80CALL_abfragen" hier wird abgefragt, ob das BIOS eine Anforderung an den BC hat. Wenn ja, so wird diese abgearbeitet.
2271 bis 2278 dient der TRACE-Bearbeitung. Diese wird zukünftig nicht mehr unterstützt.
2261 bis 2280 Diese loop / endloop Schleife wird ständig abgearbeitet.
Quelltext des BusControllers (BC) für RONPAS-Compiler: CPD5_BC_CPM_2.2_F000.ZIP
Hinweis:
Diese ZIP-Datei enthält ebenfalls den erforderlichen CP/M-Binärcode umgewandelt in PASCAL-Quelltext. Es handelt sich hier um ein einfaches CP/M 2.2-System. Das BIOS beginnt ab der Adresse 0F000H.
Assemblieren der Quelltexte mit dem Assembler M80.COM in einem CP/M-Emulator
M80 CPD5.ERL,CPD5.PRN=CPD5BAT/M/Z
CPD5BAT.MAC = zentrale Assembler-Datei von der aus alle Include-Dateien aufgerufen werden
CPD5DEF.INC = Wichtigste Include-Datei mit allen Variablen- und Speicherplatzdefinitionen
CPD5ULDR.INC = klein aber wichtig, der Urloader, der das BIOS vom Anfang des RAMs in den Speicherbereich für das BIOS (F000H) kopiert
CPD5BIOS.INC = hier ist der Quelltext des eigentliche BIOS (sehr ausführlich dokumentiert)
CPD5Z80C.INC = auch eine sehr kleine, aber wichtige Datei, dies ist die Software-Schnittstelle zwischen dem CP/M-BIOS und dem Mikrocontroller
CPD5INIT.INC = nach dem Hochladen des CP/M-BIOS in seinen Speicherbereich, werden danach als Erstes die PIOs mit dieser Routine initialisiert
MONITOR.INC = In dieser Include-Datei befinden sich einige nützliche Hilfsprogramme (z.B. Ausgabe einer Hexadezimaladresse an CONOUT, oder Ausgabe eines ganzen Sektors an CONOUT), die aber für den späteren Betrieb von CP/M nicht unbedingt benötigt werden. Sinnvoll können diese Hilfsprogramme sein, wenn man den Ablauf von Programmteilen überwachen möchte.
Damit das BIOS nach dem Verschieben in den oberen Speicherbereich auch sauber läuft wird bei der Assemblierung in der Datei CPD5BAT.MAC mit der Anweisung
.PHASE BIOSBASE
das BIOS und die dazugehörigen Unterprogramme auf die neue Adresse verschoben.
Nach dem Assemblieren folgt das Linken mit LINKMT.COM
LINKMT CPD5=CPD5/M/P:0000
Die so entstandene CPD5.COM Datei muss nun in den Z80 Speicher ab Adresse 0000H geladen werden. Da dies beim CPD5 der BC übernimmt, muss diese Datei in den PASCAL-Quelltext eingebunden werden. Das geht recht einfach mit dem Windows-Programm COM2INC.exe (am besten innerhalb einer Batchdatei).
COM2INC.exe CPD5.COM CPD5_TXT.INC Laenge_CPD5_Array CPD5_ARR
Aus der COM Datei wird ein Byte-Array (mit dem Namen CPD5_TXT.INC) in der Größe der COM-Datei erstellt. Dieses Byte-ARRAY wird durch den BC in den RAM geladen werden.
Hinweise zum BIOS
Das BIOS ist sehr ausführlich kommentiert. Die Interaktionen mit dem BC laufen immer gleich ab.
Dazu hier das Beispiel der Ausgabe eines Zeichen an CONOUT.
In diesem Beispiel wird die CONOUT-Schnittstelle des CP/M BIOS gezeigt. Nach dem Aufruf von CONOUT wird das B-Register mit dem CODE für CONOUT geladen und das Unterprogramm "UP_Z80CALL" aufgerufen.
Im Unterprogramm "UP_Z80CALL" wird als Erstes gewartet, bis eventuelle alte Anforderungen abgearbeitet sind. 17 bis 20 Die übergebenen Parameter werden in RAM-Speichervariablen abgelegt. Da der BC auch vollen Zugriff auf den RAM hat, kann er später diese Inhalte auslesen.
23 bis 26 nun wird die Steuerleitung für den Z80CALL auf Low gelegt. Das ist für den BC das Zeichen, dass eine Anforderung des Z80 vorliegt.
Offiziell wartet jetzt die Z80, bis die Anforderung vom BC abgearbeitet wurde und der BC dann die Steuerleitung Z80AK auf Low legt.
Nun läuft folgendes ab:
der BC fragt innerhalb seiner loop / endloop Schleife die Steuerleitung Z80CALL ab
ist diese auf Low, so erzeugt der BC eine Busanforderung an die Z80 über BUSRQ
die Z80 läuft derzeit in der Warteschleife und bestätigt die Busanforderung mit BUSAQ
solange "schläft" die Z80 und der BC hat vollen Zugriff auf alle Bussysteme und den Speicher
der BC liest nun aus der Speicherzelle RAM_Z80CALL_MD den Mode zur Anforderung der Z80 aus (Was soll ich denn machen liebes Z80-System?)
anhand dieses Mode-Bytes verzweigt der BC in der Prozedur "Z80CALL_abfragen" zu den entsprechenden Abarbeitungsprozeduren der Anforderungen
nach der Abarbeitung schaltet der BC die Bestätigungsleitung "Z80AK" auf Low, damit bestätigt der BC die Fertigstellung der Anforderung
die Z80 "schläft" noch im BUSRQ
erst wenn der BC die Kontrolle wieder an die Z80 übergibt - mit High setzen der BUSRQ-Leitung - erhält das Z80-System nun die Meldung von der Fertigstellung der Anforderung durch die High gesetzte Z80AK-Leitung
solange dies passiert, wartet der BC noch in einer Schleife auf das High setzen der Anforderungsleitung "Z80CALL". Nun setzt die Z80 in Zeile 35 bis 38 die Anforderung zurück und der BC geht dann wieder in seine loop / endloop Schleife
in Zeile 42 wird das Register A mit einem eventuellen Rückgabewert geladen (z.B. bei Tastatureingabe) und die Z80 kehrt zurück aus dem BIOS-Programm und arbeitet weiter im Hauptprogramm
Soweit das Beispiel zur Abarbeitung der CONOUT-Anforderung.
BIOS Quelltext für CP/M 2.2 mit Anbindung an die CONSOLE (Version 1.6): CPD5_BIOS_2.2_V_1.6.ZIP
Wie schon CPD2 und CPD3 kann auch CPD5 über die USB-SERIAL-Verbindung mit dem PC kommunizieren. Für die ersten Tests ist dies eine einfache und schnell umzusetzende Lösung. Leider läuft die Übertragung der Daten über die 128000 Baud recht langsam.
Das Programm mit Quelltext wird unter CONSOLE im Bereich "Programmier-Projekte Lazarus / Free Pascal" beschrieben.
Aus den eigenen Erfahrungen beim Aufbau der Testplatine des CPD5 und aus Anfragen des ersten Nachbauers sollen an dieser Stelle einige Hinweise gegeben werden.
schrittweiser Test
Nach dem Aufbau der gesammten Schaltung oder nach dem Aufbau der jeweils erforderlichen Komponenten wird ein schrittweiser Test empfohlen. War der Test erfolgreich, kann der nächste Test durchgeführt werden. Wenn nicht, muss der Fehler gesucht werden.
1. LED Blinktest am BC
Der BC wird mit den wichtigsten Anschlüssen versehen und bekommt am Port D7 eine rote LED. Diese LED soll nun blinken.
Hinweis: Der Blinktest läuft auch ohne Einstellung der Fuses. Bei neuen ATMEGAs ist immer der interne Generator mit etwa 1 MHz aktiviert.
LED Blinktest des BusControllers (BC) - Version 1: 01_Blinktest_BC.zip
LED Blinktest des BusControllers (BC) - Version 2: 01_CPD5_BC_LED-Blinken.zip
2. Ausgabe eines Zeichens an die serielle Schnittstelle des BC
Blinkt die LED am BC, ist der ATMEGA1284 grundsätzlich in Betrieb. Der nächste Schritt ist die Inbetriebnahme der seriellen Schnittstelle und die Ausgabe eines Zeichens an ein Terminalprogramm.
Hierfür müssen die Fuses auf den externen Quarz umgestellt werden.
Für die Kommunikation kann ein beliebiges Terminalprogramm genutzt werden. Die Programme wurden alle mit dem SETERM getestet.
BAUDRATE = 81920
Ausgabe eines Zeichens an die serielle Schnittstelle des BC: 02_CPD5_BC_Serial.zip
3. Beschreiben und Lesen des RAM, Starten der Z80
Läuft nun auch die serielle Schnittstelle des BC können die folgenden Softwaretests "vonn innen" durchgeführt werden. Dazu werden kleine Testprogramme installiert, die dann über ein empfangenes Zeichen von der seriellen Schnittstelle aktiviert werden. Mit dieser Methode kann man Schritt für Schritt Aktionen Auslösen (z.B. das Laden des Z80-Binärcodes in den RAM) und danach kontrollieren, ob das Programm ordentlich ausgeführt wurde.
BAUDRATE = 81920
Beschreiben und Lesen des RAM, Starten der Z80: 03_CPD5_BC_SRAM.ZIP
Beschreiben und Lesen des RAM, Starten der Z80: 14_CPD5_BC_Z80_CONIO.ZIP
4. Hardwaretest
An meiner laufenden Nummerierung (15 für Hardwaretest) kann erkannt werden, dass dazwischen viele Tests gemacht wurden, aber es inhaltlich eigentlich nicht wirklich voran ging. Die Ursache ist ein Fehler in meiner Hardware, den ich einfach nicht finden konnte. Das Testprogramm der Z80 (dass die LED am PIO-Port blinken läßt) lief mal und mal nicht.
Daher entschied ich mich ein Hardwaretestprogramm zu schreiben. Die Z80 und der RAM müssen dafür vom Sockel entfernt werden. Mit den beiden Mikrocontrollern BC und AE werden einzeln die Adressleitungen auf High gelegt. So kann man mit einem einfachen Logiktester überprüfen, ob die Adressen bis zur Z80 und bis zum RAM sauber geschaltet werden.
Der Fehler in meiner Hardware war eine kalte Lötstelle in einer Adressleitung.
Hardwaretest: 15_Hardwaretest.zip
5. Z80 Entwicklung und weitere Tests
Spätestens nach dem Hardwaretest sollte die Hardware sauber laufen. Mit dem Aufruf von CONIN und CONOUT im Z80-BIOS kann man nun ein einfaches Monitorprogramm erstellen (mit Menüs und Unterprogrammen). Einige nützliche Routinen befinden sich in der Datei "MONITOR.INC" unter den Assemblerprogrammen (CPD5_BIOS_2.2_V_1.6.ZIP). Oder man versucht jetzt die endgültige Version des BCs (CPD5_BC_CPM_2.2_F000.ZIP).
Sollte es zu Problemen kommen kann man durch Einfügen folgender Zeilen in den Quelltext des BC
Write_String:='yTestpunkt 01';
WriteLn;
eine Ausgabe auf den Protokollbildschirm der CONSOLE erreichen. So sieht man welche Stellen im Programm sauber abgearbeitet wurden. Diese Technik kann man selbstverständlich auch in den Prozeduren einfügen.
Diese Technik nutze ich auch während der Entwicklung und dem Test neuer Programme (siehe auch 3.1.13 Anzeige eines Kommentars in 3.1 Beschreibung der einzelnen Protokoll-Anforderungen).
Der CPD5-Kern allein ist ein sehr interessantes System. Die Vorteile dieses Systems werden aber erst zusammen mit VGAGEN2 (VGA-Grafikkarte) erlebbar.
Die Performance beim Zusammenspiel beider Baugruppen war während der Entwicklung noch nicht absehbar. Wird nur mit der RAM-Floppy gearbeitet, reagiert CP/M erfreulich schnell. Das Laden neuer Programme dauert nur Sekundenbruchteile (kleiner 1 Sekunde). Das Arbeiten mit dem guten alten CP/M macht nun richtig Spass.
Hier ein kurzes Video zur Arbeit mit CPD5 (etwa 65 Sekunden)
DIR - Anzeige des Directorys
TURBO - Starten von Turbo Pascal
Y - mit Fehlermeldungen
W - Workfile -> laden einer Arbeitsdatei -> ESC.PAS -> ein kleines Testprogramm für den VGA-Monitor
E - Editor starten (nur zum Test)
O C Q - das berühmte Umschalten auf den Compilermode mit Erzeugen der COM-Datei
C - Compiling - Compilieren der ESC.PAS Datei nach ESC.COM
Q - Turbo Pascal beenden
zurück am Promt - Laufwerk A:
ESC - Starten des Testprogramms
Die VGA-Grafikkarte VGAGEN2 ist über das ITP2-Protokoll mit dem CPD5 verbunden. Da der CPD5 eine eigene RAM-Floppy besitzt und die CONIN (Tastatur) und die CONOUT-Schnittstelle (Monitor) über den VGAGEN2 bedient werden, ist diese Konfiguration eigenständig laffähig. Es müssen nur einmalig die erforderlichen Programme von der PC-Console (Laufwerk B:) auf die RAM-Floppy (Laufwerk A:) kopiert werden - natürlich am Besten mit POWER.COM.
VGAGEN2 selber ist ein eigenständiges Projekt und wird auf der Internetseite VGAGEN2 näher erläutert.
Diese(s)
Werk bzw. Inhalt von Ronald Daleske steht unter einer
Creative Commons Namensnennung-Nicht-kommerziell 3.0
Deutschland Lizenz.
keine Mängelgewähr
DIESE SOFTWARE WIRD VOM URHEBERRECHTSINHABER "OHNE MÄNGELGEWÄHR" BEREITGESTELLT. ALLE AUSDRÜCKLICHEN ODER STILLSCHWEIGENDEN GEWÄHRLEISTUNGEN, EINSCHLIESSLICH DER STILLSCHWEIGENDEN GEWÄHRLEISTUNG DER MARKTGÄNGIGKEIT UND EIGNUNG FÜR EINEN BESTIMMTEN ZWECK (JEDOCH NICHT DARAUF BESCHRÄNKT), WERDEN AUSGESCHLOSSEN. DER URHEBERRECHTSINHABER IST IN KEINEM FALL UND NACH KEINER HAFTUNGSTHEORIE (SEI ES AUF VERTRAGSBASIS, AUF DER BASIS STRENGER HAFTUNG ODER UNERLAUBTER HANDLUNGEN, EINSCHLIESSLICH FAHRLÄSSIGKEIT) FÜR BELIEBIGE VERURSACHTE DIREKTE, INDIREKTE, ZUFÄLLIGE, BESONDERE, EXEMPLARISCHE SCHÄDEN ODER FOLGESCHÄDEN (EINSCHLIESSLICH, JEDOCH NICHT BESCHRÄNKT AUF BESCHAFFUNG VON ERSATZPRODUKTEN ODER -LEISTUNGEN, NUTZUNGSAUSFALL, DATEN- UND GEWINNVERLUST ODER GESCHÄFTSAUSFALL) HAFTBAR, DIE AUFGRUND DER VERWENDUNG DIESER SOFTWARE ENTSTEHEN KÖNNEN. DIES GILT AUCH, WENN AUF DIE MÖGLICHKEIT SOLCHER SCHÄDEN HINGEWIESEN WURDE.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.