PC Serial Loader - Datenübertragung via Nullmodem mal anders

@mgutzeit,
das sieht sehr interessant aus und ich denke, dass es auch sehr nützlich sein kann.

Das sollte man sich mal näher ansehen und probieren.

Danke für den Thread und für den Link.

mfG. Klaus Loy

Das sieht vielversprechend aus, muss ich mal testen. Ich hoffe aber, dass die serielle Verbindung auch mehr als 9800 Baud unterstützt, jeder XT muss eigentlich wenigstens 19200 schaffen.

Zitat von 1ST1

jeder XT muss eigentlich wenigstens 19200 schaffen.

Für den Apple II gibt's seit Jahrzehnten solch eine serielle Lösung: ADT bzw. ADTpro. Der Apple II schafft 115kBaud.

Gruß, Ralf

sehr schick!

Cooles Projekt ! Muss ich mal antesten.

Ich beschäftige mich zwischendurch mir Assembler am XT. Im dementsprechenden Register für den COM-Port kann ich maximal 9600 baud einstellen. Vielleicht gibts da ja einen Trick ?!

Der Atari 800 schafft 115200 Baud, genauso wie der Apple 2, was oben bereis erwähnt wurde. Sogar der Imsai 8080 schafft 19200 Baud. Komisch, dass da beim IBM bei 9600 Baud Ende sein soll…

Gruss Jan

Ich würde auch gern was in dieser Richtung basteln, aber Assembler will ich mir nicht antun und ich wollte eigentlich auf die Parallel-Schnittstelle gehen, weil schneller.

Aber zumindest ist der DOS-Teil dieses Projekts etwas den ich nutzten kann. Sprich den Teil auf dem Modernen Rechner, wäre dann mein Hauptpunkt und dort möchte ich gern das ganze mit Python realisieren...

Aber naja, vermutlich finde ich sowieso nicht die Zeit für den Spaß...

Zitat von Jan1980

Ich beschäftige mich zwischendurch mir Assembler am XT. Im dementsprechenden Register für den COM-Port kann ich maximal 9600 baud einstellen. Vielleicht gibts da ja einen Trick ?!

Im originalen IBM PC war der Intel 8250 drin. Später gab's Derivate von diversen Herstellern, die teils einen gesteigerten Leistungsumfang hatten. So mein Kenntnisstand.

Der 8250 wird von einem externen Takt gespeist, der im Vergleich zu anderen Seriellchips relativ frei wählbar ist. Im Chip ist ein konfigurierbarer Teiler, der bei üblichen anliegenden Takten von 1,8432 bis 8,0MHz 38400Baud und mehr zuläßt. Im National-Datenblatt zum NS16450/8250A finde ich als Grenze 250kBaud.

Gruß, Ralf

Zitat von jedie

Ich würde auch gern was in dieser Richtung basteln, aber Assembler will ich mir nicht antun und ich wollte eigentlich auf die Parallel-Schnittstelle gehen, weil schneller.

Für Parallel gibt es ab 386SX aufwärts ParCP USB. Rein Parallel hat den Nachteil, dass heute kaum noch PCs den Port haben. Das ist bei ParCP-USB geschickt gelöst. Da der Quellcode von ParCP-USB offenliegt, schau dir das mal an, und schaue, ob du es sinnvoll erweitern kannst. Die Idee aus diesem Projekt hier, Remote Disketten-Images auf Scheiben zu schreiben, finde ich genial und man könnte versuchen, sie in ParCP auch einzubauen. Außerdem könnte man sich mal ansehen, ob man ParCP so anpassen kann, dass es auch ohne QEMM (also ab 386SX) zum Laufen zu bekommen ist. Eine Amiga-Version wäre sicher auch nicht uninteressant.

Zitat von jedie

Sprich den Teil auf dem Modernen Rechner, wäre dann mein Hauptpunkt und dort möchte ich gern das ganze mit Python realisieren...

