FTOS (Flash TOS) und TOS Switch gewusst wie

[1ST1]

Wenn das jetzt original Atari TOS wäre, würde ich sagen, mach die Partitionen niemals 256 MB groß, immer ein bischen unter solchen Grenzen drunter bleiben, z.B. 254 MB und lieber ein bischen nicht partitionieren... Bei EmuTOS habe ich keine Erfahrungen, aber beim Atari TOS hab ich da schon öfters Probleme gehabt.

[Atariosimus]

Bei Atari TOS funktioniert es ja sehr gut mit der Aufteilung. Sogar bei allen
3 TOS Varianten.

Vielleicht ist EmuTOS da restriktiver? Allerdings hätte ich dann erwartet, dass bei allen
Laufwerken was nicht stimmt.
Der Fehler sollte zum Prüfen leicht reproduzierbar sein.

Ich finde es jedenfalls seltsam, dass nur das D Laufwerk spinnt. Brennfehler schliesse
ich aus. Eingebaut ist der Adapter von AmigaKit. Vielleicht liegt es daran.

[czietz]

Ich kann das Problem nachvollziehen. Es ist m.M.n. ein Bug in HDDRUTIL (aus HDDRIVER) beim Anlegen der Partitionen, kein Bug in EmuTOS.

Ich muss jetzt auf der EmuTOS-Liste diskutieren, ob wir einen Workaround dafür bauen können. Ich bitte Dich aber, vorerst EmuTOS nicht mit dieser so partitionierten SD-Karte zu benutzen. Bei einem Schreibzugriff auf die falsch angezeigte Partition D: würde es zu Datenverlust kommen.

[Atariosimus]

Na super, vielen Dank czietz. 

Ich hatte mir schon ernsthaft Gedanken gemacht
die Hardware irgendwie geschrottet zu haben.

Bei TOS hatten die schon diesen Workaround drin.
ohne den HDDriver von Seimet zu kennen.   

Betrifft das auch andere Festplattentreiber?
Wie hätte ich die SD-Karte partitionieren müssen um keinen Pixelmüll zu erhalten?

Ich hätte noch eine Bitte zur Dauer der  Startsequenz.
Die ist mir viel zu schnell eingestellt als dass man sie als Neu User
komplett lesen und reagieren kann.
Musste mehrmals resetten um die Optionen nach lesen zu können.

Es wäre besser die Zeit beim ersten Start
zu erhöhen vielleicht 30 Sekunden. Diejenigen die das dann
verkürzen wollen können das mittels Button einstellen.

[Atariosimus]

Bei meinem Mega STE mit drei 300MB Partitionen auf einer SCSI/ACSI Platte ist von der 0.991 Bootdiskette gebootet alles in Ordnung.

Wie sehen denn da die Parameter von HDDriver aus?

[czietz]

Bei TOS hatten die schon diesen Workaround drin.
ohne den HDDriver von Seimet zu kennen.   

Nö, hatten sie nicht. Atari TOS kann mit Festplatten von sich aus ja gar nicht umgehen. Du nutzt ja unter TOS automatisch HDDRIVER, während EmuTOS seinen eigenen Plattentreiber mitbringt. Alle Details unter: https://sourceforge.net/p/emutos/mailman/message/36494360/
Kurzfassung: Bei TOS/Windows-kompatibel partitionierten Medien nutzt EmuTOS die Windows-Werte und die sind an einer Stelle falsch. Wenn Du diese SD-Karte in einen Windows-10-Rechner (der Zugriff auf alle vier Partitionen erlaubt) stecken würdest, hättest Du dasselbe Problem wie unter EmuTOS.

Wie hätte ich die SD-Karte partitionieren müssen um keinen Pixelmüll zu erhalten?

Ich denke, letztlich kann nur Uwe Seimet beantworten, warum das Problem genau bei Laufwerk D: auftritt.

Ich hätte noch eine Bitte zur Dauer der  Startsequenz.
Die ist mir viel zu schnell eingestellt als dass man sie als Neu User
komplett lesen und reagieren kann.
Musste mehrmals resetten um die Optionen nach lesen zu können.

Es wäre besser die Zeit beim ersten Start
zu erhöhen vielleicht 30 Sekunden. Diejenigen die das dann
verkürzen wollen können das mittels Button einstellen.

Den meisten Usern ist die Startzeit von EmuTOS recht. Künstliche Verzögerungen werden keine Mehrheit finden. Auch ich will nicht jedes Mal (wie bei TOS 2 oder 3) eine Taste drücken müssen, damit der Rechner endlich bootet. Du kannst beim Booten Shift drücken und festhalten, damit der Startbildschirm nicht verschwindet. (Steht da auch.)

[Atariosimus]

Du kannst beim Booten Shift drücken und festhalten, damit der Startbildschirm nicht verschwindet. (Steht da auch.)

...und genau das kann ich wegen der Schnelligkeit nicht lesen 

Wenn Du diese SD-Karte in einen Windows-10-Rechner (der Zugriff auf alle vier Partitionen erlaubt) stecken würdest, hättest Du dasselbe Problem wie unter EmuTOS.

Ich nutze noch XP und sehe nur die erste Partition 
PP hat mal einen Weg erklärt wie man bei XP trotzdem alle sehen kann.

[Atariosimus]

Drive D: is wrong, however: FAT size under TOS 4096 bytes * 16 sectors =
65536 bytes, under EmuTOS 512 bytes * 64 sectors = 32768 bytes. This
causes EmuTOS to look for the root directory where actually the second
FAT is.

Verstehe ich das richtig das die FAT Grösse von TOS doppelt so groß ist wie bei EmuTos
und deshalb sieht EmuTOS im Root Verzeichnis statt auf D nach?
Wie hätte ich denn partitionieren müssen um Pixelmüll zu verhindern und trotzdem
zwischen EmuTOS und TOS optimale Kompatibilität zu haben?

Da würde mich jetzt die Einstellung von Frank interessieren.

[Lukas Frank]

Ich habe keinerlei Probleme. Ich nutze eine 4GB SCSI Festplatte und HDDriver 10.12

[czietz]

Verstehe ich das richtig das die FAT Grösse von TOS doppelt so groß ist wie bei EmuTos

Die vermeintliche (also aus dem Bootsektor gelesene) FAT-Größe, ja.

und deshalb sieht EmuTOS im Root Verzeichnis statt auf D nach?

Nein, EmuTOS und Windows und andere sehen in der zweiten FAT nach, wenn sie eigentlich das Root-Verzeichnis öffnen wollen.

Wie hätte ich denn partitionieren müssen um Pixelmüll zu verhindern und trotzdem
zwischen EmuTOS und TOS optimale Kompatibilität zu haben?

Wie oben schon geschrieben: Im Regelfall macht es HDDRUTIL ja richtig, siehe Deine Laufwerk C:, E: und F:. Was dafür sorgt, dass D: falsch ist, muss vermutlich Uwe Seimet herausfinden. Nur er weiß, wie HDDRUTIL diese Werte berechnet.

[Atariosimus]

Frank benutzt eine 4GB Festplatte, ich gehe davon aus, dass das bei einer SD-Karte auch keinen
Unterschied macht. Werde das jetzt nach seinen Angaben umstricken.

Allerdings nur 3 Partitionen auf Festplatte und die Letzte auf USB Stick.

Fällt mir noch ein Wunsch ein. Kann man ab einer bestimmten Größe das EmuTos nicht so
umstricken, dass statt Bytes GB oder MB angezeigt werden? Find das immer übel
wenn in einem Ordner so eine riesen Zahl in Bytes steht und man beim Umrechnen doch
etwas handlichere Werte hat.

Vielleicht noch eine Idee wie man dieses Thema statt Workaround auch abhandeln könnte.
Entweder prüft EmuTOS vorab ob die Partitionen kompatibel sind oder man legt noch ein
Zusatzprogramm bei dass nur angibt ob es installiert werden kann.

Letztlich wird der normale User bei Auftreten dieses Bugs immer zuerst EmuTOS verantwortlich
machen. Da ja seiner Ansicht nach es bei TOS keine Probleme gab.

Ob Seimet sich da überhaupt dransetzt ist die Frage. Er könnte ja auch argumentieren, daß er mit EmuTOS nichts am Hut hat und den Treiber für TOS ausgelegt hat und da funktioniert es ja.

[czietz]

Ob Seimet sich da überhaupt dransetzt ist die Frage. Er könnte ja auch argumentieren, daß er mit EmuTOS nichts am Hut hat und den Treiber für TOS ausgelegt hat und da funktioniert es ja.

Sei versichert, Uwe Seimet wird sich darum kümmern. Wir stehen schon in Kontakt.

Das obige Argument zöge übrigens nicht, denn die Partitionierung ist ja als "TOS & Windows"-kompatibel angegeben und unter Windows hättest Du exakt dasselbe Problem. Es ist kein EmuTOS-spezifischer Bug!. Ich habe mir vor ein paar Monaten, als ich meinen Windows-10-Rechner neu hatte, übrigens vermutlich dadurch eine Partition D: auf einem HDDRUTIL-partitionierten Medium zerschossen. Zum Glück gab  es ein Backup. Ich habe es damals nicht weiter untersucht, aber nun bin ich sicher, dass es damals auch der Bug in HDDRUTIL war.

[czietz]

Ich habe das Problem übrigens nicht, wenn ich ein 1-GiB-großes Medium händisch wie im Anhang dargestellt partitioniere, statt den "Splitten"-Knopf zu drücken.

[Lukas Frank]

Ist das Problem nur da wenn man vier Partitionen anlegt? Ich hatte bei mir einfach Splitten in drei Teile angeklickt.

[Atariosimus]

Das sind ja interessante Neuigkeiten. Dann bekommen wir sicher bald ein neues Update von Uwe.
Vielleicht ist Neubrennen überflüssig nach dem Update.

Mach das jetzt auch händisch.

In der Zwischenzeit noch ein paar Impressionen von dem QUAD TOS.
Ich musste da etwas improvisieren mit den Sockeln. Die kann man auch
tiefer legen. Der Prototyp funktioniert sehr gut. Alle Verbindungen zwieschen
den Leisten wurden nochmals verlötet um auch sicheren Kontakt zu gewährleisten.

Mit dem Entreprellen und der Auswahllogik lass ich mir noch etwas Zeit.

[Atariosimus]

Anhand dieses asynchronen Frequenzzählers eine Klickschaltung aufgebaut um die 4 verschiedenen
Betriebssysteme anzusteuern. Die Hälfte der Schaltung genügt.
https://elektroniktutor.de/digitaltechnik/teiler.html

Eingesetzt wurde ein 74LS74 RS FlipFlop (siehe Schaltbild). Testweise  mit dem Clockeingang
an Masse gegangen. Und siehe da das TOS wechselte. Inwieweit das prellt kann ich so
noch nicht beurteilen, da mir erstmal wichtig war überhaupt einen Wechsel herbeizuführen.

Nebenbei ist mir beim Aufruf des EmuTOS noch ein witziges Feature aufgefallen.
Klickt man auf das linke Fuji Logo wird eine kurze Melodie abgespielt. Das rechte Fuji ist jedoch tonlos.

[Atariosimus]

Bei EmuTOS ist mir noch was aufgefallen.

Nach dem Umschalten von TOS ergibt sich folgende Meldung beim Anspeichern des Desktops.
Das Dateisystem wurde auf die entsprechnde Größe abgeändert, so dass D jetzt keinen
Pixelmüll mehr hat.

[Atariosimus]

Hier die HDDRUTIL

Kann man denn die einmal beschriebene SD Karte nicht einfach so für ein anderes
Betriebssystem weiterbenutzen?

Kann mir nur vorstellen das der eigene Treiber der in EmuTOS schon vorhanden ist
mit dem HDD Treiber irgendwie kollidiert.
Vielleicht geht das nur richtig wenn man diesen zuvor deinstalliert.

[czietz]

Sei versichert, Uwe Seimet wird sich darum kümmern. Wir stehen schon in Kontakt.

Ganz frisch: HDDRIVER 10.14: https://www.hddriver.net/de/news.html, in dem unterem anderem dies in HDDRUTIL korrigiert ist.
Das Update ist -- wie bei HDDRIVER üblich -- für Käufer einer Version 10.x kostenlos.

[Lukas Frank]

Vielen Dank, direkt gezogen ...