Hallo NKC-Freunde,

Ende Juli 2025 startet ich hier eine Anfrage

https://www.nkcforum.de/forumdrc/index.php?mode=viewthread&forum_id=2&thread=151

zu diesem Thema, dass ich damals mit Hilfe von Steffen.111 und seinem SER.700 bewältigen konnte. Ich habe mittlerweile mit Assembler für den Z80 weitergemacht und versuche, ein Übertragungsprogramm für die serielle Schnittstelle zu programmieren.

Mein Aufbau: NKC mit Z80-Vollausbau (4 Mhz), GP-2018 v3, GDP64k und der SER mit P6551 Version 1.0 Neuauflage 07/2027 MA.

Anm.: Ich verwende das GP-2018, weil es im Quellcode vorliegt und für Lernzwecke sehr gut geeignet ist.


Hier der Auszug aus dem Empfangsteil meines Programms:



Es handelt sich um den Empfang mit der SER (P6551) in der Betriebsart RTS/CTS. Die Variablen rtson (0x0B) und rtsoff (0x03) schalten den Sender ein oder aus. Bei den Baudraten 300 und 1200 funktioniert das auch, ab 2400 Bd bis 9600 Bd werden zu Beginn einer Übertragung meist das 3. Byte verschluckt. Die Sendung von "000102030405060708090A0B0C0D0E0F" über das Serialtool (Mac, freie Version) bringt beim Empfang im Empfangsspeicher (hl) (eingestellt in der Startroutine - hier nicht abgebildet - auf 0x8000) das Ergebnis "0001020405060708090A0B0C0D0E0F" -> 03 fehlt.

Ich habe das nach der Empfehlung von https://test.nkc-wiki.de/index.php?title=SER so aufgebaut. Im Tracer des GP-2018 kontrollierte ich den Ablauf. Da klappte das alles und das Programm erwies sich als fehlerfrei. Wenn im Empfangsregister ein Byte steht, setze ich sofort rtsoff ab, damit sind die nachfolgenden Programmteile für die Speicherung und Anzeige von Statusinformationen unkritisch.

Meine SER habe ich so konfiguriert:


Für die Datenflusskontrolle setze ich diesen Drivergenius ein.



Hier noch das Datenblatt vom P6551....
Rockwell-Datasheet-R6551P.pdf

Ich lerne gerade Assembler und die verwendeten Befehle im Programm sind die Einfachsten. Orientiert habe ich mich an den Beispielen von RDK in seinen Büchern und Beschreibungen zur SER.

Könntet ihr mal da drüber schauen, ob euch etwas auf- oder einfällt? Warum versagt das Programm trotz RTS/CTS ab 2400 Baud?

Besten Dank im voraus für eure Hilfe.

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!

Hallo Jürgen,

da fallen mir 2 Dinge zu ein:

1) Der 6551 hat einen sehr antiquierten Blick auf RTS/CTS.
Die taugen, wie implementiert, für Dich nicht wirklich. In das Loch bin ich schon vor 40 Jahren beidbeinig hineingetrampelt.
Wenn die Gegenseite CTS auf MARK setzt hat der 6551 gerne schon mit dem nächsten Zeichen begonnen.
Er hört dann _mitten_ im Zeichen auf zu senden, das gibt praktisch jedesmal Bitsalat.
Das bei RTS-> MARK der Sender im 6551 mit ausgeschaltet wird, ist auch nicht hilfreich.
Da praktisch alle Handshakeleitungen Nebeneffekte haben, die man so nicht ganz erwarten würde und deren Beschreibung bunt über das Datenblatt verteilt ist (man weiss nie, ob man wirklich alle gefunden hat...) und nicht alle 6551-Varianten zwingend identisch sind, ist viel Spaß angesagt, wenn man mit den Handshakeleitungen etwas anderes als ein antiquirtes Modem steuern möchte.

