Beiträge von t.schlumpf

Hallo funkenzupfer, danke für Deine Antwort.

Der Empfänger, ein Apple II mit SuperSerialCard und CP/M, hat eine SY6551 UART, ohne RX FIFO.

Die Zeit von RTS inaktiv bis wieder aktiv ist meistens kürzer als eine Byte-Zeit, jenachdem, was der Apple mit dem Zeichen tun muss. Solange sie kürzer ist, funktionierts. Das Empfangsprogramm hat verschiedene Modi, Text- oder HEX Darstellung, die unterschiedliche Zeiten zur Verarbeitung benötigen, zudem tragt auch das Bilschim-Scrollen wesentlich zur Verarbeitungszeit bei.

Ich werde versuchen, das Empfangsprogramm so umzubauen, so, dass nach RTS inaktiv noch mindestens eine Bytezeit auf ein nächstes Zeichen gewartet wird. Dauert aber noch ein Weilchen, es ist inzwischen ein anderes Baby auf dem Wickeltisch...

lg Tony

Ja, ich verwende Ext/Status Interrupts. Das direkt-Lesen ist allerdings auch ohne die Interrupts nicht möglich, wenn nicht zuvor ein Reset-Kommando erfolgt ist. Meine Versuche haben das so bestätigt.

Zum Zweiten: Ich verstehe nicht genau, was Du mit verknüpfen meinst.

Mein letzter Versuch war, vor dem jedem Schreiben ins Senderegister auf AllSent zu warten. hat aber auch nichts verändert.

Ja, funkenzupfer, genau das wollte ich, bytegenau steuern. Der Empfänger (ein Apple II mit CP/M) ist im Polling-Modus, nimmt nach jedem Zeichen den Handshake zurück und setzt ihn wieder, wenn das Byte verarbeitet ist. Bei einem Empfänger mit FIFO (z.B. eine Z80-SIO) funktioniert's problemlos.

Ich werde veruchen, Deinen Hinweis umzusetzen und nach Rücknahme des Handshake mindestens eine Bytezeit auf das noch folgende Zeichen zu warten.

Zitat von funkenzupfer

Ich bin ziemlich sicher, das man CTS / DSR direkt lesen kann

CTS/DSR werden bei Statuswechsel gelatcht, erst nach dem Reset Kommando ist der aktuelle Status verfügbar:

Data Carrier Detect (D3)

The DCD bit indicates the state of the DCD input at the time of the last

change of any of the five External/Status bits (DCD, CTS, Sync/Hunt,

Break/ Abort, or Transmit Underrun/EOM). Any transition of the DCD

input causes the DCD bit to latch and causes an External/Status interrupt.

To read the current state of the DCD bit, this bit must be read immediately

following a Reset External/Status Interrupt command.

Dies ist ein Auszug aus dem SIO Datenblatt.

lg und danke

Hallo funkenzupfer und tofro

Erstmal danke für Eure Antworten.

Das angefangene Byte ist nicht das Problem, es ist das darauf folgende, obwohl der Handshake inaktiv ist. Beide Interrupt-Routinen testen des Status des Handshake nach einem 'Reset Ext/Status Int' Kommando, das erforderlich ist, um den aktuellen Status zu erhalten. Ist der Handshake inaktiv, wird nichts mehr ins Senderegister geschrieben.

Ich habe auch versucht, vor jedem Schreiben auf das Leerwerden des Schieberegisters zu warten (All Sent im RR1). Gleiches Resultat.

Auf der im ersten Post verlinkten Seite steht the Tx registers are doubly buffered, im Datenblatt habe ich jedoch nichts derartiges gefunden. Dies würde das Verhalten erklären, wenn das AllSent Bit bereits nach einem Byte gesetzt wird.

Wie es aussieht, gibts hier keine Lösung ausser dem Verwenden von AutoEnables, damit funktionierts, gibt aber Probleme mit RTS wie im obigen Link beschrieben.

Hallo miteinander

Zur Zeit versuche ich, serielles Senden mit der Z80-SIO zum Laufen zu kriegen. Soweit funktioniert's auch, es gibt nur ein Problem mit dem Handshake, wenn auf der Empfängerseite ein Gerät ohne Empfangs-FIFO ist.

Dies ist die Ausgangslage:

Z80-SIO mit TX- und Ext Interrupts, konfiguriert ohne AutoEnable. Das Sendesystem (Kaypro II) sendet ununterbrochen eine Zeichenfolge. Ein Breakpoint ist auf die Ext-Interrupt Service Routine gesetzt. Der KO triggert auf die negative Flanke des Handshake-Signals (gelbes Signal), was einen Ext-Interrupt auf dem Kaypro auslöst.

Das rote Signal ist der TX des Kaypro, Baudrate 4800, Zeitbasis 500uS. Es ist klar zu erkennen, das hier dem angefangenen Byte ein weiters folgt, obwohl der Sender im Breakpoint ist. Dies führt dazu, dass der Empfänger ohne FIFO (und im Polling-Modus) dieses Zeichen vergisst.

