Archiv der Kategorie: Wissensdatenbank

Das ist die Oberkategorie, um die Systemkategorien der Wissensdatenbank ordnen zu können.

Adapterkabel Sharp MZ800 zu Commodore 1084 Monitor

Hier habe ich die Pinbelegung eines Adapterkabels, mit dem man den 1084 Monitor an den Sharp MZ-800 über die RGB-Buchse anschließen kann. Zumindest bei meinem MZ-800 ist die FBAS-Ausgabe so schlecht, dass der 1084 ein Schwarz-Weiß-Bild zeigt. Über die RGB-Buchse kommt dagegen ein sauberes Farbbild. Und die beiden Buchsen sind gleich, aber VÖLLIG unterschiedlich belegt, ein 1:1 Kabel geht also nicht. Denkt deswegen an die Kennzeichnung, welche Seite wohin gehört.

 

Tastenkappen beim Amstrad NC100 entfernen

Beim Abhebeln der Tastenkappen von der Tastatur eines NC 100 ist eine gewisse Vorsicht nötig. Die Tastenkappen haben nämlich noch einen extra Führungsstift, der beim Verkanten der Tasten (also wenn man nur von einer Seite aus hebelt) leicht abbrechen kann. Der Trick liegt darin, von links UND rechts gleichzeitig zu hebeln. Wenn man dabei noch die beiden Plastikhebel nach innen drückt, kann man die Tastenkappe ohne Kraftaufwand abziehen.

 

 

 

 

 

Über den Tastaturkontakten sind Gummihütchen, die vom Stempel eingedellt werden. Die Rückstellkraft des Gummis reicht aus, die Taste wieder zu heben. Es kann vorkommen, dass sich dieses Gummihütchen verschiebt, so dass der Stempel nicht mehr auf die Spitze, sondern mehr auf den Rand drückt. Deswegen geht die Taste dann auch nicht mehr hoch. Mit dem Schraubenzieher kann man das Hütchen in die richtige Position bringen und dann geht diese Taste wieder.

 

 

Tastatur reinigen/reparieren

Toshi´s Vorgehensweise, klappt auf allen CBM Keyboards (wie C16,C64,VC20,PET oder CBM-II)

  1. Tastatur komplett zerlegen
  2. In Spülmittel / Seifenlauge einweichen, dann Einzelteile mit Zahnbürste reinigen
  3. Unterseite der Kontakstempel (leitfähiger Gummi) mit Glasfaserstift aufrauen, dann mit Wattestäbchen und IPA (2-Propanol, auch als Isopropylalkohol oder Isopropanol bekannt) reinigen/entfetten
  4. Kontakt Chemie Graphit 33, ein Sprühstoß in die Dosen-Kappe, Leitlack mit Wattestäbchen aufnehmen und dünn auf die Kontaktstempel tupfen
  5. Trocknen lassen, ein paar Stunden
  6. Ggf. zweiter Durchgang
  7. mit sauberem Wattestäbchen nachpolieren
  8. Platine reinigen mit IPA
  9. Zusammensetzen und Freude erleben

SGI IRIX Images auf CD-R brennen

Images von SGI IRIX CDROMs sind nicht im ISO 9660 Format. Sie lassen sich aber unter Linux ganz einfach mit dem Befehl

wodim -v dev=/dev/sr0 imagename.img

auf einen CD-R Rohling brennen (wobei /dev/sr0 der Devicename des CD-Brenners ist).

Die CD ist dann unter IRIX problemlos lesbar und man kann auch (bei IRIX CDs) das miniroot bootloaden.

Der Schalter „-raw“ (-raw96r) bei wodim umgeht die TAO/DAO Funktion von CD-Writern (inkl. Puffer) was üblicherweise zu weniger Konfikten mit „besonderen“ Formaten bzw. Firmware führt. Bei vielen CD Writern scheint das aber nicht notwendig zu sein.

Defekte Elkos beim Apple Newton 100 OMP tauschen

Wenn der Apple Newton 100 sich nicht einschalten lässt und auch sonst keinerlei Reaktion zeigt, können defekte Elkos die Ursache sein.

