Beiträge von t.schlumpf

    Soeben von eBay eingeflogen...



    ... wurde als 'brandneu verkauft, sieht auch so aus. Der MPF lief dann auch für etwa fünf Sekunden, dann SYS-SP. Danach nur noch Abstürze. Nach einigen Messungen stellte sich heraus, dass der 7474 im Clock/Reset Bereich



    dafür verantworlich war. Er zog zeitweise seinen eigenen Reset-Eingang auf Masse, das Clocksignal kam nur hin und wieder bis zur CPU. IC gewechselt, Freude herrscht...

    Danke Dir für die Vorschläge. Du liegst genau richtig. Nur die OpCode Adressen düfen nicht in den I/O Bereichen liegen, bei den Operanden spielt´s keine Rolle. Ich hab´s auch so implenentiert. Hier Ausschnitte aus dem List-File:

    Je nachdem, welche Instuktionen vor und an den betroffenen Adressen liegen, müssen die DS nn angepasst werden. Natürlich müssen nach jeder Aenderung im Code, sofern sich die Codelänge ändert, die Skips neu getestet und ggf geändert werden. Etwas mühsam, aber es funktioniert.

    Es ist Zeit für ein Update:


    Der oben erwähnte Trick mit den NOPs an den Codeadressen xxCA und xxCB funktioniert nur bedingt, es passieren zeitweise Abstürze. Ueberspringen der Adressen hingegen funktioniert.


    Trotz der Widrigkeiten mit den ´verbotenen´ Adressen konnte ich es nicht lassen. Ich habe eine kleine Bibliothek erstellt, die ein paar Funktionen, z.T. interruptfähig, zur Verfügung stellt:

    • Initialisieren der IOM Devices USART, CTC und PIO. Die möglichen Betriebsarten sind alle über EQUates vordefiniert. Interrupts müssen ausgeschaltet sein.
    • USART Empfangs- und Sendefunktionen. Es wird nicht auf Bereitschaft gewartet, das ist Aufgabe des Hautprogramms. Der Status wird zurückgegeben.
    • Setzen und Rücksetzen von RTS/DTR.
    • Interrupt Vektortabelle für CTC- und PIO Interrupts.
    • Funktion zum Setzen des Interrupt-Modus und Laden des I-Registers mit dem HiByte der Vektortabelle.
    • Funktion zum Sperren der Interrupts mit Rückgabe, ob die Interrupts bei Aufruf freigegeben waren.
    • Interrupt Handler für alle möglichen Interrupts des IOM Boards. Bei der Initialisierung kann optional für jeden Interrupt eine Callback Adresse definiert werden, die dann bei jedem Interrupt aufgerufen wird. Jeder Handler bedient einen 8-Bit Zähler, woraus das Hauptprogramm sehen kann, ob und wie oft ein Interrupt aufgetreten ist. Das Hauptprogramm löscht diesen Zähler nach Bedarf.
    • Einlesen des DIP-Schalters auf dem IOM mit optionaler Vorgabe einer Maske. Die Funktion gibt dann über das CY zurück, ob sich an den maskierten Bits etwas geändert hat.
    • Konvertierungen binär <-> HEX ASCII mit Angabe der Anzahl Stellen (1..4). Der Monitor kann das auch, aber nicht mit laufenden Interrupts.
    • Konvertierung nach Grossbuchstaben
    • Verifizierung, ob ein Zeichen darstell- und druckbar ist. Falls nicht, Rückgabe eines Space.
    • Ersatz für die Monitor-Beeper Funktionen, die nicht interruptfest sind. Dabei sind ein Beep, der unabhängig von der momentanen Systemeinstellung beept, eine Funktion, die nur beept, wenn vom System freigegeben, eine dritte, bei der die Parameter definiert werden können.
    • Statische Ausgabe gleicher Zeichen an beliebiger Position auf dem Display (analog der Tape-Load Funktion des Monitors). Kann z.B. zur Fortschrittsanzeige während zeitkritischen Prozessen verwendet werden. Muss nicht zyklisch aufgerufen werden.
    • Funktion zur Aktualisierung des Display und Lesen der Tastatur (analog der SCAN1 Funktion des Monitors) mit Uebergabe der ASCII Bufferadresse. CTRL-G ändert den Status des System-Beepers. Wartet nicht auf Eingabe. Muss zyklisch aufgerufen werden, damit das Display sichtbar bleibt.
    • Textzeilen-Editor mit wählbarer Bufferadresse, 20 Zeichen ohne Scrolling. Initialisieren des Buffers wählbar. Blinkender Cursor, mit den Pfeiltasten verschiebbar, wobei Pfeil-auf an den Anfang, Pfeil-ab ans Ende, nach letzter Stelle, die nicht Space ist, bewegt. Ctrl-U erlaubt das Wiederherstellen des Buffers, wie er bei Aufruf war. Ctrl-G ändert des Status des System-Beepers. Da die Funktion auf eine Eingabe wartet, kann von einer Interrupt-Funktion eine Speicherstelle beschrieben werden, die den Editor zwangsweise beendet.
    • Empfangsfunktion für Intel-HEX Dateien mit der USART. Damit können Programme für den MPF auf Fremdsystemen entwickelt werden (wie z.B. diese Library). Prüft die Zeilen-Checksummen und verifiziert die geschriebenen Daten. Die Uebertragungsparameter sind 1200,N,8,1. Diese wurde gewählt, damit ein Uebertragen ohne Handshake möglich ist (wie z.B. CP/M´s PIP).

    Im Anhang ist nebst den Sourcen ein ROM Image für ein 2732 EPROM, das in den normalerweise freien Sockel U6 des PRT-MPF, Adresse 7000H, passt. Darin sind das Empfangsprogramm, Start mit G 7000, und die Library Routinen ab 7800H.


    Damit die Interrupts mit dem Testprogramm ´sichtbar´ werden, die Verdrahtung des IOM. Die Ports A0-A3 des PIO werden von den Interrupt Callbacks angesteuert, B0-B3 vom Hauptprogramm. Dabei ist PB7 ein Eingang, der bei positiver Flanke einen Interrupt auslöst. Deshalb ist dieser mit dem Ausgang PB0 verbunden.



    Viel Spass, mindestens soviel, wie das Entwickeln gemacht hat...

    Tony

    Hallo und guten Abend funkenzupfer

    Besten Dank für Deine Reaktionen.


    Zur ersten: Gute Frage. Eigentlich dürfte bei inaktivem /RD vom 8251 nichts auf den Bus kommen. Ich habe das Datenblatt nochmals angeschaut, hier ist das Verhalten von /RD ODER /WR beschrieben, nicht aber wenn beide Signale bei aktivem /CS inaktiv sind, was ja bei einem INTACK Zuklus der Fall ist.

    Möglicherweise ist dies ein für den 8251 verbotener Zustand und er verhält sich undefiniert. Versuche haben jedenfalls ergeben, dass der 8251 für die Abstürze verantwortlich ist. Bei entferntem Chip oder Code im nicht betroffenen Bereich läufts wie erwartet, keine Abstürze.


    Zur zweiten: Keine Daten auf dem Bus würde ich eher ausschliessen. Die Interrupts werden vom CTC und der PIO ausgelöst, der 8251 kann keine Ints erzeugen, die Pins (TxEmpty und RxReady) sind beide nicht angeschlossen. Zudem wäre er inkomatibel zu Z80´s IM2.


    Zur dritten: Ja das trifft zu, und wird im IOM Manual auch so beschrieben. Der Trick mit den NOP´s an Codeadressen xxCA und xxCB hat sich bewährt.


    Ich hab noch das Schema MPF-1P_IOM-Schematics.pdf angehängt, damit wir vom gleichen reden...


    Nochmals vielen Dank

    Tony

    Ich habe einen MPF-1P mit IOM-MPF



    und PRT-MPF Erweiterungsmodulen. Sehr schönes Teil mit PIO, CTC und 8251 USART. Nur fehlt brauchbare Software dazu. Im ROM des IOM sind Demoprogramme für alle drei Chips, nur nützen die wenig, das CTC Programm stürzt sogar ab...

    Im Manual des IOM wird erwähnt, dass auf dem Printermodul ein Design-Fehler existiert, der verhindert, dass Interrupts funktionieren. Das Signal M1 des Z80 wird bei der Dekodierung der I/O Ports nicht berücksichtigt. Dies führt dazu, dass das Printerboard bei einem Interrupt-Acknowledge Zyklus seine Daten auf den Bus legt und die vom Gerät, das den Interrupt angefordert hat, verfälscht, sofern die ausgeführte Adresse beim Auftreten des Interrupts xxCA oder xxCB (die Portadressen des Printerboards) sind. Die einzige Lösung des Problems ist, entweder die Speisung der Druckerkarte zu unterbrechen oder sämtliche Programmadressen, die mit CA oder CB enden, mit dem Lowbyte des Interrupt-Vektors zu versehen. Etwas aufwändig, aber funktioniert.


    Aber das ist nur die halbe Wahrheit. Den gleichen Fehler haben die Entwickler auch beim IOM gemacht. Hier betrifft es die 8251 USART (standardmässig nicht bestückt, darum wurde es vielleicht nicht beachtet).



    Auch hier fehlt M1 zur Decodierung der I/O Adressen. Für CTC und PIO spielt dies keine Rolle, da diese die Decodierung mit M1 selbst erledigen. Anders beim USART. Der legt frisch-fröhlich seine Registerdaten auf den Bus, sobald ein Interrupt-Ack Zyklus im Adressbereich xx40 - xx60 ausgeführt wird (der 8251 belegt IO-Adressen 60 und 61). Schon wieder ein Crash. Das heisst also, Monitorfunktionen mit laufenden Interrupts sind tabu. Im Anwenderprogramm darf zwischen xx40 und xx60 kein Code sein, der mit Interrupts unterbrochen werden kann. Dies ist übrigens auch der Grund, warum die CTC Demo abstürzt. Nach Verschieben in einen nicht betroffenen Adressbereich funktionierts.


    Ich werde nun versuchen, die wichtigsten Funktionen zum Ablegen im EPROM Printer- und USART sicher zu implementieren.

    Update folgt...

    Hallo Fritz

    Danke für die Info, diese Seite kenne ich bereits, nur ist auch hier leider keine Info zur VKI Video/Tastaturkarte (die mit dem Z80) vorhanden, die ich verzweifelt suche...

    Für das 96TPI Format (5.33T DT) muss ich ZCPR erst anpassen. Ich nehme nicht an, dass die CCP Adresse gleich wie bei T ST ist.

    Dauert aber einen Tag oder zwei...


    Bis dann!

    Hallo Fritz

    Danke für den Link. Meines Erachtens hat ZCPR jedoch den Vorteil, dass kein zusätzlicher Speicher gebraucht wird (passt in den standard CP/M CCP Bereich) und auf den System-Tracks der Disketten liegt, also sofort nach dem Booten verfügbar ist. Trotzdem werde ich NZ-COM mal probieren...


    Mit freundlichem Gruss

    Tony

    Wer einmal ZCPR unter CP/M gerochen hat, möchte es nicht mehr missen. So gings mir auch mit dem neuesten Baby, dem ITT-3030. Ich habe ZCPR D&J V1.4 adaptiert, läuft bestens. Im Anhang sind die Sourcen sowie das SAMdisk image (heisst .ITL wegen der Assoziierung und dem Kontexmenu in Windows). Muss für SAMdisk auf .DSK umbenannt werden. Das System im Image ist CP/M 2.2, 5.33T ST. Für DT hab ichs nocht nicht erstellt, wäre aber bei Bedarf problemlos möglich.

    -ZCPR---.PRJ.ZIP


    Vielleicht kann´s jemand brauchen...


    Gruss an alle

    Tony

    Hallo Axel


    Vielen Dank für die Dokus. Diese beschreiben jedoch nur den Video/Tastaturadapter I, dessen Charactergenerator nicht mehrsprachenfähig ist. Ausserdem steht hier. dass die Umschaltung des Zeichensatzes duch Tausch des EPROMS erfolgt. Von der VKI steht gar nichts, oder ich hab's überlesen.

    Dein Link ist für mich trotzdem sehr nützlich, weil darin, entgegen der Version, die ich habe, die Seriell- und Parallel-Adapter beschrieben sind. Offenbar gibts verschiedene Versionen des gleichen Dokuments, auch wenn beide den gleichen Stand vermerkt haben...


    Die Testanleitung anderseits weist nur auf mögliche Probleme bei Verwendung nicht verträglicher OS/Tastatusadapter/Tastatur hin.


    Nochmals danke!

    lg Tony

    Ein Hallo in die Runde


    Ich möchte auf dem ITT3030 in Pascal und Assembler programmieren. Das geht auch, nur sehen die Programme mit Umlauten anstelle der Klammern doch eher seltsam aus. In meinem System ist die VKI Video/Tastatur-Karte



    eingebaut. Ich habe das EPROM ausgelesen und festgestellt, dass nebst dem Programmcode für den Z80 zur Tastaturbedienung der Character-Generator für Standard-ASCII sowie die Umlaute für deutsch und französisch enthalten sind, im Gegensatz zum ROM der normalen Video-Tastaturkarte, wo anstelle der ASCII-Zeichen die deutschen Umlaute stehen. Ich schliesse daraus, dass zwischen den Zeichensätzen umgeschaltet werden kann. Nur, wie?

    Ich habe versucht, mit GEN eine englische Version des CP/M zu erstellen, hat funktioniert, die Tastenbelegung ist anders, aber immer noch keine [\]{|}. Braucht es dazu eine andere Version des CP/M (ich habe 2.2 5.33T ST)?

    Neben dem PIO sitzt eine 6polige Stiftleiste, zwei der Pins sind mit einem Jumper gebrückt. Ich traue mich jedoch nicht, ohne Dokumentation/Schema verschiedene Positionen zu probieren. Weiss jemand, wofür diese Stiftleise ist? Trotz intensiver Suche im Web habe ich nirgends eine Bescheibung dieser Karte finden können. Weiss jemand eine Quelle?


    lg Tony

    Hallo Frank

    Ja, hast Du. Der VK1 (der mit dem Z80) läuft auch einwandfrei. Den Ersatzkontroller hab ich nur mal testen wollen. Leider gibt die Doku keine Auskunft darüber, welcher Controller für welche Tastatur/CPM-Version benötigt wird.

    Zum VK1 hab ich (noch) keine Dokumentation gefunden. Weisst Du eine Quelle? Ich hätte gerne Schema und Beschreibung.


    lg Tony

    Hallo fishermansfriendtoo und fanhistorie. Besten Dank für Eure Antworten. Inzwischen habe ich die Testanleitung etwas genauer durchgelesen (hätte ich schon früher tun sollen...). Derzufolge muss es ein Kompatibilitätsprobem zwischen Tastatur, Adapter und Betriebssystem sein.

    Ich werde weitere Versuche durchführen. Vermutlich ist es aber so, dass der oben gezeigte Adapter nur die Standard-Tastatur unterstützt, ich habe aber eine Textverarbeitungs-Tastatur.


    lg Tony

    Hallo miteinander!


    Kürzlich habe ich den ITT3030 von fhw72 erstanden, läuft eigentlich einwandfrei. Es war auch, nebst der eingebauten Grafikkarte, der Original



    Video/Keyboard Controller dabei. Ich wollte den mal in Betrieb nehmen, doch der verhielt sich reichlich merkwürdig. Nach dem Booten wird ununterbrochen die zuletzt eingegebene Taste ('b') abgezeigt, bis der Buffer voll ist, dann von neuem. Beim Drücken einer anderen Taste wird diese endlos angezeigt. Keine Möglichkeit, ein Kommando einzugeben. Der Strobe-Input an Pin1 des Controllers ist ruhig (low), solange keine Taste gedrückt ist. Die Zeichen erscheinen auch, wenn die Tastatur ausgesteckt wird. Das System läuft mit der Grafikkarte ok, ich vermute deshalb den Fehler im Original-Keyboard Controller.


    Nun meine Frage: Hat jemand so eine Karte, ev. auch leihweise, übrig, damit ich den Fehler durch Vergleichsmessungen besser einkreisen könnte?


    Eine weitere Frage: Hat es jemand geschafft, den Editor von dBaseII auf dem ITT zu konfigurieren? Ich habe festgestellt, dass bei der Curosr-Positionierung für den Zeilen-Offset 33 anstelle der üblichen 32 verwendet werden muss, damit die Positionierung funktioniert. Das klappt bestens bei Turbo-Pascal und dem DevPac80 Editor, hier kann der Offset für Zeile und Spalte separat definiert werden, nicht so bei dBase. Gibt's hier eine Lösung?


    Danke schon mal...

    Tony

    ... und vom Marktplatz zu mir ...


    Ich hab den ITT von fhw72 gekauft, kam in eiwandfreiem Zustand an. Erst jetzt habe ich ihn in Betrieb genommen, läuft alles einwandfei, ausser den Floppies. Es waren 4(!) Stück dabei, 1x48TPI, 3x48TPI (so waren sie jedenfalls angeschrieben, es stellte sich aber heraus, dass es von jeder Sorte zwei sind). Das eine 48TPI lief (fast) auf Anhieb, bootet CP/M 2.2 5.33T ST nach z.T mehrmaligen Versuchen. Der Spindelmotor lief zu schnell, nach Korrektur mit Hilfe der Stroboskopscheibe wars dann ok. Die anderen liefen auch, aber mit sehr nervigem Geklacke, der Head-Load Magnet zieht und fällt mit jedem Selekt des Laufwerks, und der ITT de/selektiert innerhalb eines Zugriffs viele Male, vermutlich während der Verarbeitung der gelesenen Daten (eher ungwöhnlich). Zudem stellte der Sindelmotor, einmal gestartet, nie mehr ab, solange die Diskette im Laufwerk war.

    Der Vergleich des ruhigen mit den klappernden zeigte etliche Unteschiede. Nach erfolgtem Patch



    Die kalte Löstelle ist inzwischen bereinigt...


    funktionierten zwei der drei wie gewünscht, das dritte klapperte frisch fröhlich weiter. Verantwortlich dafür war der Treiber 7438 in der Selbst-Halteschaltung des Load-Magneten, der Ausgang blieb immer high (im Schema grün).


    Wieder ein Schätzchen vor der Müllhalde gerettet. Jetzt gehts weiter mit dem Testen der verschiedenen Interfacekarten,..


    In dem ITT ist ja auch eine Grafikkarte (diese hier) eingebaut, sie funktioniert bestens. Nur habe ich keine Dokumentation dazu finden können. Hat jemand eine Anleitung und/oder technische Infos dazu?

    Hallo tomtom


    Du liegst richtig, es ist die Z80-Karte. Wenn diese fehlt, dann läufts. Es ist ein Clone, ist aber kompatibel mit der von Micosoft.



    Ich habe ja auch noch die Apple2-IO-RPI Karte drin. Diese läuft, nachdem Indentify in Betieb war, nicht mehr. Die erste Adresse im EEPROM ($C500, Slot5) wird mit null überschrieben, ein Booten vom RPI ist nicht mehr möglich. Ein C500:E0 im Monitor schafft Abhilfe.


    lg Tony

    Hallo tomtom

    Danke für die Antwort.

    Der Fehler tritt immer auf, die Adresse im Monitor ist jedoch nicht immer gleich. Je nach Art des Fehlers wird die CPU noch unkontrollierte Instruktionen ausführen, bis dann mal ein BRK auftritt, und das kann irgendwo sein. Hab ich schon viel erlebt, z.B. bei uninitialisierten Pointern...


    Das mit den Karten werd ich mal probieren, obwohl es ja Sinn und Zweck des Programms ist, eben diese Karten zu erkennen.

    Ich melde mich dann wieder.

    Tony

    Hallo in die Runde


    Ich hab mir das Programm gekauft und übersehen, dass es für Mitglieder gratis wäre. Ist ja nicht ein Riesenbetrag.


    Nur, das Programm meldet sich bei mir so:



    Es ist ein 64k AppleII+ mit RAM-Card, Printer Interface, Apple SSC, Videx 80-Zeichen Clone, Z80 Karte, Apple2-IO-RPI von JPT und DiskII Controller. Alles andere (DOS/ProDOS/Apple-Pascal/CP/M) läuft einwandfrei, auch die Apple-Dealer-Diagnostik gibt keine Fehler aus. Deshalb nehme ich an, dass es kein Hardware-Problem ist.


    Hat jemand eine Lösung dafür?


    Danke schon mal

    Tony

    Jan, danke, gute Idee.


    Ich versuche aber weiterhin ein 27C64 aufzutreiben, Wenn dies dann funktioniert, ist das Problem gelöst.


    Zu Deiner Frage: Ja, die HELLOs und STARTUPs, läuft gut, ausser CP/M wird mit dem Netzschalter beendet...

    lg Tony

    Hallo Jan

    Die Idee mit dem Wegbiegen des /WR Pins hatte ich auch schon. /WR muss dann aber auf +5V liegen, wäre mit einem Widerstand lösbar. Ich habe aber nicht gerne so Bastleien, zudem müsste für einem Update der Originalzustand wieder hergestellt werden.

    Ich habs auch mit einem EPROM 2764 probiert, läuft, aber unzuverlässig. Warscheinlich mit 200nS Zugriffszeit zu langsam, ein 27C64 konnte ich (noch) nicht auftreiben, dieses hätte 150nS.

    Im Moment hab ich es so gelöst, dass BOOT.COM vom CP/M 0E0H nach 0C500H (Slot5) schreibt, bevor der Bootvorgang ausgelöst wird. Zudem tun die STARTUPs auf den DOS3.3 und ProDOS Disketten dasselbe, sofern nicht bereits 0E0H dort steht (um Scheibzylen möglichst gering zu halten).


    Tony

    Hallo Apple-Freaks


    Ein Problem(chen) mit dem Apple2-IO-Rpi im AppleII+:


    Nach dem Booten von CP/M wird das erste Byte des Apple2-IO-Rpi EEPROM überschrieben, ProDos vom RPi kann danach nicht mehr gestartet werden. PR#x hängt.

    Der Apple2-IO-Rpi ist in Slot 5

    Original: C500: E0

    Nach Booten von CP/M: C500: 02

    Nach einem Firmware-Update oder im Monitor C500:E0 funktionierts wieder.


    Kann das EEPROM schreibgeschützt werden? Wenn ja, wie?


    Besten Dank schon mal

    Tony

    Ein Hallo in die Runde


    Ich hab ein Apple2-IO-Rpi von JPT gekauft, läuft prima, auch auf dem AppleII+! Danke für Dein grossartiges Projekt, Terence!

    Ein kleiner Wehrmutstropfen, die Shell lässt sich mit nur Grossbuchstaben schlecht bzw. gar nicht bedienen.

    Obwohl ich ein absoluter Neuling in Sachen 6502 Assembler bin (bis jetzt nur Z80), habe ich versucht, den Code des Shell-Programms zu verstehen und so zu ändern, dass die Shell auch auf dem II+ bedienbar wird. Das Resultat ist im Anhang.


    So meldet sich Shell2P auf dem 40-Zeichen Bilschirm



    Nach dem Umschalten auf 80 Zeichen



    Mit CTRL-A lässt sich, wie von CP/M und DOS gewohnt, zwischen Gross- und Kleinschrift umschalten.


    Noch eine Frage zum ProDos-Utility: Ich hab es nicht geschafft, eine Datei in einem Image zu löschen. Das Kommando

    Code
    prodosutil -d <imagedatei> -c rm -i <dateiname> -p /

    beendet ohne Fehlermeldung, die Datei wird jedoch nicht gelöscht. Das gleiche passiert, wenn eine nicht existierende Datei mit -i angegeben wird. Hinzufügen funktioniert, sofern die gleiche Datei nicht schon vorhanden ist. Mache ich hier etwas falsch?


    Grüsse aus der Schweiz

    Tony

    Eine tolle Sache, CP/M auf dem Apple II+


    Der Dateitransfer mit ADT unter DOS funktioniert zwar einwandfrei, es ist allerdings etwas mühsam, für jede Datei ein ganzes Diskimage zu transferieren. Im Manual der Z80-Softcard ist ein Programm abgedruckt, das den Dateitransfer via serielle Schnittstelle zu einem anderen CP/M System ermöglicht. Leider vermiss ich bei diesem Programm eine Abbruchmöglichkeit, auch das Dateiende wird nicht erkannt. Es muss immer manuell beendet werden...


    Ich habe die Programme UPLOAD und DOWNLOAD so modifiziert, dass diese Mängel behoben sind. Im Anhang sind die Sourcen für Apple CP/M und Kaypro II, jeweils Up- und Download. Das AppleII Programm unterstützt allerdings nur die SuperSerialCard.

    Die Sourcen sind im HiSoft DevPac80 Format, sollten aber mit M80/L80 kompatibel sein.


    Viel Spass damit!

    Tony