Kennt sich jemand mit der Z80-SIO aus? Wie kann ich das Senden nach dem angefangenen Byte stoppen ohne den Auto-Enable Modus zu verwenden? Den möchte ich nicht, er geht nur mit RTS/CTS, ich verwende DTR/DSR wegen dem anderen SIO-Problem.

Vielen Dank schon mal!

Tony

Die Zebrastreifen sind normal, während des Ladens hat die CPU keine Zeit, den Bilschirm zu bedienen. Sieht auf meinem ZX-80 genau so aus. Hast Du mal versucht, ein Programm vom Tonband zu laden?

Da ging noch was vergessen...

Hier sind die EPROM-Images:

2532, MPF-1_MON-RH-CL-LIB_U6: MPF-1 Monitor, Receive-Hex (0800), Clock (0A00) und Library (ab 0C00). Passt in U6 des MPF, Basic ist nicht mehr drin.

2716, MPF-1_RH-CL-LIB_U7: Receive-Hex (2000), Clock (2200) und Library (ab 2400) für U7.

Es hat sich auch noch ein Bug in der Library in lDKN() eingeschlichen, ist behoben.

Hallo allerseits

Hier ein kleines Update zum Empfangsprogramm des MPF-1. Da ich kürzlich einen EPB-MPF EPROM Programmer

ergattern konnte, ergab sich das Problem, wie bringe ich ein EPROM-Image, das für irgendeine Addresse assembliert ist, in den Buffer des Programmers?

Ich habe dies so gelöst, dass beim Programmstart die Ladeadresse eingegeben werden kann:

.

Ist diese ungleich 0 und ist an der Adresse RAM, werden die Adressen im HEX File ignoriert und die Daten an die angegebene Adresse gschrieben. So können auch mehrere Programme an verschiedene Adressen geladen und dann zusammen ins EPROM programmiert werden.

Der Anhang enthält CP/M M80 Sourcen für Adresse 1800. Durch ändern der ORG kann dies an eine beliebige Adresse verschoben werden. RH benötgt zudem Library-Routinen, der Source und das EPROM Image (Adresse 2400) dazu sind ebenfalls im Anhang (RH.ZIP).

@MicrotronicHamburg

Jo, das ist CP/M. Hat der TRS-80 auch eine Z80-SIO? Wenn ja, brauchst Du nur die Portadressen der SIO anzupassen (LIBH.DEF), dann sollte es laufen. Andernfalls bräuchte es einen Treiber für die UART.

lg Tony

Ich habs korrigiert, danke für den Hinweis!

Inzwischen habe ich ein Progrämmchen auf dem Kaypro gebastelt, womit HEX Dateien zun MPF übertragen werden können, obwohl es auch mit PIP funktionieren würde. Nur sind die etwas schrägen RS-232 Parameter (300,N,,8,2) auf dem Kaypro nicht mit BAUD.COM einstellbar. Zusätzlich kann eine Verzögerung am Zeilenende definiert werden, falls die HEX Zeile mehr als 16 Bytes enthält.

Angeschlossen wird das ganze sehr einfach:

Angehängt sind die Sourcen des Sendeprogramms auf dem Kaypro sowie die des Empfangsprogramms auf dem MPF-1. Das EPROM-Image ist im ersten Post zu finden.

Das ist schon das ganze Geheimnis.

DB25:

Empfangsleitung des MPF and Pin2 (TX)

Masse des MPF an Pin7 (GND)

Pin4 mit Pin5 verbinden (RTS/CTS)

Pin6 mit Pin20 verbinden (DSR/DTR)

DB9:

Empfangsleitung des MPF and Pin3 (TX)

Masse des MPF an Pin5 (GND)

Pin7 mit Pin8 verbinden (RTS/CTS)

Pin6 mit Pin4 verbinden (DSR/DTR)

Viel Erfolg!

Hallo Shadow-aSc

Nein. da ist nichts drin ausser den Handshake-Brücken. Wie oben erwähnt, ist die Schaltung des MPF so ausgelegt, dass das -/+ RS-232 TX Signal ohne Gehahr für Sender oder MPF direkt am EAR Eingang angeschlossen werden kann (beim MPF-1P gehts nicht, der hat einen Kondensator in serie, die Zeitkonstante des RC Glieds ist zu kurz für 300 Baud).

Bei Fragen einfach fragen...

Schönes Ding, dieser MPF-1. Macht richtig Spass, damit zu spielen...

Es ist nur etwas mühsam, die Programme, assembliert mit z.B. CP/M's M80, einzutippen. Vor allem, wenn etwas an der Grösse verändert wurde, alle absoluten Sprünge und Calls händisch ändern. Wäre doch schön, wenn die Programme anstelle des Eintippens seriell übertragen werden könnten, etwa so:

Nur, der MPF hat keine UART. Bietet sich also Bit-Banging über den Tape-Eingang an. Dies ist problemlos ohne Hardware-Anpassung möglich. Der TX-Pin des Senders kann direkt an die EAR Buchse des MPF angeschlossen werden, Beim Kabel ist darauf zu achten, dass senderseitig RTS/CTS und DTR/DSR überbrückt werden müssen.

MPF-1_RH-EAR-Input.jpg

Seriewiderstand und Schutzdioden sind vorhanden, es können keine verbotenen Spannungspegel auftreten.

Fehlt noch die Software. Ziel ist es, keine Aenderung an der Firmware durchzuführen, der MPF soll original bleiben und Laden von Band soll weiterhin möglich sein. Deshalb wird das Empfangsprogramm im EPROM U7 abgelegt. Wer nicht auf das BASIC verzichten will, kann anstelle des MPF-1 Monitors den des MPF-1B verwenden, hier ist BASIC integriert. Zu beachten ist dabei, dass ein 2532 EPROM benötigt wird, ein 2732 funktioniert nicht.

Ein wesentlicher Teil der Entwicklung war das Ableichen der Zeiten für die Sampling-Punkte des seriellen Bit-Stroms (rot ist das serielle Signal, gelb die Sampling-Punkte des Empfangsprogramms)

Es ist kein Handshake verfügbar, durch die Verarbeitungszeit einer Zeile der HEX-Datei (Umwandlung nach binär, Adressen-Test, Checksummenberechnung, Verifizierung) ist eine maximale Geschwindigkeit von 300 Baud, und erst noch mit zwei Stoppbits, möglich. Damit wird in etwa die Geschwindigkeit des Ladens von Band erreicht.

Im Anhang MPF-1.ZIP sind die Sourcen, das EPROM Image und WAV Dateien. Die WAVs dienen dem Debugging und können nur verwendet werden, wenn in U7 ein RAM sitzt. Zusätzlich zum Empfangsprogramm sind auch eine CTC-Interrupt gesteuerte Uhr sowie verschiedene Hilfsroutinen, u.A. Interrupt-Serviceroutinen für CTC und PIO mit konfigurierbaren Callbackadressen, vorhanden.

Viel Spass damit!

Tony

RetroGuy: Man darf...

War nicht ganz billig, aber für 'neuwerting in OVP' hats mich nicht gereut. 150 Franken hat der MPF gekostet, inklusive Versand aus USA und defektem IC.

Gruss
Tony

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:

--------------
IOM skip, xx6x
--------------
  DA5D    1A          lOHBL:        LD    A,(DE)     ; get digit
  DA5E    13                        INC    DE        ; point to next
                                
  DA5F    18 0F                     JR    ISIOM1     ;-------------------------------------
  DA61                              DS    0FH        ; $$$ IOM-MPF: skip I/O xx6x
  DA70                ISIOM1:                        ;-------------------------------------
                                
  DA70    FE 20                     CP    dcASP      ; space equals to '0'
  DA72    20 02                     JR    NZ,lOHBC   ; not space

------------------------
printer skip, xxCA, xxCB
------------------------
  DAC3    3A FEF4                   LD    A,(dvMBT)  ; A= system beep enable flag
  DAC6    B7                        OR    A          ; zero means disabled
                                
  DAC7    18 03                     JR    ISPRT1     ;-------------------------------------
  DAC9                              DS    3          ; $$$ PRT-MPF: skip I/O xxCA, xxCB
  DACC                ISPRT1:                        ;-------------------------------------
                                
  DACC    CC DAD1                   CALL  Z,lSBEEP   ; beep if enabled

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...

fritzeflink: Fritz, danke für die Info. Hab alles durchgekämmt, leider nichts brauchbares für die VKI... Das webarchive werde ich noch durchsuchen-

Hier ist das gewünschte 96TPI Image. Ich hab noch die Original-ZCPR-Doku hinzugefügt.

zcpr_96.zip

Gruss

Tony

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!

fritzeflink

Aber gerne doch: itt3030_zcpr.zip

Habs mit SAMdisk konvertiert, hoffentlich klappts...

Gruss Tony

funkenzupfer

Gemäss der Dokumentation muss NZ-COM nach einem Reboot geladen werden. Die TPA wird dann etwa 5k kleiner. Ich habs noch nicht probiert, werde das aber noch nachholen.

Gruss Tony

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

The hard way...

Ich habe das Problem durch ändern des Charactergenerators gelöst (zumindest bis irgendwo doch noch eine Beschreibung zum VKI auftaucht).

Das geänderte ROM-Image is im Anhang. Läuft aber nur auf dem VKI Adapter

PAW, tolle Sache, Dein SAMconv, vielen Dank dafür!

Ich habe Definitionen für den ITT3030, 48 und 96TPI estellt, dazu ein Disk-Image zum Testen, siehe Anhang. Vielleicht kannst Du diese in die nächste Version übernehmen.

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