Quasi-MMU im 68000er ST

[goetz @ 3rz]

Hallo,

Landon Dyer schreibt in seinem Blog über eine Möglichkeit im MegaST, eine „MMU für Arme“ dort nutzen zu können, für UNIX/unixoide Umgebungen. Ich dachte, wir hätten es hier schonmal davon gehabt, finde aber nichts.

Wenn nicht: Ist dem so, kann der MegaST das – weiß das jemand? Und weiß jemand, ob das ein System auch nutzt (sowas wie Beckemeyer, oder OS-9, oder IDRIS, oder …)?

[1ST1]

Diese MMU war nicht für den Mega-ST, sondern für den E(-)ST. Siehe http://www.atarimuseum.com/computers/16bits/est/mmu.txt

[czietz]

Und vom E-ST gab's (wenn überhaupt?) nur Prototypen, sodass es vermutlich kein OS gegeben haben wird, dass diese "MMU" genutzt hat.

[1ST1]

Genau das schreibt Landon Dyer in seinem Text. OS-Support gab es noch nicht. Und wenn doch, wäre es, wie dort zu lesen stand, wohl ein Unix geworden, und damit wäre TOS tot gewesen. Ob das gut oder schlecht gewesen wäre, mag jeder selbst entscheiden. Was mich dabei wundert, der E-ST hatte den 68020 und dafür gab es von Motorola die MC68851 MMU. Wozu dann noch die Atari-MMU?

[mfro]

Das, was im verlinkten Text beschrieben wird, ist keine MMU. Und ich glaube auch nicht, dass das bei der ST-Gemeinde besonders gut angekommen wäre.

Ich würde das eher "Verkrüppelung" nennen; m.E. macht es aus dem schön linearen Adressraum des m68k einen "verbogenen", segmentierten (die beschriebene "MMU" macht was ganz ähnliches wie die Segmentregister im 80286 protected mode). Es hätte also pro Prozess einen deutlich eingeschränkten Speicherbereich bedeutet.

Zusätzlich wäre kein altes Programm mehr lauffähig gewesen, weil alle "ernsthaften" Stackzugriffe erst mit einem "harmlosen" ("throwaway") Befehl hätten prüfen müssen, ob sie aus ihrem Adressraum herauslaufen oder nicht.

Alles in allem eine ziemliche Schnapsidee, so wie ich das verstehe.

[1ST1]

Einer der Gründe, warum das mit dem E-ST nichts wurde?

[mfro]

Einer der Gründe, warum das mit dem E-ST nichts wurde?

Der Hauptgrund, dass diese seltsame "MMU" nicht realisiert wurde dürfte wohl sein, dass sich die mangelhaften Virtualisierungsfähigkeiten des 68000ers mit der Verfügbarkeit des 68010 erledigt haben. Den haben dann selbst die Workstationhersteller verwendet, die vorher um die Misslichkeiten des 68000ers "herumgebastelt" haben.
Von Apollo Domain (ist die Namensgleichheit  Absicht?) beispielsweise gab's eine Workstation, die zwei 68000er verwendet hat. Eine davon war mit nichts anderem beschäftigt, als der anderen aus einem Page Fault zu helfen, wenn der auftrat.

[goetz @ 3rz]

Der Hauptgrund, dass diese seltsame "MMU" nicht realisiert wurde dürfte wohl sein, dass sich die mangelhaften Virtualisierungsfähigkeiten des 68000ers mit der Verfügbarkeit des 68010 erledigt haben.

Zur Entwicklungszeit des ST und erst recht beim E-ST gab es den 68010 aber schon, der kam 1983 raus. Trotzdem setzte man zuerst auf den 68000.

[goetz @ 3rz]

Genau das schreibt Landon Dyer in seinem Text. OS-Support gab es noch nicht. Und wenn doch, wäre es, wie dort zu lesen stand, wohl ein Unix geworden, und damit wäre TOS tot gewesen. Ob das gut oder schlecht gewesen wäre, mag jeder selbst entscheiden. Was mich dabei wundert, der E-ST hatte den 68020 und dafür gab es von Motorola die MC68851 MMU. Wozu dann noch die Atari-MMU?

Die 68851 MMU macht wohl Strafzyklen rein, wenn eine Adresse getroffen wird, die von der MMU abgefrühstückt werden muss. Damit hat man unterschiedliches Laufzeitverhalten für den selben Code, und das System kommt halt effektiv mit einem zusätzlichen Waitstate daher.

[goetz @ 3rz]