Die Reparatur erfordert Lötgeschick, ist aber ansonsten nicht kompliziert. Im Newton 100 (OMP) sitzen 2 Elkos, die altersbedingt Probleme machen. Es handelt sich um liegende SMD-Elkos, die in einer Art rechteckigen Ummantelung stecken. Der eine sitzt auf der Oberseite der Hauptplatine (= Displayseite) in der Nähe des Kartenschacht-Connectors (C51: 3,3µF, 35V), der andere auf der Unterseite (Batteriefachseite) in der Nähe des Einschalters (100µF, 4V).

Beide Elkos waren bei meinem System ausgelaufen und hatten ihr Elektrolyt großzügig in der Umgebung verteilt. Fast direkt neben dem Elko auf der Unterseite (der mit 100µF) sitzt eine kleine SMD-Sicherung (flink, 1,25A) – die war ebenfalls defekt und hatte keinen Durchgang mehr, was zum Nichtreagieren auf den Einschalter geführt hat.

Die beiden Elkos müssen ausgelötet und nach Säuberung des umliegenden Bereichs vom Elektrolyt durch normale radiale Elkos mit entsprechenden Werten und niedrigem Durchmesser ersetzt werden. Aufgrund der engen Lage der Lötpads passen keine der üblichen SMD-Elkos. Die Elko-Beinchen lssen sich aber zurechtbiegen, was ein komfortables Löten erlaubt. Anschließend ist die SMD-Sicherung durch ein identisches Modell zu ersetzen. Danach sollte das System wieder einwandfrei starten.

Leider scheint das Kondensator-Problem kein Einzelfall zu sein, denn auch bei anderen Geräten waren beide Elkos bereits kräftig am Auslaufen. Ein Austausch und Säuberung des PCB vom Elektrolyt haben auch hier das Einschaltproblem behoben.

von Ralph_Ffm (Vereinsforum)

Apple 8-Bit News Ausgabe April 2016

 

Wieder waren die Liebhaber der Apple II- Modelle nicht untätig. Hier eine Übersicht der Neuheiten:

Hardware

  • Neuer A2DiskContoller
    Ultimate Apple2 stellt einen neuen Disk Controller für 3.5″ Laufwerke am Apple //e for. Er erlaubt es, 800K und 1,44 MB Laufwerke des IIGS auch am //e zu verwenden. Es handelt sich um einen Nachbau der Apple 2.3 Drive Controller Card. Die Karte ist für US-$ 149,99 im Shop von Ultimate Apple erhältlich.

  • Ebenfalls von Ultimate Apple2 sind eine Leerplatine und ein fertig aufgebautes Ersatz-Netzteil für den Apple II, //e und IIGS angekündigt worden.
    siehe http://a2central.com/6953/ultimatemicro-news/