Warum Python? Der Quellcode des Windows-Teils in C liegt vor. Warum alles nochmal neu erfinden. Autor kontaktieren und deine Erweiterungen einbringen! Cool wäre zum Beispiel, wenn man darüber z.B. 22disk und weitere Tools für Fremdformate fernsteuern könnte, um so auch Fremdformate schreiben zu können.

Zitat von 1ST1

Für Parallel gibt es ab 386SX aufwärts ParCP USB. Rein Parallel hat den Nachteil, dass heute kaum noch PCs den Port haben. Das ist bei ParCP-USB geschickt gelöst. Da der Quellcode von ParCP-USB offenliegt, schau dir das mal an, und schaue, ob du es sinnvoll erweitern kannst. Die Idee aus diesem Projekt hier, Remote Disketten-Images auf Scheiben zu schreiben, finde ich genial und man könnte versuchen, sie in ParCP auch einzubauen. Außerdem könnte man sich mal ansehen, ob man ParCP so anpassen kann, dass es auch ohne QEMM (also ab 386SX) zum Laufen zu bekommen ist. Eine Amiga-Version wäre sicher auch nicht uninteressant.

ParCP kenne ich auch, siehe: Datenaustausch XT/286 per Seriellen/Parallel Schnittstelle zu modernen Rechner...

Das ganze auch für <368 zu realisieren, wäre natürlich großartig.

Zitat von 1ST1

Warum Python? Der Quellcode des Windows-Teils in C liegt vor. Warum alles nochmal neu erfinden.

Weil ich gern eine Lösung für Linux hätte und ich C nicht kann und will

Zitat von Jan1980

Cooles Projekt ! Muss ich mal antesten.

Ich beschäftige mich zwischendurch mir Assembler am XT. Im dementsprechenden Register für den COM-Port kann ich maximal 9600 baud einstellen. Vielleicht gibts da ja einen Trick ?!

Der Atari 800 schafft 115200 Baud, genauso wie der Apple 2, was oben bereis erwähnt wurde. Sogar der Imsai 8080 schafft 19200 Baud. Komisch, dass da beim IBM bei 9600 Baud Ende sein soll…

Zitat von RalfK

Im originalen IBM PC war der Intel 8250 drin. Später gab's Derivate von diversen Herstellern, die teils einen gesteigerten Leistungsumfang hatten. So mein Kenntnisstand.

Der 8250 wird von einem externen Takt gespeist, der im Vergleich zu anderen Seriellchips relativ frei wählbar ist. Im Chip ist ein konfigurierbarer Teiler, der bei üblichen anliegenden Takten von 1,8432 bis 8,0MHz 38400Baud und mehr zuläßt. Im National-Datenblatt zum NS16450/8250A finde ich als Grenze 250kBaud.

Ich habe im technischen Handbuch des XT nachgesehen. Darin ist unter anderem folgendes zu finden:

Warum die Datenrate nur max. 9600 Baud betragen darf ist nicht beschrieben.

Wie man sieht, ist der Teiler für 9600 Baud auf 12 eingestellt. Das bedeutet, dass man bis zu 115200 Baud einstellen könnte (Teiler = 1). Möglicherweise gibt es aber dann bei der Abarbeitung des Interrupts zeitliche Probleme. Vermutlich müsste man eigene Routinen schreiben und nicht das BIOS dafür verwenden.

Zitat von PAW

Möglicherweise gibt es aber dann bei der Abarbeitung des Interrupts zeitliche Probleme. Vermutlich müsste man eigene Routinen schreiben und nicht das BIOS dafür verwenden.

Bei der bescheidenen Rechenleistung eines Intel 8088 mit 4,77MHz und der vermutlich nicht gerade optimalen Implementierung der Interrupt-Service-Routinen sind die 9600Baud im Interruptbetrieb bereits ziemlich "sportlich", IMHO. Da allerdings im Falle der blockweisen Übertragung von Image-Dateien eine ganz andere Vorgehensweise vorteilhaft ist, sollte man sich bemühen diese zu nutzen.

