Probleme und Fehler im BigDOS ...

[1ST1]

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.

[Gaga]

Kontaktiert ihn über die Piratenpartei.

[1ST1]

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.

[Thorsten Otto]

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.

[ari.tao]

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

[1ST1]

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

[1ST1]

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

[ari.tao]

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

[KarlMüller]

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. 

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?

[ari.tao]

Vermutlich ein Zeiger auf den ´Memory Parameter Block´
   -> ProfiBuch S.89

[Arthur]

Kennt jemand den Inhalt des Cookies "MPB*" den, wenn ich es richtig sehe, Big-DOS anlegt?

http://toshyp.atari.org/de/003007.html#MPB

[czietz]

Was ist eigentlich aus diesem Thema geworden? Hat jemand Kontakt zu Rainer Seitel bekommen?

[goetz @ 3rz]

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.

[czietz]

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.

Für das oben genannte Problem in BigDOS habe ich eine Lösung; das bekomme ich auch im Binary gepatcht. Besteht Interesse?

[Lukas Frank]

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.

[tuxie]

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.

[Lukas Frank]

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

[Arthur]

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.

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?

[1ST1]

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)

[czietz]

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.