Software

  • Sheldon Simms portiert AT&T UNIX System 6 auf Apple //e

    Sheldon Simms hat in der Newsgroup comp.sys.apple2.programmer mitgeteilt, das er die Arbeit an einer Portierung von UNIX System 6 auf den Apple //e wieder aufgenommen hat. UNIX System 6 war die erste Version von UNIX, die AT&T im Mai 1975 veröffentlicht hat, sie war auf DEC PDP-11 beschränkt. Diese Version ist im Quellcode verfügbar. System 6 ist deutlich kleiner als System 7, das zahlreiche Erweiterungen enthält.

    Es ist geplant, den Kernel, das Filesystem und das vollständige Userland inklusive C, Fortran, dc, nroff usw. zu portieren. System 6 enthält sehr viel PDP-11 Assembler Code, weshalb die Portierung in 65c02 Assembler mittels MERLIN erfolgt. Der C Compiler erzeugt ebenfalls 65×02 Assembler Code.

    Gegenwärtig konnte Sheldon bereits einige Erfolge verbuchen:

    • Der System 6 Filesystem Code wurde bereits fast vollständig in 65c02 Assembler umgeschrieben, ist aber noch nicht einsatzfähig. In der Endfassung wird das Dateisystem nicht ProDOS kompatibel sein.
    • Pass 1 des Original Dennis Ritchie’s 6th Edition C Compilers wurde modifiziert und die PDP-11 Abhängigkeiten entfernt. Dieser Compiler ist lt. Sheldon der einizige, der die alte 6.Version von C implementiert und klein genug für den Apple //e ist.
    • Es wurde ein Kompatibilitätslayer erstellt, der Systemaufrufe auf ProDOS umlenkt und so eine Arbeitsumgebung für das Userland bereitstellt. Dies ist eine Übergangslösung, bis der multitaskingfähige Kernel bereitsteht.
    • Tools wie cp, cat, od, tr wurden implementiert
    • Der UNIX Assembler wurde komplett neu geschrieben, Pass 1 des Assemblers funktioniert bereit.

    Sobald der Assembler funktioniert (was Ende April sein soll), steht die Portierung der Shell und einiger Tools an. Dieser Versionsstand wird für Juni erwartet und soll dann veröffentlicht werden. Anschliessend will Sheldon Simms den Kernel und das Dateisystem vollständig fertigstellen- er rechnet im Herbst mit einer veröffentlichungsfähigen Version.

    Die Apple //e Version von System 6 soll mit 128k lauffähig sein, RAMWorks Karten werden optional unterstützt. Ein 128k System wird aber ausreichend sein, um 4-6 Programme parallel laufen zu lassen. Die Programme sind sehr klein- so benötigt die tr Implementierung etwa 2 kB, ed nur 8 kB und der Pass 1 Assembler gerade mal 14 kB.

    Eine Festplatte ist jedoch obligatorisch für System 6. Zwar werden sich Floppies verwenden lassen, aber aufgrund der IRQ Deaktivierung während des Zugriffs wird dies das Multitasking ausbremsen. Schliesslich soll die Portierung ein vollständiges Multiuser / Multitasking-System darstellen, das alles das kann, was die PDP-11 Version auch konnte. Dies bedeutet allerdings auch, das es keine Netzwerkfunktionen oder UUCP geben wird, da diese erst mit System 7 aufkamen. Einige serielle Karten für externe Terminals sollen aber unterstützt werden.

    Einen ersten Eindruck des Entwicklungsstandes liefert dieser Clip auf Youtube:

    1. https://youtu.be/OdVGZLiiUjw
    2. https://youtu.be/GK2RMh7wpjQ

Bastelprojekt: Apple III ganz ohne Floppy Disk

Dass Apple-Computer etwas teurer sind, ist nicht erst seit gestern so – das war eigentlich schon immer der Fall. Da passt es gut ins Bild, dass die meisten modernen Massenspeicherlösungen für klassische Apples ebenfalls nicht in die Kategorie „preiswert“ fallen. Das gilt ganz besonders dann, wenn der nicht ganz so häufig verkaufte Apple /// den Anschluss an die moderne Welt finden soll.

Ausgangspunkt ist aber auch in diesem Fall das von Rich Dreher für die offenen Systeme Apple II bis //gs entworfene und produzierte CFFA-System (Compact Flash for Apple). Festplattenemulation, zwei virtuelle Diskettenlaufwerke, Kabelfernsteuerung und (vor allem) eine regelmäßige geupdatete Firmware machen diese Erweiterungskarte zu einem „must have“ für Nutzer von Apple-II-Computern. Mit ein bisschen Mühe leistet das CFFA aber auch im Apple /// verlässliche Dienste. Wie gesagt: Mit ein bisschen Arbeit. Denn bis dieses Projekt abgeschlossen war, mussten einige Hürden überwunden werden.

  • Hürde 1: Betrieb des CFFA im Apple /// (als Diskettenlaufwerk)
  • Hürde 2: Betrieb des CFFA im Apple /// (als Festplattenlaufwerk)
  • Hürde 3: Start des Apple /// von einem virtuellen Speichermedium
  • Hürde 4: Weitere Nutzung des integrierten physikalischen Laufwerks
  1. Betrieb des CFFA im Apple /// (als Diskettenlaufwerk)

Bei der Entwicklung des Apple /// haben die Ingenieure seinerzeit einen „demokratischen Kompromiss“ zwischen dem offenen, mit acht Steckplätzen ausgerüsteten Apple II und dem von Steve Jobs geforderten (und später mit dem Macintosh umgesetzten) „geschlossenen System“ ohne Erweiterungsmöglichkeiten gefunden. Will heißen: Der Apple /// verfügt nicht über acht, sondern vier Steckplätze, in denen Apple-II-Karten zumindest theoretisch verbaut werden können. In der Praxis funktionieren nur spezielle für den ///er entwickelte Karten – und das CFFA, allerdings mit einer Einschränkung: Das Gehäuse des Apple /// ist so geformt, dass der integrierte USB-Adapter auf der Karte direkt an der Innenseite des Rechners anschlägt. Das heißt, für die Nutzung kommt nur eine CF-Karte in Frage, denn die wird von oben in das CFFA gesteckt.

Einmal mit CF-Karte ausgerüstet, ist die Installation ein Kinderspiel. Deckel auf, CFFA in einen beliebigen Slot stecken (nehmen wir einfach #1), die DIP-Schalter auf der Karte so umstellen, dass der Apple ///-Modus gewählt ist, CF-Karte mit Software in den passenden Schacht auf der Karte schieben – fertig!

Tja … hört sich einfach an, ist es auch – aber funktioniert leider nur im Apple-II-Modus. Also dann, wenn ich auf die erweiterten Fähigkeiten des Apple /// verzichte und den Rechner wie einen Apple II plus mit 48 K RAM betreibe. Dann kann ich das CFFA ganz normal bei Firmware-Routine (im beschrieben Fall CALL-16080) ansprechen, meine virtuellen Disketten mounten und vom virtuellen Slot #1 starten. Für den Anfang ist das eine Menge, hat aber mit dem „richtigen“ Apple-///-Betrieb nicht viel zu tun.

  1. Betrieb des CFFA im Apple /// (als Festplattenlaufwerk)

Um den Apple /// mit einer virtuellen Festplatten auszurüsten, benötigt man mehrere Dinge.

  • Ein ProDOS-Festplattenimage von maximal 16 MB Größe. Darauf wird später unsere Apple ///-Software kopiert – und 16 MB sind tatsächlich mehr als genug Platz. Die gesamte Softwarelibrary für diesen Rechner würde wahrscheinlich fünf Mal auf ein Image dieser Größe passen. Und woher nehmen: Am besten ein modernes Tool wie Ciderpress nehmen, das Image erzeugen und dann auf die CF-Karte kopieren. Wichtig: Das Image sollte profile.po heißen. Warum das so ist, dazu später mehr.
  • Benötigt wird außerdem ein spezieller Treiber, um die virtuelle Festplatte in das Apple ///-Betriebssystem SOS einzubinden. Den Treiber hat David Schmidt bereits vor einiger Zeit zur Verfügung gestellt – entsprechende Download-Links finden sich auf der Internetseite www.dreher.net . Das Image mit dem Treiber muss per ADTpro auf eine physikalische Diskette kopiert werden. Die Installation erfolgt dann so:
    • SOS von Diskette starten
    • System-Konfigurationsprogramm starten und vorhandene Treiber laden
    • Diskette mit dem CFFA-Treiber einlegen und Treiber laden/hinzufügen
    • Den ersten CFFA-Treiber in der Liste umbenennen in PROFILE
    • Startdiskette wieder einlegen und neue Systemkonfiguration speichern

Prinzipiell ist die Installation damit abgeschlossen und der Apple /// kann nach dem Start von SOS auf die Festplatte zugreifen. Mit Hilfe der System Utilities können zum Beispiel Dateien vom internen Laufwerk (Gerätename: .D1) auf die neue „Festplatte“ (.PROFILE) kopiert werden. Der Nutzwert ist jedoch eingeschränkt, denn im Gegensatz zum Apple II verfügt der Apple /// über keine Möglichkeit, ein Programm zu unterbrechen/zu beenden ohne dass der Rechner einen Soft Reset durchführt. Konkret heißt das: Ein neues Programm starten bzw. von einem Programm in ein anderes wechseln funktioniert nur über einen Neustart des Betriebssystem, also von Diskette. Das war 1981 vielleicht noch akzeptabel, heute ist es einfach nur ärgerlich.

Der Ausweg sind Festplatten-Tools, die bereits in den 1980er Jahren von Drittanbietern entwickelt wurden: Quark Catalyst und Selector ///. Beide ergänzen SOS um eine Art Shell, aus der verschiedene Programme gestartet werden können. Empfehlung wäre hier Selector ///, da dieses Tool im Gegensatz zu Catalyst ohne Kopierschutz auskommt und über eine gut verständliche Anleitung verfügt. Mit etwas probieren gelingt es, den Apple II-Emulationsmodus, BASIC, Pascal sowie Anwendungsprogramme (3EZ Pieces, Draw on three) auf die virtuelle Festplatte zu laden. Da Selector /// ein „altes Programm“ ist, setzt es eine Harddisk mit dem Gerätenamen .PROFILE voraus – das ist der Grund, warum der CFFA-Gerätetreiber umbenannt werden musste.

Zwischenstand damit: Der Apple /// bootet SOS und die Selector ///-Oberfläche von Diskette; danach kann der Rechner komplett im Festplattenbetrieb gefahren werden.

  1. Start des Apple /// von einem virtuellen Speichermedium

Mit dem beschriebenen Verfahren lässt sich der Apple /// bequem im Festplattenbetrieb nutzen. Das Ziel war jedoch, vollständig auf physikalische Disketten zu verzichten. Um das zu erreichen, wird ein zweites Bauteil benötigt, und zwar das von Plamen Vaysilov entwickelte SDFloppy II (www.a2heaven.com). Ursprünglich als preisgünstiges SD-Kartenlaufwerk für die Apple-II-Serie entwickelt, kann es auch Apple ///-Images verarbeiten, denn auch bei diesen wird das bekannte DSK-Format mit 143 K Kapazität genutzt.

Erster Schritt ist also, ein Image der SOS und Selector ///-Startdiskette zu erzeugen – am einfachsten auf einem typischen Apple II. Dieser kann die Diskette des „großen Bruders“ zwar nicht verarbeiten, wohl aber lesen und mit Hilfe der (kurzzeitig umgesteckten) CFFA-Karte in ein Image verwandeln. Dies wiederum wird auf das SD-Floppy kopiert, das auf dem Apple /// nun die Rolle des eingebauten Laufwerks .D1 übernehmen soll.

Ein Problem gibt es dabei zu überwinden: Auf dem Apple II wird ein 20-adriges Flachbandkabel nebst dazugehörigem Stecker genutzt, das interne Laufwerk des Apple /// ist dagegen 30-adrig. Glücklicherweise werden die „hinteren“ zehn Adern nicht genutzt, so dass ein Adapterkabel schnell gebastelt ist. Einfach das eine Ende abschneiden, zehn Adern vorsichtig mit einer scharfen Klinge abspalten und die verbleibenden 20 mit einem passenden Klemmstecker versehen. Achtung: Unbedingt auf die richtige Polarität achten – zu erkennen an der roten Markierung des Flachbandkabels.

Zum Schluss nur noch SDFloppy und Apple /// mit dem (sicherheitshalber noch einmal geprüften) Kabel verbinden. Dazu wird der Apple /// umgedreht, aufgeschraubt und der Diskettenstecker auf der Hauptplatine abgezogen. Das 30-adrige Kabelende kommt (logischerweise) in den Rechner, das Ende mit dem 20-poligen Stecker schließt das virtuelle Laufwerk an. Nun kann der Apple /// vollständig „virtuell“ gestartet werden.

  1. Weitere Nutzung des integrierten physikalischen Laufwerks

In der bisher beschriebenen Konfiguration verfügt der Apple /// über keine Möglichkeit mehr, physikalische Disketten zu lesen. Im Gegensatz zum Apple II, der problemlos auf diese Weise betrieben werden kann, benötigt der Apple /// in einigen Fällen jedoch den Zugriff auf ein „richtiges Diskettenlaufwerk“ – vor allem dann, wenn eines der wenigen Spiele für diesen Rechner geladen werden soll.

Die Lösung für diese Problem ist vergleichsweis einfach: Das Flachbandkabel des integrierten Laufwerks ist lang genug, um an der Innenseite des Gehäuse nach außen geführt zu werden. Dort befindet sich der Anschluss für das externe zweite Diskettenlaufwerk .D2, als das unsere eingebaute Floppy nun angesprochen werden kann. Sollte der Apple /// also doch einmal nach einer „richtigen“ Diskette verlangen – einfach die SD-Karte aus dem SD-Floppy II entfernen. Der Rechner „sucht“ sich dann nächste vorhandene Laufwerk und startet in diesem Fall von .D2 – also von dem Port, an dem nun unser altes .D1 angeschlossen ist.

Fazit: Mit etwas Mühe und ein wenig Fingerspitzengefühl lässt sich auch ein Apple /// komplett ohne physikalische Speichermedien betreiben. Der Aufwand lohnt sich, denn mit der Doppellösung aus CFFA und SDFloppy II kann dieser 8-Bit-Dinosaurier genauso komfortabel wie die Rechner der Apple-II-Serie betrieben werden.

AMIGA Diskettenformat

Wieso hat der AMIGA 880kBytes grosse Disketten, der Atari ST aber nur 720KBytes?

Der Amiga schreibt und liest sein Old und Fast File System genau wie ST, PC und viele weitere Systeme in MFM. Siehe Wikipedia-Artikel

Da der Amiga aber keinen Hardware-Floppycontroller hat (z.B. ein NEC uPD 765 wie in PCs oder dem WD1772 im ST), der diese Codierung durchführt, sondern sich da auf die frei programmierbare Paula verlässt, kann er auch GCR lesen und schreiben, wozu das allerdings genutzt wird/wurde, erschließt sich mir nicht auf Anhieb. Vielleicht wollte man damit erreichen, dass der Amiga Disketten der CBM- und VC- 8-Bit-Floppys oder gar des Apple Macintosh lesen kann, für Shapeshifter sicher ein nettes Feature. Oder es wurde als Kopierschutz missbraucht. Jetzt hab ich doch eine wichtige Begründung gefunden!

Der Unterschied 720 kB (PC/ST) und 880 kB (Amiga) kommt schlicht aus der Anzahl Sektoren, die der Amiga schreibt und liest. PC/ST nutzen standardmäßig 9 Sektoren (80 Spuren, 2 Seiten, 9 Sektoren, 512 Bytes), beim Amiga sind es 11 Sektoren, in denen er dann 880 kB unterbekommt. Alten ATARI ST Hasen wie mir klingeln da natürlich gleich die Glocken, denn 11 Sektoren können „wir“ auch, und wir kommen damit auch auf etwas mehr als 880 kB (916960 Bytes abzüglich etwa 10 kB für FAT, Bootsektor, Root-Verzeichnis und andere reservierte Sektoren).

Der Unterschied zwischen ST und Amiga ist da also nicht sonderlich groß. Das Standard-720kB-Format ist nur auf Sicherheit getrimmt: Ein Sektor besteht ja nicht nur aus den 512 Bytes, die man da speichern kann, sondern da kommt ja Brutto noch was drauf: Lückenbytes, Syncbytes, Sektornummerierung, Checksummen, noch mehr Syncs, und vieles mehr. Diese Lückenbytes sind wichtig, den die braucht der Controller oder Computer um sich seelisch/moralisch drauf vorzubereiten, dass da jetzt was wichtiges (nämlich ein Sync auf den nächsten Datensektor) vorbei kommt. Und die Syncbytes melden ihm, dass es jetzt tasächlich los geht bzw. schon wieder vorbei ist. Und da geht das 720kB-Format eben auf Nummer sicher und ist sehr großzügig, dass auch selbst die lahmste Kiste sich noch darauf einstellen kann, dass da demnächst eine Syncmarkierung kommt.

Diese „hochformatierten“ Disks setzen genau hier an: Die Lücken und Syncs werden verkürzt, wodurch noch zusätzlicher Platz für bis zu weitere 2 Sektoren entsteht. Der WD1172 im ST ist da so tolerant, dass er bei gleicher Datenrate mit verkürzten Lücken und Syncs 11 Sektoren schaft, ein uPD765 (im PC) schafft maximal 10 – warum man ST-Disks mit 11 Sektoren im PC weder lesen, noch imagen kann. Ich kann mich noch genau erinnern, zunächst wurde man als ST-User mit 10 Sektoren von findigen Programmierern überrascht, und dann gingen mit richtigem „Timing“ sogar 11 Sektoren zuverlässig. Das ist auch mit ein Grund, warum PC-Floppycontroller keine Amiga-Disketten (mit 11 Sektoren) lesen können. Der andere Grund schließt dann auch den ST aus, denn der WD1772 und der uPD765 erwarten ein ganz bestimmtes Format für diese Syncmarkierungen, Lückenbytes, sprich wie so ein Sektor-header und Abschluss aufgebaut ist. Nur der Amiga macht das anders, nutzt andere Syncmarkierungen, andere Lückenbytes, die Checksumme wird anders berechnet, Little/Big-Endian, usw. Der Amiga war eben von vorneherein nicht de Bohne auf „Kompatibel“ ausgelegt, während der ST sich sogar auf BIOS/XBIOS/GEMDOS-Ebene dem MS-DOS (und CP/M) anbiederte (damit GEM leicht zu portieren war).

Beitrag von 1ST1 aus dem Forum