Software > Software (16-/32-Bit)

Probleme und Fehler im BigDOS ...

<< < (10/19) > >>

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:

--- Zitat von: Thorsten Otto am Sa 01.09.2018, 15:23:04 ---
--- Zitat von: Nervengift am Sa 01.09.2018, 13:47:25 ---Fürs EmuTOS fände ich's echt cool, wenn es größere Partitionen oder Spechermedien von Haus aus unterstützte.
--- Ende Zitat ---

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).


--- Ende Zitat ---

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:

--- Zitat von: Lukas Frank am Do 30.08.2018, 18:51:21 ---
--- Code: ---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.
--- Ende Code ---

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

czietz:

--- Zitat von: KarlMüller am So 09.09.2018, 08:40:58 ---Wie sind denn im besagten Fall die Programmflags von BigDOS gesetzt? Ist Bit 2 gesetzt, das Malloc Speicher aus dem Alternate-RAM bedient?

--- Ende Zitat ---

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..

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete