atari-home.de - Foren
Hardware => Emulatoren => Thema gestartet von: Arthur am Do 11.04.2019, 12:53:49
-
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... >:D
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. :D >:D
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:
-
Hyperview streigt bei mir unter EasyMint auf realer Hardware auch aus. Da scheine ich also nicht alleine zu sein.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Schau dir mal insaneboot an, damit spielt die Reihenfolge keine Rolle mehr.. nutze ich auf meinem TT und auch auf der Vampire!
-
@tuxie, super Tipp. Werde ich noch ausprobieren und dann hier berichten. Genau so etwas sollte mit Hatai gleich mitgeliefert werden. Vielen Dank.
-
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.
-
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...
-
Aber z.B. die Kronos-Sache könnte ein Bug sein.
-
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
-
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 ...
-
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.
-
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.
-
Als Hyp_view benutze ich nun eine 0.40er Version (http://xaaes.gokmase.com/tools/hypview_040.zip)... die es auch tut. In älteren FreeMiNT Archiven bin ich nicht fündig geworden.
-
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.
-
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.
-
Danke für den schnellen Bugfix.
-
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.
Auch von mir, danke.
-
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.
Ja, das wäre gut. Das von Ingo weiter oben genannte Programm insaneBOOT (ftp://ftp.untergrund.net/users/insane/atari/autoexec.zip) ist, wenn es wie gedacht funktioniert, aber eine perfekte Alternative..
-
Auch von mir, danke.
Aber gern. Der Build ist durch, Du könntest also nochmal runterladen und testen.
-
Aber gern. Der Build ist durch, Du könntest also nochmal runterladen und testen.
Schau ich mir heute noch an.... der Rest vom MiNT, bis auf Hyp_view, ist ja identisch, oder?
-
Schau ich mir heute noch an.... der Rest vom MiNT, bis auf Hyp_view, ist ja identisch, oder?
Prima. Bis auf NOHOG2.ACC (das Du mit XaAES nicht brauchst) müsste der Rest identisch sein.
-
HYP_VIEW.APP funktioniert jetzt. Als CPU wird jedoch min. 68020+FPU vorausgesetzt. Interessant ist die geringe Dateigröße mit 100KB gegenüber 150KB beim Original... aber das war ja auch der Sinn der Bib. :D
-
HYP_VIEW.APP funktioniert jetzt. Als CPU wird jedoch min. 68020+FPU vorausgesetzt.
Auch wenn Du Dir die 68000-Variante ("000-st_ste") davon herunterlädst? Das wäre dann ein Fehler.
https://bintray.com/freemint/freemint/snapshots/1-19-7bbdc647
-
HYP_VIEW.APP funktioniert jetzt. Als CPU wird jedoch min. 68020+FPU vorausgesetzt. Interessant ist die geringe Dateigröße mit 100KB gegenüber 150KB beim Original... aber das war ja auch der Sinn der Bib. :D
Das Original aus dem letzten freemint-Build mit mintlib (statt libcmini) hatte 253357 Bytes ;)
Danke fürs Ausprobieren!
P.S.: HYPVIEW.APP gibt's in allen 6 freemint-Geschmacksrichtungen: ColdFire, 060, 040, 030, 020-60 und 68000.
Welches Archiv hast Du runtergeladen? Die aktuelle 68000er-Version sollte 109937 110261 Bytes haben.
-
Nein, ich habe das Paket 020-060... beruhigend das es auch für den normalen 68K eine Version gibt.
Wer ist zur Zeit für Hyp_view zuständig?
Mir viel auf das unter TOS die Menuleiste blank ist. Die Symbole sind da einfach weiß auf weißem Hintergrund. Wenn man sie anklickt funktionieren sie... macht aber keinen Spaß.
-
Mir viel auf das unter TOS die Menuleiste blank ist.
Das kann durchaus sein, weil hyp_view keine Anstalten macht Color-Icons selbst darzustellen wenn das AES es nicht kann. Auch die Popups werden dann vermutlich nicht funktionieren, es sei denn man hat wdialog installiert. Ist aber kein bug im eigentlichen Sinn, eher ein fehlendes Feature.
-
So isses. HYPVIEW braucht ein AES > 3.31, das Coloricon- und Popup-Menü-Support hat. Ohne MiNT also mindestens einen Falcon.
Selbst wenn das vorhanden ist: richtig angezeigt werden die Icons nur, wenn man die NVDI-Palette geladen hat.