Allgemeine Fragen zu Hatari 2.2.1 MiNT, TOS und zur Kompatibilität

[Arthur]

Zur Zeit spiele ich mit Hatari als  Atari TT (Auflösung TT high, TOS 3.06) konfiguriert unter Windows 10 rum.

Als erstes viel mir auf das der Auto-Ordner eines Windows-Ordners, der als GEMDOS-Festplatte herhalten sollte, nicht in der Atari-üblichen Reihenfolge abgearbeitet wird, sondern stur in Alphabetischer Reihenfolge. Besonders störend macht sich das bei Geneva bemerkbar da dieses mit einem Cookie-Fehler nicht startet... das nur als Beispiel.

Halb so wild...

Ich lege eine leere Datei mit 1024MB Größe an und benutze diese nun als ACSI-Festplatte, soweit so gut.

In Disk A: lege ich die HDDriver 10.15 Disk und starte Hddriver aus dem Autoordner. Mit HDDRUtil werden zwei Partitionen a 512MB angelegt. Nach zig versuchen die LNX anzulegen (wird stur als BGM angezeigt) ändere ich diese statt dessen in RAW und dann klappt auch dies. Am echten TT klappt es mit LNX... auch.

Ich lade mit nun https://bintray.com/freemint/freemint/download_file?file_path=snapshots%2F1-19-36cf2b41%2Ffreemint-1-19-36c-02060-tt_falcon_clones.zip herunter und kopiere den Inhalt auf acsi c:

Formatieren von D: mit mkfs.ttp als ext2 klappt ohne weiteres unter MiNT.

Zu testen kommte jetzt noch ein wenig Software auf C: ... ArthurXP von RGF, ganz wichtig Gembench, Kronos, Thing1.27 QED und 7Up.

Kronos bleint beim CPU-Test nach der 4ten von 6 LEDs stehen? Ich dachte das ich in Hatari mit exact cycle bla besonders kompatible wäre... Haken raus genommen und Kronos läuft.

ArthurXP... egal welche Version, tut nichts, trotz Key in der CFG? Memory Protection hab ich aus geschaltet... hilft aber auch nicht.

Ich denke mir RTFM vielleicht steht da etwas wichtiges... ist aber ein *.HYP Datei.... da war doch was?
Ja mit MiNT kommt eine Hypview.app... damit schau ich mir das mal locker an... aber Pusteblume. 

Auf einen Doppelklick hin öffnet sich der Dateiauswahldialog und nach manövrieren in das Verzeichnis und Auswahl des Files passiert nicht's außer das Hyperview nicht läuft. Egal was ich mache, auch als ACC... keine Chance und keine Fehlermeldung. Wie denn auch, hab den Dubug-Level ja auch geändert.

Auch als STE mit 68020 und 6888x FPU, nada.

Neue Idee um es doch noch zu schaffen...

Ich benutze statt TOS 3.06 nun EmuTOS (512KB) in Hatari da gegen Bus-Fehler geimpft.

Nach dem Reset fällt auf das der HDDRiver nicht benutzt wird da schon im EmuTOS einer Plattentreiber enthalten ist. Alle Partitionen werden gefunden und ein Wunder geschieht... alle Versionen von ArthurXP laufen problemlos...

Schön, aber wieso gehts nicht mit TOS 3.06? Muss ich mal am realen TT testen... aber später.

Vielleicht klappt jetzt auch mit Hyperview, denke ich? Aber das Programm schmiert nach dem Start direkt ab. Ich kann mich nicht erinnern mit einen dieser Viewer irgendwann warm geworden zu sein... das sind alles...gr%mp$h.

Hier die Fehlermeldung:

[1ST1]

Hyperview streigt bei mir unter EasyMint auf realer Hardware auch aus. Da scheine ich also nicht alleine zu sein.

[czietz]

Dass die Reihenfolge der Dateien bei GEMDOS-Emulation nicht nachgebildet werden kann, liegt nicht an Hatari, sondern daran, dass die Dateisysteme auf dem Host (also NTFS unter Windows in Deinem Fall) das i.d.R. nicht nachbilden können. Es steht auch im Handbuch, dass man die AUTO-Ordner-Reihenfolge deshalb nur durch Umbenennen verändern kann:
https://hatari.tuxfamily.org/doc/manual.html#GEMDOS_based_hard_drive_emulation

Ebenso ist dokumentiert, dass die TT-Emulation experimentell und nicht komplett ist:
https://hatari.tuxfamily.org/doc/manual.html#Experimental_TT_hardware_emulation