2) Viele serielle Bausteine unterdrücken bei CTS nur das Tx-Ready-Bit. Was schon in der Schnittstelle ist wird auch noch gesendet.
Das Byte im Schieberegister und das Byte im Transmit-Holding-register.
Das wäre dann in Deinem Falle eines zu viel.
Über USB wird der Rechner nur benachrichtigt, was er dann erfolgreich tun kann und dann tut, wer weiss...

In diesem Falle müsste das Overflow-Bit gesetzt sein.
Aber das wid schon wieder gelöscht, wenn Du das Datenbyte liest.
Also bekommst Du es nicht zu sehen.
-> Vor dem Lesen des Bytes prüfen, Flag setzen, später Flag ansehen.

Ich könnte mir vorstellen, wenn Du die vermutlich zeitaufwändigen Ausgabeaufrufe für Pufferadresse ind Statusregisterinhalt auskommentierst, funktioniert es schon anders ;-)
Aber warum es nun augerechnet das 3. Byte erwischt kann ich mir auch nicht ausmalen. Aber vielleicht jemand anderes.

Herzliche Grüße
Detlef

Hallo Detlev,

herzlichen Dank für Deine Erläuterungen.

Ich werde die Unterprogrammaufrufe auskommentieren und dann testen.

In einem zweiten Versuch beschäftige ich mich mit Xon/Xoff und einem 64 Byte großen Puffer. Meinst Du, diese Möglichkeit wäre eher von Erfolg gekrönt?

Und generell, wie würdest Du hier vorgehen, um einen Datenaustausch von Programmen vom PC(hier ein Mac) zum NkC durchzuführen?

Ich habe da zwar CASNEO und IOUSB mit Vdip1 auch am Start, aber der direkte Transfer ist schon bequem und schneller.

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!

Hallo,
Ich hab ein ser. Transferprogramm für den 68k NKC (für die SER1 mit 6551) geschrieben.
Die PC Seite via Python Programm und am NKC via Assembler.
https://github.com/avg67/nkc/tree/main/SW/Python_dl
Funktioniert in beide Richtungen um Files hin und her zu schicken. Steht schon länger auf meiner Todo- Liste das mal auf den Z80 zu portieren.
Wenn Bedarf besteht erstell ich mal eine genauere Beschreibung wie das ganze intern funktioniert.
LG Andi

Hallo Jürgen,

Zitat von redo: In einem zweiten Versuch beschäftige ich mich mit Xon/Xoff und einem 64 Byte großen Puffer. Meinst Du, diese Möglichkeit wäre eher von Erfolg gekrönt?

Jain.
Wenn Du XOFF sendest dann dauert es mehr als ein Zeichen lang, bis der Sender das bekommen hat. Zwischendurch sind doch wieder 1,2,3 Bytes auf dem Weg, die Du nicht gebrauchen kannst.
Und Du weisst auch nicht so genau, wie viele da noch kommen.
Das ist unbequem.
Small is beautiful. Es geht doch eigentlich nur darum, einigermassen zuverlässig fertig übersetzten Maschinencode vom Computer in den NKC zu bekommen, oder?
Wenn Du das Protokoll selbst bestimmen kannst (oder eines wie XMODEM nehmen kannst), dann wäre ein einfacher Weg, in Blöcken von z.B. 128 Bytes zu senden.
Die kommen in einen Puffer.
Der Sender wartet dann, bis er eine Bestätigung erhält.
Also kann der Block bekannter Maximalgrösse in aller Ruhe fertig verarbeitet werden.
Und Zeit für Bildschirmausgabe ist auch noch.
Wenn der Z80 wieder bereit ist, schickt er die bestätigung und weiter geht's.

Zitat: Und generell, wie würdest Du hier vorgehen, um einen Datenaustausch von Programmen vom PC(hier ein Mac) zum NkC durchzuführen? Ich habe da zwar CASNEO und IOUSB mit Vdip1 auch am Start, aber der direkte Transfer ist schon bequem und schneller. VG Jürgen

