Turbo Pascal 3.01 (MS-DOS Version)
128 KB
MS-DOS 2.11
HP 110 Portable, HP Portable Plus
HP 150
(die HP Rechner verstehen Terminal Escape Sequenzen zur Cursor Positionierung etc.)
Turbo Pascal 3.01 (MS-DOS Version)
MS-DOS 2.11
läuft nicht auf der P3!
Sicher, daß TP keine "IBM HW Funktionen" nutzt?
Auf welcher Maschine/RAM hast Du das geprüft?
Da muß man dann auch noch nach der DOS-Version unterscheiden, die erforderlich ist.
Für die originale 8088-Karte für den CBM-II gibt es z.B. lediglich MS-DOS 1.25.
Größtes Manko dabei: Unterverzichnisse gibt es erst ab MS-DOS 2.
Die DOS-Version von Move-IT läuft auf nicht PC-kompatiblen MS-DOS Versionen.
Das ist ein Programm zur Verbindung zweier Rechner über die serielle Schnittstelle (direkt oder über Modem) für Kommunikation und Dateitransfer.
Man merkt dem Programm deutlich seinen CP/M ursprung an:
Die Hardwareanpassung für die serielle Schnittstelle muß der Benutzer selbst auf Assemblerebene vornehmen, wenn für den verwendeten Rechner noch keine passende Konfiguration vorhanden ist.
Übertragende Dateien werden auf die nächsten vollen 128 Bytes aufgefüllt.
Es stammt noch aus der DOS 1 Zeit, kann also auch nicht mit Unterverzeichnissen umgehen, und arbeitet nur in dem Verzeichnis, aus dem es aufgerufen wurde.
Ich kenne davon außerdem Versionen für CP/M 80 und CP/M 86.
Turbo Pascal:
Es gibt eine PC-DOS und eine MS-DOS Version.
Die MS-DOS Version ist generisch und kann mit Escape-Sequenzen konfiguriert werden.
Die PC-DOS Version ist für den IBM-PC mit PC-DOS und nutzt z.B. INT10h.
See Archive.org und Vetusware
Grundsätzlich laufen natürlich auch praktisch alle Kommandozeilen Compiler, z.B. Turbo C 2,.01 (MS-DOS 2.11).
Bei den GUI Programmen gab es anfangs viele, die von CP/M portiert wurden und damit auch auf generischen Rechnern liefen (Turbo Pascal eben), bevor dann alle Hersteller direkt auf die Hardware zugriffen.
Wordstar kam z.B. mit dem WSINSTALL, Turbo Pascal mit dem TINST Programm, mit dem man Terminal-spezifische Escape-Sequenzen programmieren konnte. Das setzt voraus, dass das System ein Minimum an Terminal-Fähigkeiten hat, wenn eine Alphatronic da nichts bietet, kann man all diese GUI Programme, deren Ausgabe auf Escape-Sequenzen basiert, auch nicht verwenden. Es sei denn, man schreibt einen Gerätetreiber wie ANSI.SYS dafür. Das sollte nicht so schwer sein.
Wir hatten damals dBase 2.x und ein Wordstar 3.x für MS-DOS.
Wir hatten damals dBase 2.x und ein Wordstar 3.x für MS-DOS.
Weißt Du welche Maschine/DOS Version?
Ist das Sinnvoll, sowas in einem normalen Forumsthread zu sammeln, der nach einiger Zeit untergeht und kaum auffindbar ist?
Ich bin ja der Meinung wir sollten ein Wiki haben, in dem alle Vereinsmitglieder direkt mit arbeiten können, ohne sich vorher zu melden...
Ist das Sinnvoll, sowas in einem normalen Forumsthread zu sammeln, der nach einiger Zeit untergeht und kaum auffindbar ist?
Ich bin ja der Meinung wir sollten ein Wiki haben, in dem alle Vereinsmitglieder direkt mit arbeiten können, ohne sich vorher zu melden...
Als ersten Schritt mach ich mal die Tabelle als Ergebnis aus diesem Thread und den Thread kann ich sticky machen.
Wiki ist nett, bist Du der Freiwillige, der das aufsetzt und sich kümmert 
?
Wir hatten damals dBase 2.x und ein Wordstar 3.x für MS-DOS.
Weißt Du welche Maschine/DOS Version?
Wie das oben schon erwähnte Turbo Pascal für MS-DOS, waren diese Versionen maschinenunabhängig und die Bildschirm- und Tastatur-Codes wurden konfiguriert. Also so wie unter CP/M. So habe ich das jedenfalls in Erinnerung. An die MS-DOS Version kann ich mich leider gar nicht mehr erinnern.
Wir hatten die Programme zum Beispiel auf Victor Sirius und auf Sharp MZ-6500 laufen.
Vermutlich waren diese Progamme fast 1:1 identisch zu dem CPM/86-Version.
dBASE verwendet Bildschirmmasken in denen der Cursor positioniert werden kann.
Auch inverse Zeichen-Darstellung wird genutzt.
Die frühen Versionen von dBASE (sowohl für CP/M als auch für MS-DOS) verwenden dazu Escape-Sequenzen.
Spätere Versionen benutzen dann das BIOS oder greifen direkt auf den Videospeicher zu.
Diese sind dann nicht mehr auf generischen MS-DOS Systemen lauffähig, sondern nur noch auf kompatiblen PCs.
Das dBASE II v2.41 für MS-DOS Installationsprogram bietet folgende Terminal-Typen an:
- ADDS VIEWPOINT 0123
- ADM 31
- ADM 3A
- CANON AS100
- COLUMBIA 1600
- COMPAQ
- CROMEMCO 3102
- EAGLE 1600
- GRID COMPASS
- HAZELTINE 1500
- HEATH 89
- HP 2621
- IBM DISPLAY WRITER
- IBM PC
- NEC 5200
- PERKIN ELMER
- SOROC
- TELEVIDEO
- TI PROFESSIONAL
- TOSHIBA T300
- VISUAL 100
- VT - 52
- VT - 52 ENHANCED
- WANG PC
- XEROX 820 - II
- ZENITH Z100
- ANSI STANDARD
- DEC RAINBOW
- VICTOR 9000
- APRICOT
- VIC-AP
- SIRIUS
- ANDY (was ist denn das?)
Eigene Definitionen, wie bei Wordstar oder Turbo-Pascal 3.0 sind nicht vorgesehen.
Die Handvoll Escape-Sequenzen für das HP 2621 Terminal an Offset 0x23B0 in INSTALL.DAT sollte auch für andere HP Geräte, wie den HP 150 oder 110 passen.
ESC H home cursor
ESC J clear display from cursor to to end
ESC P delete character
ESC &a000y000C cursor addressing row,col
ESC &a23y1C cursor to status line
ESC &dB enhancement inverse video
ESC &d@ end enhancement
Ansonsten kann man ja patchen und testen.
Vielleicht gibt es in dBASE Büchern oder Zeitschriften weitere Patch-Anleitungen, wie sie z.B. für Wordstar existieren.
Die frühen Versionen von dBASE (sowohl für CP/M als auch für MS-DOS) verwenden dazu Escape-Sequenzen.
Spätere Versionen benutzen dann das BIOS oder greifen direkt auf den Videospeicher zu.
Ich kann mich noch gut an die erste Wordstar-Version (3.3 oder 3.4) für IBM-Kompatible erinnern. Die lief auf meinem PC10 gefühlt 10x so schnell wie die ansonsten identische MS-DOS-Version für Nicht-Kompatible.
Deswegen haben die IBM-Kompatiblen den anderen Rechner ja so schnell das Wasser abgegraben. Wegen der standardisierten Hardware-Plattform gab es sehr schnell speziell angepasste Programme, die viel schneller liefen.
Da soll mir einer erzählen, Standards würden den Fortschritt bremsen. Ohne die IBM-Kompatiblen würde wir vermutlich heute noch bei jeder Programminstallation ESC-Sequenzen konfigurieren. 
Wie man's nimmt.
Natürlich ist es gut, daß sich ein Standard durchgesetzt hat.
Allerdings ist es schade, daß es ausgerechnet so eine vermurkste Kiste war, die sich da durchgesetzt hat.
Ich finde, gerade die "nicht 100% kompatiblen" haben Besonderheiten/Eigenarten, die sie Erhaltens/sammlungswürdig machen.
Auf jeden Fall. Da gab es ganz spannende Techniken, wie z. B. die Diskettenlaufwerke des Victor Sirius mit variabler Drehzahl.
Allerdings ist es schade, daß es ausgerechnet so eine vermurkste Kiste war, die sich da durchgesetzt hat.
Gabs damals unvermurkste Kisten? Der Amiga hat zwar vieles eleganter/besser gelöst, hat aber auch viele Leichen im Keller bzw im OS und der Architektur.
Mit dem ST kenne ich mich zu wenig aus das bewerten zu können.
Die CBM Serie war vmtl. auch eine Sackgasse (wegen der 8 bit....)
Was gabs sonst noch mit Potential Anfang der 80er?
Wie man's nimmt.
Natürlich ist es gut, daß sich ein Standard durchgesetzt hat.
Allerdings ist es schade, daß es ausgerechnet so eine vermurkste Kiste war, die sich da durchgesetzt hat.
Wenn IBM vorher gewusst hätte, dass das mal ein Standard wird, dann hätten sie sich vielleicht etwas mehr Mühe gegeben. 
Wenn IBM vorher gewusst hätte, dass das mal ein Standard wird, dann hätten sie sich vielleicht etwas mehr Mühe gegeben.
Wenn IBM gewußt hätte, wie viele PCs sie im Jahr 1990, 2000, 2020 verkaufen, hätten sie es vielleicht ganz gelassen.
at Toshi:
Welche Version von Turbo C läuft auf "nicht-kompatiblen" Rechnern?
at Toshi:
Welche Version von Turbo C läuft auf "nicht-kompatiblen" Rechnern?
keine Ahnung, mußt Du Martin Hepperle fragen, der hat das ins Spiel gebracht, siehe oben
nö, Posting #1 und #2 sind von Toshi
nö, Posting #1 und #2 sind von Toshi
Du kannst mir glauben, ich weiß, was ich in welcher Reihenfolge geschrieben habe.
Damit will ich doch nur sagen, daß die Angabe daß Turbo C auf alten nicht-kompat. Maschinen "offensichtlich" von Ihnen stammt. Zum Zeitpunkt von posting #2 hat noch niemand anderer gepostet - und posting #2 ist lt. den Angaben der Forumssoftware nicht nachträglich editiert worden. Also ist mir nicht ersichtlich, wieso diese Angabe nicht von Ihnen stammen sollte.
Toshi hat hier im Forum Superkräfte und kann Postings nachträglich editieren. Daher spiegelt die angezeigte Reihenfolge nicht die zeitlich Reihenfolge der Inhalt wieder.
Oh, das klärt das Mißverständnis.
Dann möchte ich der Liste hinzufügen: dBase II 2.41 läuft ebenso auf dem NCR DMV (Erscheinungsjahr 1982/83), ebenso WordStar 3
Die Lauffähigkeit von "neueren" Programmen (ab ca 1985) auf diesen alten Maschinen hängt, wie hier eh jeder weiß, hauptsächlich mit 3 Dingen zusammen:
- dem Versuch der Programme direkt in den Videospeicher zu schreiben
- dem direkten Zugriff auf Portadressen oder bestimmte Werte des BIOS an Adressen, wie sie auf IBM Computern normal sind
- der Verwendung der Funktionen des Video-Interrupts 10H
- der Verwendung des Keyboard-Interrupts 16H
Wenn es nur die letzten beiden Punkte sind, ist Abhilfe möglich. Selber Programmieren ist dann aber angesagt.
Für den DMV kann ich sagen, daß die Bereitstellung selbst programmierter Video/Keyboard Interruptroutinen einiges ermöglicht.
So läuft dadurch auf dem NCR DMV (mit NEC yPD7220 Grafikprozessor und nicht ibm-kompatibler Tastatur) zB WordStar 4, TurboPascal 3.02A (PC-DOS Version), Tools von TurboPower für TP3, oder auch Zorlite C 2.1.
NCR DMV (mit NEC yPD7220 Grafikprozessor und nicht ibm-kompatibler Tastatur)
Ist der mit dem japanischen PC98 Standard kompatibel?
wieso diese Angabe nicht von Ihnen stammen sollte.
Ich habe in der Tabelle gleich oben versucht zusammenzufassen, was der Thread an Infos liefert, so daß man es schneller finden kann.... und das habe ich auch vor, fortzusetzen.
Lattice C Ver. 2.12 läuft auf einer Nixdorf PWS-D mit 80186.
... bei Turbo-C läuft leider nur der Kommandozeilen-Compiler TCC, also nicht die IDE.
Im Grunde laufen ja praktisch alle Kommandozeilen-Compiler auf den generischen MS-DOS Rechnern, Lattice C und später Microsoft C auch.
Zu den Escape-Sequenz-Geschichten muss man aber auch sagen, dass das eigentlich sehr schön war, da das ja auch schon netzwerkfähig war. Unschön war und ist nur. dass es zig Terminals mit zig Sequenzen und keinen eindeutigen Standard gab (später dann ANSI).
Im Grunde ist X-Windows unter Linux ja auch nichts anderes - bestimmte Bytesequenzen werden über's Netzwerk geschickt und dann vom Treiber ausgewertet, mit Text und Grafik.
Auf dem IBM PC gibt es auch den Treiber ANSI.SYS, der da vermittelt zwischen der Escape-Sequenz-Welt und dem BIOS.
Im Grunde kann man so auch für jeden MS-DOS Kompatiblen einen ANSI.SYS Treiber schreiben/anpassen, der dann auf die jeweilige Video-Hardware übersetzt.
Martin