Um den Rest Deiner Beschreibung genauer zu untersuchen, würden den Hatari-Entwicklern Details fehlen. Falls Du die Fragen auf deren Mailingliste https://hatari.tuxfamily.org/contact.html stellen möchtest, wäre Deine hatari.cfg wichtig. Sinnvollerweise auch das verwendete Festplattenimage, evtl. mit entfernter HDDRIVER.SYS, damit Du keine kommerzielle Software weitergibst.

[czietz]

PS: Noch ein Hinweis zu MiNT und der GEMDOS-Emulation unter Hatari: nur der speziell dafür gebaute MINTHAT.PRG-Kernel läuft mit GEMDOS-Emulation. Die übrigen Kernel (also auch der für den TT) benötigen ohnehin ein Festplatten-Image.

[Arthur]

Dass die Reihenfolge der Dateien bei GEMDOS-Emulation nicht nachgebildet werden kann, liegt nicht an Hatari, sondern daran, dass die Dateisysteme auf dem Host (also NTFS unter Windows in Deinem Fall) das i.d.R. nicht nachbilden können. Es steht auch im Handbuch, dass man die AUTO-Ordner-Reihenfolge deshalb nur durch Umbenennen verändern kann:
https://hatari.tuxfamily.org/doc/manual.html#GEMDOS_based_hard_drive_emulation

Ich sag immer wo ein Wille ist ... da das GEMDOS-Laufwerk ja nur Emuliert ist könnte man sich statt dessen an Datum und Uhrzeit orientieren. Mit Umbenennen konnte ich das Problem nicht lösen... Es soll Programme geben die kennen ihren Namen und entnehmen ihm Parameter.

Ebenso ist dokumentiert, dass die TT-Emulation experimentell und nicht komplett ist:
https://hatari.tuxfamily.org/doc/manual.html#Experimental_TT_hardware_emulation

Der Text steht schon eine Ewigkeit so und unter einen ST/STE mit TOS 2.06 und 68020/68882 sieht es ja nicht anders aus. Genau so lange wird behauptet das unter Windows mit einer geheimnisumwitterten Bibliothek MiDI ginge. Die kann man aber nicht finden und trotzdem steht geschrieben. Sorry Christian.. wollte meinen Frust nicht an dir ablassen. Die Jungs tun ihr bestes.

Um den Rest Deiner Beschreibung genauer zu untersuchen, würden den Hatari-Entwicklern Details fehlen.

Ja, klar.

Falls Du die Fragen auf deren Mailingliste https://hatari.tuxfamily.org/contact.html stellen möchtest, wäre Deine hatari.cfg wichtig. Sinnvollerweise auch das verwendete Festplattenimage, evtl. mit entfernter HDDRIVER.SYS, damit Du keine kommerzielle Software weitergibst.

Gibt es da keine Button für einen Bugreport? Welche Liste soll ich nehmen, Devel oder User? Auf SourceForge ging das damals leichter.

[Arthur]

PS: Noch ein Hinweis zu MiNT und der GEMDOS-Emulation unter Hatari: nur der speziell dafür gebaute MINTHAT.PRG-Kernel läuft mit GEMDOS-Emulation. Die übrigen Kernel (also auch der für den TT) benötigen ohnehin ein Festplatten-Image.

In dem Paket s.o. gibt die Datei nicht. Und wird der passende Kernel... so vorhanden, nicht automatisch gewählt?

Edit: Es gibt noch den Masterbranch... da gibt es die minthat.prg... höre ich heute zum ersten mal.

[Arthur]

Hyperview streigt bei mir unter EasyMint auf realer Hardware auch aus. Da scheine ich also nicht alleine zu sein.

Danke, dann kann ich mir das ja sparen.

[tuxie]

Schau dir mal insaneboot an, damit spielt die Reihenfolge keine Rolle mehr.. nutze ich auf meinem TT und auch auf der Vampire!

[Arthur]

@tuxie, super Tipp. Werde ich noch ausprobieren und dann hier berichten. Genau so etwas sollte mit Hatai gleich mitgeliefert werden. Vielen Dank.

[czietz]

Ebenso ist dokumentiert, dass die TT-Emulation experimentell und nicht komplett ist:
https://hatari.tuxfamily.org/doc/manual.html#Experimental_TT_hardware_emulation

Der Text steht schon eine Ewigkeit so

Vermutlich, weil es schon eine Ewigkeit lang zutreffend ist. Aber Du hast Recht: Wenn Dein Problem auch mit ST+68020 auftritt, ist es kein Problem der unvollständigen TT-Emulation.

Genau so lange wird behauptet das unter Windows mit einer geheimnisumwitterten Bibliothek MiDI ginge. Die kann man aber nicht finden und trotzdem steht geschrieben.

Das gilt m.W. nur, wenn Du Hatari unter Windows selbst compilierst. Die fertigen Binaries werden hingegen swiw für Windows ohne Portmidi-Bibliothek erstellt. Die Hatari-Entwickler sehen Windows nicht als primäre Plattform für ihren Emulator an.

