EmuTOS mit "BusyBee"

[mfro]

... Wenn nicht die gesamte Hardware der Maschine unetrstützt wird, dann unterstütz es diese Maschine nicht...

Der Meinung kann man natürlich sein.

Konsequenterweise unterstützt dann aber auch TOS3.06 den TT nicht und TOS4.04 nicht den Falcon ...

[1ST1]

Wieso? TOS 3.06 unterstützt alle Hardwaredes TT, und TOS 4.04 alle Hardware des Falcon. Zumindestens wird sie brauchbar (nicht immer optimal, siehe Initiator-ID bei SCSI, siehe was HDSMODEM macht) initiialisiert. Aber wenn schon das Booten von einer SCSI-Platte, die das Gerät in seiner Grundstruktur auszeichnet, nicht klappt, dann ist das unbrauchbar.

Das Knowhow, SCSI-Boot in EmuTOS reinzubringen ist bei einigen hier sicher da. Und man könnte es besser machen als Atari, z.B. könnte man NVRAM gesteuert eine initiator-ID und Parity ein und ausschalten. Vielleicht mal Herrn Seimet fragen, ob er Lust hat, das in EmuTOS zu implementieren?

[mfro]

Wieso? TOS 3.06 unterstützt alle Hardwaredes TT, und TOS 4.04 alle Hardware des Falcon.

Nö.

Sowohl mein Falcon als auch mein TT wurden beispielsweise mit einem LAN Port ausgeliefert, der von Atari auch beworben wurde.

RS422 Softwareunterstützung? Nope. Nullkommanull.

Mit dem SCC (dem Atari sogar eine eigene DMA-Engine zur Seite gestellt hat) hätte man per SDLC + DMA und einem passenden Token-Ring Protokoll mit 2 MBit/s Daten übertragen können. Also während der letzten 25 Jahre etwa 150 TB .

Das hat mich persönlich jedenfalls jahrelang fuchsig gemacht (aber anscheinend sonst niemanden gestört). Heute könnte ich (wenn ich es noch haben wollte) das Zeug einfach in EmuTOS einbauen ...

[1ST1]

Ok, diese Ausnahme gibt es. Netzwerk war damals aber nicht als essentiell wichtig angesehen worden und kann auch per Software nachgerüstet werden. Und heute gibts andere Lösungen wie diese proprietäre Schnittstelle, die man z.B. an PCs nicht findet, also letztendlich mit sehr begrenztem Nutzen. Ein Bootlaufwerk aber lässt sich durch nachträgliche Software nicht einbinden. Soweit ich mich erinnere gabs bei dem LAN Port auch noch ein rechtliches Problem, denn dieser LAN Port ist hardwareseitig identisch mit Apple Local Talk. Man konnte/wollte die Konkurrenz nicht unnötig aufscheuchen. Möglich ist auch, dass als die LAN-Hardware im TT, M-STE und Falcon schon fertig war, dass sich zeitglich Ethernet (BNC, RJ45) durchsetzte und das miteinander nicht kompatibel ist und man deswegen für diese Schnittstelle die Prio weg genommen hat - sollen doch andere was damit machen... Und es gibt ja doch ein bischen Software, die damit umgehen kann, Cubase zum Beispiel, die neueste Beta von Midicom auch, letzteres wollte ich mal ausprobieren, habe aber noch nicht intensiv nach passenden Steckern gesucht, habe aber auch noch nicht rausgefunden, wie das Kabel richtig terminiert werden muss. https://de.wikipedia.org/wiki/EIA-422

[mfro]

... Ein Bootlaufwerk aber lässt sich durch nachträgliche Software nicht einbinden...

Das steckt man - bis EmuTOS auch SCSI kann - einfach an den ACSI-Bus. Oder geht gleich zu IDE über.

Außer, man hat eh' kein Interesse an EmuTOS und sucht nur was zu meckern. Punkt.

[1ST1]

Ja, so kann man natürlich ne Diskussion auch abwürgen. Ich will von meiner ohnehin vorhandenen SCSI Platte (73 GB groß, leise und schnell genug) booten. Ist das so schwer zu verstehen?

[mfro]

Ja, so kann man natürlich ne Diskussion auch abwürgen. Ich will von meiner ohnehin vorhandenen SCSI Platte (73 GB groß, leise und schnell genug) booten. Ist das so schwer zu verstehen?

Mir liegt nix dran, irgendeine Diskussion abzuwürgen.

(Auch) Du wirst SCSI in EmuTOS nicht herbeidskutieren können.

Das kommt, wenn sich einer dransetzt und es macht. Und das wird dann passieren, wenn derjenige es selber haben will und/oder Spaß dran hat (und - natürlich - die Zeit dafür erübrigen kann).

Bis dahin bleibt EmuTOS für dich wohl unbrauchbar und für mich 'ne tolle Sache (bei der ich auch über die ein oder andere Unzulänglichkeit hinwegsehen kann).

[1ST1]

Naja, da haben wir dann ja doch einen Kompromiss gefunden: Dem eine sing Ühl ess dem andre singe Nachijall.

[gh-baden]

Wieso? TOS 3.06 unterstützt alle Hardwaredes TT, und TOS 4.04 alle Hardware des Falcon.

Ne, tut sie gerade nicht: die LAN-Schnittstelle bspw. Das OS kann die nur als RS232 nutzen, nicht als „LAN” (RS422). Und dabei hatte Atari die sogar beworben.

Beim STE-kompatiblen Sound sieht es auch böse aus: unterstützt das TOS 1.62, 2.06 und 3.06 nicht, es gibt schlicht keine Routinen dafür, man muss im Speicher rumprokeln, um Samples abzuspielen (0xFF8900 etc., siehe Atari Compendium, Kapitel 5.19). Erst beim Falcon gab es dafür eine API.

Kein SCSI am TT kann natürlich weh tun, wenn man das braucht, keine Frage. Aber es ist ja nicht so, dass die echten TOSse alle relevante Hardware unterstützt hätte, s.o.

[gh-baden]

Soweit ich mich erinnere gabs bei dem LAN Port auch noch ein rechtliches Problem, denn dieser LAN Port ist hardwareseitig identisch mit Apple Local Talk. Man konnte/wollte die Konkurrenz nicht unnötig aufscheuchen.

Das wäre mir neu. Zum einen hätte man mit anderen Sachen viel mehr Ärger mit Apple haben können (GEM 1.x, siehe DR-Prozeß), was Atari auch nie anging. Zum anderen sind die Chips hinter LocalTalk auch keine Apple-Erfindung, die Schöpfungshöhe von Apple liegt IMO allein im Software/Netzwerkstack AppleTalk, siehe bspw. das OSI-Diagramm auf http://www.knubbelmac.de/themen/netzwerke/appletalk-afp-localtalk/

Möglich ist auch, dass als die LAN-Hardware im TT, M-STE und Falcon schon fertig war, dass sich zeitglich Ethernet (BNC, RJ45) durchsetzte und das miteinander nicht kompatibel ist und man deswegen für diese Schnittstelle die Prio weg genommen hat - sollen doch andere was damit machen...

Daran glaube ich auch nicht, denn auch in frühen TT-Typen von Ende 1989, Anfang 90 ist der LAN-Port IIRC schon drin -- und da hatte sich Ethernet a) noch nicht durchgesetzt, und b) noch reichlich teuer. Und das haben sie dann noch 3,5 Jahre später im Falcon wieder eingebaut, und dort gibt es auch keinen Support für.

[mfro]

Das dürfte schlicht damit zu tun haben, daß die Tramiels gemerkt haben, daß Softwareentwicklung ein teures Geschäft ist. Deshalb so wenig wie nötig davon. Alle zwei Jahre ein bezahltes Upgrade (das man praktisch installieren *muß*) - das Geschäftsmodell war noch nicht erfunden. Kunden gingen damals davon aus, daß (OS-) Software von Atari nichts (oder nur wenig) kosten darf. Für meine TOS 1.04 ROMs habe ich - glaube ich - 50 Mark bezahlt (mir kam das schweineteuer vor). Davon kann man nicht allzuviele Entwickler durchfüttern.

