atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: Atariosimus am So 30.12.2018, 00:21:11
-
Das neue EmuTOS 0.9.10 ist auf EPROMs gebrannt.
Vermisse dabei die Anzeige der Dateigrösse.
Beim TOS 2.06 wurde diese immer angezeigt beim Anklicken einer bestimmten Datei.
Jetzt wird nur noch konstant ein Wert aller Dateien auf einer Partition angezeigt,
die auf der obersten Ebene sind.
Ist das Absicht?
Weiterhin wird im Mid Res Modus bei XBoot folgende Meldung angezeigt:
XBoot benötigt eine Auflösung von Mindestens 640x200 Pixel
Mit Taste ESC kommt man dann erst weiter. Leider führt er dann das Xboot aus ohne das man
noch Einfluss hat. Jetzt kann man nur im High Res Modus XBoot ganz abschalten und
dann im Mid Res weitermachen um zum Beispiel Spiele auszuführen. Das war beim TOS
einfacher. Andernfalls wird der Speicher durch Programme belegt.
Liegt das am TOS 2.06, dass etwas toleranter ist?
-
Jetzt wird nur noch konstant ein Wert aller Dateien auf einer Partition angezeigt,
die auf der obersten Ebene sind.
Ist das Absicht?
Es wird (wie in TOS 1) die Größe aller Dateien im jeweils geöffneten Ordner angezeigt. Es ist korrekt, dass nicht die Größe der ausgewählten Dateien angezeigt wird.
Weiterhin wird im Mid Res Modus bei XBoot folgende Meldung angezeigt:
XBoot benötigt eine Auflösung von Mindestens 640x200 Pixel
Das musst Du mir näher erklären: Du startest XBoot doch offensichtlich direkt beim Booten. Woher weißt Du dann, dass Du im "Mid Res Modus" bist; das kannst Du doch zu diesem Zeitpunkt noch gar nicht auswählen.
Davon abgesehen: Ich guck's mir mal an.
-
Das musst Du mir näher erklären: Du startest XBoot doch offensichtlich direkt beim Booten. Woher weißt Du dann, dass Du im "Mid Res Modus" bist; das kannst Du doch zu diesem Zeitpunkt noch gar nicht auswählen.
Ja, Xboot wird direkt beim Booten gestartet. Nachdem ich die ESC Taste gedrückt habe um die Meldung weg zu bekommen geht es in die genannte Auflösung. Bei TOS gibt es keine Meldung und ESC entfällt.
Die Auflösung hatte ich mit Arbeit speichern im Desktop festgelegt.
Es wird (wie in TOS 1) die Größe aller Dateien im jeweils geöffneten Ordner angezeigt. Es ist korrekt, dass nicht die Größe der ausgewählten Dateien angezeigt wird.
Gibt es dafür einen bestimmten Grund (Kompatibilität, Platz)?
Ich finde es schon sehr nützlich zu sehen wie groß eine
einzelne Datei ist. Z.B. beim Zusammenstellen einer 720k Disk.
-
Der Rechner bootet immer erst in ST-Gering im Farbmodus und schaltet dann erst wenn die Desktop oder Newdesk.inf geladen wird auf ST-Mittel um ...
-
Wie Frank schon schreibt: Die DESKTOP.INF/NEWDESK.INF/EMUDESK.INF kommt erst zum Zuge, wenn der Desktop startet, also nach den AUTO-Ordner-Programmen und somit nach XBOOT.
Die Auflösung (schlechter Wortwitz) ist recht simpel: Unter TOS schaltet XBOOT selbstständig in die mittlere Bildschirmauflösung um. Unter EmuTOS macht XBOOT das nicht und beklagt sich folglich, dass die beim Starten mit Farbbildschirm immer eingestellte geringe Auflösung zu gering ist.
Bis ich herausgefunden habe, wie man XBOOT dazu bewegt, auch unter EmuTOS umzuschalten, möge das angehängte Programm im AUTO-Ordner als Workaround dienen. Es muss in der Bootreihenfolge natürlich vor XBOOT stehen und darf nicht in XBOOT deaktiviert werden. Es schaltet, falls der Rechner in der niedrigen Auflösung ist, in die mittlere um. In der hohen Auflösung (monochrom) macht es nichts, stört also auch nicht.
-
Danke, das ging ja schnell. Vielleicht hätte ich besser einfach nur im Colormodus geschrieben.
Und die Geschichte mit der Dateigrösse bleibt das so?
-
Und die Geschichte mit der Dateigrösse bleibt das so?
Ist jetzt implementiert, siehe Screenshot. (Beachte: Die Übersetzungen sind noch nicht vorgenommen, daher wird die Infozeile im Fenster derzeit noch auf Englisch angezeigt.)
-
Danke, das ist eine gute Neuigkeit. :D
Die Übersetzung finde ich nicht so gravierend ist eher das I-Tüpfelchen.
Weitere Frage: Ist die Anzeige der Bytes nicht irgendwie anpassbar in Kilo- oder Mega-Bytes.
Ich finde es im Orignal Tos schon ätzend immer diese riesen Zahlen einer Partition umrechnen
zu müssen. Klar sind einzelne Programme immer unter der Mega-Byte Grenze aber bei Partitionen
oder schon bei HD Disketten sind diese riesen Zahlen einfach unhandlich. Ideal wäre ab 1024 Bytes
alles in Kilo und ab 1 Mio in Mega darzustellen.
Leider kenn ich mich mit Assembler und dem Betriebssystem nicht aus. Vielleicht frisst dass
aber auch zuviel Speicherplatz, der woanders dringender gebraucht wird. Schön wäre es in jedem
Fall.
Eine Frage noch zu dem eingebauten Treiber in EmuTos. Beisst sich dieser nicht, wenn da noch
ein zusätzlicher Plattentreiber von Uwe Seimet draufliegt.
Sollte man bei Betrieb mit EmuTos diesen besser deaktivieren?
-
Da EmuTOS weiss daß es einen eingebauten Treiber hat, versucht es auch nicht einen zu booten. Du musst ihn also nicht abschalten, höchstens dann wenn noch einer im AUTO-Ordner liegt (was aber normalerweise nicht der Fall sein dürfte).
-
Ist jetzt implementiert, siehe Screenshot. (Beachte: Die Übersetzungen sind noch nicht vorgenommen, daher wird die Infozeile im Fenster derzeit noch auf Englisch angezeigt.)
Wo kann man diese Version herunterladen? finde nur diese Seite
https://sourceforge.net/projects/emutos/files/emutos/0.9.10/ (https://sourceforge.net/projects/emutos/files/emutos/0.9.10/)
im deutschen 256er ist das leider noch nicht drin.
-
https://sourceforge.net/projects/emutos/files/snapshots/
Weil das der "daily build" ist, ist allerdings nicht immer garantiert, daß der Snapshot auch tatsächlich funktioniert.
Auch wenn das in 99 von 100 Fällen der Fall sein dürfte: jedenfalls erst mal ausprobieren.
-
Danke, mach ich gerade mit Steem das Ausprobieren.
-
Danke, mach ich gerade mit Steem das Ausprobieren.
... da müsste übrigens auch dein XBoot-Problem gelöst sein.
-
... da müsste übrigens auch dein XBoot-Problem gelöst sein.
...ja tatsächlich. Gerade neue EPROMS gebrannt und läuft durch :D
-
Noch ein bisschen zur Terminologie: Releases (die unter https://sourceforge.net/projects/emutos/files/emutos/ liegen) gibt es ein- bis zweimal im Jahr. Sie sind mit einem großen Testaufwand (mehrere Leute, mehrere Wochen) verbunden und stellen quasi die stabilen Versionen dar, deren Erscheinen hier auch immer angekündigt wird.
Natürlich wird der Quellcode aber kontinuierlich weiterentwickelt. Da nicht jeder die Möglichkeit hat, sich aus dem Quellcode eine frische Version zu bauen, lassen wir automatisch Snapshots (abgelegt unter https://sourceforge.net/projects/emutos/files/snapshots/) erzeugen, die jeweils den aktuellen Stand widerspiegeln. Diese Snapshots sind jedoch nicht gründlich getestet und können auch mal Fehler enthalten, dafür sind aber die neusten Features und Bugfixes drin.
-
Danke Christian.
Nun habe ich ganz begeistert alles schön gebrannt und jetzt ist wieder was aufgefallen.
Da ich mit dem normalen TOS immer sofort vergleiche, ob es denn nicht doch am Rechner
liegt ist jetzt folgendes Aufgetreten:
Ziel war es die Hotlist vom Diskettenlaufwerk A nach Laufwerk G (GigaFile) in den Ordner
CAB zu kopieren. Dies gelang nach mehrmaligen Versuchen einfach nicht.
Ich habe dann abgebrochen und danach war Laufwerk G angeblich leer und nicht mehr ansprechbar.
Sorry für die etwas schlechte Bildqualität, denke jedoch zur weiteren Fehlerbeseitigung trotzdem hilfreich.
Wie gesagt, beim normal TOS keine Probleme. Schade, hatte mich schon so gefreut das ich
zum letzten mal den Brenner heute anwerfen musste.
-
Wie gesagt: Snapshots können Fehler enthalten, auch kritische.
Das Laufwerk G: war aber nicht zufällig mit HDDRIVER vor 10.14 als TOS&Windows-kompatibel partitioniert worden?
-
Ich habe eine Gigafile am Mega ST (nicht STE), die hatte massive Probleme, bis ich da noch zwei kleine Kondensatoren nachgerüstet habe. Ich könnte mir vorstellen, daß das Bustiming mit einem optimierten TOS geringfügig anders ist als mit dem Original, wodurch solche Probleme provoziert werden könnten. Muß also kein Fehler in EmuTOS, sondern kann auch ein wackliger ACSI Bus sein.
MfG
Ektus.
-
Es wäre tatsächlich wichtig zu erfahren, auf welchem Gerät das Laufwerk G: ist und wie dieses mit dem Atari verbunden ist. Meldungen wie "Das Ausgabegerät empfängt keine Daten" kenne ich in der Tat eher von "wackeliger" Hardware.
-
Hat er doch geschrieben: Eine Gigafile. Und die schließt man an einem ST/STE bekanntlich per ACSI an...
-
Eine Gigafile nutze ich in meinem MegaSTE auch - auch mit EmuTOS. Ein prinzipielles Problem ist es demnach nicht.
Hinweis am Rande: Wenn Du Snapshots nur mal ausprobieren willst, verwende doch die .prg-Version und spare die Zeit fürs EPROM-Brennen. (Dauerte das nicht mehrere Stunden(!) mit Deinem EPROM-Brenner?)
-
Das Laufwerk G: war aber nicht zufällig mit HDDRIVER vor 10.14 als TOS&Windows-kompatibel partitioniert worden?
Ja, die Gigafile wurde mit vor 10.14 partitioniert. Dafür aber das Hauptlaufwerk (Adapter von Amigakit).
Da wackelt nichts (leider) alles sehr solide verbunden und mit dem original TOS auch solche
Effekte nie gesehen.
-
Und als "TOS&Windows"-kompatibel partitioniert? Bekanntermaßen gab es da mit Versionen vor 10.14 ein Problem.
Mit "wackelig" war nicht mechanisch gemeint sondern elektrisch grenzwertig (wie Ektus schon schrieb: z.B. bzgl. Timing), was man der Verbindung natürlich nicht ansieht. Wie weiter oben geschrieben: Es gibt keine grundsätzlichen Probleme mit EmuTOS und der Gigafile -- wie ich aus eigener Erfahrung weiß.
-
Und als "TOS&Windows"-kompatibel partitioniert?
Ja.
Dann partitioniere ich die neu.
-
So, trotz Partitionierung jetzt mit ca. 500MB je Partition auf der Giga File und 10.14 Treiber gleiches Verhalten. >:(
Es kommt die Meldung "Das Ausgabe-Gerät empfängt keine Daten."
Auf Normal TOS kein Problem. Habe dort testweise auch zwischen internen und externen SD Dateien verschoben. ca. 6000 Stück ohne Unterbrechung.
Klicke ich auf Laufwerk V kommt noch diese Fehlermeldung:
Danach noch ein Bild wie Partitioniert wurde.
-
Danke fürs wiederholte Testen und die Screenshots. Ich habe es an die Entwickler-Mailingliste weitergegeben. Mehr kann ich leider aus zeitlichen Gründen derzeit nicht tun. :(
-
Danke fürs wiederholte Testen und die Screenshots. Ich habe es an die Entwickler-Mailingliste weitergegeben. Mehr kann ich leider aus zeitlichen Gründen derzeit nicht tun.
Du machst hier schon mehr als genug ;D
-
Ich gehe davon aus, daß der Absturz ein (nichtdestotrotz behebenswürdiger) Folgefehler ist.
Er hat mit dem eigentlichen Problem (Lesefehler) nichts zu tun, sondern passiert im Desktop (beim Versuch, das Icon zu selektieren) in act_allchg(). Möglicherweise hat eine "wildgewordene" DMA-Übertragung die resource-Struktur zerschossen.
-
Was immer es auch sein mag. Im TOS geht es nur bei EmuTOS leider nicht.
Das Verhalten sollte sich auch auf anderen Rechnern reproduzieren lassen.
Heisst von Diskette A Dateien auf die GigaFile kopieren.
-
Das Verhalten sollte sich auch auf anderen Rechnern reproduzieren lassen.
Heisst von Diskette A Dateien auf die GigaFile kopieren.
Leider habe ich weder eine Diskette A noch eine Gigafile - ich würde sonst gerne versuchen, dir zu helfen.
-
Nachfrage von Roger: wenn der Fehler aufgetreten ist, und du neu bootest, ist der Ordner dann imm er noch leer? Also ist wirklich das Filesystem zerschossen, oder zeigt er wegen dem Kopier-Fehler nur nix mehr an?
-
Nach dem Boot ist alles wieder da.
P.S. Die ganze Partition ist leer nicht der Ordner.