Zum Vergleich in der Betriebsart der blockweisen Übertragung nochmal zum Apple II, der ja "nur" ein paar Jahre älter ist: mit dem üblichen 6551 als Seriellchip sind 115kBaud das Maximum, weil der mit seinem Baudratengenerator nicht mehr kann. Läßt man den Chip außerhalb seiner Spec mit dem doppelten Tat laufen, was die meisten mitmachen, AFAIK, dann kommt man mit einem 6502 @1MHz auf 230kBaud. Für mehr braucht man wirklich einen anderen Chip, so z.B. den älteren 6850, der bis 1Mb/sec schaffen kann. Mit einer Beschleunigerkarte (Transwarp @3,58MHz) kann man den 6850 bis 460kBaud betreiben, mit einer DC65 @12,5MHz sind 921kBaud drin. Und jetzt vergleichen wir nochmal die 9,6kBaud in einem Intel-8088-PC. Da muß mehr zu schaffen sein.

Gruß, Ralf

Zitat von RalfK

Bei der bescheidenen Rechenleistung eines Intel 8088 mit 4,77MHz und der vermutlich nicht gerade optimalen Implementierung der Interrupt-Service-Routinen sind die 9600Baud im Interruptbetrieb bereits ziemlich "sportlich"

Nö, Norton-Commander / Laplink schaffen zwischen XTs auch 19200 Baud.

Wenn wir damals XT's für DFÜ verwendet haben, haben wir immer COM-Karten mit dem 16550 FIFO-UART eingesetzt. Damit lief das dann wie geschmiert. Ansonsten gab's Problem mit dem Datentransfer zwischen CPU und UART.

Ich weiß aber nicht mehr genau, welche Baudraten wir bei den XT's standardmäßig verwendet haben. Also aber welcher Geschwindigkeit es mit dem UART ohne FIFO Probleme gab.

Das Problem war wohl der Interrupt. Wenn jedes eingehende Zeichen einen Interrupt auslöst, dann kam die CPU wohl nicht hinterher.

Bei Laplink & Co könnte ich mir vorstellen, dass die immer einen ganzen Block ohne Interrupt gesendet und empfangen haben.

Das sind aber jetzt alles nur Vermutungen.

Zitat von RalfK

Bei der bescheidenen Rechenleistung eines Intel 8088 mit 4,77MHz und der vermutlich nicht gerade optimalen Implementierung der Interrupt-Service-Routinen sind die 9600Baud im Interruptbetrieb bereits ziemlich "sportlich"

Nö, Norton-Commander / Laplink schaffen zwischen XTs mit den normalen 8250 auch 19200 Baud.

Kann man die Baudrate nicht (auch) im BIOS einstellen?

Zitat von Bodhi1969

Kann man die Baudrate nicht (auch) im BIOS einstellen?

XTs haben kein BIOS-Setup.

Zitat von 1ST1

Zitat von Bodhi1969

Kann man die Baudrate nicht (auch) im BIOS einstellen?

XTs haben kein BIOS-Setup.

Oh.

Die Baudrate der RS232-Schnittstelle konnte man nie im BIOS einstellen.

Die Anwendungsprogramme haben sich da grundsätzlich immer selber drum gekümmert. Ausser man hatte einen Fossil-Treiber installiert.

Zitat von detlef

Die Baudrate der RS232-Schnittstelle konnte man nie im BIOS einstellen.

Die Anwendungsprogramme haben sich da grundsätzlich immer selber drum gekümmert. Ausser man hatte einen Fossil-Treiber installiert.

Ok, ich glaube, das irgendwo gelesen zu haben. Kann aber sich aber auch um einen anderern Rechnertyp gehandelt haben. Gelesen hatte ich das mal hier.

Mein erster IBM-Kompatibler war übrigens ein 286er.

Zitat von mgutzeit

Felix (Der Autor) ... Treffe ihn Sonntag.

Schlag ihm mal vor alle Sourcen auf github zu packen. Denke das kann nicht schade, um mehr Sichtbarkeit zu bekommen und erleichtert die Mitarbeit...

Zitat von Toast_r

Im BIOS-Setup einstellbare Baudraten kenne ich eigentlich nur von Servern, die eine serielle Konsole unterstützen.

Ok, dann habe ich wohl etwas falsch verstanden.

Moin,

hier ist der Autor von dem Dingen. Schön, dass mein Programm so viel Gesprächsstoff geliefert hat, aber Markus hatte so etwas ähnliches schon prognostiziert.

Ich versuche mal die diversen Fragen und Vermutungen einzusammeln und zu kommentieren.

Wieso 9600 Baud?

Ich benutze die BIOS-Interrupts und int 14,0 geht nur bis 9600 Baud (https://stanislavs.org/helppc/int_14-0.html).

Wieso BIOS-Interrupts?

Weil die wichtigste Eigenschaft des Initial Loaders die Abtippbarkeit als ALT+nnn ist, und es einen empfindlichen Unterschied bedeutet, ob man 45 Instruktionen oder 200 Instruktionen fehlerfrei abtippen muss.

Geht das nicht auch schneller auf einem XT?

Ganz ehrlich: keine Ahnung! Ich hatte mit "zjlink" etwas ähnliches ca. 10 Jahre zuvor probiert, um Dateien auf einen 286er zu bekommen. Das hatte ich in C geschrieben und das pollt direkt die Register des UARTS. Das lief WIMRE bis 19200 Baud zuverlässig, danach gingen Bytes verloren. Aber in C zu pollen ist bestimmt nicht das Nonplusultra in puncto Geschwindigkeitsoptimierung.

C vs. Python, etc.

Ich habe die Win32-Komponente in C geschrieben, weil das für mich der beste Kompromiss aus a) kann ich und b) läuft überall war. Aus meinem Build-Prozess fällt eine EXE mit 75 KB Größe raus, die in genau der Form unter Steinzeit-Windows und Neuzeit-Windows läuft. Zumindest hatte ich das mal auf Windows 95 und Windows NT 4.0 getrimmt, teste das aber nicht bei jedem Build nach, und manchmal kriechen dann doch Convenience-Funktionen rein, die z.B. erst seit Windows XP verfügbar sind (wie etwa RegGetValue). Aber im Prinzip ist das Toolbox-Protokoll sehr primitiv und kann problemlos mit anderen Client-Programmen in allen erdenklichen Programmiersprachen bedient werden.

Übrigens: meine Releases baue ich unter Linux mit mingw32 und die GUI startet in Wine einwandfrei; wenn der auch COM-Ports ordentlich mappt, dann spricht zumindest nichts dagegen das auch von Linux aus zu benutzen. Mit Wine läuft deutlich mehr als man denkt, vor allem was native Win32-API angeht.

8250/UART/FIFO/Interrupts

Da wäre noch etliches an Grundlagenforschung nötig, und ich wittere Hardware-Abhängigkeiten, Konfigurations-Vielfalt, etc. die ich mir nicht ans Bein binden will. Aber: das Design ist so offen, dass man einfach die Toolbox durch was "stärkeres" ersetzen kann, gerne auch ein ausgewachsenes Programm, das man einmal überträgt und direkt auf dem Target startet, statt jedes mal zu übertragen. Dieses Initial-Loader-Toolbox-Geraffel ist ja quasi der Bootstrap um auf einem fast nackten DOS aufzusetzen; wenn man erst mal Zugang zu dem Gerät hat, kann man ja alles mögliche tun. (Oder halt auch einfach ein LapLink nachladen und dessen Fähigkeiten nutzen -- ich bestehe nicht darauf Das Beste Tool Der Welt zu bauen.)

Die GUI-Komponente kann entweder schon bis Anschlag (1 MBit/s?) oder leicht aufgebohrt werden, ist normales CreateFile, SetCommConfig & Co.

Kann man das BIOS austricksen?