Einer der Gründe, warum das mit dem E-ST nichts wurde?

Eher, dass der E-ST nur API-kompatibel zum ST war, aber wohl so gar nicht hardwarekompatibel. Der TT kommt dem ST schon deutlich näher, aber das treibt halt auch die Fertigungskosten in die Höhe. Und 1988 war halt viele Software noch Schweinesoftware, die wild im Speicher rumschrieb, oder kühne Annahmen über Interna als selbstverständlich ansah.

[mfro]

... Und 1988 war halt viele Software noch Schweinesoftware, die wild im Speicher rumschrieb, oder kühne Annahmen über Interna als selbstverständlich ansah...

Das hat sich bis heute nicht geändert. Aktuelles Beispiel: schau' mal auf die "Issues" Seite von EmuTOS auf github. Da wird von solch einem Dickkopf gerade genau diese Art von Software als die einzig richtige gefeiert ...

[goetz @ 3rz]

... Und 1988 war halt viele Software noch Schweinesoftware, die wild im Speicher rumschrieb, oder kühne Annahmen über Interna als selbstverständlich ansah...

Das hat sich bis heute nicht geändert. Aktuelles Beispiel: schau' mal auf die "Issues" Seite von EmuTOS auf github. Da wird von solch einem Dickkopf gerade genau diese Art von Software als die einzig richtige gefeiert ...

Ich weiß, ich diskutiere mit einem davon auf dem Forum von exxos … (und bin Vertreter der "saubere Nutzung der API-Fraktion").

[goetz @ 3rz]

... Und 1988 war halt viele Software noch Schweinesoftware, die wild im Speicher rumschrieb, oder kühne Annahmen über Interna als selbstverständlich ansah...

Das hat sich bis heute nicht geändert.

Nun kam aber ab 1989 wirklich eine Menge relativ sauberer Software, gerade aber nicht nur auf dem deutschen Markt, heraus. Ab Autoswitch Overscan nahm die Software so langsam nicht mehr automatisch an, dass 640x400 in Stein gemeißelt sind, mit dem TT starb das "lass uns die oberen 8 Bit einer Adresse für lustige Status-Bits mißbrauchen",  "wenn die Auflösung größer gleich 640x400 ist, dann gibt es keine Farbe" und "aller Speicher gehört mir" ging mit MultiGEM und Mag!X 1.0 dahin.

Klar gibt es immer noch Ausnahmen, aber die üblichen großen Vertreter Script, That’s Write, Signum, Papyrus, Tempus Word, K-Spread, Texel, Adimens, Phoenix, Didot, X-Act etc.pp. liest man bei der EmuTOS "Problemliste" nun ja gerade nicht.

Und die meiste dieser Software würde auch auf dem EST laufen. Aber halt erst 1992 aufwärts, nicht schon 1988 …

[goetz @ 3rz]

Diese MMU war nicht für den Mega-ST, sondern für den E(-)ST. Siehe http://www.atarimuseum.com/computers/16bits/est/mmu.txt

Danke für den Hinweis, habe das mal Landon geschrieben.

[mfro]

Ich weiß, ich diskutiere mit einem davon auf dem Forum von exxos … (und bin Vertreter der "saubere Nutzung der API-Fraktion").

Das ist nicht "einer davon", das ist genau derselbe.

[1ST1]

Ich weiß, ich diskutiere mit einem davon auf dem Forum von exxos … (und bin Vertreter der "saubere Nutzung der API-Fraktion").

Und ich bin erstaunt, ausgerechnet einer meiner Programmier-Helden...?

[goetz @ 3rz]

Ich weiß, ich diskutiere mit einem davon auf dem Forum von exxos … (und bin Vertreter der "saubere Nutzung der API-Fraktion").

Und ich bin erstaunt, ausgerechnet einer meiner Programmier-Helden...?

Ob man so oder so programmiert ist nicht eine Frage des Können, sondern der Weltanschauung. Die Diskussion ist so alt wie ... Glühbirnen? Felsen?

Ich höre das jedenfalls schon seit etwa 1987. „Sauber“ vs „kreativ“ oder „innovativ“. Die sauberen halten die anderen für nicht vorausschauend, die kreativen halten die anderen für eingeengt oder langweilig. Oder so.

* gh-baden ist ein Freund des sauberen Stils - AHIG, Geiss&Geiss, Atarium ...

[1ST1]

Ich kene die Diskussion, als Nutzer von AutoSwitch Overscan war ich sofort betroffen.