Gibt es da keine Button für einen Bugreport? Welche Liste soll ich nehmen, Devel oder User? Auf SourceForge ging das damals leichter.

Anhand der Beschreibung ("This is the list for the normal users of Hatari. For example, if you've got a problem with your configuration, or just want to report a bug [...]") würde ich die Users-Liste wählen.

[Arthur]

Hab mich da für die Mailingliste registriet. Jetzt fällt mir aber gerade ein das, wo das Problem mit hyperview ja auch auf realer Hardware auftritt, es vielleicht dann auch kein Hatari-Fehler ist...

[czietz]

Aber z.B. die Kronos-Sache könnte ein Bug sein.

[czietz]

Bezüglich HYP_VIEW: Da hast Du in der Tat einen Bug gefunden, aber nicht in Hatari, sondern in FreeMiNT (unter Beteiligung von @mfro's libcmini). Ich habe ein Ticket aufgemacht, damit sich die FreeMiNT-Entwickler dessen annehmen: https://github.com/freemint/freemint/issues/110

[mfro]

Bezüglich HYP_VIEW: Da hast Du in der Tat einen Bug gefunden, aber nicht in Hatari, sondern in FreeMiNT (unter Beteiligung von @mfro's libcmini). Ich habe ein Ticket aufgemacht, damit sich die FreeMiNT-Entwickler dessen annehmen: https://github.com/freemint/freemint/issues/110

Ah, danke für den Hinweis, da hat sich wohl was eingeschlichen.

Ich bin sicher, das hat funktioniert, als ich libcmini das erste mal eingebaut und getestet habe ...

[Arthur]

Bezüglich HYP_VIEW: Da hast Du in der Tat einen Bug gefunden, aber nicht in Hatari, sondern in FreeMiNT (unter Beteiligung von @mfro's libcmini). Ich habe ein Ticket aufgemacht, damit sich die FreeMiNT-Entwickler dessen annehmen: https://github.com/freemint/freemint/issues/110

@czietz, danke für deinen Bugbericht. Das es kein Hatari-Fehler ist habe ich in #10 ja auch geäußert. Als ich heute den Fehler in der ST-Emulation sicherheitshalber nochmal überprüfte, konnte ich den Kronos-Fehler nicht reproduzieren.

Könnte ich aber trotzdem als Bugreport mailen.

Nach dem ich die Debug Settings in Mint wieder zurück gesetzt habe bringt nun auch ArthurXP von RGF eine Fehlermeldung unter TOS3.06/MiNT unter EmuTOS läuft es.

[Arthur]

Mehr durch Zufall fand ich heraus das ArthurXP unter MiNT läuft wenn NVDI installiert ist... welches unter EmuTOS dafür ja nicht benötigt wird.

[Arthur]

Als Hyp_view benutze ich nun eine 0.40er Version... die es auch tut. In älteren FreeMiNT Archiven bin ich nicht fündig geworden.

[goetz @ 3rz]

Dass die Reihenfolge der Dateien bei GEMDOS-Emulation nicht nachgebildet werden kann, liegt nicht an Hatari, sondern daran, dass die Dateisysteme auf dem Host (also NTFS unter Windows in Deinem Fall) das i.d.R. nicht nachbilden können. Es steht auch im Handbuch, dass man die AUTO-Ordner-Reihenfolge deshalb nur durch Umbenennen verändern kann:
https://hatari.tuxfamily.org/doc/manual.html#GEMDOS_based_hard_drive_emulation

Hm, ein Mechanismus von Hatari, das mit einer AUTOEXEC.BAT zu handhaben, wäre praktisch. Manche Programme mögen es nicht umbenannt worden zu sein, v.a. welche, die ihre Parameter aus dem Dateinamen herausparsen (bpsw. "RAMD512" für eine RAM-Disk von 512K). Wenn die dann FAMD512 heißen, tut’s öfter nicht.

[mfro]

Bezüglich HYP_VIEW: Da hast Du in der Tat einen Bug gefunden, aber nicht in Hatari, sondern in FreeMiNT (unter Beteiligung von @mfro's libcmini). Ich habe ein Ticket aufgemacht, damit sich die FreeMiNT-Entwickler dessen annehmen: https://github.com/freemint/freemint/issues/110

Ah, danke für den Hinweis, da hat sich wohl was eingeschlichen.

Ich bin sicher, das hat funktioniert, als ich libcmini das erste mal eingebaut und getestet habe ...

Ja, war ein Fehler in libcmini.

Mit dem nächsten automated build sollte hypview (eigentlich) wieder funktionieren.

[czietz]

Danke für den schnellen Bugfix.