Weiß ich nicht, aber ich könnte mir vorstellen, dass die BIOS-Interrupts ja auch nichts anderes machen als das UART zu bedönern und die Engstelle der int 14,0 ist, mit den 3 Bits für die Baudrate. Vielleicht kann man ja die Baudrate auch hinterrücks im 8250-Register verfummeln und trotzdem int 14,1 und int 14,2 als Frontend benutzen? Wäre mal einen Versuch wert. Da die Toolbox selbst nichts mehr dran fummelt, könnte man auch einfach eine "Zwischen-Toolbox" laden, die nur mit 5 oder 6 Instruktionen das Ding pimpt. Das wäre zumindest ein schneller Test als Proof-of-concept. Vielleicht mache ich das demnächst mal.

Auf GitHub veröffentlichen

Das ist eine andere Geschichte über der ich derzeit brüte. Im Moment fühle ich mich wohl mit meinem Raspberry Pi als Server, und die Welt muss erst mal damit klar kommen, dass mein Code als ZIP- bzw. Tarball auf meiner Webseite liegt. Ich habe im Moment keine Lust für jedes Projekt Einzelentscheidungen zu treffen, ob es für die große weite Welt gedacht ist oder nur für mich, oder wann der Sprung vom lokalen Git auf einen öffentlichen Remote angebracht ist. Aber ich glaube der Teil der Diskussion wird OT.

Gruß,

Felix

Danke fürs Anmelden und den Kommentar zu dem interessanten Tool von dir.

Für den initialen Loader spricht ja nichts dagegen, da bei 9600 zu bleiben, der ist ja klein. Aber wenn dann das Hauptprogramm gestartet wird, kann das ja mal ausprobieren, was auf dem COM-Port so geht...?

Bei einem "normalen" 8250 muss man für jedes empfangene Zeichen einen Interrupt auslösen und das Zeichen sofort abholen - ansonsten wird es durch das nächste ankommende Zeichen überschrieben. Für Baudraten jenseits von 9600 ist ein 4.77MHz-PC einfach zu langsam. Daher kann das BIOS auch keine höheren Baudraten.

19200 kann man mit solchen Rechnern schaffen, wenn man (ohne Interrupt) die Statusregister des UART pollt - Jenseits dieser Baudrate ist bei denen dann aber auch schnell Schluss.

Schnellere Rechner schaffen auch im Polling-Betrieb höhere Baudraten, und spätere UARTs (16550) haben bis zu 16 Bytes Pufferspeicher - damit muss man nicht mehr für jedes ankommende Zeichen einen Interrupt abarbeiten und kann auch mit etwas langsameren Rechnern höhere Baudraten schaffen.

@Zotteljedi, sehr schöne arbeit, Respekt.

Was deinen bootloader angeht, eintippen ist überflüssig, es geht auch wie folgt, ...

Du kannst dein initld.com auch über die serielle Schnittstelle in den Zielrechner laden.
So macht es das DOS Tool Interlink/Intersvr und vermutlich Laplink.
Ich hab das schon mal untersucht, leider finde ich das Zeug gerade nicht.

Voraussetzung:

Dein initld.comenthält kein Ctrl-Z Zeichen 0x1A. (hab ich schon geschaut, passt).

Auf dem Target ist DOS installiert, das bringt die Kommandos MODE und CTTY mit.

Schritte: (ungetestet, aus dem Gedächtnis, aber so ähnlich geht es)

1. Target C:> MODE COM1:9600,n,8,1,p <Enter>

2. Target C:> CTTY COM1

3. Der Client schickt:

COPY COM1 > INTLD.COM <Enter>

<initld.com> File Inhalt binär senden
Ctrl-Z

INTLD.COM <Enter>

Diese Schritte erzeugen das File initld.com auf dem Target und startet es gleich.

Als Schritt 0 könnte die Client Software folgenden Hinweis anzeigen:

Quelle: Interscr.exe (Bestandteil von DOS-6.22),

wenn es mit INTERSVR /COPY aufgerufen wurde.

Der ähnliche Mechanismuss würde auch für CP/M Systeme funktionieren.

Als Plan B, fall das MODE und/oder das CTTY Programm auf dem target nicht existieren ist dann halt abtippen des initld.com Hexcodes.