Probleme und Fehler im BigDOS ...

[Nervengift]

Bigdos habe ich nur als olle Zicke kennengelernt. Wenn man aber den Quellcode frei bekäme und sich jemand der Sache annähme, wäre das sicherlich auch echt nicht schlecht. Vor allem für die ST(E), auf denen MiNT nicht besonders performant läuft.

Klar ist haben schöner als nicht haben, aber sind _große_ Dateisystem an einem "nackigen" ST(E) echt so wichtig? Was für Gigabytes Daten will man denn mit einem 68000/8 wuppen? Mir reichen da 1-2x 512 MB gut aus …

Ist ein Argument. Manche möchten vielleicht auch nur die Möglichkeit haben oder sie sehen es aus der Perspektive des "proof of concept"?

[goetz @ 3rz]

Manche möchten vielleicht auch nur die Möglichkeit haben

Jaja, Modelleisenbahnersatz, oder je nach Typus der gleiche Grund, warum SUVs gekauft werden. Könnte man ja vielleicht mal brauchen. Ist dann zwar für den Zweck trotzdem ungeeignet, aber das undifferenziert gute Gefühl hält bis dahin ja erstmal an ;-)

Das „ich könnte ja“ ist echt eine mächtige Droge. 

oder sie sehen es aus der Perspektive des "proof of concept"?

Man muss, weil man kann. Auch eine Möglichkeit. 

[Thorsten Otto]

Klar ist haben schöner als nicht haben, aber sind _große_ Dateisystem an einem "nackigen" ST(E) echt so wichtig? Was für Gigabytes Daten will man denn mit einem 68000/8 wuppen? Mir reichen da 1-2x 512 MB gut aus …

Naja praktisch wäre das schon, vor allem zum Austausch mit anderen Systemen, die dann vermutlich ein anderes Dateisystem verwenden als das archaische FAT16.

[goetz @ 3rz]

Naja praktisch wäre das schon, vor allem zum Austausch mit anderen Systemen, die dann vermutlich ein anderes Dateisystem verwenden als das archaische FAT16.

Turnschuhnetzwerk hab ich nach den Disketten aufgegeben :-) Schnelle serielle Leitung, PARCP oder IP-basiert. Hintragen zu einem Rechner will ich maximal ein kleinen Booter für einen Kickoff. Disketten oder Sticks (was letztlich auf das gleiche rauskommt) nutze ich nur bei Geräten, bei denen ich obige (für mich bessere) Alternativen nicht haben kann, etwa Schneider/Amstrad CPC, für den ich keine (schnelle) serielle habe.

Und seit es a) Ethernet am Atari in X Variationen (Netusbee, Unicorn, Lightning) günstig+gut gibt, und b) WLAN-Ethernet-Bridges für ~15€, oder auch c) Bluetooth-RS232-Wandler, zwei Stück für 20€, ist‘s einfacher denn je geworden.

Ich hab schon früher lieber MIDICOM benutzt, als Syquests/ZIPs etc. rumzutragen, und v.a jedesmal den Kontext am Gerät zu verlieren beim Rumlaufen und dann was draufzukopieren und dann fehlt doch wieder was … nee. Nix für mich :-)

[mfro]

Finde ich auch. Heutzutage gibt es so viele Möglichkeiten für den Datenaustausch, dass es nicht notwendig ist, die alten Kisten mit modernen Filesystemen zu plagen. Man bedenke: die FAT eines x-GB FAT32-Mediums z.B. belegt typischerweise x MB.

Und die Kisten, die damit nicht so geplagt sind (CT60, FireBee & Co.) sind  potent genug, um MiNT (das alles mitbringt, was man braucht) darauf zu fahren.

[ari.tao]

Gute Argumente!
Muß dringend einen ParCp anschaffen - für die kleinen häufigen Kopierereien.
(Lightning gibt´s ja leider nur für TT & MSTE, und wenn dann hoffentlich doch mal für STs, dann würde das für jede Kiste extra dann aber zu teuer).
Für größere Kopier-Aktionen geht´s dann doch per BarfußNetzwerk schneller...
Habe gestern mal eine Kiste mit nur 4MB RAM hochgefahren: Kein Problem mit MiNT & MAGX, da bleibt noch genug Speicher frei obwohl beide üppig ´was brauchen.

