oh das wäre eine idee, gleich mal testen (patchen)
Burkhard, hier gehts um XBoot III. Wenn du diese Version nicht kennst, oder nicht kennen willst, funke doch einfach mal nicht dazwischen.Was habe ich jetzt wieder falsch gemacht, daß Du "Mäuschen" mir wieder negativ über den Mund fahren mußt!
... oder ... Alternative mir nennen ?Eine Alternative wäre Startup wohl, wenn es sich um das Handling der AUTO Programme, ACCs, verschiedener Desktops handelt!
Ansonsten würde ich eventuell mal versuchen etwas zu entwerfen von Grund auf neu, vielleicht hab ich ja auch eine Idee wie man das ganze noch anders machen könnte.
Hab Startup mal getestet, ist eigentlich genau das was ich brauche. Einfach um Apps im Auto Ordner zu aktivieren oder zu deaktivieren. Nicht mehr und nicht weniger :) vielen Dank
Komm auf die Retrolution, dann zeige ich dir wie das mit XBOOT III geht.
Du kopierst einfach alle Programe in einen AUTO-Ordner und legts dir für jeden Anwendungsfall im Manager ein Set an, in dem du die Programme aktivierst, die dafür nötig sind. Und das selbe mit ACCs, Desktop-INF-Dateien, Asign.sys für NVDI/GDOS, usw. Dann wählt man nur noch so ein Set aus, und der Autostart-Manager benennt alle Dateien dementsprechend um.
Den Autoordner beim Booten komplett auszutauschen geht nicht, denn dadurch würde wahrscheinlich die Abarbeitung der Programme im Autoordner gestört. Der ST würde sich den Ast absägen, auf dem er sitzt.
Ich habe stattdessen mehrere Partitionen mit je einem \AUTO\ bootfähig eingerichtet und kann per HDDRIVER (oder CBHD oder...) ganz einfach zw. diversen OSsen wechseln! Benutzt man in jedem \AUTO\ einen Batcher, kann man nicht nur diverse Sets als .BATs einrichten, sondern auch den Inhalt der \AUTO\-Ordner hübsch klein halten.
Ich selber finde BootSelektoren ziemlich überflüssig, unbequem und manchmal sogar gefährlich (weil schon vom \AUTO\ aus schreibend auf die Platte zugegriffen wird).Fragwürdige Ansicht! Das Einzige, was Startup speichert, ist das Überschreiben der DESKTOP.INF!
Ich habe stattdessen mehrere Partitionen mit je einem \AUTO\ bootfähig eingerichtet und kann per HDDRIVER (oder CBHD oder...) ganz einfach zw. diversen OSsen wechseln! Benutzt man in jedem \AUTO\ einen Batcher, kann man nicht nur diverse Sets als .BATs einrichten, sondern auch den Inhalt der \AUTO\-Ordner hübsch klein halten.Was für eine Platzverschwendung! Das einzige, was für mich mehrere Bootdrives sinnvoll macht, ist ein Computer mit mehreren OS, die dann aber auch notwendig sein dürften!
ZitatDen Autoordner beim Booten komplett auszutauschen geht nicht, denn dadurch würde wahrscheinlich die Abarbeitung der Programme im Autoordner gestört. Der ST würde sich den Ast absägen, auf dem er sitzt.
Das sollte doch gehen. Ich meine wenn man einen Autoordner angelgt, in dem ein Programm liegt, das dann einfach eine Auswahl an Ordnern bietet, die dann abgearbeitet werden soll, das müsste doch machbar sein? Oder eben wie man das von späteren DOSen gewöhnt ist, dass man Startdateien anlegen kann, in denen man mehrere Sets hat, aus denen man per Startmenü auswählen kann, welches dann entsprechend abgearbeitet wird. Diese Lösung fände ich persönlich besser als die ganzen Bootmanger.
ZitatKomm auf die Retrolution, dann zeige ich dir wie das mit XBOOT III geht.
Zu weit weg. ;) Komm nach Hannover zum nächsten Retro-Computer-Treff!
Gibts da oben niemanden der dir das zeigen kann?Nö, hier im Raum Hannover kennt sich niemand mit XBoot aus!
Welches Programm nutzt Du in diesem Zusammenhang?Ich benutze eine spez. Variante B+EXT.PRG von MCMD.PRG (aus einer früheren MAGIC-Distribution). Aber empfehlen würde ich Dir AUTOMORE von T.Binder!
Burkhard, Du solltest inzwischen wissen, daß ich Warnungen nicht spekulativ ausspreche, sondern daß dahinter immer eine böse Erfahrung steckt! Ein einziger Schreibzugriff kann genügen!Ich selber finde BootSelektoren ziemlich überflüssig, unbequem und manchmal sogar gefährlich (weil schon vom \AUTO\ aus schreibend auf die Platte zugegriffen wird).Fragwürdige Ansicht! Das Einzige, was Startup speichert, ist das Überschreiben der DESKTOP.INF!
Was für eine Platzverschwendung!Ganz im Gegenteil!
Burkhard, Du solltest inzwischen wissen, daß ich Warnungen nicht spekulativ ausspreche, sondern daß dahinter immer eine böse Erfahrung steckt! Ein einziger Schreibzugriff kann genügen!Das Überschreiben einer (NEW)DESK(TOP).INF Datei ist sogar durch die Entwicklung des ST und seiner Nachfolger vorgesehen! Wenn bei einem solchen Vorgehen ein Fehler passiert, hat Deine Platte sicher andere Probs (zumindest auf der Bootpartition) gehabt!
Ganz im Gegenteil!Doch - meistens braucht man für viele Arbeitsumgebungen einen vergleichbaren Inhalt des AUTO-Ordners; und Du höchstwahrscheinlich auch! Mehrfach das gleiche Programm auf verschiedenen "Ebenen" unter selben OS = Platzverschwendung, auch wenn der benötigte Platz verschwindend gering ausfällt!
Ich benutze eine spez. Variante B+EXT.PRG von MCMD.PRG (aus einer früheren MAGIC-Distribution). Aber empfehlen würde ich Dir AUTOMORE von T.Binder!
Für die SETs gibt es eine Menge verschiedener Anwendungsmöglichkeiten. Naheliegend ist, sich für jede seiner Standardanwendungen ein SET zu erstellen, also zum Beispiel eins für die Arbeit mit der Textverarbeitung, eins für DTP, eins für das Grafikprogramm usw. Dabei bietet es sich natürlich an, für jedes dieser SETS in XBoot zusätzlich einen Autostart anzugeben, damit zum Beispiel bei der Auswahl des SETS Wordplus das Programm WORDPLUS.PRG nach dem Booten automatisch gestartet wird. Der automatische Start von GEM-Programmen funktioniert mit XBoot übrigens auch unter den alten TOS-Versionen 1.0 und 1.2.... dann muß ich sagen: "Das - oder ähnliches - kann Startup auch!" Ich möchte mir eine Arbeitsumgebung für TeX anlegen;
Die SETs eignen sich jedoch auch für ganz andere Dinge. Anwender, die ihren ST sowohl mit dem SM 124 als auch mit einem Farbmonitor betreiben, kennen das Problem: Waren die Fenster- und Icon-Positionen auf dem Desktop in der monochromen Auflösung noch in Ordnung, so treiben in der mittleren oder niedrigen Auflösung "übereinandergestapelte" Icons und nicht oder kaum erreichbare Fenster den Anwender oft zur Weißglut. Ähnliche Sorgen plagen auch die Besitzer von Großbildschirmen. Mit den Infodateien in XBoot bekommt man solche Ärgernisse sicher und schnell in den Griff. Dazu wird lediglich für jede der Bildschirmauflösungen ein eigenes Desktop erstellt und mit Arbeit sichern abgespeichert. Nach dem Abspeichern muß die entstandene Datei DESKTOP.INF noch umbenannt werden, damit sie nicht beim nächsten Speichern überschrieben wird. Am besten gibt man den auflösungsabhängigen DESKTOP.INF-Dateien Namen wie DESK HI.INF (hohe Auflösung), DESK MED.INF (mittlere Auflösung) und DESK LOW.INF (niedrige Auflösung). Nach diesen jede der Auflösungen ein eigenes SET erstellt werden, für das man die zugehörige alternative DESKTOP.INF-Datei bestimmt. So arbeitet man immer auf einem aufgeräumten Desktop.
Natürlich kann man neben den "Standard"-Desktops auch für jede Anwendung ein individuelles Desktop benutzen. Wie wäre es zum Beispiel, wenn bei der Auswahl des SETs Wordplus auf dem Desktop sofort die Fenster mit den Ordnern geöffnet würden, in denen sich Wordplus und die gespeicherten Textdokumente befinden? Dazu verfährt man genauso wie oben beschrieben und nennt die neue DESKTOP.INF-Datei einfach DESKWORD.INF. Nun muß diese Datei nur noch beim nächsten Systemstart in das SET Wordplus übernommen werden.
XBoot lässt sich mit der Maus bedienen.Benötige ich nicht!
Innerhalb XBoot kann man die Startreihenfolge im Autoordner... ändern.Wozu sollte das gut sein, wenn man doch weiß, daß der ST gerne Bombenhagel losläßt, wenn PRG Z vor PRG A gestartet wird!
Innerhalb XBoot kann man die Startreihenfolge ... bei ACCs ... ändern.Da verschließt sich mir völlig der Sinn - ich kenne kein ACC, bei dem es wichtig wäre, vor einem Anderen gestartet zu werden!
Innerhalb XBoot kann man die Startreihenfolge ... bei ... CPXen ändern.dto.
Im übrigen kann XBoot auch CPXe verwalten.XControll adé?
Möchte ich nicht mehr missen. Tastaturbedienung geht natürlich auch. Ist so halt flexibler.XBoot lässt sich mit der Maus bedienen.Benötige ich nicht!
Ja, genau dafür. Du weißt sicher wie aufwändig das sonst ist. In XBoot verschiebe ich das Programm einfach dahin wo ich es haben will.Innerhalb XBoot kann man die Startreihenfolge im Autoordner... ändern.Wozu sollte das gut sein, wenn man doch weiß, daß der ST gerne Bombenhagel losläßt, wenn PRG Z vor PRG A gestartet wird!
Z.B. damit man im ACC-Menü eine bestimmte Reihenfolge hat.Innerhalb XBoot kann man die Startreihenfolge ... bei ACCs ... ändern.Da verschließt sich mir völlig der Sinn - ich kenne kein ACC, bei dem es wichtig wäre, vor einem Anderen gestartet zu werden!
Die wichtigsten CPXe oben, die unwichtigen unten.Innerhalb XBoot kann man die Startreihenfolge ... bei ... CPXen ändern.dto.
Wenn ich kein MiNT boote, brauche ich auch kein Mint.cpx. Wenn ich keinen NVDI boote, brauche ich auch kein NVDI.CPX, ... Kann ich also schön an meine Startkonfig anpassen.Im übrigen kann XBoot auch CPXe verwalten.XControll adé?
Und was das Übrige betrifft: mit GDOS und NVDI befasse ich mich erst seit kurzem (eigentlich bislang noch gar nicht, da mein Mega ST4+ noch nicht für den Dauereinsatz bereit ist und ich mich bislang um andere wichtige Familienangelegenheiten kümmern mußte, die wichtiger sind als mein Hobby) - also noch keinerlei Erfarung und darum auch kein Grund umzusteigen!Ich will niemanden bekehren. Dich schon garnicht. Denn gegen (Irr)Glauben ist kein Kraut gewachsen. Ich kann nur (duch sachliche Argumente) überzeugen. Das ist ein riesen Unterschied.
Nein - dadurch kannst Du mich auch nicht bekehren!
... wie es bei Magic gemacht wird.Ja tuxie, geht mit einem sep. CLI/BATcher auch mit MiNT und anderswo, nicht bloß genauso, sondern sogar besser! Und dann kann man den auch für Magic benutzen und ist nicht mehr auf das in Magic eingebaute, sehr primitive Ding angewiesen!
... die Programme in den Auto Ordner kopiert ...Nein, die *Programme* müssen gar nicht kopiert werden. Die werden einfach von da gestartet, wo sie liegen - irgendwo auf der Platte! MaW.: Bis auf wohlbegründete Ausnahmen (siehe mein ScreenShot) ist der CLI das einzige ausführbare Prg. im \AUTO\. Das restliche Volk im \AUTO\ besteht aus Konfigurations-Dateien und .BATs!
Umbenennen geht einen Ticken schneller.Noch einen Tick schneller geht ´drüberbügeln´ (ie. der .BAT- & Konfig.-Dateien).
... zum richtigen Zeitpunkt ... Taste drücken ...Bitte nicht niesen! Und hoffentlich kommt keine BusyBee dazwischen! >:D
Von ATARI gibts ein command.prg ...Geht vielleicht auch, habe ich nicht ausprobiert. So komfortabel wie der MCMD sind nur wenige CLIs.
... es sei denn der letzte Befehl in der Batch ist mint.prg oder newdesk.prg ...oder SET_ENV.PRG oder AUT?X.PRG oder ....
...eine ganze Ecke komfortabler ...Obwohl ich mich nie mit MSDOS abplagen mußte und trotz meiner heißen Vorliebe für GUIs bevorzuge ich im \AUTO\ einen CLI 8) ! Ich würde tuxie und Nervengift dies und Burkha rd einen BootSetter empfehlen ;D !
... jegliche Schreinzugriffe ...Wer seinen Schrein liebt, der hat min. zwei Backup-Platten (& nicht bloß eine Partition wie unser leichtsinniger B.!).
... Übersichtlichkeit ...Ja !!! Das ist das wichtigste aller Kriterien!
Also meinetwegen "AUTO", "AUTO1", "AUTO2" usw..Wie wär´s mit A:\AUTO, B:\AUTO, C:\AUTO usw.?
Allwissende Müllhalde? lol ! Weiß nicht mehr @Nervengift , woher ich´s habe, aber schau mal in den Anhang. Ist ja Freeware.ZitatIch benutze eine spez. Variante B+EXT.PRG von MCMD.PRG (aus einer früheren MAGIC-Distribution). Aber empfehlen würde ich Dir AUTOMORE von T.Binder!@ari.tao: Nach "Automore" von Thomas Binder habe ich mal in der allwissenden Müllhalde gesucht und leider nichts gefunden. Weißt Du eine Bezugsquelle für das Programm?
Xboot III bombt bei mir ...Siehe auch Posting #34.
Möchte ich nicht mehr missen. Tastaturbedienung geht natürlich auch. Ist so halt flexibler.Cursortasten und <TAB> (bzw. <A> - zum Wechsel zwischen PRG und ACC) - mehr brauche ich auch idR nicht!
Ja, genau dafür. Du weißt sicher wie aufwändig das sonst ist. In XBoot verschiebe ich das Programm einfach dahin wo ich es haben will.Einmal einrichten - und wenn neue PRG dazukommen und die Stelle weiß, wo es am Besten zu starten wäre physikalisch per Hand neu sortieren reicht doch wohl völlig!
Z.B. damit man im ACC-Menü eine bestimmte Reihenfolge hat.Pustekuchen! Ich habe experimentiert, um eine bestimmte Reihenfolge der ACC in den Slots unterm DESK-Menü zu erhalten, funzt net! Egal in welcher Reihenfolge ich die ACCs physikalisch laden lasse, sie erhalten bei mir immer den gleichen Slot!
Die wichtigsten CPXe oben, die unwichtigen unten.Mir nicht wichtig - alle CPX, die ich in XControl aktiviert habe, sind mir "wichtig" und die unwichtigen sind deaktiviert!
Wenn ich kein MiNT boote, brauche ich auch kein Mint.cpx. Wenn ich keinen NVDI boote, brauche ich auch kein NVDI.CPX, ... Kann ich also schön an meine Startkonfig anpassen.Kann man auch erreichen, wenn man für ein Nachlade-OS eine eigene CPX-Verwaltung nutzt ...!
Wie wär´s mit A:\AUTO, B:\AUTO, C:\AUTO usw.?:o Willst Du allen Ernstes bei Plattennutzung AUTO-Ordner von Disklaufwerken nutzen? ???
Nein, die *Programme* müssen gar nicht kopiert werden. Die werden einfach von da gestartet, wo sie liegen - irgendwo auf der Platte! MaW.: Bis auf wohlbegründete Ausnahmen (siehe mein ScreenShot) ist der CLI das einzige ausführbare Prg. im \AUTO\. Das restliche Volk im \AUTO\ besteht aus Konfigurations-Dateien und .BATs!
Jeder hat einen anderen Geschmack und jeder hat eine andere Art Ordnung auf seinem Rechner zu halten. Daher gibt es für jeden auch verschiedene Ansätze wie etwas gehandhabt wird.
Die Idee mit einem Prozess der alle einzelnen Programme Lädt hatte ich auch, ich weiß nur nicht in wie weit das Machbar ist, oder vielleicht schon gemacht wurde?Wie soll ich die Frage verstehen? Ist das eine rethorische Frage? Du mit Deinen 5k Postings hier im Forum kannst doch unmöglich die Antwort nicht wissen 8) ! Aber ich beantworte sie trotzdem mal:
... Ich fürchte, dass meine Idee nicht unbedingt auf Gegenliebe bei den EmuTOS-Leuten gestoßen ist. Insofern muss es wohl für die meisten von uns eben weiterhin XBoot & Co. tun.
Hast Du EmuTOS installiert und meinen (auf der Mailinglist bereits abgesonderten) Vorschlag (mehrere Partitionen mit unterschiedlichen Konfigurationen, Auswahl der Bootpartition im "Welcome-Screen") schon mal praktisch ausprobiert?
Das funktioniert um Klassen bequemer und schneller als ein Boot-Selektor, der in 99% der Fälle nur aufhält (weil man ihn meist sowieso bloß "wegdrückt"). Will man mal eine andere Konfiguration, drückt man nach einem Kaltstart einfach die Taste mit dem passenden Laufwerksbuchstaben.
Ich erinnere noch mal kurz daran, daß es weitere Möglichkeiten gibt, den BootVorgang im \AUTO\ umzuleiten:
http://forum.atari-home.de/index.php?topic=13024.msg208629#msg208629
Wer eine MultiUser-Umgebung benötigt, der schaue sich GEM-init von Ulrich Kaiser an.
ZitatWer eine MultiUser-Umgebung benötigt, der schaue sich GEM-init von Ulrich Kaiser an.
Bekommt man aber ab MiNT Version 1.16.x nicht mehr so einfach realisiert, da man ab dieser Version nur noch als root die AES starten kann. Man bleibt als normaler User in der Kommandozeile hängen. Es gäbe sicherlich die Möglichkeit die Zugriffsrechte alle entsprechend anzupassen, aber das habe ich mich noch nicht wirklich getraut.
Brauchst deinen Nutzer nur in die Enstprechenden Nutzergruppen hinzufügen, ist kein hexenwerk und relativ einfach zu realisieren.
??? Habt Ihr alle kleine Brüder, wie 1ST1 ? ;D
Nein damit hebelst du das doch nicht aus, genau dafür ist es doch gedacht das dein nutzen die bechtigung bekommt die er haben soll und braucht und nur weil er xaaes ausführen darf heißt das ja nicht das es Root rechte sind
Warum nicht die Optionen nutzen, die einem ein System bietet? Ich bastel ja auch gerne. :DEntia non sunt multiplicanda praeter necessitatem! (Occam´s razor)
Hallo @Burkhard Mankel ,
ich gebe dir da recht, habe mich da auch zurückgehalten weiteres zu schreiben da ich mein Programm gefunden habe (StartUP).
Aber!! Es ist so das bei größeren Maschinen wie die CT60 oder der Milan die inhalte des Autoordners bis weit über 10 - 15 Einträge übersteigen kann und es auch je nach Konfiguration verschiedene Treiber und Zusätze geladen werden müssen. Der ST und auch der TT ist da noch recht harmlos bei sowas.
Ich habe mir lange überlegt, ob ich hier noch was schreiben soll! Das was hier zuletzt diskutiert wird, dient doch bestenfalls dazu, sehr ... sehr ... sehr viel Platz zu verschwenden - was mich nur noch mit dem Kopf schütteln läßt!
Gerade wenn man CF-Adapter und dergleichen am Atari nutzt, gibt es heutzutage wirklich kein Platzproblem mehr.Was den verfügbaren Datenträgerbestand belangt, magst Du ja durchaus recht haben! Aber ein herkömmlicher ST ist mit maximal 14 Partitionen a max. 2GB da durchaus beschränkt und wenn man von den 14 möglichen Partitionen noch 10 Partitionen als Bootpartition harausarbeiten will, die - von Treiberentwicklern dokumentiert - sehr viel kleiner als besagte 2GB sein sollten, und noch eine Partition für einen 2. zum Datentausch mit anderen Computern res3erviert haben will, kann man schnell an die Grenzen des Systems kommen!
Nein - einzig für mich sinnvolle Anwendung einer Festplatte ist: [...]
Burkhard, jetzt hast du meinInteresse geweckt. Wie macht man das mit 2 GB Partitionen am ST?Sicherungslaufwerk - um dem vorzubeugen, wovor hier scheinbar viele Leute Angst zu haben scheinen!
Was ist die maximale von HDDRIVER unterstützte Partitionsgröße?
Die Obergrenze hängt vom Betriebssystem und vom Dateisystem ab. TOS 1.00/1.02 unterstützt Partitionen bis zu 256 MiB, TOS 1.04-3.06 bis zu 512 MiB, TOS 4.0x bis zu 1 GiB, MagiC bis zu 2 GiB. Diese Angaben gelten auch für Bootpartitionen sowie für mit HDDRUTIL erzeugte TOS/Windows-kompatible Partitionen. Mit Big-DOS lassen sich die TOS-Limits heraufsetzen. MiNT und MagiC unterstützen Dateisysteme (FAT32/ext2), die praktisch keine Größenbeschränkung besitzen.
Ein "Sicherungslaufwerk" auf demselben Medium ist Kappes.Hab´ ich ihm doch auch schon mal erklärt. Aber B. ist halt Optimist 8) >:D :-* !!
Ein "Sicherungslaufwerk" auf demselben Medium ist Kappes.Ich arbeite (befaasse mich) seit 1989 aktiv mit dem Atari ST und seit etwa Mitte der 90er auch mit HDDs dazu! Ich habe es in dieser Zeit nicht ein einziges Mal geschaft, die Partitionstabelle zu zerstören! Aber auch für den Fall habe ich zusätzlich meine komplette CF Karte auf dem PC ausgelesen und die Dateien kopiert! Zusätzlich habe ich meine Dateien auch noch auf verschiedenen 44er und 88er SyQuest Medien!
Wenn Du dir die Partitionstabelle zerschießt, hast Du gar nix mehr ...
_^^_ Schade. Hatte schon gehofft, BIGDOS könnte mehr :( .Wirf die Flinte nicht ins Korn - Im Zusammenspiel mit mit Pera Putniks Treiber und BigDOS schafft man 2GB! Bei mir jedenfalls !!!ZitatEin "Sicherungslaufwerk" auf demselben Medium ist Kappes.Hab´ ich ihm doch auch schon mal erklärt. Aber B. ist halt Optimist 8) >:D :-* !!
-------
Hast Du denn, @Burkhard Mankel , diese 2GB-Partition auf Deinem Medium schon eingerichtet? Oder waren das bloß Pläne?
Atari ST software from me:Von Pera Putniks IDE Page (http://atari.8bitchip.info/astide.php)!
Hard disk driver for DOS partitioned disks It can handle up to 14 FAT16-BigDOS partitions from drives of capacity to 128GB. Needs freeware program BigDOS for work. Max part. size is 2GB. Only for IDE interfaces. Falcon compatible.
Und BIGDOS reicht auf Laufwerken mit TOS-Partitionierungsschema auch nur für 1 GB große FAT-16-Partitionen hab ich schon mit TT und Falcon getestet, mehr geht da nicht.
Also, Burki, wie?
Ps: Ich stimme mfro zu, mit der Sicherungspartition auf der selben Platte...
nein, Bigdos kann 2GB Partitionen verwalten mit TOS Partitionen auf einer Platte. Lediglich die Bootpartitionen müssen für TOSe 1.x und 2.x unter 100MB sein. Ansonsten kann jede TOS Version fröhlich auf 2GB Fat16 Partitionen zugreifen mit Bigdos. So mach ich das immer. Unter Linux die Partitionen eingerichtet (100MB) für TOSe als Bootpartition, Programme und Install Dateien sowie Spiele liegen auf 2GB Partitionen.
_^^_ Sehr richtig, das hatten wir ja schon mal anderswo:Ich kann in dem besagten Post nichts herauslesen, das für oder gegen Pera Putnicks Treiber spricht - was hier zuletzt diskutiert wird!
http://forum.atari-home.de/index.php?topic=12847.60
-> Posting #71
Aber eins würde mich doch noch interessieren:
Wie hoch ist denn der Verschnitt ( := (belegt - gefüllt) / belegt ) auf der 2GB großen FAT16-Partition?!
Wer immer noch ein TOS < 2.06 benutzt, dem ist sowieso kaum zu helfen (außer durch den Hinweis, es schleunigst wechseln zu lassen).Das sehe ich ein bißchen anders! Allerdings abeite ich auch am liebsten unter TOS 2.(0)6 oder Alternativen OS, aber es gibt in sehr frühen ST-Zeiten programmierte SW (überwiegend Spiele), mit der man sich ab aund an beschäftigt, die hier nicht (mehr richtig) laufen wollen!
Falls man _hinter_ BIGDOS auch noch einen FAT32-Treiber installieren könnte, wär´s ja vielleicht brauchbar. So aber bleibe ich lieber bei MiNT_1-15-9 .Ich frage mich gerade: Wenn ich die Dokus zu BigDOS richtig übersetzt habe und mich nicht verlesen habe, beinhaltet es doch die korrekte FAT(32) Behandlung - wozu dann noch 'n zusätzlichen FAT32 Treiber?
Wie hoch ist denn der Verschnitt ( := (belegt - gefüllt) / belegt ) auf der 2GB großen FAT16-Partition?!Bei Platten arbeitet man immer auf Cluster-Ebene, ein Cluster besteht immer aus mindestens 2 Sektoren. Das heißt, die kleinste Einheit, die von einer 1-Byte Datei belegt wird, ist ein Cluster. 2, 4, 8... Sektoren. Jetzt verlinke ich mal zum ATARI-Killer...
Ich frage mich gerade: Wenn ich die Dokus zu BigDOS richtig übersetzt habe und mich nicht verlesen habe, beinhaltet es doch die korrekte FAT(32) Behandlung - wozu dann noch 'n zusätzlichen FAT32 Treiber?
...MagiC nicht? Meineswissens verarbeitet MagiC auch lange Dateinamen, Leerzeichen im Dateinamen, Umlaute usw.! Und Umlaute gehen unter TOS doch auch - allerdings mit dem Haken, das kleingeschriebene Umlaute und Großgeschriebene Umlaute als unterschiedliche Zeichen verarbeitet werden!
Vollständiger FAT 32 Support, sprich lange Dateinamen, Leerzeichen im Dateinamen, Umlaute usw., würde auch Anpassungen im ganzen TOS erfordern. Das hat nur MiNT.
...
...Wirklich?
Und bei den Umlauten muss man halt aufpassen, ATARI kodiert die mit anderen ASCII-Werten als MS-DOS (außerdem Codepage abhängig) und Windows (wieder anders, kann auch groß/klein unterscheiden!). Dateinamen mit Umlauten zwischen ST und PC sind eine echte Seuche. "ß" (SZ) auch! Besser nicht ausprobieren, wenn man Dateien zwischen beiden Welten hin und her schieben will, oder wenn man aus einem ST-Emulator auf das PC-Dateisystem zugreifen kann (z.B. in Aranym) oder über ein Netzwerkshare (unter MiNT oder evtl. auch mit CosmosEx, die Sache mit den Umlauten hab ich da noch nicht probiert).
* tuxie holt sich eine Tüte Popcorn und schaut sich das Spektakel an .................
* ari.tao holt sich ein paar Stücke Obst und sieht sich an, wie tuxie sich das Spektakel anschaut ................
1) In der BIGDOS-Doku steht nix von FAT32. Halu? LeseSchwäche? LiPuPa?Eine einzelne Doku zu BigDOS habe ich noch gar nicht vor Augen gehabt. Ehrlich gesagt hatte ich auch immer gedacht, daß es auf den Mist von Pera Putnik gewachsen ist und zu seinem Treiberpaket gehört!
2) MiNT läuft selbstverständlich auch auf kleinen STs mit 4MB - aber natürlich nur die älteren Versionen, nicht die fetten Teile > 1.15.12 !Wo könnte man eine solche ältere Version downloaden?
3) Mit der Frage nach dem Verschnitt wollte ich doch nicht die Theorie abfragen, @1ST1 , (das ist doch klar, daß man mit nur 64k Dateien a 1Byte fast alles verschwendet), sondern wollte von @Burkhard Mankel wissen, wieviel Verschnitt er _praktisch_ hat, nachdem er seine Sicherungs-Dateien angelegt hat...Verschnitt? Falls damit etwaige "Verschwendung von Festplattenplatz" gemeint ist: Ich denke da nicht wirklich drüber nach, da ich bei meinen bisherigen Computwertätigkeiten festgestellt habe: das, für das sich der ST noch für mich sinnvoll darstellt, reicht selbst 1GB dicke - und jetzt habe ich die 4fache Größe! Also mehr als ausreichend Platz ...
4) MAGX ist leider auch buggy, wenn es um die Kürzung langer DateiNamen geht.Ehrlich gesagt: So viel habe ich bishermit MagiC auch nicht gemacht, weil ich bei der Nachlade-Version tatsächlich fehlerhaftes Arbeiten für mich diagnostizierte!
5) Die Verarbeitung von PC-Umlauts etc. auf Atari-Pfaden ist katastrofürchterlich!Das, was ich hierbei brauche, funzt scheinbar tadellos - und mehr brauche ich nicht!
6) Kein Wunder, daß der Monitor bei "ÜßMürÜbl" ausfällig wurde. Recht hat er! ;DIst mir nicht aufgefallen - meine Monitore sind scheinbar nicht so empfindlich!