Ich würde mal nach der alten CAS graben.
Die Software dafür im uralten RDK 1.1-Monitor hat die Kommunikation über INTEL-Hexformat abgewickelt.

Das ist so vermutlich auch noch in späteren Versionen implementiert.
Das Format enthält die Zieladresse im Speicher.
Der Z80 hat also nur die Bytes gelesen, Prüfsummen überprüft und sofort den Speicher gefüllt.
Das geht relativ schnell.
Das wäre dann auf die 6551ACIA 'umzuschreiben'.
Oder eine ganz einfache Karte mit 6850 aufzubauen.
Die braucht noch einen Baudratengenerator und die Software muss umgepatcht werden, damit der 6850 den Takt durch 16 teilt (ist auf :1 für Casetteninterface eingestellt).
Damit kannst Du in beide Richtungen ohne Handshake vermutlich mindestens 9600 Baud übertagen.
Darf es mehr Aufwand sein, kämen ein ATMEGA-Controller und ein USB-Serial-Interface (CH341T) dazu.
Der Controller muss 'wissen', wann der Z80 das Datenregister im 6850 liest oder schreibt.
Und dann sofort Daten schieben.
Damit lässt sich die maximal mögliche Geschwindigkeit erreichen.

Aber ich bin bequem und würde wohl versuchen, den 6551 mit angepasstem RDK-Grundprogramm zum Laufen zu bringen. Vermutlich sind alle benötigten Routinen schon vorhanden, die SER wird doch auch unterstützt...

Herzliche Grüße
Detlef

Hallo Andi,
in einem zweiten Projekt mit Tang Nano und der 68008 CPU will ich das auch mal mit Assembler probieren. Das ist gerade in der Mache. CPU und Bootrom sind schon da, der Tang Nano von tuti kommt dazu. Ich werde das dort mit Deiner Lösung gerne probieren.

Hallo Detlev,
besten Dank für die Ratschläge. Ich teste das jetzt mal und suche die Routinen aus dem alten GP. Da ich mit dem Xon/Xoff schon begonnen hatte, untersuche ich das auch mal weiter. Eine XModem Lösung hatte ich mangels Protokoll- Wissen nicht verfolgt. Ich gestehe, ich bin auch erst am Anfang mit meinen Künsten.
Ich melde mich hier wieder mit den Ergebnissen.

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!

Es ist am einfachsten, kein flow control zu verwenden, sondern dafür zu sorgen, dass der NKC schnell genug arbeitet. Der Z80 sollte damit kein Problem haben, wenn der Code halbwegs in Ordnung ist. Der PC hat zum einen Puffer im UART und zum anderen normalerweise Puffer im OS.

Michael

Hallo Michael, hast Du da einen Vorschlag, welche Programmroutine da am Besten geeignet ist, bzw. welche vorhandene Software für den NKC verwendet werden kann? Wie gewchrieben, setze ich gerade das GP-2018 v3 ein, dass ich wegen seiner Sourceverfügbarkeit zum Lernen z.B. dem GP-2019 vorgezogen habe. Zudem werden alle Komponenten in meinem NKC dort unterstützt.: CASNEO mit Bedienteil und IOUSB. Sieh dazu auch
https://www.ndr-nkc.de/compo/project/z80/gp2018a.htm

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!

Hallo Jürgen,

von wo nach wo willst Du eigentlich übertragen?

Ein Hardware-Protokoll ist sicherlich das eleganteste. Mit einem Software-Protokoll ist es aber wesentlich einfacher, sowohl was das Kabel anbelangt als die genaue Kenntnis der Gegenstelle.

Ich arbeite deshalb mit dem XMODEM-Verfahren und habe die Programme PCPUT und PCGET von Ward Christensen z. B. für den Philips P2000C und das System IV von j&k angepasst. In abgewandelter Form habe ich die Programme auch für die Diskettensicherung verwendet. Auf dem PC benutze ich dafür Teraterm.

Viele Grüße
Mathias

P2000GET.ASM

P2000PUT.ASM

