atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: Lukas Frank am Do 30.08.2018, 18:51:21
-
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.
Schade da BigDOS dringend benötigt wird z.B. bei FAT16 USB Sticks unter single TOS.
Hat denn jemand eine Mailadresse des BigDOS Autors oder Kontakt?
-
Ist die Adresse auf seiner Webseite nicht mehr gültig?
http://rainer-seitel.onlinehome.de/bigdos.html
Optimal fände ich es, wenn man Rainer Seitel überzeugen könnte, Big-DOS als Open-Source zu veröffentlichen. (Wie es Andreas Kromke mit MagiC macht.) Denn wie Frank schon schreibt, ist Big-DOS immer noch alternativlos, um am PC eingerichtete FAT16-Dateisysteme zu lesen. Es sei denn man wechselt z.B. auf EmuTOS, natürlich.
-
Ist die Adresse auf seiner Webseite nicht mehr gültig?
Die Maus-Addresse? Ganz bestimmt nicht ;)
-
Im Impressum steht eine andere
http://rainer-seitel.onlinehome.de/impressum.html
-
Die Yahoo-Adresse habe ich mal angemailt und keine Antwort bekommen. Über Teleauskunft.de bekommt man in Rastatt auch niemanden dieses Namens, nur einen Norbert in Gaggenau.
Vielleicht kann man ihn hierüber erreichen, die Einträge sind von 2016: https://vimeo.com/user9233816
Das ist noch viel aktueller: https://www.youtube.com/playlist?list=UU4VMc3B-RuNHZz3cRyIjSGg - Er hat einen aktuellen Google Account. Möchte jemand versuchen, ihn darüber zu kontaktieren?
-
Übrigens, weitere Fehler:
1. Muss beim Falcon als allerletztes Programm im Auto-Ordner gestartet werden, weil BigDOS den GEM-Start an sich reißt, und hinter BigDOS keine weiteren Programme im Autoordner mehr ausgeführt werden.
2. Öfters gelingt es nicht, (leere) Ordner auf der Platte zu löschen, wenn BigDOS aktiv ist.
Noch ein Thread zu BIGDOS-Fehler: https://forum.atari-home.de/index.php?topic=13490.20
- Demnach kennt @gh-baden Reiner Seitel höchstpersönlich und sieht ihn hin und wieder?
-
Schreibe mir mal eine PM mit der Google Account.
-
Ich habe ihm bereits auf seine Youtube-Pinnwand geschrieben. Über Google+ finde ich ihn nicht.
Da ist ein Foto von ihm: http://piraten-mittelbaden.de/landtagswahl-2016/
-
Noch ein Thread zu BIGDOS-Fehler: https://forum.atari-home.de/index.php?topic=13490.20
- Demnach kennt @gh-baden Reiner Seitel höchstpersönlich und sieht ihn hin und wieder?
Streiche das "höchst", aber ja, ich kenne Rainer. Und alle Jahre seh ich ihn mal. Wenn es sich ergibt, frage ich ihn.
-
Die gesamte Funktionalität von BigDOS (und noch mehr!) ist iirc schon von FN in MiNT eingebaut worden; und die MiNT-Quellen sind doch offen...
-
Kannst dich ja mal hinsetzen, und aus den MiNT Sourcen (oder EmuTOS!!!!) alles benötigte rausholen und daraus ein BigDOS-Ersatz für alle möglichen TOS-Versionen kompilieren.
-
Muß ich gar nicht, ich habe einfach MiNT_1.15.9 installiert. :-*
-
Unter MiNT läuft nicht alles. Je nach Rechner braucht MiNT auch zu viel Speicher.
-
Jeder Atari läßt sich auf min. 4MB aufrüsten: Mehr als genug RAM.
Was läuft nicht? MiNT läßt sich bei Bedarf via Tasten beim Boot aushängen.
-
Was läuft nicht? MiNT läßt sich bei Bedarf via Tasten beim Boot aushängen.
... womit man dann wieder das Problem hätte, dass man auf einem TOS 2.0x/3.0x Rechner nicht auf die 1 GB Partition drauf kommt*, auf der das auszuführende Programm liegt. Denn BigDOS ist neben MiNT die Möglichkeit, auf solche Partitionen zuzugreifen....
Henne, Ei, Henne, Ei, ...
* auch bei älteren TOS-Versionen verdoppelt BigDOS die maximale Partitionsgräße (256->512)
-
FAT16-Partitionen > 255,9MB sind sowieso Unsinn wg. #Verschnitt (außer in Deinem Hühnerstall natürlich). Mit MiNT aber kann man riesiges FAT32 sinnvoll betreiben - mit BigDOS nicht.
-
Soso, Unsinn... Du solltest dazu schreiben, dass das dein IMHO ist, und nicht allgemeingültig.
14*256 MB = 3,5 GB, also von C: bis P: . Ich erschlage das auf dem TT mit 3 Partitionen (1x 512 MB + 3x 1 GB) oder auf dem Falcon mit 4x 1 GB und hätte mit einer 4 GB CF noch immer 10-11 Laufwerksbuchstaben frei.
Wenn man so viele und große Partitionen hat, ist "Verschnitt" mehr oder weniger Egal. Ich bekomme so immer noch auf einer 16 GB CF mit 14 1Gb Partitionen mehr Dateien unter, als du auf einer 4 GB mit 14x 256 MB.
In der Realität nutze ich aber 32 GB CFs (Falcon) und 73 GB SCSI (TT), die Laufwerksbuchstaben C-P (und Dank HDDRIVER und BIGDOS darüber hinaus) sind jeweils so große Partitionen wie geht, und der Rest ist als eine große ext2 Partition für MiNT reserviert.
Der Verschnitt ist übrigens maximal so groß, wie Dateien auf der Partition liegen, deren Größe nur mit Rest durch die Clustergröße teilbar sind. Der maximale Verschnitt pro Datei ist maximal Clustergröße minus ein Byte. Das selbe gillt übrigens auch für kleinere Partitionen.
Übrigens bedeutet "Egal" bzw. "Verschnitt" bei CF Karten, dass die CF oder SD derart unbenutzte Sektoren innerhalb eines Clusters für "wear levelling" nutzen kann. Das heißt, das ist sogar gut für die Haltbarkeit von Flash-Medien. Siehe https://de.wikipedia.org/wiki/Solid-State-Drive#Wear-leveling
Ich würde mir übrigens wünschen, zumindestens mit dem Falcon könnte ich auf der "internen" CF (also die, die immer drin bleibt) sogar die unter DOS/Windows bei FAT16 eigentlich maximal nutzbaren 2- oder 4 GB Partitionen anlegen. Denn das würde mir weitere Laufwerksbuchstaben einsparen, ich könnte sämtliche Szene-Demos für den Falcon auf eine Partition legen, und eine noch größere MOD und MP3-Sammlung auf dem Falcon ablegen. Ich verfahre nämlich nach dem Motto "Eine Partition" pro Anwendung/Datentyp, sofern die Sammlung zu dem Thema etwas größer ist. Das wäre der Übersicht sehr einträglich.
-
Übrigens bedeutet "Egal" bzw. "Verschnitt" bei CF Karten, dass die CF oder SD derart unbenutzte Sektoren innerhalb eines Clusters für "wear levelling" nutzen kann. Das heißt, das ist sogar gut für die Haltbarkeit von Flash-Medien. Siehe https://de.wikipedia.org/wiki/Solid-State-Drive#Wear-leveling
Das ist IMHO Unsinn. Zum einen weiss ein SSD Drive herzlich wenig irgendwas von Clustern. Zum anderen werden die unbenutzten Sektoren eines Clusters ja gar nicht erst beschrieben, und demzufolge auch nicht als "nicht mehr aktuell" markiert.
Ich würde mir übrigens wünschen, zumindestens mit dem Falcon könnte ich auf der "internen" CF (also die, die immer drin bleibt) sogar die unter DOS/Windows bei FAT16 eigentlich maximal nutzbaren 2- oder 4 GB Partitionen anlegen.
Mit originalem TOS geht das halt nicht, das hat nun mal diese Enschränkungen. Klar wäre es toll wenn GEMDOS das von Anfang an richtig gemacht hätte, dann hätte man diese Probleme nicht (zumindest nicht bis ~4GB, mehr geht halt bei FAT16 nicht). Aber der Zug ist nunmal abgefahren.
-
Letzteres Problem könnte eine neuere Version von BigDOS lösen. (Oder EmuTOS) Mal gespannt, ob an den BigDOS-Quellcode heran zu kommen ist. Siehe anderen Thread.
Die SSD/CF/SD muss nichts von Clustern wissen. Sie arbeitet scheinbar mit einem Zähler pro physischem Speicherblock, und mappt/beschreibt immer die bisher am wenigsten beschriebene Blöcke auf die logischen Sektoren, die das Betriebssystem zu sehen bekommt. Das ist aber sehr vereinfacht ausgedrückt, in wirklichkeit ist der Algorythmus dahinter sicher komplexer, denn sonst würden ja irgendwann schon vor langer langer Zeit das letzte Mal mit Inhalt beschriebene Blöcke überschrieben, obwohl sie noch gebraucht werden. In dem Wikipedia-Artikel steht dazu ein bischen was.
-
Letzteres Problem könnte eine neuere Version von BigDOS lösen. (Oder EmuTOS)
Ja, eben. Irgendeinen Zusatz wirst du immer brauchen. Aber selbst bei 4GB Partiotionen wirst du Festplatten von >70GB ohne das ext2-Dateisystem von MiNT nicht sinnvoll nutzen können.
-
Das FS ext2 ist eine Un*x-Angelegenheit und hat mit MiNT generisch nix zu tun. Für MiNT genügt FAT32 - wie es bis dato von jeder WinDose benutzt wird (und Un*x kommt afaik damit auch klar und erzwingt kein ext2).
Hat mal jmd. nachgerechnet, wie lange ein BackUp von 73GB auf dem Atari braucht?!
Solche Mengen, Mr. "IMHO", sollten besser nicht einem Atari zugemutet werden. Und wenn Du mal Deine 4GB-CF nahezu voll hast (wie ich), dann wirst auch Du nach Wegen suchen, mehr als 50% Verschnitt (mit einer Atari-typischen File-Mischung - auf die Praxis kommt´s an!) auf ca. 20% zu reduzieren.
Lediglich Musiker brauchen Partitionen > 255MB (und haben mit ihren riesigen Files dann auch wenig Verschnitt).
-
Hat mal jmd. nachgerechnet, wie lange ein BackUp von 73GB auf dem Atari braucht?!
*kicher*
Ich hab hier noch ein paar 40GB SCSI Tapestreamer rumliegen, falls jemand interesse hat.
-
Für MiNT genügt FAT32
Ja, aber auch dafür brauchst du MiNT, solange kein anderes TOS das kann. Dann kannst du auch gleich das viel besser organisierte ext2 nehmen.
Hat mal jmd. nachgerechnet, wie lange ein BackUp von 73GB auf dem Atari braucht?!
Grob geschätzt, bei einer Übertragungsrate von 2MB/sec (was schon optimistisch sein dürfte) 10h.
Lediglich Musiker brauchen Partitionen > 255MB
(du meinst vermutlich GB)
Kann man so nicht sagen. Meine Arbeitspartition ist knapp 500GB, und die ist zu 80% belegt. Da ist keine einzige Musik-Datei drauf.
-
Ich hab hier noch ein paar 40GB SCSI Tapestreamer rumliegen, falls jemand interesse hat.
Welche Technik? SLR? DDS? VXA?
-
Welche Technik? SLR? DDS? VXA?
Zwei von diesen DLT1 Laufwerken, ein kleineres das aber kaputt ist, dazu ein 7-fach Tapemagazin das aber auch nicht funktioniert (das dort verbaute Laufwerk ist wohl kaputt), und noch 2 DDS-Streamer.
Von den DLT-Bändern hab ich noch so ca. 20 Stück oder so, die meisten unbenutzt.
-
Letzteres Problem könnte eine neuere Version von BigDOS lösen. (Oder EmuTOS)
Ja, eben. Irgendeinen Zusatz wirst du immer brauchen. Aber selbst bei 4GB Partiotionen wirst du Festplatten von >70GB ohne das ext2-Dateisystem von MiNT nicht s
Sinnvoll nutzen können.
Das lass mal meine Sorge sein...
-
Hat mal jmd. nachgerechnet, wie lange ein BackUp von 73GB auf dem Atari braucht?!
Auf den Rest gehe ich erstmal nicht weiter ein. Aber das hier. Du vergisst, dass ich einen Fileserver habe. Siehe es eher so: Das was auf dem Atari liegt, ist ein von 2 Backups. Also, alles IMHO kein Problem.
-
Was macht denn der Versuch der Kontaktaufnahme?
-
Meine Arbeitspartition ist knapp 500GB, und die ist zu 80% belegt. Da ist keine einzige Musik-Datei drauf.
Aif meinem "Dicken" PC ist die Platte mit Daten 2 TB groß, und zu 60% voll. Fotos in verschiedenen Bearbeitungsstufen, selbst aufgenommene Videos, Materialsammlungen zu verschiedenen technischhistorischen Themen (zu dem einen hab ich mit nem Bekannten eine Webseite, die allerdings die letzten Jahre kaum geupdated wurde, weil das Thema inzwischen im Prinzip erforscht ist. Und der gangte Bürokram, den man so anhäuft. Der FIleserver hat rund 18TB, zu 70% voll, viele Multimedia-Sachen, wobei ganz wichtige Sachen wöchentlich auf eine zweite Platte gesynct werden. Da ist auch das Retro-Computer-Zeug dabei. Von den TV-Aufnahmen mache ich keine Backups. Und mein Netbook, mit dem ich auch gerade rumtrippe, hat eine 1 TB SSD, 700 GB Datenpartition, mit dem was ich immer um mich herum haben muss. Wenn ari.tao mit weniger auskommt, ist das schön für ihn.
-
Boah, @Lukas Frank, hast recht , was wir hier schon wieder offtopic sind... Also, zurück zu BigDOS.
-
Nicht ´wir´, sondern _Du_ bist hier schon wieder OT. Ich hatte lediglich die Probleme und Fehler von BIGDOS mit den Vorteilen von MiNT verglichen und habe mich ausdrücklich auf Datenmengen im Atari bezogen - Du aber nimmst das zum Anlaß für eine Märchenstunde über Deine PC-Boliden: Dazu frage ich bloß ´cui bono´?
Und wenn´s nun ´zurück zu BigDOS´ gehen soll:
Was macht denn der Versuch der Kontaktaufnahme?!!
(Würde mich sehr wundern, wenn RS noch ´was an BigDOS basteln tät - der weiß ja auch um MiNT).
-
Siehst du, es geht hier nicht um Datenmengen, die du (ver)brauchst, es geht hier um die Möglichkeiten von BigDOS, und deren Verbesserung.Da ist deine Zufriedenheit mit dem Status Quo völlig fehl am Platz.
BigDOS ist nicht älter als MiNT, sogar eher jünger, und trotzdem gibt es das. Was die Kontaktaufnahme zu RS angeht, findest du den bisherigen Stand hier im Thread, inzwischen etwas versteckt, durch Postings, die behaupten Partitionen über 256 MB wären Platzverschwendung.
Ich denke, du solltest dich mal etwas zügeln, sonst geraten wir beide uns wieder in die Haare, die jeweiligen Folgen sind bekannt.
-
... Du aber nimmst das zum Anlaß für eine Märchenstunde über Deine PC-Boliden: Dazu frage ich bloß ´cui bono´?
Das ist bloß die übliche Phase 3 (https://forum.atari-home.de/index.php/topic,14592.msg230987.html#msg230987).
Nach "ahnungslos, aber vehement Mist behaupten" (wear leveling), ", "Widerspruch mit abstrus hergegoogeltem Material, das nichts mit dem Einwand zu tun hat, bekämpfen" kommt eben "wenn's argumentativ eng wird, schnell Thema wechseln".
Immer die gleiche Leier.
-
Jetzt bereits in Phase_4:
"Wenn auch die Abschweifung in´s OT nicht hilft, dann den zum Feind erkorenen auf der persönlichen Ebene atackieren":
Ich denke, du solltest dich mal etwas zügeln,...
Ich rätsele immer noch, welche Motivation dahintersteckt. Wenn er so durchschaut wird, dann müßte das doch eigtl. einen Paradigmenwechsel zur Folge haben...
PS: Rhetorik war ein Lieblingssport der Römer.
-
Ich rätsele immer noch, welche Motivation dahintersteckt. Wenn er so durchschaut wird, dann müßte das doch eigtl. einen Paradigmenwechsel zur Folge haben...
Das ist wohl aufgrund seines Dickkopfes, Sturrheit, Rechthaberei etc. ihm wohl nicht möglich. Wie @mfro schon schrieb, "er hat Recht und wir unsere Ruhe". Ab einem bestimmten Punkt hilft nur noch ignorieren. Alles andere wäre dann irgendwie für mich unnötige Energieverschwendung. Also mal zurück zum Thema!
Ich hatte Bigdos nie im Einsatz. Ich hatte das mal versucht, aber da es beim Booten abstützte, hatte ich's dann gelassen. Ich hatte auch nie die Veranlassung es zu nutzen, da ich schon seitdem ich im Besitz eines Falcons bin (1998) MiNT nutze. Im Grunde brauche ich auch nicht so viel Speicherplatz. Wie jemand das nun organisiert mit dem Speicherplatz, das soll meinetwegen jeder selber wissen.
Fürs EmuTOS fände ich's echt cool, wenn es größere Partitionen oder Spechermedien von Haus aus unterstützte. Wäre sicherlich ein Argument mehr für EmuTOS. Ansonsten machen MiNT und Magic das, was ich brauche. Ich bin kein Programmierer oder Entwickler, aber wäre es möglich EmuTOS neue Dateisysteme beizubringen oder führte das dann zu einem Aufblähen von EmuTOS, was die Entwickler sicherlich nicht wollen?
-
Der Grund warum man BigDOS bei den USB Lightning Geschichten braucht ist das man FAT16 am PC eingerichtete USB Sticks oder auch andere Medien benutzen kann mit dem Atari. Das geht ansonsten nur mit EmuTOS und das benutze ich persönlich nicht weil es doch noch Software gibt die es zum Absturz bringt und beim Atari TT fehlt ja da wohl noch einiges ...
-
Ich hatte das mal versucht, aber da es beim Booten abstützte, hatte ich's dann gelassen.
Genau so ging es mir auch.
-
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).
wäre es möglich EmuTOS neue Dateisysteme beizubringen oder führte das dann zu einem Aufblähen von EmuTOS, was die Entwickler sicherlich nicht wollen?
Möglich schon, aber sicher sehr aufwendig. Und dann, wegen dem ohnehin schon knappen Platz in den meisten ROM-Versionen, sicherlich nicht für alle Maschinen verfügbar. Fragt sich auch wer dann die Beta-Versionen, die sicherlich noch Fehler haben werden, auf seine Platten loslässt ;)
-
Möglich schon, aber sicher sehr aufwendig. Und dann, wegen dem ohnehin schon knappen Platz in den meisten ROM-Versionen, sicherlich nicht für alle Maschinen verfügbar. Fragt sich auch wer dann die Beta-Versionen, die sicherlich noch Fehler haben werden, auf seine Platten loslässt ;)
Ersteres sehe ich da schon echt als Problem. Letzteres finde ich weniger dramatisch, da einige doch ein paar Platten rumliegen haben, die man für solche Basteleien ja durchaus hin und wieder einsetzt. :D Für Clones wie die Firebee wäre das bestimmt klasse, wenn EmuTOS auch von Haus aus andere Dateisysteme unterstützte, aber man soll ja auch nicht übertreiben. ;)
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.
-
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 …
-
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"? :D
-
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. >:D
oder sie sehen es aus der Perspektive des "proof of concept"? :D
Man muss, weil man kann. Auch eine Möglichkeit. :D
-
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.
-
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 :-)
-
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.
-
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.
-
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....
-
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 (https://freemint.github.io/tos.hyp/de/gemdos_programs.html#Die_20Programmflags) von BigDOS gesetzt? Ist Bit 2 gesetzt, das Malloc Speicher aus dem Alternate-RAM bedient?
-
Wie sind denn im besagten Fall die Programmflags (https://freemint.github.io/tos.hyp/de/gemdos_programs.html#Die_20Programmflags) 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...
-
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..
-
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 (https://freemint.github.io/tos.hyp/de/gemdos_programs.html#Die_20Programmflags) 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.
-
... 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.
-
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.
-
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?
-
... 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...
-
^^-- 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.
-
... 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?
-
Oder mal mit Stopuhr ein 20MB oder größer TIFF Bild laden
-
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?
-
Oder mal mit Stopuhr ein 20MB oder größer TIFF Bild laden
Vermutlich wird wohl die Platte das Nadelöhr sein. >:D :D
-
Was ist denn aus den Kontaktaufnahmen zum Autor geworden?
Auf meinem Eintrag in der Youtube-Pinnwand hat er bisher wohl nicht reagiert. Meine Hoffnung berugt auf @gh-baden. Eine andere Möglichkeit habe ich noch nicht gefunden. Wenn noch jemand eine Idee hat...?
Wenn das nicht klappt, müsste sich vielleicht jemand hinsetzen, und das GEMDOS aus EmuTOS herausoperieren, idealerweise um Support für FAT bis 4 GB erweitern, und das als Autootdner-Patch anbieten.
-
Kontaktiert ihn über die Piratenpartei.
-
Kontaktiert ihn über die Piratenpartei.
Das ist noch einen Versuch wert, ich habe mal eine Mail an die Info-Adresse des Ortsverbandes Rastatt geschickt, ich hoffe, dass sie es weiterleiten.
-
müsste sich vielleicht jemand hinsetzen
Da war er wieder...
und das GEMDOS aus EmuTOS herausoperieren, idealerweise um Support für FAT bis 4 GB erweitern, und das als Autootdner-Patch anbieten.
...und sich damit die gleichen Probleme wie BigDOS einhandeln. Die Speicherverwaltung vom GEMDOS ist dann schon initalisiert, inklusive vlt. schon resident installierter Programme. Pexec etc musst du aber abfangen weil du Programme von deinen Partionen laden können willst. Womit wir wieder am Anfang wären. Klasse daß du dir das immer alles so einfach vorstellst. Wenns das wäre hätte es vermutlich schon längst jemand gemacht.
-
^^-- Kommt mir vor wie die Fahrrad-Szene, wo auch das Rad immer wieder neu erfunden wird.
Warum eigtl. gibt es keine Adapter IDE2USB ? Müßte doch viel höhere Transferraten haben als L.
-
^^-- Kommt mir vor wie die Fahrrad-Szene, wo auch das Rad immer wieder neu erfunden wird.
Warum eigtl. gibt es keine Adapter IDE2USB ? Müßte doch viel höhere Transferraten haben als L.
Darf ich dich darauf aufmerksam machen, dass das nicht zum Thema gehört? Mach einen Thread dafür auf und fang an zu entwickeln.
-
...und sich damit die gleichen Probleme wie BigDOS einhandeln. Die Speicherverwaltung vom GEMDOS ist dann schon initalisiert, inklusive vlt. schon resident installierter Programme. Pexec etc musst du aber abfangen weil du Programme von deinen Partionen laden können willst. Womit wir wieder am Anfang wären. Klasse daß du dir das immer alles so einfach vorstellst. Wenns das wäre hätte es vermutlich schon längst jemand gemacht.
Dann muss der neue GEMDOS Treiber wohl in den Plattentreiber rein?
-
^^-- Kommt mir vor wie die Fahrrad-Szene, wo auch das Rad immer wieder neu erfunden wird.
Warum eigtl. gibt es keine Adapter IDE2USB ? Müßte doch viel höhere Transferraten haben als L.
Darf ich dich darauf aufmerksam machen, dass das nicht zum Thema gehört?
Darf ich Dich darauf aufmerksam machen, daß der erste Teil direkt zum Thema gehört.
Und der zweite Teil ist eine Anmerkung zum EingangsPosting des OP (habe bloß nix zitiert).
Außerdem schreibe ich keine OT-Romane wie Du sondern bloß kurze RandBemerkungen.
... und fang an zu entwickeln.
... alles wie gehabt:
müsste sich vielleicht jemand hinsetzen
Da war er wieder...
-
Die Programmflags sind hier nicht relevant, weil Big-DOS sowieso sämtlichen Speicher übernimmt (ST- und TT-RAM) und seine eigene Speicherverwaltung installiert.
Du hast recht, ich hätte da vorher nachschauen sollen.
Wäre es open-source, hätte ich das schnell gefixt...
Ich hätte da, allerdings für den aktuellen Fall, zwei total unwichtige Teile im Quellcode. Einmal das Löschen der CPU Cache und die Auflösung des Versionsstring als Zeichenkette. ;D
Ansonsten hatte ich es mal vor längerem dissaembliert. Ist aber alles andere als einfach da durch zu blicken.
Kennt jemand den Inhalt des Cookies "MPB*" den, wenn ich es richtig sehe, Big-DOS anlegt?
-
Vermutlich ein Zeiger auf den ´Memory Parameter Block´
-> ProfiBuch S.89
-
Kennt jemand den Inhalt des Cookies "MPB*" den, wenn ich es richtig sehe, Big-DOS anlegt?
http://toshyp.atari.org/de/003007.html#MPB
-
Was ist eigentlich aus diesem Thema geworden? Hat jemand Kontakt zu Rainer Seitel bekommen?
-
Was ist eigentlich aus diesem Thema geworden? Hat jemand Kontakt zu Rainer Seitel bekommen?
Wenn (von meiner Seite), dann kommt er zu einer Veranstaltung am Anfang. Dann ja. Sonst nicht.
-
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.
Für das oben genannte Problem in BigDOS habe ich eine Lösung; das bekomme ich auch im Binary gepatcht. Besteht Interesse?
-
Für das oben genannte Problem in BigDOS habe ich eine Lösung; das bekomme ich auch im Binary gepatcht. Besteht Interesse?
Natürlich, ohne BigDOS kann man Fat16 USB Stick nicht benutzen unter TOS.
-
Ich habe ehrlich gesagt noch niemals BigDos genommen, ich habe einen Stick den ich mir mit HDDriver eingerichtet habe. Diesen auf 4 Partitionen aufgeteilt mit je 500Mb und diese dann Windows Kompatibel gemacht. Bigdos habe ich noch nie verwendet da ich es auf dem TT noch nie zum laufen gebracht habe. Habe immer nur Bomben erhalten (auch ohne USB), Und da ich Win10 verwende kann ich auch auf alle 4 Partitionen zugreifen.
-
Habe ich jetzt auch so gemacht allerdings kann ich keine USB Sticks unter Single TOS partitionieren "Die Kapazität des Mediums konnte nicht ermittelt werden". Unter MiNT klappt das partitionieren. Ein Nachteil gegenüber BigDOS ist natürlich die Langsamkeit, bei mir so um 350kB/s ...
-
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.
Für das oben genannte Problem in BigDOS habe ich eine Lösung; das bekomme ich auch im Binary gepatcht. Besteht Interesse?
Das war doch rhetorisch gemeint, oder? >:D ;D
-
Für das oben genannte Problem in BigDOS habe ich eine Lösung; das bekomme ich auch im Binary gepatcht. Besteht Interesse?
Ja, es besteht Interesse. Es besteht auch Interessa an weitere Bugfixes. Wir müssen nur uns noch festlegen, welche BigDOS-Version modifiziert wird. Es gibt ja neben der "normalen" auch eine, die auch auf Falcon mit 060 läuft... (die aber als Letztes im Autoordner stehen muss damit sie funzt)
-
Ja, es besteht Interesse. Es besteht auch Interessa an weitere Bugfixes. Wir müssen nur uns noch festlegen, welche BigDOS-Version modifiziert wird. Es gibt ja neben der "normalen" auch eine, die auch auf Falcon mit 060 läuft... (die aber als Letztes im Autoordner stehen muss damit sie funzt)
Hat dieser Falcon dann auch TT-RAM? Mein Bugfix (gibt's voraussichtlich am Wochenende) betrifft ja das Anfordern von TT-RAM.
-
Mein Falcon mit ct60e hat selbstverständlich TT-RAM. 512 MB, um genau zu sein... Ist halt nur die Frage, ob deine Bigdos-Version, die du fixen willst, grundsätzlich auf dem Falcon läuft. Möchtest du mal die Version haben, die ich dort verwende?
-
Mein Falcon mit ct60e hat selbstverständlich TT-RAM. 512 MB, um genau zu sein... Ist halt nur die Frage, ob deine Bigdos-Version, die du fixen willst, grundsätzlich auf dem Falcon läuft. Möchtest du mal die Version haben, die ich dort verwende?
Ja. Ich nehme an, es ist nicht die im Downloadarchiv von Big-DOS 8 enthalten ist.
-
Alles was Ich kann sagen hier, um Topic ist: statt fixen problemen mit BigDOS es wurde besser zum schreiben ganz neue Program mit Gleiche Ziel - unterstützung von DOS art FAT16 BifDOS Partizionen.
Aber warum im Jahr 2018 ? Wer wird starten gross Arbeit auf das ?
Viel besser ist zu modifizieren TOS selbst. And das ist was ich habe gemacht mit TOS für ST, STE, Mega ST, Mega STE .
Ich kann verstehen das Leute möchtet gleich für TT und Falcon. Aber bitte verstehen das das ist sehr viel Arbeit and viel Zeit ist benötigt. Atari könnte lösen es selbst, aber das passierte nicht - von 1984 bis 1992 (wann Falcon gehte auf Markt, mit um halb Jahr verzögerung - ich kenne das genau - Ich plannierte zum kaufen) .
Ich denkte um improvieren FAT16 von TOS 1.04 10 Jahres vor. Aber ich kennte das es ist sehr schwer und viel Zeit ist benötigt. Besonders ohne Sourcen .
Was ist möglich zu machen mit TOS 4.04 ? Machen gleich als Ich habe gemacht mit 1.04 - disassemblieren - 100% korrekt disasm. braucht viel Zeit, 100 Stunden mindestens. Dann machen alle modifikazionen. Testen .... Aber ... Ich kann nicht laufen Falcon TOS im Steem Debugger. And ohne so gut und user-friendly Werkzeug alles das wurde dauern 3x mehr. So statt 2 Monaten 6 Monaten, glaublich.
Andere Weg: brauchen C Sourcen von TOS 4.04 - wann es sind erreichbar. Ich kenne nicht über das.
Arbeit für gut C Koder (was Ich bin nicht).
Dann Leute wurde haben improviert Falcon TOS, und könnte brauchen DOS Partizionen ohne BigDOS.
Driite Weg ist brauchen TOS/DOS kompatibel hard disk driver SW.
-
A fixed BigDos is enough, TT and Falcon have plenty of RAM, don't care for loading it. Or taking the EmuTOS FAT support code, enhance it for support of 1 Gb (or 2 GB?) Fat 16 partitions, and create a new BigDOS driver for original TOS from that.
-
... Or taking the EmuTOS FAT support code, enhance it for support of 1 Gb (or 2 GB?) Fat 16 partitions ...
EmuTOS unterstützt 2 GB (DOS-) Partitionen. Seit (ungefähr) 7 Jahren.
-
Um so besser. Wer machts? (Mir fehlen dazu die Programmierkenntnisse... :-( )
-
(Mir fehlen dazu die Programmierkenntnisse... :-( )
Keine Ausrede. Kann man sich aneignen.
-
Würde aber lange dauern... Für euch ist das eine Fingerübung.
-
Da ich 1ST1s "Spezialversion" nicht bekommen habe, hier ein reguläres Big-DOS 8, händisch gepatcht bzgl. des Mxalloc-Bugs, der in https://forum.atari-home.de/index.php/topic,14630.msg231628.html#msg231628 beschrieben ist.
Ich habe es aus Zeitgründen nur unter Hatari getestet, evtl. mag jemand anders bestätigen, dass nun die MEMSPEED-Werte auf dem TT erwartungsgemäß ausfallen. (Das war ja der Grund, warum dieses Problem überhaupt bemerkt wurde.)
-
Bei mir am Atari TT sind die Memspeed Werte für das TT Ram wieder in Ordnung.
-
Bei mir am Atari TT sind die Memspeed Werte für das TT Ram wieder in Ordnung.
Danke fürs Testen.
-
Da ich 1ST1s "Spezialversion" nicht bekommen habe,
Besser spät als nie...
Wer die XBoot-Version noch sucht, die auf dem 060 geht, PN...