Computer - Moppel Wiederbelebung - 2014 bis ...
Vom Schrotthaufen zum CP/M Rechner (hier der Baufortschritt in "Prosa" - Details findet Ihr im Dokubereich)
da ich das Teil ungern zur Verwertung geben wollte, werde ich ihn wieder vollständig aufbauen und wenn möglich einer sinnvollen Tätigkeit zuführen ...
(Fundus)
(die ersten Versuche)
(das neue Heim)
(er lebt)
Damit ist Der Moppel erstmal voll Einsatzfähig, das System hat nun den Softwarestand Vx.5 (1985) für alle EPROM's - Mit dem Editor und Assembler können nun Programme geschrieben, mit Hilfe des Disassembler auch analysiert und mit dem EPROM-Brenner für eine weitere Generation in Stein gemeißelt werden. Des weiteren ist der CP/M-Betrieb möglich.
Nochmals vielen Dank an Jörg für die Hardwareunterstüzung und an Herrn Meister, der mir den kompletten EPROM-Satz zur Verfügung stellte.
Für die Programmanalyse und Entwicklung habe ich auf der Windowsseite ein gutes und preiswertes System gefunden. Nennt sich 8085 Simulator IDE, stammt von Oshonsoft. Dort ist ein ordentlicher Assembler, Disassembler und ein 8085 Simulator untergebracht und das ganze für schlappe 25€. Für Z80-Fans gibt es auch eine größere Version.
( Beispiel für die Tastataurtabelle und Speichertest )
( Galep mit EEPROM's als Transfer )
Als Promer dient ein Conitec GALEP-III, Schnäpchen aus eBay und die Software gibt es immer noch beim Hersteller, die sogar unter Windows 8.0 einwandfrei funktioniert.
Derzeit baue ich die Software für den EPROM-Simulator. Da aus vergangenen Tagen ein PEPS (c't - Conitec Projekt) rum liegt und ich keine neue Hardware bauen will, bietet es sich an, ihn mit einem vorgeschalteten Mega8 auch aus der Windowswelt zu befeuern.
Die Software nimmt über das Terminalprogramm die Intel-Hexdaten per RS232 in den Eingabepuffer. Sobald das Zeilenende erreicht ist kann die Zeile analysiert werden. Hierzu muss der Startwert ":" gefunden werden, danach wird die Anzahl der DatenBytes, die Adresse sowie der Typ ermittelt. Dann folgen die Datenbytes und alles wird mit der Prüfsumme abgeschlossen.
Die Datenbytes werden wieder in einem Ausgabebuffer gespeichert und sobald die Prüfsumme OK ist können die Bytes an Peps übergeben werden. Soweit die Theorie, die einzelnen Module arbeiten im Simulator (AVR-BASCOM) einwandfrei. Bei der zusammenführung gibt es noch ein paar Problemchen ...
Das mit der RS232 ist nun endlich gelöst - wollte mein Konzept schon in die Kiste werfen - BUG im Basic-Compiler, bei einem Füllstand von ca.80% des Eingabebuffers (einstellbar) wurde das RTS-Signal richtig gesetzt. Nur leider beim leeren nicht zurückgesetzt, somit war die weitere Datenübertragung blockiert. Bis zum Update wird RTS nun separat gelöscht. Warum noch keiner diesen Fehler bemerkt hat, liegt wohl daran, das kein Mensch mehr Handshake nutzt und BASCOM wohl vornehmlich im Hobbybereich eingesetzt wird. TXD, RXD und Masse genügt ja auch meistens.
Jetzt müssen nur noch die beiden Module - Intel-Hex "interpreter" und Datentransport nach PEPS in Einklang gebracht werden. Obendrauf gibt es noch ein kleines Menü, damit das Terminalprogramm nicht so leer aussieht ...
Es ist geschafft, die Version 1.0 tut ihren Dienst. Die Menüführung lässt zwar noch zu wünschen, aber alle Bytes kommen an der richtigen Stelle im "EPROM" an.
-------------------
Die Hardware mit dem Mega8 habe ich wieder mit der Fädeltechnik aufgebaut und ein nettes Gehaüse lag auch noch rum, Peps auf die Trägerplatine geklebt und mit zwei Schrauben gesichert. Als Datentransfer über den Promer klappt es schon hervorragend, der Stresstest (als Videomonitor EPROM) steht noch aus.
Die Software:
Größte Herausforderung war neben den RS232 Problemen der "Intel-Hex Interpreter", hier wird immer eine Zeile eingelesen und dann Stück für Stück zerlegt. Dabei wird die Prüfsumme ab dem Lägenbyte Byteweise addiert und ergibt dann inkl Prüfsumme = 0. Damit können Übertragungsfehler aufgedeckt werden.
Ursprünglich wollte ich die Daten für PEPS auch in einem Buffer halten und erst am Ende des "Interpreters" gesammelt übertragen. Das Füllung klappte auch sehr gut, leider rückte der Buffer die Daten nicht so raus wie ich es gerne hätte, so habe ich dann direkt innerhalb der Datenschleife die Übergabe an Peps realisiert - liegt sicherlich an meinem Unvermögen das richtig zu händeln.
Die Bedienung ist noch nicht das Gelbe vom Ei, wenn man das i fürs Einlesen vergisst bzw einen CR dabei eingibt hängt sich die Datenübertragung auf - Hyperterminal wieder zurücksetzen und einen neuen Start versuchen - dass muss noch deutlich besser werden ...
Schaltbild und Programm kann aus dem DOKU-Bereich geladen werden ...
--------------------
Da nun alle Komponenten laufen (04/2014) wollte ich die Daten aus vergangenen Tagen retten - und schon fängt der Ärger an. Da stehen noch die Quellen fürs BIOS, Video-Monitor und weitere wichtige Dinge die sich nicht lesen lassen. Damals habe ich dummerweise vor dem Verkauf des PROF180 nicht alles auf ein aktuelles Medium gesichert, der konnte alles was irgendwie nach Floppy aussah lesen, lediglich Appel- und 8"-Disketten mit Hardsektoren funktionierten nicht - so ist halt das Leben.
Also im Netz gesucht und einige Lösungen gefunden - mit 22DISK gibt es die Möglichkeit auf einem DOS-PC bzw. DOS-BOX von W98 unterschiedliche Formate - in der CP/M Welt gab es dutzende - zu bearbeiten. Viele Tage später und Unterstützung aus dem CP/M-Forum funktioniert das Moppel-Format (3,5" bzw. 5.25" SSDD 80Spuren) für den Datenaustausch einwandfrei. Das Prof180x Format
weigert sich (noch).
Immerhin sind die Quellen fürs BIOS und dem Video-Monitor erhalten geblieben, damit kann nun die BIOS-Anpassung für die 2. Diskettenseite durchgeführt werden.
Bei diesem Diskettenabendteuer kommt der Wunsch auf, einen einfacheren Transfer zwischen den Welten zu haben. Das beste wäre eine Direkte Verbindung zwischen beiden Systemen. Denn für den Datenaustausch erst eine "alte" DOS-Kiste anwerfen, eine Datei kopieren um dann festzustellen, dass das Programm doch noch nicht funktioniert - effektief ist das nicht.
Mit den modernen Mikrocontroller sind wir ja auch reichlich verwöhnt, hängen ja direkt an der "Nabelschnur" und eine Byteänderung dauert nur wenige Sekunden.
So etwas sollte doch möglich sein ...
------------------------
Also ein neues Projekt für den Moppel aufgelegt. Ein Interface für eine CF-Karte soll den Austausch deutlich vereinfachen. Im Netz gibt es ja viele ähnliche Projekte mit den unterschiedlichsten
Ansätzen ...
Als Grundlage habe ich das Projekt "CF-PROF" von http://www.prof80.de/index.html gewählt.
Und so sieht derzeit meine "Lösung" aus:
- Die Cf-Karte wird von einem Atmega 644 komplett bedient, denn hierzu gibt es genügend
Hilfestellungen im Netz (AVR-DOS). Damit ist dann das FAT16 Dateisystem komplett abgewickelt.
- Auf der Moppelseite ist es dann nur noch eine parallele Schnittstelle, die ich mit dem
PIO-Baustein 8255 und ein bischen TTL aufbauen will. Der ist dann auch das Bindeglied
zwischen Atmega und Moppel.
- Schaltpläne für den 1.Entwurf sind gezeichnet und die IC's sowie der CF-Slot haben
schon mal (fürs Foto) Platz genommen. Der Max soll erstmal nur die PC-Kommunikation
mit dem AVR sicherstellen, bis das Dateisystem läuft.
Begründung:
CF-Karte wegen der 5V Versorgung, SD benötigt einen Wandler auf 3,3V. Lösungen mit Spannungsteiler sind nur suboptimal. Und ich habe noch ein paar ;-). Es gibt natürlich einen deutlich höherer Verdrahtungsaufwand gegenüber der SD-Karte. Die PIO erleichtert mir den Handshake mit dem AVR, So kann der Datenaustausch asynchron, gesteuert über Statusworte (PC4-7), abgewickelt werden. Soweit die Theorie ...
Die Adressdecodierung sieht ein bisschen komisch aus, aber im Moppel sind HI- Lo-Nibbel vertauscht.
Damit die IO-Adressauswahl für derzeit nicht zu überblickenden Einsatz gut gerüstet ist, habe ich ein paar Jumper SV2 - SV4 spendiert. Der ECB-Reset ist über Inverter auf die PIO geführt, der 2. und 3. bildet das Rest-Signal für die CF-Karte und dem AVR.
Der ECB-Teil ist nun fertig gehäkelt. Beim IO-Test bin ich über die "unvollständige" Adressdecodierung auf der 87er CPU-Karte gestolpert. Die "Grundlagenforschung" von Anno 85 nochmals überprüft und hoffentlich anschaulich dokumentiert. (siehe DOKU-Bereich)
Die PIO-Port A wird im Modus 2 (bidirektional) betrieben. Der Port C stellt dann die Handshakeleitungen da. Port C0 soll die Unterscheidung zwischen Befehl und Daten darstellen. Port B und die Reste von C sind derzeit unbenutzt (Quelle c't 7 1985).
Ein wenig später ...
AVR-Teil verdrahtet, jetzt fehlt erstmal ein gründlicher Check ob alles soweit funktioniert.
Anschließend ist noch der "Datenbus" zwischen PIO und AVR herzustellen ...
Sobald der AVR-Teil funktionstüchtig ist kann ich mir ernsthafte Gedanken über den Datenaustausch zwischen den beiden machen und testen ob mein "Gedankenmodell" umsetzbar ist - schauen wir mal.
27.05.2014 Das Interface raubte mir einige Nerven. Sektoren konnten gelesen und beschrieben werden aber vom Dateisystem keine Spur. Die Initialisierung brachte seltsame Fehler, bis jemand den Vorschlag machte, es mit größeren CF-Karten zu versuchen. Mit der 1GB-Karte klappt nun alles hervorragend. Zwischenzeitlich habe ich noch einen SD-Kartenanschluß hinzugefügt. Als Interface dient ein Conrad-Modul (für den C-Control). Damit kann man dann noch einen kompletten Port freischaufeln - auch hier wieder das gleiche Spiel mit verschiedenen Karten.
Die Portzuweisung musste auch geändert werden, damit genügend freie für den Dattenaustausch zur Verfügung stehen. Hierbei kommt es aber zu Doppelbelegungen mit dem SPI-Interface - also zum Programmieren ist die Karte zu ziehen. Und der gleichzeitige Betrieb CF- / SD-Karte ist ja nicht vorgesehen.
Nun müssen die beiden Welten über die PIO verbunden werden, nach dem ganzen Problemen und den wenigen freien Ports wollte ich schon auf sie verzichten und den AVR direkt ansteuern. Dazu muss aber die ISR auf dem AVR die Daten sehr zügig entgegennehmen - kein Latch. Das CS-Signal lässt mir ca 6,8µs für die Dekodierung des Steuerwortes und abholen der Daten. In Assembler bestimmt machbar, der AVR ist ja gut dreimal so schnell wie der Moppel mit seinen 6mhz, es gab aber mahnende Stimmen ;-)).
So werde ich die ürsprüngliche Idee mit der PIO umsetzten, denn dort läuft der Handshake mit Hardwareunterstützung ab.
Erläuterung zum Oszibild: CS-Signal in Ausgabeschleife auf den IO-Port, ohne Verwaltung der Buffer
und Handshake - also die maximale Datenrate von rund 140kByte/sec.
Nur damit ich abschätzen kann wie schnell der AVR reagieren muss.
Zunächst wurde die CPU-Karte und das Videointerface ans Labornetzgerät auf Grundfunktion getestet, Stromaufnahme, Clock-Signale und bei der CPU Adress und Datenleitungen mit dem Oszi auf sinnvolle Signale getestet. Backplane ins Gehäuse geschraubt und die beiden Karten mit einem provisorischem Netzteil versorgt. Videosignal über einen Video-RGB-Converter auf dem Monitor geschaltet und siehe da, die Moppel-Monitormeldung aus grauer Vorzeit kam zum Vorschein - somit ist der erste Schritt getan. Nur ohne Tastatur ist die Einflußnahme sehr gering ;-)) - es gibt noch ein paar Fragmente in der Bastelkiste aber für eine ASCII-Tastatur reichte es nicht. Bei eBay war auch nicht so viel brauchbares zu finden, da die modernen nur noch Kunststoffolien mit aufgedampften Leitebahnen haben, ist ein Umbau mit dem Lötkolben nicht möglich.
In Mikrocontroller.net einen uralten Artikel vom Moppel gefunden und aufleben lassen - meine Nachfrage zur Tastatur wurde von Jörg umgehend mit einer alten Tastatur aus einem Großrechner bedient. Der Decoder war schnell gebaut und so konnte die weitere Inbetriebnahme voranschreiten. Die 32KByte-Speicherkarte war OK, bei dem seriellen Interface hatte der UART (6850)
eine Macke, ausgetauscht und die Bits laufen wieder im Gänsemarsch mit 4800Bd.
Bei dem Floppyinterface gab es erhebliche schwierigkeiten. Sobald eine Funktion aufgerufen wurde verschwand der Rechner ins Nirawana ???. Zunächst alle Ports auf der Karte mit einem Testprogramm überprüft, Controller gewechselt (hab ein paar) kein Erfolg. Das Netzteil gewechselt da es bei mehr als drei Karten schon mal austieg. Karten am Bus umgesteckt - CPU, RAM und FDC dierekt nebeneinander - er läuft. Da gibt es wohl Signalprobleme auf dem BUS. Bei der Aufbereitung des Assemblerlisting für den FDC bin ich über den markanten Punkt gestolpert - die FDC-Routinen laufen überwiegend mit Interrupt-Betrieb und wenn der nicht kommt bleibt das Programm natürlich hängen. Hier hatte Jörg auch eine Lösung parat - Terminierung - und sogar noch eine alte Karte die das mit einer Konstantstromquelle für alle Adress- Datenleitung erledigt.
Für den CP/M Betrieb habe ich damals eine 64kByte Speicherkarte gehäkelt, hier musste ich ein paar Drähte nachziehen, die durch die Lagerung beschädigt wurden. Sie wird per Bankumschaltung ab Adresse 4000h eingeblendet und sobald der Bootloader fertig ist komplett eingeschaltet. Somit steht die "weite Welt" der CP/M Software offen - wenn es nicht noch ein paar Probleme mit den 3" Diskettenlaufwerken geben würde. Boot läuft, Inhaltsverzeichnis wird noch angezeigt aber Lesefehler verhindern jegliche Programmaufrufe, selbst neu erstellt Systemdisketten machen den gleichen Ärger. Also zurück zu den guten alten TEAC 5 1/4 Zoll Laufwerken, die funktionieren ausgezeichnet (haben ja auch mal über 500DM-chen gekostet).
Die 3 1/2 Zoll Laufwerke aus älteren Pc's funktionieren, wenn man die richtigen Disketten (2SDD) einlegt, denn HD kann mit dem Controller WD1770 nicht funktionieren. Leider haben die "modernen" Laufwerke keine Jumper mehr.
Prototyp mit
AVR 644
----------------------------
30.12.2014
Nach längerer Sommerpause geht es nun weiter, zum Eingewöhnen habe ich mir die Speicher- und Portadresslage zur Brust genommen. Wie schon mehrfach angemerkt sind leider nicht alle Portadressen eindeutig zugeordnet, so muss man bei eigenen Projekten höllisch aufpassen das es nicht zu komischen Efekten kommt. Im Doku-Teil habe ich die Aufstellung nochmals überarbeitet und mit der Speicherbankumschaltung ergänzt. Im CP/M Betrieb wird ja laufend zwischen RAM und dem
Monitor-ROM bzw. die Zeichenausgabe auf der Videokarte umgeschaltet - bestimmt nicht das schnellste Verfahren aber zu damaliger Zeit völlig OK - ist ja kein Rennwagen.
20.01.2015
Da für das CF-Interface einiges an Testsoftware in den Moppel gepumpt werden muß, wollte eigendlich ein "Zwischenprojekt" starten, Intel-Hex Daten per V24 zum Moppel übertragen. Es gibt ja im Monitorprogramm die Funktionen v aaaa,eeee (Daten senden) und w aaaa,eeee (Daten empfangen). Das Senden war ja auch nie das Problem, alle Bits purzeln mit 4800Bd in Richtung PC.
Nur der Empfang funktioniert nicht, Hardware überprüft und streckenweise ausgetauscht nichts ging.
Die Taktrate sah mit 208µs gut aus, gleiche wie beim Senden - scheinbar alles OK.
Aber da war doch was mit "Abtasttheorem" - die Bits sollen doch in der Mitte abgetastet werden, hierzu ist ja mindestens die doppelte Taktrate erforderlich. Im UART kann nur 16-und 64fache eingestellt werden - auch gut. Timerwerte neu berechnet (1/2 CPU-Frequenz / 16 / Baudrate) und den Timer damit geladen - wer sagt es denn - Daten kommen ordentlich an.
Beim Studium des Datenblattes MC6850 ist mir aufgefallen, der macht gar keinen Handshake. RTS muss man selber bauen, das hätten die aber besser machen können !
Nah ja, immerhin wird der volle Empfangsbuffer im Statuswort signalisiert, so gibt es die Möglichkeit den Datenfluß vom Sender auszubremsen. Entweder über das Modusregister oder im UART das RTS-Bit entsprechen zu setzen.
Als nützlicher Nebeneffekt kommt bei der Fehlersuche noch ein Assemblerlisting vom Monitor rum.
Details, wie immer im Dokuteil ...
Übersichtsplan
Damit hat sich der WorkAround für die Softwareentwicklung für den Moppel deutlich vereinfacht. Jetzt ist nur noch die V24Schnittstelle und auf der PC-Seite Hyperteminal erforderlich um die Dateien aus dem Assembler in den Moppel zu schaufeln.
Denn auf dem Moppel möchte ich mit dem schwachen Editor keine Programme mehr schreiben, das geht bei aller Begeisterung für die alte Technik mit einem PC deutlich einfacher ...
30.01.2015
Das Intel-Hex Ladeprogramm für die Übertragung der Intel-Hex Datein ist nun funktionstüchtig. Es kann Daten über die V24 schnittstelle empfangen und legt das komplette Hex-File in den Buffer, hier sind 16kB ab 9000h vorgesehen. Anschließend startet der "Hex-Interpreter" und macht daraus das entsprechende Binär-File. Da die Zieladressen aus dem Hex-File genommen werden ist es wichtig dass beim Assembler der Richtige ORG gesetzt wird. Sonst überschreibt der Interpreter den falschen Bereich - hier ist es Sinnvoll ORG 0F000h einzusetzen, da kann nichts passieren. Der Buffer ist derzeit groß genug gewählt um auch das Hex-File für ein 4kByte Binär-Code aufzunehmen. Es würde ein Buffer reichen der genau eine Hex-Zeile aufnimmt (44Byte) und der Interpreter das dann zug um zug abarbeitet.
Die "Benutzerführung" ist natürlich sehr spartanisch, es wird nur angezeigt das der "Sender" zu starten ist
(zeitgleich mit RETURN am Moppel) und ein paar Hinweise was er so gerade treibt.
Hier müsste ich nochmal etwas nachlegen - da das ganze ja nur dazu dient, Testprogramme auf einfacher Weise in den Moppel zu Pumpen halte ich das aber für nicht so wichtig ...
Im Dokuteil ist das komplette Listing hinterlegt.
Hex-Lader in Aktion
17.02.2015
Altes Siemens Datenbuch "Mikrocomputer Bausteine Peripherie 79/80" wiedergefunden.
Dort steht für den UART 8251A folgendes:
Der Abtastzeitpunk für die Bits wird beim Asynchronbetrieb digital bestimmt. Es ist zu diesem Zweck erforderlich, daß die Frequenz des Empfangsteiltaktes ein Vielfaches (16/64) der Baudrate ist ! ... Wenn mann jedoch dafür sorgt, daß der Takt an beiden Enden der Übertragungsstrecke völlig synchron ist, kann die Frequenz gleich der Baudrate sein, in diesem Fall spricht man von ISO-Sysnchron.
Bei der Kopplung von zwei Moppels ist das möglich, da der Takt an der 25pol Sub-D Pin 9 herausgeführt und an Pin 24 wieder zugeführt wird (Br.2 entfällt). Damit ist die Ehre vom Entwickler (Herrn Gößler) wieder hergestellt ;-). Im modernen PC so nicht mehr möglich, also Monitor nachbessern ...
01.03.2015
Das CF-Karteninterface macht deutliche fortschritte:
Datenaustausch über die PIO8255 ist nun komplett fertig, gegenüber dem 1.Entwurf sind die beiden Adressleitungen A0,A1 entfallen. Der Moppel leitet den Datenaustausch mit einem Befehl (Reset, Spur/Sektor setzen und Sektor lesen/schreiben) ein.
Die Parameter folgen dann im nächsten Byte, Daten werden dann in einem Rutsch (512byte) ausgetauscht.
Mit den Testprogrammen können die grundlegenden Funktionen auf der Moppel-Monitorebene durchgeführt werden. Für den Test habe ich auf der CF-Karte ein 2MB großen Datenbereich angelegt. Da dieser im FAT-Bereich integriert ist musste ich dafür Sorge tragen, dass der Moppel nicht wild auf der CF-Karte schreibt, sondern nur innerhalb dieses Datenbereiches. Im Hexeditor ist dieser Bereich leicht zu lokalisieren und der Startsektor dann entsprechend angepasst - mit der 4MB Karte liegt er ab Sektor 128. Das ist als Offsetwert in die Berechnung auf dem AVR berücksichtigt. Wenn die Software ins CP/M-Bios integriert wird muss ich dann nochmals darüber nachdenken ob es bei der Übertragung beim kompletten physikalischen Sektor bleibt oder ob es sinnvoller ist, das auf logische Sektoren (CP/M - 128Byte) zu ändern. Hierzu muss dann im AVR das Blocking/Deblocking durchgeführt werden - schauen wir mal was der bessere Weg ist ...
[Bildschirmmeldung FDC-Routinen alt/neu mit CF-Karte] ==>
Für den späteren Betrieb ist es bestimmt sinnvoll, einen Bootmanager zu etablieren und die V24 auf der Frontplatte zu montieren, damit sind dann Programmänderungen einfach möglich und die V24 könnte mit einem entsprechenden Befehlssatz auch vom Moppel bedient werden. Pufferspeicher ist ja genügend vorhanden und mit Handshake macht der AVR deutlich mehr als 9600Bd.
07.03.2015
10.03.2015
15.03.2015
11.04.2015
Zunächst sollten die CF-Routinen in die Floppyrotinen integriert werden, so können auf Monitorebene alle Eingangsparmeter weiter benutzt werden, lediglich die Laufwerksauswahl bestimmt das Ziel (LW 03 = CF-Karte). Da ich aber in der Testphase nicht dauernd ein EPROM brennen wollte, wurde das ganze auf Adresse F000h assembliert und konnte dort eingehend getestet werden. Auf der AVR-Seite wird die Sektoranzahl durch zwei geteilt, da die CF-Karte ja 512Byte/Sektor hat. Damit kann die CF-Karte schon mal mit 320kByte angesprochen werden - im Monitorbetrieb völlig ausreichend und ggf. Könnte man ja die Parametergrenzen 80Spuren a 16 Sektoren ja im Quellcode erweitern.
Der AVR im Interface hat noch nicht viel zu tun, da nur die Befehle RESET, SET SPUR, SET SEKTOR, RW-Sektor und STATUS zu bewältigen sind. So benötigt diese Version gerade mal 4% von den vorhandenen 64kByte. Nur so am Rande 28kByte schreiben/lesen dauern keine zwei Sekunden, das alte TEAC-Laufwerk muss dafür gute 25 Sekunden schuften. Also eine Steigerung um das 10fache - ein nettes Ergebnis.
Die aktuellen Testprogramme sind im Dokuteil hinterlegt.
Die CF-Routinen sind nun ins FDC-ROM untergebracht, mit 1kByte Platz war es etwas eng, also Meldetexte stark eingekürzt und mit den Rezepten aus der Softwareküche Anno 85 "selbstmodifizeirenden Code" habe ich jetzt noch drei Bytes frei.
... eigendlich wollte ich die CP/M Anpassungen vornehmen. Da gibt es aber wieder ein paar Stolpersteine, wie baue ich das BIOS mit dem CCP/BDOS zusammen, da ja kein Quellcode vohanden ist, müssen die Teile händisch aneinander gefügt und wieder zurück auf die Systemspuren gebracht werden. Eingangstore habe ich ja bereits einige, aber ein Binär-File in den PC zu bekommen ist ein wenig schwieriger. Überlegungen ein Terminalprogramm auf den Moppel zu etablieren halte ich auf der Monitorebene für zu umfangreich.
Andere Idee, den Hexlader so umgebaut, dass er im gemeinsamen RAM-Bereich ab 2800h steht. Es wird eine Zeile empfangen, direkt interpretiert und im Ziel abgelegt. Damit ist die Speicherverschwendung zu ende, ferner wird das Programm mit einer kleinen Ladefunktion ins RAM 2800h kopiert und dort ausgeführt.
So kann über die Bankumschaltung das BIOS an die richtige Adresse EA00h auf bank #1 schaufeln. Der Workaround sieht dann folgendermaßen aus, CP/M über Diskette starten, Reset und anschließend das neue BIOS über den Hexlader nachlegen und einen Kaltstart durchführen. So bleibt der CCP und BDOS unberührt und ich kann das BIOS einfach austauschen.
... es ist geschafft - das CF-Interface funktioniert nun auch unter CP/M !
Die CP/M BIOS-Anpassung war schon eine kleine Herausforderung. Da das Listing nicht gut dokomentiert war, hieß es erstmal verstehen lernen "was uns der Autor sagen wollte" ;-)
Die Diskettenzugriffe sind dreifach gegliedert. Zunächst fragt das BDOS die Schreib/Lese-routine an, hier wird erstmal die Umrechnung BIOS-Record in Moppelsektoren vorgenommen (Record/2 +1 und mit 0Ch maskiert - da komme ich später drauf zurück) und verglichen ob der Record schon im Buffer vorhanden ist. Wenn ja, braucht ja nur der Record aus dem Buffer kopiert werden, sonst gibt es einen Diskettenzugriff. Im zweiten Teil steht die Bufferverwaltung, hier ist am Ende des Speicherbereichs FC00H 1KByte vorgesehen und die eigendlichen Floppyroutinen (3.Teil) tauschen Ihre Daten nur mit dem Buffer aus. Es werden immer 4Sektoren a256Byte gelesen bzw. geschrieben. Das ist genau der Punkt wo ich meine CF-Routinen einbauen konnte. Mit Prüfung des Laufwerksbuchstaben (D) entscheide ich ob die Diskette oder die CF-Karte angesprochen wird. Die Parameter werden über drei Speicherstellen für Laufwerk, Spur und Sektor übergeben.
Im AVR-Teil wird die Spur in Sektoren umgerechnet und mit der Sektoranzahl addiert. Da die CF-Karte 512Byte pro Sektor hat, muss hier nochmals eine Division durch 2 + Rest (Modulo) durchgeführt werden (BASCOM hat da glücklicherweise eine fertige Funktion für). Zunächst habe ich alles mit dem DPB vom Moppelformat ausprobiert, schreiben auf CF-Karte funktionierte auf anhieb, nur leider konnten die Programme nicht gestartet werden - Rechner hing sich auf oder brachte seltsame Meldungen - viele ? standen mir über über dem Kopf.
So stand eine umfangreiche Analyse an:
Dateivergleich auf der CF-Karte mit dem Orginal brachte keinen Anhaltspunkt, alles OK.
Auch das Auslesen der Karte mit AVR-DOS auf den PC zeigte keine Unterschiede, alle Bytes an richtiger Stelle.
Hilft nur eins, mit dem DDT das Programm von der CF-Karte lesen lassen.
Siehe da es gab beim STAT.COM (mein Testobjekt) an vier stellen fehlende Bytes, immer wieder an der gleichen Stelle, der Versatz wurde dann beim nächsten Sektor wieder begradigt. Vier Bytes ist ja nicht die Welt aber doch entscheident ob es klappt oder nicht. Wenn die Fehler wenigstens auf Record oder Sektorgrenzen liegen würde, hätte ich ja eine einfache Erklärung dafür aber mitten im Block fand ich das höchst seltsam. Viele Theorien aufgestellt und einige Testprogramme entwickelt z.B. die TPA von Bank #1 in den RAM bereich Bank #0 kopieren um diesen sonst für den Monitorbetrieb verborgenem Bereich zu beleuchten, erst als ich den 1k Buffer #1 auf Bank #0 protokolieren konnte war es klar - es ist die CF-Leseroutine. Also die AVR-Seite nochmals gründlich überprüft, außer ein paar Kleingkeiten nichts konkretes gefunden. So langsam gingen mir die Ideen aus - aber da war doch am Anfang das Problem, die kleinen Karten laufen nicht dem dem kompletten AVR-DOS "Dateisystem nicht vorhanden". Das wars - die 1GB-Karte vorgereitet und der Spuk hatte ein Ende - CP/M kann von dieser Karte einwandfrei lesen.
Die alten Karten haben beim lesen ein Timingproblem, der AVR ist einfach zu schnell, dies ist bei den ersten Tests, lesen der Karte über die Serielle Schnittstell mit 9600Bd, nicht aufgefallen. Erst das "Dauerfeuer" mit ca. 20kByte/sek bringt die Dinger aus den Tritt. Warum das aber immer an der gleichen Stelle passiert, kann ich nicht nachvollziehen. Hier könnte ich nochmals tiefer einsteigen, ggf. die Leseroutinen mit "halber Geschwindigkeit" laufen lassen.
Nun steht der eigendlichen Einbindung ins CP/M-System nichts mehr im Wege. Dafür muss ja nur noch der DiskParamerBlock angepasst werden. Unter CP/M sind maximal 8MB möglich (mit entsprechenden BIOS-Anpassungen geht auch mehr), das reicht in jedem Fall aus "wird nie voll" war ja bei DOS mit den 20MB-Platten ein gängiger Spruch - jedes Bild aus einer durchschnittlichen Kamera ist heute schon locker 10MB groß ...
Zurück zum DPB, jetzt benötigen wir noch einen sinnvollen Wert für die Anzahl der DIR-Einträge (512), dann die Blockgröße festlegen (hier 4096Byte) und noch die Anzahl der Records pro Spur - fertig. Hier stößt die Berechnung Records in Sektoren (siehe oben) sauer auf, durch die Maskierung (0Ch) gibt es maximal 32Records bzw. 16Sektoren !
Was auf der CF-Seite ja nur 8Sektoren/Spur sind. Hier muss sowieso alles auf Sektoren umgerechnet werden, glücklicherweise wird die Anzahl der Sektoren nicht durchs BIOS verfälscht und können dann im CF-Teil sauber verarbeitet werden. Das ganze ergibt bei 8MB im BDOS eine sehr große Spurzahl (xxx) , diese wird glücklicherweise 16Bittig übergeben und macht keine Probleme.
Quelle für eine anschauliche Darstellung und Berechnung des DPB:
Schöner sehe es aus wenn die Sektoren pro Spur auf z.B. 256 angehoben werden könnte, dazu müsste aber die BIOS Record/Sektor neu geschrieben werden - später vieleicht einmal...
Jetzt freu ich mich erstmal über die gelungene Implemetierung der CF-Karte. :-]]]
Die CF-Karte als Bootlaufwerk ist der nächste Schritt, im DPB habe ich dafür schon mal 4 Systemspuren reserviert.
Der Bootloader auf der AVR-Seite ist bereits eingebaut und das Interface hat noch weitere Reserven:
- schnelles RS232 Interface,
- die PIO hat noch den freien B-Kanal mit entsprechenden Handshake ggf als Druckerschnittstelle
- und als Abschluß die volle Nutzung des AVR-DOS Systems.
damit sollen dann die CP/M-Dateien auf den DOS Bereich und umgekehrt gespiegelt werden. Das war ja das eigendliche Ziel der ganzen Übung - wird aber noch eine ganze Weile dauern ...
STAT DSK:
26.05.2015
Im großen Warenhaus eine schöne Laptop-Tastatur von HP gesehen, genau das richtige für den Moppel - 3.2.1. meins ;-)) Die haben natürlich nur Folienanschlüsse und mit Lötkolben geht da nichts, hatte mal irgendwas geschlachtet und so eine "schöne" Anschlussbuchse lag sitdem in meiner Bastelkiste. Leider gibt es keine 1mm Rasterplatinen oder fertige Adapter. In Eagle geht aber fast alles, kleines Layout entworfen und mit der "Transferfolie" von Jan Wüster gelingen die Platinen auch mit diesen Leiterbahnabständen. Da kein Anschlußplan vorhanden war musste die Matrix selber ermittelt werden, nach einigen Versuchen waren die Anschlüsse soweit klar. Ein wenig optimert
und die Matrix liegt nun wohl geordnet vor (siehe Bilder).
Als nächstes benötige ich noch das Interface aus zwei 74LS138 und einem 373er TTL, wie beim Moppel. Da die Adapterplatine so gut funktioniert hat, werde ich dafür auch eine ätzen. Am besten geht das mit SMD, da brauche ich keine Löcher bohren ...
15.01.2016
Nach langer Sommerpause, ging ja locker bis Ende Dezember ;-)) geht es nun weiter.
Zum eingewöhnen wird erstmal die HP-Tastatur vollendet. Das Gehäuse entstand als Schicht-bauweise mit drei 4mm starken ABS-Platten - dies kann die Fräse gut bearbeiten. Der Drahtverhau sieht nicht gut aus, dadurch kann ich das Interface aber an den unterschiedlichsten Layouts anpassen. Und da wartet ja noch die Tandbergtastatur auf ein schönes Heim.
Jetzt fehlt nur noch das Anschlußkabel und die Tastaturtabelle im Video-Monitor ...
31.01.2016
So einfach wie gedacht ist das mit der HP-Matrix nicht, denn für die Sondertasten (Shift, Cursor, Funktion etc.) gibt es keine separaten Zeilenleitungen. Das bedeutet, die CTS/CI-Routinen müssen komplett neu geschrieben werden. Aber Hauptproblem ist die Kontaktierung mit der SMD-Buchse. Mal fehlte die eine Leitung, mal die Andere, also kein gesicherter Betrieb möglich - erstmal alles auf Eis gelegt bis besseres in Sicht ist. Oder, wesentlich einfacher - man nehme eine PS/2 Tastatur und ein AVR der das ganze auf V24 bzw. Parallel umsetzt.
Nichts ist unnütz, es kann noch als schlechtes Beispiel dienen ;-))
Für die Entwicklung der CTS/CI-Routinen wollte ich eigendlich den PEPS auf den Platz des Video-Montors ins System stecken. Damit wäre dann die Softwareentwicklung an der Nabelschnur sehr effektiv. Hierzu habe ich erstmal die PEPS-Software soweit angepasst (Version 1.2), dass die Adresse aus der INTEL-Hex-Datei bei jeder Zeile berücksichtigt wird und die Sprünge entsprechend aufgefüllt werden.
Anmerkung: Ich halte es für Übersichtlicher wenn Texte und Tabellen am Ende des Assemblercode stehen(ORG-Anweisungen)
Über den EPROM-Brenner oder reiner Lesebetrieb z.B. freier EPROM-Platz auf der großen Speicherkarte funktioniert alles wunderbar. Aber als Ersatz für den Videomonitor funktioniert der Simulator nicht. Austausch des Datenbustreiber brachte etwas Besserung, hier muss ich wohl alle Treiber und RAM-Bausteine durch deutlich schnellere ersetzen.
Schauen wir mal ob es hilft ...
07.04.2016
Die Zeit fliegt nur so dahin, aber doch einiges für den Moppel gerichtet. Den Epromsimulator PEPS kann ich leider nicht dazu bewegen, den Monitor auf Platz #0 zu emulieren, alle Bemühungen mit schnelleren Speicherbausteinen und neuen Treibern waren ohne Erfolg, es kommt nur Datensalat an. Für die Analyse und Neuaubau des Monitorprogramms muss ich mir einen anderen Weg einfallen lassen.
Dafür habe ich aber die CF-Karte ein Stückchen weiter gebracht. Die V24 vom AVR kann nun über den Moppel angesprochen werden und überträgt die Daten mit 38kb/s - schon eine deutliche Steigerung. Derzeit sind Einzelne Buchstaben und ganze Strings bis zu 64Byte möglich. Damit kann dann der Hex-Lader deutlich beschleunigt werden. Eine Binäre übertragung ist derzeit (noch) nicht eingebaut, da ich ja das CR als Flusssteuerung nutze. Für die Übertragung der Strings ist sowohl auf der Moppel- und der AVR-Seite ein Buffer 64Byte Buffer eingerichtet. Dieser wird vom Moppel befüllt und dann per Interrupt-Routine vom AVR gesendet. Das gleiche in umgekehrter Richtung. Die V24 arbeitet mit Hardwarehandshake (RTS/CTS) damit der Moppel nicht vom PC überrant wird, umgekehrt ist das sicherlich nicht zu befürchten ;-). Über das CTS-Signal kann der Moppel aber sehen ob eine Übertragung überhaupt möglich ist, denn alle Handshake-Signale können über eine Statusabfrage ausgewertet werden.
Darüber hinaus ist der Rest vom PIO-Baustein als parallele Schnittstelle ausgebaut. Ein-/Ausgabe auch mit Handshake /OBF und /ACK möglich, ggf für eine Druckerschnittstelle - bei meinen Drucker "HP Laser Jet" funktioniert das leider nicht. Es fehlen natürlich einige Signale wie Papierende, Error, Bussy etc. Hier könnte ich mir in Zukunft einen DIP-Schalter vorstellen um Grundeinstellungen im System festzulegen, wie das IO-Byte in CP/M.
Damit ich das Ganze auch noch im nächsten Winter nachvollziehen und dort anknüpfen kann, habe ich alles in einer , hoffentlich ausführlichen, Dokumentation gepackt. Siehe Dokuteil ...
Erstmal genug gebastelt, der Garten und die Motorräder rufen ...
21.04.2016
da mein rechter Huf vorrübergehend stillgelegt wurde, habe ich viel Zeit noch etwas für den Moppel zu bauen ...
Den Hexlader habe ich so umgebaut, dass er die Daten über die V24 Schnittstelle der CF-Karte mit 115kb/s schaufelt. Netto bleibt davon natürlich nicht soviel übrig, da der Moppel mit dem "Hex-Interpreter" gut beschäftigt ist. Ist aber deutlich zügiger als mit den mageren 4800b/s der "alten" V24. Listing im Dokuteil ...
Nächstes Ziel ist der Bootlader für CP/M, er soll das System von CF-Karte laden. Vier Systemspuren hatte ich ja bereits bei der Definition vom DPB reserviert ...
Ladeprogramm V3.0
in Aktion
04.05.2016
Mal eben den alten CP/M Bootloader anpassen war ja nicht - es warteten einige Fallstricke ...
Der Reihe nach, die CF-Karte ist in den FDC-Routinen und im BIOS als 4.Laufwerk deklariert, soweit klappt das ja auch. Nur die Batch-Routinen arbeiten nur mit dem 1.Laufwerk, Anpassungen passen aber nicht mehr ins 2K-ROM. Hinzu kommt noch die unterschiedliche Sektorgröße, 256Byte zu 512Byte bei der CF-Karte. Im BIOS war ich durch den 1kByte Buffer fein raus und brauchte die Sektoranzahl nur durch 2 (+Rest) teilen. Dieser Buffer steht im Monitorbetrieb leider nicht zur Verfügung.
Also komplett selber schreiben, zunächst sollen die 4 resevierten Systemspuren auf der Cf-Karte von allem Müll gereinigt werden. Hört sich schlau an, ist aber nur ein einfaches füllen mit 00h. Dies könnte etwas aufgebohrt werden, dann wird auch das Inhaltsverzeichnis direkt mit E5h überschrieben.
Als nächstes müssen die Systemspuren von der Diskette den Weg in die CF-Karte finden. Dies ist in zwei Schritten aufgebaut.
Zuerst werden diese in den Buffer geladen, ist mit 32kByte ausreichend groß, um dann im zweiten Schritt auf die CF-Karte geschrieben. So habe ich noch die Möglichkeit kleine Änderungen oder das ganze BIOS neu einzufügen.
Schlussendlich kommt dann der CP/M Boot und alles wird von der CF-Karte in die 2.Speicherbank an richtiger Stelle kopiert. Das geht "rasend schnell", leider tritt derzeit CP/M noch mächtig auf die Bremse, denn beim Kaltstart wird immer auf das 1.Laufwerk geschaut um anschließend das LW D, also die CF-Karte anzusprechen.
Entweder finde ich dafür einen Patch um diese Eigenart auszumerzen oder ich deklariere die CF-Karte als Laufwerk A. Dazu müssen aber alle FDC-Routinen und das BIOS angepasst werden ...
06.05.2016
... nach intensivem Studium der CCP/BDOS-Listings habe ich mich entschlossen, die Laufwerkszuordnung in den FDC-Routinen und im BIOS anzupassen. Nun hat die CF-Karte den Laufwerksbuchstaben A im CP/M und 0 unter Monitorbetrieb.
Dabei sind die beiden 5 1/4 Zoll Laufwerke durch ein 3 1/2 ersetzt worden. Zwei Laufwerke sind mehr als genug, zumal die CF_Karte rund 8MB Speicherplatz bietet.
Die Bootroutine ist im EPROM bei 5000h untergebracht, diese kopiert den eigendlichen Lader dann nach 2800h. Dort holt er sich die Daten ab dem 2.Sektor von der CF-Karte und schaufelt alles nach D4000h (Beginn CCP) in die Speicherbank 1. Das sieht erstmal etwas durch die Brust ins Auge aus, hier müssen aber die Feinheiten vom Moppel berücksichtigt werden.
Die Bankumschaltung blendet den oberen Teil von Bank 1 ab 4000h ein - liegt einfach an der Speicherselektierung auf der CPU-Karte, hier werden alle Segmente 0000h-3FFFh codiert. Die EPROM's von 4000h bis 7FFFh sind aussen vor und werden beim Banking einfach abgeschaltet. Schöner wäre es wenn die Bankumschaltung bei 8000h beginnen würde, dann könnte ich die ganzen Tools ab 4000h unterbringen und brauchte nicht diesen Dreisprung zu machen - hätte hätte ...
Das Hardwarekonzept ist halt damals so festgelegt worden, basta.
Nun ist das Händling super einfach geworden, am Monitorpromt einfach B (war mal der Sprung zum BASIC-Interpreter) und Return drücken und "rats fatz" steht CP/M zur Verfügung.
Bevor die "große Reise" durch die CP/M Welt geht, muss ich mich nun in den Transfer von Windows nach CP/M mit 22DSK einarbeiten. Ein alter Rechner mit DOS und Win-XP wartet schon auf etwas Arbeit ...
Moppel mit Nabelschnur zum Windowsrechner V24 mit 115kbit/s
der 25pol Stecker ist der Tastaturanschluß
Ein Steckplatz ist am EC-BUS noch frei
12.05.2016
Auf der CF-Karte sind 4 Systemspuren reserviert, das sind 16kByte wovon das System gerade die Hälfte belegt, so wollte ich mal eben den Startsektor weiter nach hinten legen, um vorne für Batchprogramme Platz zu schaffen. Das ging gründlich schief. Beim Wechsel vom Assembler zurück zum Editor habe ich mir die Quelldatei zerschossen, natürlich kein brauchbares Backup vorhanden - Scheibenkleister. Dann hatte der Moppel noch ein paar unerklärliche Zicken, konnte keine Diskette mehr lesen, spazierte unkontrolliert durch seinen Speicher und ähnliche Scherze - keine Erklärung gefunden. Seit die Haube ab ist funktioniert wieder alles - Hitzestau ?
Nun konnte ich alle Änderungen nochmals neu aufgebauen und vernünftig sichern! Das vorläufige Ergebnis steht nebendran ...
Die CF-Tools haben folgende Funktionen:
- Systemspuren löschen, mit 00H überschreiben.
- Systemspuren von Laufwerk 1 (B) ins RAM schreiben, ab Adresse D400H (CCP,BDOS,BIOS)
- Speicher ab D400H in die Systemspuren der CF-Karte schreiben
- BOOT von CF-Karte
Da die Routinen einzeln aufgerufen werden können/müssen kann ein neues BIOS
mit dem HEX-Lader zwischen dem 2. und 3.Schritt eingefügt werden.
Solange der Moppel nicht abgeschaltet oder ins Nirwana geschickt wird ist der Austausch des BIOS ruckzuck erledigt - Hex-Datei laden, sichern und booten.
Als nächstes soll die schöne schnelle V24 der CF-Karte unter CP/M nutzbar werden, also "Gerätetreiber" für die Lochstreifen-Leser/Stanzer bereitstellen. Wundert euch nicht über die komischen Begriffe, Lochstreifen gibt es schon lange nicht mehr, CP/M kommt halt aus dem letzten Jahrhundert. Darauf kann dann ein Terminalprogramm zugreifen und CP/M rückt ein kleinen Schritt näher an die Windowswelt ...
14.05.2016
"Handbuch" für den CP/M Betrieb mit der CF-Karte ist im Dokuteil hinterlegt ...
14.07.2016
Die "Programmentwicklung" unter CP/M sieht derzeit noch sehr vorsintflutlich aus, Entwicklung auf dem PC unter Win7, dann das ganze übers Netzwerk auf einen Win98-Rechner schaufeln, der daraus eine Moppel-Diskette baut. Diese dann unter CP/M kopieren und schließlich mit dem CP/M-Loader, der aus dem Hex-File ein Programm zusammen schraubt. In der Monitorebene klappt das mit der V24 auf der CF-Karte deutlich besser - sowas muss auch für CP/M her.
Aber mal eben ein DFÜ-Programm basteln ist ja nicht, hier fehlten im BIOS doch einige grundlegende "V24-Treiber". Treiber, hört sich sehr hochtrabend an und hat mit den modernen Gerätetreibern unter Windows natürch nichts zu tun (geht ja schon vom Umpfang nicht, das BIOS ist nur wenige kByte groß ;-)), Es geht lediglich nur um eine geordnete Datenübertragung von A nach B und die DFÜ-Programme benötigen bei Zeitüberschreitung einen definierten Abbruch, so nach spätestens 10s.
So sind nun eine Handvoll "V24-Treiber" entstanden, diese sind über die erwiterte BIOS-Sprungleiste ab EA33H also Warmstart + 30H erreichbar sind. Auf Monitoreben funktioniert es bestens, hierzu habe ich das BIOS einfach in der Bank#0 an der Zieladresse geladen und mit diversen Testprogrammen ausgiebig getestet, nun müssen sie unter CP/M-Regie beweisen ob alles so funktioniert wie geplant ...
27.07.2016
... Nach etlichen Stolpersteinen - endlich fertig!
Da das BIOS deutlich angewachsen ist, und ich es nicht mehr auf dem Schirm hatte, wieviele Sektoren der Bootloader wirklich kopiert - gibt es natürlich komische Reaktionen, kein Wunder wenn der entsprechende Code nicht geladen wurde. Bootloader angepasst und alles ist schön.
Wie war das sogleich mit den Fehlern vor der Tastatur zwischen den Ohren ;-))
Jetzt ist die V24 der 87er Hardware voll einsetzbar und über das IO-Byte können die verschiedenen "Treiber" aktiviert werden. RDR und PUN für die einfache Ein-Ausgabe oder für die DFÜ-Programme mit Zeitüberwachung, nach ca. 10s wird Control-Z zuückgegeben. Auch die Ankopplung eines externen Terminals wird nun unterstützt (Hyperterminal oder ähnliches). Einfach den Befehl "stat con:=crt:" absetzen und die Consolenausgabe ist auf das externe Terminal mit 9600Bd umgelenkt.
Externe Programme können über die erweiterte Sprungleiste unter Umgehung vom BDOS die diversen Routinen auch direkt nutzen. z.B. 0040H ins DE-Register laden und mit Call (WBOOT + 30H) die Baudrate 4800Bd einstellen.
Habe im großen Kaufhaus ein Televideo 935 für kleines Geld geschnappt. Damit ist die Anpassung der diversen CP/M-Programme wie Wordstar, dBase, Turbo-Pascal etc. ein Kinderspiel. Im Netz aus alten Zeiten von Ellis Computing den Nevada EDIT wieder gefunden. Das ist ein Bildschirmeditor, deutlich besser als ED - gehört ja auch nicht viel dazu - und genügsamer als Wordstar, für kleine ASM-Programme genau das richtige.
Nun kann es mit der Anpassung, "Entwicklung" von CP/M-Prommen losgehen, zunächst das X-MODEM Programm auf die schnelle V24 der CF-Karte, bzw. den Intel-Hexlader unter CP/M lauffähig anpassen. Damit wird dann der WIN98 Rechner wieder arbeitslos ...
Im Moppel tickt die Uhr noch im verborgenem und der direkte CP/M-Start könnte dann das "neue" Terminal aktivieren - es gibt da noch einige Ideen, der nächste Winter kommt bestimmt ...
15.01.2017
... wieder Winter und Moppelbastelzeit.
Zunächst ein kleines DFÜ-Programm gebastelt, es kann derzeit ein HEX-File über die Moppel-V24 entgegennehmen (9600Bd) und auf Diskette/CF-Karte speichern, alles noch ohne Schnörkel und Komfort.
Ein paar Dinge müssen noch verbessert werden und damit das ganze auch über die schnelle V24-Schnittstelle der CF-Karte läuft benötigt es dort noch die Nachrüstung eines Time-Outs nach ca. 10 Sekunden. Das erwarten die großen DFÜ-Programme XMODEM/Kermit auch. Im BIOS hatte ich das bereits für die Moppelhardware eingebaut.
16.01.2017
es ist geschafft, das DFÜ-Programm ist fertiggestellt.
Über die schnelle V24-Schnittstelle der CF-Karte nimmt es eine HEX-Datei entgegen. Der nun eingebaute Timeout (ca 7,5s), wenn kein Zeichen mehr empfangen wird, löst er die Verbindung. Anschließend schreibt es die Datei als "I.HEX" auf das Laufwerk A. Unter CP/M kann sie dort mit LOAD I.HEX in eine ausführbare Datei "I.COM" umgewandelt werden.
Wenn notwendig noch umbenennen und das neue Programm steht unter CP/M zur Verfügung.
Wie bereits erwähnt, kein Komfort, Dateiname ist im Quellcode verankert, keine Anzeige für den Übertragungsstatus etc. ganz einfach gestrickt, lediglich die Anzahl der zu schreibenden Records wird angezeigt.
Hier gibt es ggf. noch Raum für Erweiterungen, wie z.B. wahlfreier Dateiname, Erweiterung des Recordzählers für mehr als 32kByte usw. Da das Programm aber als Zwischenlösung für ein XMODEM/KERMIT-Programm dienen soll, werde ich das erstmal nicht weiter spinnen.
Nun kann der W98-PC wieder in den einstweiligen Ruhestand versetzt werden.
Denn der Workaround mit dem Assembler unter WIN7, dann das Ergebnis per Netzwerk an den W98 senden, dort auf eine Moppel-Diskette schreiben und schließlich im Moppel mit dem Hex-Lader in ein Programm verwandeln, war schon sehr umständlich ...
20.01.2017
... nun ist die Zeit auch in CP/M angekommen. Die CMOS-Uhr tickte lange im Verborgenem und konnte nur über das Monitorprogramm aufgerufen werden. Mit einer kleinen BIOS-Erweiterung können CP/M Programme die Uhrzeit abrufen. In der BIOS-Sprungleiste WBOOT + 51h wird die Uhrzeit vom Monitorprogramm bereitgestellt und in einem BIOS-Buffer als ACII-String abgelegt (CP/M-Gerecht mit der Endung "$"). Im Register (HL) steht die Startadresse des Strings zur Übernahme und Weiterverarbeitung, wie das nebenstehende Bild zeigt.
Das Stellen der Uhr ist noch dem Monitorprogramm vorenthalten, die Adresse WBOOT+54h ist schon mal vorbereitet,es fehlen aber noch ein paar Programmzeilen.
Als Nebenprodukt ist die Analyse des Monitorprogramms wieder ein kleines Stückchen weiter ...
07.03.2017
Damit der Moppel noch ein paar Kontakte zur Außenwelt knüpfen kann, fehlte noch eine Multi-IO-Karte mit Centronic's, V24-Interface, etc...
Anno 85 hatte ich sowas mal entwickelt und verstaubte seit dem in der Bastelkiste. Sie hat zwei V24-Schnittstellen, eine davon konnte auf TTL-Pegel umgestellt werden, daneben war noch eine Centronic's-Schnittstelle und die Systemuhr sowie ein Mäuseklavier um die Konfiguration einzustellen. Alle Umschaltungen konnten per Software vorgenommen werden, selbst die unterschiedlichen Baudrate für Senden/Empfangen war implementiert - frei nach dem Vorbild BTX (1200Bd Empfangs- und 75Bd Senderate).
Leider läßt sie sich nicht mehr zur ordentlicher Mitarbeit bewegen, mal klappt die eine V24 oder andere V24 nicht, mal will die Centronic's keine Daten senden. Fehler nicht greifbar, wahrscheinlich ein paar Wackelkontakte in der Häkeltechnik, ab zur Bauteilrückgewinnung - Fädelkämme gehen so langsam aus.
Also Neubau, hatte die Wahl zwischen klassischem Konzept oder modern, so wie die CF-Karte. Ein ATMEGA hätte die ganzen Schnittstellen bereitgestellt und über die bewährte Portanbindung dem Moppel mundgerecht aufbereitet.
Da der Moppel ein "Oldtimer" ist, passt das klassische Konzept besser. Sie beherbergt wie die ursprüngliche Karte zwei V24-, eine Centronic's-Schnittstellen, die Systemuhr sowie den DIP-Schalter für die Konfiguration (IO-Byte). Die Schnittstellen sind für ein normgerechten Pegel über entsprechenden Treiber geführt. Die Systemuhr (RTC58321) hängt direkt am PIO2 Baustein und liefert Datum/Uhrzeit im BCD-Modus, die freien Port's sind auf einer Steckerleiste für zukünftige Erweiterungen herausgeführt. Die Karte belegt 16Adressen, die Basisadresse kann wird über die Jumper entsprechend eingestellt, hier x3h (freie Bereich unterhalb der Hex-Anzeige/Banking).
Alles wieder in alter Manier zusammengehäkelt. Ja, ordentlich geätzte Platine ist natürlich besser, dazu müsste ich aber die Profiversion von Eagle kaufen und Prototypenplatinen kosten dann nochmals locker 60-80€. Der Aufwand ist mir zu hoch, soll ja keine Serie werden ...
Die Hardware tut nichts außer Strom verbrauchen wenn die passende Software sie nicht entsprechend auf Trapp hält. Für den Kartentest ist da eine kleine Sammlung entstanden die unter Monitorkontrolle die wichtigsten Tests ermöglicht.
05.11.2017
nun ist die Karte komplett einsatzfähig
Dokumentation und Schaltbilder auf der Dokuseite ...
(C)2017 Werner Römer
20.02.2018
nun bastel ich schon seit 2014 an diesem Moppel herum, einige Feature sind hinzugekommen CF-Karte, Datentransfer per Intel-Hex, Multi-IO-Karte usw. damit halte ich die Wiederbelebung für Erfolgreich und schließe das Thema.
Das bedeutet aber nicht, dass er wieder in die Versenkung verschwindet, nein er ist ja jetzt voll CP/M tauglich und dort gibt es dann den Fortsetzungsroman ;-))