Hallo,
hier auch noch ein paar Info's PCPUT, PCGET:
https://github.com/glitchwrks/pcget_pcput
Grüße
Hans-Werner

-----------------------
Ob 8bit oder 16 oder 32 ist doch egal, Haupsache selbstgebaut!

Hallo Matthias, hallo Hans-Werner,
danke für die Hilfe zum X-Modem unter CP/M Bedingungen.
Mein Übungsprojekt überträgt primär vom PC zum NKC. Zur Übertragung werden BIN-Dateien aus dem Arnoldassembler direkt in den Zielspeicherbereich übertragen, der vorher im Empfangsprogramm gewählt wurde. Für die Übertragung auf der PC-Seite (Macbook) verwende ich die freie Software SerialTool (auch für Windows und Linux), mit der ich auch die byteweisen Übertragungen teste. Ein Filetransfer (raw) zum NKC ist möglich. Ich lerne Assembler im GP-2018 v3 und dieses Programm ist mein erstes Projekt, um meine zukünftigen Sachen zum Test schnell in den NKC laden zu können. Vorher teste ich die Software noch, so weit es geht, im NKCEmulator
https://www.ndr-nkc.de/compo/emu/versionen.htm

Mein Kabel ist 9-polig, gekreuzt für Tx/RX und RTS/CTS. DSR/DCD verwende ich nicht. Die Übertragungsstrecke Macbook (Serialtool) über den FDTI-232 (DriverGenius) und dem 9-poligen Kabel funktioniert soweit.