Mini-DIN und SDLC sind (und waren damals schon) internationale Normen, da gab's für Apple nichts zu greifen. Das Netzwerkprotokoll hätte ja nicht AppleTalk sein müssen.

[Lukas Frank]

Für viele DTP´ler war der Atari TT damals die billigere Macintosh Plattform.

Sind ja auch alle später dorthin gekommen ...

Ich hätte nichts gegen Appletalk gehabt.

[1ST1]

Die Angst vor Apple war bei Atari durchaus da, das hat mir auf der Atari-Ausstellung der ehemalige Marketingmanager gesagt, die wurden ja was das Aussehen von GEM angeht, weitestgehend verschont, aber die Beschränkung auf max 4 Fenster auf dem Desktop rührt ja auch da her, das ist ja keine technische Beschränkung. Da saßen sich bestimmt mal Jack und Steve knurrend einander gegenüber und fanden ein Gentlemen-Agreement. Die wollten wahrscheinlich nicht Apple einen (weiteren) Grund geben, nochmal richtig zuzuhauen.

[mfro]

... aber die Beschränkung auf max 4 Fenster auf dem Desktop rührt ja auch da her, das ist ja keine technische Beschränkung...

Tatsächlich?

[1ST1]

Ja. Soweit ich das weiß, ist das eine Abfrage an einer Stelle im Desktop, da steht die Zahl 4 drin. WinX patcht genau das, wenn man die Beschränkung aufhebt. Und wenn man in TOS 4 Laufwerksfenster auf hat, kann man immer noch zusätzlich bis zu 6 ACC Fenster aufmachen, Control, XControl, Kubis, Paula, ... die machen ja allesamt richtige Fenster auf, macht dann schon insgesamt 10 Fenster ohne zu patchen.

[mfro]

Ja. Soweit ich das weiß, ist das eine Abfrage an einer Stelle im Desktop, da steht die Zahl 4 drin. WinX patcht genau das, wenn man die Beschränkung aufhebt. Und wenn man in TOS 4 Laufwerksfenster auf hat, kann man immer noch zusätzlich bis zu 6 ACC Fenster aufmachen, Control, XControl, Kubis, Paula, ... die machen ja allesamt richtige Fenster auf, macht dann schon insgesamt 10 Fenster ohne zu patchen.

Natürlich, aber irgendeine Zahl muß da ja stehen. Die Anzahl der Fenster ist im Atari-GEM fest einprogrammiert (nicht dynamisch verwaltet). Und wenn da 20 stünde, würde so manches auf einer 512 MB-Maschine sehr, sehr eng.

[1ST1]

Ja natürlich braucht das Speicher, auch der Shellbuffer muss größer sein, aber dafür gibts ja einen Patch. Aber da gehen deutlich mehr als 4 Fenster selbst auf der kleinsten ST-Kiste, KAOS TOS demonstriert das recht gut... Auch 512 MB (Megabytes) wären schon ganz nett, da stimme ich mit dir überein.

[mfro]

Da siehste mal, ich kann auch Mist schreiben.
Den aber auch eingestehen: ja, das sollte KB heißen.

[dbsys]

RS422 Softwareunterstützung? Nope. Nullkommanull.

In Cubase gibt es einen Treiber für diese Schittstelle. Man kann dann z.B. einige MIDI-Interfaces von MidiMan (heute M-Audio) betreiben, die eigentlich nur für den Mac gedacht waren. Funktioniert prima.

Und eine 3D Software habe ich, die diesen Port für den zur Software gehörenden Dongle benutzt. Momentan fällt mir der Name der Software nicht ein.

EDIT: Jetzt ist es mir wieder eingefallen. Es handelt sich um NeoN-Grafix 3D.

[mfro]

Ich habe gerade festgestellt, daß Android anscheinend auch ein 4-Fenster-Problem hat.

Angst vor Apple? 

Haben die immer noch das Patent auf das 5. Fenster?