[1ST1]

Fürs EmuTOS fände ich's echt cool, wenn es größere Partitionen oder Spechermedien von Haus aus unterstützte.

Die Partitionsgrösse ist EmuTOS relativ egal, die Beschränkungen liegen eher im FAT Dateisystem
Und auch da sind schon deutlich grössere Partitionen als bei den meisten TOS-Version möglich (wenn ich mich nicht irre liegt die Beschänkung momentan bei 512MB).

Nur TOS 4.04 kann 1 GB (man sollte aber immer etwas unter diesen TOS-Grenzen drunter bleiben, 510 MB, 1020 MB, oder so. Wenn man genau 512 MB, 2024 MB nimmt, hab ich schon öfters defekte Dateisysteme gehabt.

Über eure Spekulationen meinerseits sehe ich jetzt mal drüber weg. Ich habe mfro eben was dazu geschrieben, vielleicht versteht er es und erklärt es euch. Langsam 10.000 neue Dateien geschrieben, gelöscht, Gröé stark geändert, deswegen 10.000 mal in die FAT geschrieben, CF/SD wegschmeißen ist das Stichwort. Dann nochmal den verlinkten Wikipedia-Artikel lesen, und drüber nachdenken, ob wear leveling nicht doch eine Rolle spielen könnte, und sich die Intelligenz in den Kärtchen sich nicht doch über unbenutzte logische Sektoren freuen könnte....   

[KarlMüller]

Code: [Auswählen]

Ich kann es in Hatari reproduzieren. Die gute Nachricht: Der Lightning-VME-Treiber ist daran völlig
unbeteiligt und nicht Ursache für den Fehler.

Die schlechte Nachricht: Das ist (ein weiterer) größerer Bug in BigDOS! BigDOS installiert, warum auch
immer, seine eigene Speicherverwaltung, statt die Speicherverwaltung TOS zu überlassen. Obwohl
Memspeed ausdrücklich nach TT-RAM fragt (via Mxalloc(..., 1)), bekommt es von der
BigDOS-Speicherverwaltung ST-RAM zurückgeliefert, was sich in der Zugriffsgeschwindigkeit zeigt.

Nun ist BigDOS "closed source", d.h. eigentlich kann nur der Autor das fixen.

PS: Falls Ihr über BigDOS diskutieren wollt, bitte einen eigenen Thread aufmachen, damit es hier
weiterhin um die Lightning VME geht.

Wie sind denn im besagten Fall die Programmflags von BigDOS gesetzt? Ist Bit 2 gesetzt, das Malloc Speicher aus dem Alternate-RAM bedient?

[czietz]

Wie sind denn im besagten Fall die Programmflags von BigDOS gesetzt? Ist Bit 2 gesetzt, das Malloc Speicher aus dem Alternate-RAM bedient?

Die Programmflags sind hier nicht relevant, weil Big-DOS sowieso sämtlichen Speicher übernimmt (ST- und TT-RAM) und seine eigene Speicherverwaltung installiert. Nein, ich vermute eher das die Implementierung von Mxalloc in Big-DOS fehlerhaft ist. Wäre es open-source, hätte ich das schnell gefixt...

[1ST1]

Wäre auch mal interessant zu wissen, waum BigDOS seine eigene Speicherverwaltung etabliert. Vielleicht hat das auch damit irgendwas zu tun, dass es zumindestens auf dem Falcon den Rest des Bootvorgangs komplett übernimmt, das heißt, keine Autoordner-Programme dahinter und starten des Desktops und Laden der ACCs wird scheinbar komplett von BigDOS gesteuert..

[ari.tao]

Wenn man das ST-RAM blockiert (zB. alles verfügbare alloziert), dann müßte doch auch BigDOS auf das TT-RAM zugreifen und MemSpeed müßte dann das testen?

-------

Wie sind denn im besagten Fall die Programmflags von BigDOS gesetzt? Ist Bit 2 gesetzt, das Malloc Speicher aus dem Alternate-RAM bedient?

Bevor jmd. mühsam mittels Hex-Monitor die Bits im Prg.-Header analysiert: Dafür gibt´s Utilities, zB. Circinus oder SetFlags.prg von Georg Acher oder SetFlags.app von Uwe Seimet.

[ari.tao]

... Rest des Bootvorgangs ...

Laden des Desktops & Starten der ACCs ist Sache der AES.
Mit deren Start wird die Abarbeitung des AUTO\ abgebrochen,
bzw. umgekehrt: Wenn man die Abarbeitung des AUTO\ abbricht, dann starten automatisch die AES. Kann man in AUTAXI ansehen.

[Thorsten Otto]

Laden des Desktops & Starten der ACCs ist Sache der AES.

Die Verwaltung derselben schon, aber geladen werden sie über Pexec(), und das wird scheinbar von BigDOS ersetzt. Was auch Sinn macht, weil sonst die internen TOS Funktionen zum Laden der Datei verwendet werden (es wird dort nicht noch einmal über den GEMDOS-Trap gesprungen). Vermutlich auch der Grund dafür, daß die Speicherverwaltung gleich mit ersetzt wird.

[Arthur]

Laden des Desktops & Starten der ACCs ist Sache der AES.

Die Verwaltung derselben schon, aber geladen werden sie über Pexec(), und das wird scheinbar von BigDOS ersetzt. Was auch Sinn macht, weil sonst die internen TOS Funktionen zum Laden der Datei verwendet werden (es wird dort nicht noch einmal über den GEMDOS-Trap gesprungen). Vermutlich auch der Grund dafür, daß die Speicherverwaltung gleich mit ersetzt wird.

Ist jetzt auch kein Beinbruch wenn Memtest da andere Werte ergibt... oder hat jemand out of the box bemerkt das der TT langsamer wäre als vorher?

[1ST1]

... Rest des Bootvorgangs ...

Laden des Desktops & Starten der ACCs ist Sache der AES.
Mit deren Start wird die Abarbeitung des AUTO\ abgebrochen,
bzw. umgekehrt: Wenn man die Abarbeitung des AUTO\ abbricht, dann starten automatisch die AES. Kann man in AUTAXI ansehen.

Da hast du ja im Prinzip recht, aber nur für ein normales TOS. Denn das AES zeigt nicht in einer Liste an, welche ACCs gerade geladen werden, kurz bevor der Desktop erscheint. Aber genau dies passiert, sobald Bigdos auf dem Falcon ins Spiel kommt. Einfach mal selbst ausprobieren und beobachten...

[ari.tao]

^^-- Anstatt von der Boot-Root lade ich meine ACCs lieber aus einem dafür festgelegten beliebigen Ordner, was zB. mit MagiC, Geneva oder NAES möglich ist.

-------

... oder hat jemand out of the box bemerkt das der TT langsamer wäre als vorher?

Seit Thunder eingebaut ist und alle Prg.-Flags auf TT-RAM gesetzt sind habe ich den deutlichen Eindruck, daß mein TT erheblich schneller läuft.

[Arthur]

... oder hat jemand out of the box bemerkt das der TT langsamer wäre als vorher?

Seit Thunder eingebaut ist und alle Prg.-Flags auf TT-RAM gesetzt sind habe ich den deutlichen Eindruck, daß mein TT erheblich schneller läuft.

Einzig bei Memtest sehe ich unterschiedliche Werte aber im Alltag spüre ich wenig bis nichts davon. Vielleicht sieht man es im Benchmark?

[Lukas Frank]

Oder mal mit Stopuhr ein 20MB oder größer TIFF Bild laden

[czietz]

Das ist mit Sicherheit kein Problem, das nur Memspeed betrifft. Alle Programme, die Speicher per Mxalloc(..., 1) (nur TT-RAM) anfragen, können fälschlicherweise auch ST-RAM bekommen. Warum man es in der Praxis so wenig merkt, könnte zwei Gründe haben: Programme die sehr viel Speicher anfragen, mehr als den freien ST-RAM, bekommen von Big-DOS TT-RAM. Programme die TT-RAM nicht per Mxalloc sondern Prgflags haben wollen, bekommen vermutlich auch TT-RAM; letzteres habe ich allerdings nicht getestet.

Was ist denn aus den Kontaktaufnahmen zum Autor geworden?

[Arthur]

Oder mal mit Stopuhr ein 20MB oder größer TIFF Bild laden

Vermutlich wird wohl die Platte das Nadelöhr sein.