CP/M habe ich noch nicht im Einsatz (bereite gerade ein Gotek und 3,5" Flopyy für meine FLO3 mit Flomon4000 vor). Dort würde ich es gerne mit eurem Vorschlag probieren.

Soweit noch von mir zum Sinn und Zweck.

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!

Hallo Matthias, hallo Hans-Werner,
danke für die Hilfe zum X-Modem unter CP/M Bedingungen.
Mein Übungsprojekt überträgt primär vom PC zum NKC. Zur Übertragung werden BIN-Dateien aus dem Arnoldassembler direkt in den Zielspeicherbereich übertragen, der vorher im Empfangsprogramm gewählt wurde. Für die Übertragung auf der PC-Seite (Macbook) verwende ich die freie Software SerialTool (auch für Windows und Linux), mit der ich auch die byteweisen Übertragungen teste. Ein Filetransfer (raw) zum NKC ist möglich. Ich lerne Assembler im GP-2018 v3 und dieses Programm ist mein erstes Projekt, um meine zukünftigen Sachen zum Test schnell in den NKC laden zu können. Vorher teste ich die Software noch, so weit es geht, im NKCEmulator
https://www.ndr-nkc.de/compo/emu/versionen.htm

Mein Kabel ist 9-polig, gekreuzt für Tx/RX und RTS/CTS. DSR/DCD verwende ich nicht. Die Übertragungsstrecke Macbook (Serialtool) über den FDTI-232 (DriverGenius) und dem 9-poligen Kabel funktioniert soweit.

CP/M habe ich noch nicht im Einsatz (bereite gerade ein Gotek und 3,5" Flopyy für meine FLO3 mit Flomon4000 vor). Dort würde ich es gerne mit eurem Vorschlag probieren.

Soweit noch von mir zum Sinn und Zweck.

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!

Hallo Jürgen,

dann ist die einfachste Lösung für Dein Problem sicher der Weg, den Michael vorgeschlagen hat.
Halt keine Grundprogrammaufrufe ausführen, die Zeit kosten könnten und ggf. Interrupts wärend der Ausführung verbieten.
(Irgendwo wird ja die Uhr auf dem Bildschirm aktualisiert. CSTS und Interrupts sind Kandidaten dafür).

Herzliche Grüße
Detlef

...kleiner Nachtrag:

Bei Reichelt gibt es immer noch den XR 16C2850 CJF für schmale 4,20EUR.
Doppel-Uart, 8250-Nachfolger, 128Bytes FIFO, automatischer Handshake (Hardware oder XON/XOFF), einfaches Bustiming.
Kleine Investition für ein lustiges Bastelprojekt...

Hallo Detlev, hallo ihr anderen Helfer,

ja, ich habe jetzt mal im Emulator diese GP Routinen getraced. Stimmt, da geht sehr viel Zeit verloren. Ich baue das jetzt mal um, den CSTS lasse ich jedoch, sind nur ein paar Bytes Programm, um aussteigen zu können.

Das mit dem XR 16c2850 klingt gut, übersteigt aber meine Fähigkeiten derzeit, was Elektronikdesign angeht. Ich schaue mir aber den Controller mal an und recherchiere?.sollte sowas mit einer IOEenh schon klappen?

Ich melde mich wieder?. Besten Dank für eure Ratschläge bisher?

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!

Das erste Buch "Computer modular" beschreibt die SER sehr gut und hat Beispielcode. Hier z.B. das Diagnoseprogramm, um Daten zu senden:

;******************************
;* Serielles Interface 6551 *
;* Test Sender Teil V24 *
;******************************

org 0100h

ser equ 0f0h ;Basisadresse der SER (Jumper 000011)

ser_dat equ ser+0
ser_sta equ ser+1
ser_cmd equ ser+2
ser_ctl equ ser+3

start1:
ld a,1eh ;9600 Baud
out (ser_ctl),a
ld a,0bh ;no par enable
out (ser_cmd),a
ld c,01101010b ; testmuster
loop1: in a,(ser_sta) ;status test
and 10h ;transmitter ready
jr z,loop1
ld a,c
out (ser_dat),a ;auf datenport
jr loop1 ;und widerholen

Wie man sieht, ist das kein Hexenwerk. Der 6551 ist wirklich sehr einfach.

Michael

Hallo Michael,

ja, das stimmt. Mein Programm hat wohl wirklich die Schwierigkeit mit den Unterprogrammen zur Anzeige der gespeicherten Bytes und der Statusanzeige der Schnittstelle.

Der Vorspann mit der Initilisierung findet bei mir weiter oben statt, ist im dargestellten Codesegment nicht sichtbar, entspricht aber dem Muster.

Ich konnte es nich nicht testen, bin aber dran. Besten Dank für die Mühe.

Ich melde mich, wenn ich es getestet habe.

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!

Hallo Detlev, hallo Michael, hallo andere Helfer,

ich habe das jetzt so geändert, dass die Unterprogramme zur Anzeige der übertragenen Bytes und der Status der Schnittstelle nicht mehr angezeigt werden.

Ja, dann hat das geklappt mit RTS/CTS und 9600 Baud. Ich habe das mit Dateitransfer (RAW) und meiner Testsequenz "010203...0F" mehrfach ohne Fehler durchführen können.

Ich lass das jetzt mal für RTS/CTS so, werde mich aber am Xon/Xoff versuchen. Ich wollte dabei so vorgehen, dass ich zunächst Xon sende und jedes empfangene Byte in einen Buffer (z.B. max, 64 Byte) schreibe.Bei 80% Füllung sende ich Xoff, warte bis das letzte Byte im Buffer ist und leere erst dann den Buffer an die Zieladresse. Danach beginnt das Spiel wieder von vorne.... Ich lass mich mal überraschen...

Die Themen XMODEM und PCPUT/PCGET greife ich gerne auf, wenn ich mich dem CP/M zuwende. Besten Dank hier für die Tipps.

Den XR 16C2850 CJF hab ich mir angesehen. Ja, das wäre Klasse, übersteigt aber meine Fähigkeiten in Elektronik. Ein bisschen rumlöten nach Anleitung, ja gerne.... aber ein neues Interface entwerfen.... Nein, das kann ich nicht.

Soweit von mir. Herzlichen Dank für eure Hilfe.

VG Jürgen

-----------------------
Nach vielen Jahren geht es mit dem NKC wieder los.... Schön!