|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > AROS und Amiga-Emulatoren > Qemu AmigaOs4.1/Morphos | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 3 4 5 6 >> Letzte | [ - Beitrag schreiben - ] |
|
03.09.2022, 23:13 Uhr Maijestro Posts: 397 Nutzer |
Kurze info: Es wird wahrscheinlich die wenigsten interessieren, aber ich habe das ganze getestet mit Qemu 7.1.0 unter MacOs Monterey. Ich habe mich intensiv damit beschäftigen müssen um es überhaupt in stande zu bekommen. Ich möchte nur damit sagen das der Weg sehr lang war......ich musste dafür unter MacOs sämtliche developer tools installieren.Da es kein MacOs Build von Qemu gibt (alles veraltet) den man einfach downloaden kann wie es unter Windows üblich ist. Die Sam460 Version von AmigaOs 4.1 habe ich leider zum derzeitigen Zeitpunkt nicht zum laufen bekommen bzw. es war mir nicht möglich diese zu installieren, da zu viele Arteffakte bei der Workbench entstanden sind. Mit der Pegasos 2 Version von AmigaOs 4.1 die ich mir gerade bestellt habe werde ich es noch versuchen, über die Qemu Emulation mit Pegasos 2 Board Emulation. OK.... dachte ich wenn Amiga Os 4.1 nicht geht probierst du als Alternative halt MorphOs in der aktuellen Version aus... und was soll ich euch sagen ich bin positiv überrascht wie schnell die Emulation ist gegenüber WinUae...mit AmigaOs 4.1 auf mein Mac Studio. Meine config für QEMU unter MacOs: Installation Morphos qemu-system-ppc -machine mac99,via=pmu -m 1024 -vga none -device sm501 -cdrom morphos-3.17.iso -boot d -prom-env "boot-device=cd:,mac_ppc32boot.img" -bios openbios-qemu.elf -hda mos.img -drive file=mos.img,if=none,id=hd-drive,format=raw -serial stdio Nach der Installation ohne CD booten (ohne internet) qemu-system-ppc -machine mac99,via=pmu -m 1024 -vga none -device sm501 -boot d -prom-env "boot-device=hd:,boot.img" -bios openbios-qemu.elf -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=mos.img,if=none,id=hd-drive,format=raw -serial stdio -net nic,model=rtl8139 -net user (Mit internet) qemu-system-ppc -machine mac99,via=pmu -m 1024 -vga none -device sm501 -boot d -prom-env "boot-device=hd:,boot.img" -bios openbios-qemu.elf -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=mos.img,if=none,id=hd-drive,format=raw -serial stdio Mit Internet und mehr Speicher qemu-system-ppc -machine mac99,via=pmu -m 2048 -vga none -device sm501 -boot d -prom-env "boot-device=hd:,boot.img" -bios openbios-qemu.elf -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=mos.img,if=none,id=hd-drive,format=raw -serial stdio Meine Hardware: Apple M1 Max Chip 10‑Core CPU mit 8 Performance-Kernen und 2 Effizienz-Kernen 24‑Core GPU 16‑Core Neural Engine 400 GB/s Speicherbandbreite [ - Antworten - Zitieren - Direktlink - ] |
|
04.09.2022, 06:15 Uhr Primax Posts: 462 Nutzer |
@Maijestro: Hallo. Danke für deinen Erfahrungsbericht. Finde ich immer spannend!  Eine Sache verstehe ich nicht: du hattest doch AmigaOS 4.1 schon unter FS-UAE laufen. Was war das denn für eine OS4-Version? Nicht die Classic? Gibt es da noch eine andere, spezielle Pegasos-Version? Der direkte Vergleich FS-UAE mit QEMU wäre natürlich spannend...was die Geschwindigkeit betrifft, aber auch Stabilität etc. Hast du unter MorphOS mal die aktuelle Wayfarer-Browserversion getestet? Grüße, Daniel [ - Antworten - Zitieren - Direktlink - ] |
|
04.09.2022, 09:45 Uhr Maijestro Posts: 397 Nutzer |
@Primax: Hi Daniel, ja es ist richtig AmigaOs 4.1 FE Classic habe ich bereits unter WinUae, sowie auch unter FS-UAE getestet .Von den Emulatoren liegen keine nativen Versionen für MacOS vor und so konnte ich nur über Umwegen alles installieren. WinUae läuft nur emuliert mit Hilfe von Wine unter MacOS. Das Programm (Wine) macht es möglich unter MacOs Windows Software nutzen zu können. FS-UAE gibt es ebenfalls nur als Intel Version und wird durch Rosetta auf neueren Macs übersetzt. Das alles genügte mir nicht, da einfach zu viel Geschwindigkeit dabei verloren geht. Als letzten Versuch entschied ich mich dann für Qemu was nativ unter MacOs mit m1 arm Prozessor läuft. Qemu bringt die volle Sam440 und auch Pegasos 2 emulation mit sich. WinUae und auch FS-UAE tun das nicht. Dementsprechend braucht man dafür auch die speziellen Versionen von AmigaOs 4.1 FE. Beide kann man käuflich erwerben. Jetzt aber zu der eigentlichen Emulation die bereits läuft: Viel hab ich noch nicht getestet nur etwas im System gestöbert und mir alles angeguckt, Morphos ist mir relativ fremd. Fensteraufbau ist sehr schnell und das starten von Programmen läuft ohne Verzögerung. Wayfarer habe ich auch getestet nach Initialisierung der Fonts was ein klein Moment dauert startet der Browser ohne Verzögerung. Bis jetzt gab es keine Abstürze und das System läuft sehr stabil. Geschwindigkeit zu beschreiben ist immer etwas schwierig. Für mich persönlich ist Qemu der klare Sieger. Es läuft wirklich sehr schnell! Was im Moment noch nicht geht es der Sound....eventuell hab ich etwas in den einstellungen vergessen unter Qemu. Da es kein Gui bzw. eine richtige Benutzeroberfläche gibt muss ich alles per Hand und über das Terminal eingeben was natürlich etwas umständlich ist. Ich werde mal ein kurzes Video machen von der Emulation Morphos mit Qemu damit man besser versteht was ich meine. Qemu MorphOs Ich hab noch ein zweites Video gemacht, jetzt mit ein paar Optimierungen und Chrysalis Software Paket für MorphOs Morphos optimiert und mit Chysalis Software Paket Man sollte auch die Systemlast unter MacOs beachten die Emulation benötigt nicht mal 20% Cpu last....ich finde das wirklich beachtlich. [ Dieser Beitrag wurde von Maijestro am 04.09.2022 um 20:14 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.09.2022, 11:51 Uhr DaFreak Posts: 344 Nutzer |
 Danke für deinen Erfahrungsbericht! QEMU scheint auf zeitgemäßer Hardware brauchbarer zu sein als viele hier sagen. [ Dieser Beitrag wurde von DaFreak am 04.09.2022 um 11:52 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.09.2022, 13:24 Uhr Maijestro Posts: 397 Nutzer |
@DaFreak: Ja läuft wirklich angenehm....dennoch gibt es noch viele Optimierungen zu bewältigen, Qemu ist sehr umfangreich was die Konfiguration anbelangt. Auf der MorphOs Seite gibt es das rtl_8139pci.device zum downloaden das entspricht etwa meine config: qemu-system-ppc -machine mac99,via=pmu -m 1024 -vga none -device sm501 -boot d -prom-env "boot-device=hd:,boot.img" -bios openbios-qemu.elf -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=mos.img,if=none,id=hd-drive,format=raw -serial stdio -net nic,model=rtl8139 -net user Siehe letzte Zeile wo ich das Netzwerk rtl8139 eingebunden habe. Jetzt zu meiner Frage, wohin kommen in allgemeinen .device datein unter MorphOs in meinen fall handelt es sich um das rtl_8139pci.device. Es schein ein Netzwerktreiber zu sein den ich aber unter MorphOs erst installieren muß. Hat sich erledigt und funktioniert. [ Dieser Beitrag wurde von Maijestro am 04.09.2022 um 19:41 Uhr geändert. ] [ Dieser Beitrag wurde von Maijestro am 06.09.2022 um 03:37 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.09.2022, 20:56 Uhr Maijestro Posts: 397 Nutzer |
Zitat: Ich denke ich hab damit das Gegenteil bewiesen das es gut laufen kann. Als nächstes werde ich AmigaOs4.1 FE Pegasos 2 Edition testen...was mir persönlich wichtiger ist als die MorphOs Version. Ich will nicht sagen das MorphOs schlecht ist in vielen dingen ist es AmigaOs4.1 voraus und sehr modern gehalten. Dennoch finde ich persönlich AmigaOs4.1 besser, es erinnert mich einfach an die zeit die ich mit mein Amiga 1200 und auch AmigaOne Xe hatte und mir kommt unter AmigaOs4.1 einfach alles viel vertrauter vor. [ - Antworten - Zitieren - Direktlink - ] |
|
05.09.2022, 20:55 Uhr Primax Posts: 462 Nutzer |
@Maijestro: Also, die Devices (ahi.device, keyboard.device, netinfo.device etc.) liegen bei mir unter "Mein MorphOS" --> "MOSSYS" --> "Devs". [ - Antworten - Zitieren - Direktlink - ] |
|
05.09.2022, 20:57 Uhr Primax Posts: 462 Nutzer |
Hast du etwas dagegen, wenn ich deinen Erfahrungsbericht in den englischen News als eben solches bringe? Oder möchtest du den gar selbst schreiben? Ich glaube, da interessieren sich einige für... [ - Antworten - Zitieren - Direktlink - ] |
|
06.09.2022, 03:36 Uhr Maijestro Posts: 397 Nutzer |
@Primax: Das kannst du gerne machen damit es auch anderen hilft es besser zu verstehen. Es gibt auch noch einige Ergänzungen die ich später hinzufügen werde. Es sind kleine Optimierungen womit das Ganze noch etwas besser läuft zb. wie man das ganze mit dem ati-vga device (ATI Rage) emulation einbindet um höhere Auflösungen unter MorphOs setzen zu können. Internet Probleme löst und die Maus Geschwindigkeit verbessert. Mein Englisch ist leider nicht so gut, darum würde ich mich freuen wenn du das übernehmen würdest. [ - Antworten - Zitieren - Direktlink - ] |
|
06.09.2022, 03:52 Uhr Maijestro Posts: 397 Nutzer |
[ Dieser Beitrag wurde von Maijestro am 06.09.2022 um 03:52 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
06.09.2022, 03:54 Uhr Maijestro Posts: 397 Nutzer |
Zitat: Perfekt es hat geklappt…danke. [ - Antworten - Zitieren - Direktlink - ] |
|
07.09.2022, 19:47 Uhr Primax Posts: 462 Nutzer |
@Maijestro: Meine Mail bekommen...? [ - Antworten - Zitieren - Direktlink - ] |
|
08.09.2022, 03:51 Uhr Maijestro Posts: 397 Nutzer |
[ Dieser Beitrag wurde von Maijestro am 28.12.2022 um 18:53 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
28.12.2022, 18:52 Uhr Maijestro Posts: 397 Nutzer |
Hier noch mal der versuch mit Qemu 7.2.0 und AmigaOa4.1 Sam460 leider bekomme ich AmigaOs 4.1 nicht installiert. Aber es ist wirklich unglaublich schnell kein vergleich zu WinUae. Die Startparameter für Qemu die ich verwende: qemu-system-ppc -M sam460ex -m 2048 -rtc base=localtime -vga none -device sm501 -drive if=none,id=cd,file=Sam460InstallCD-53.58.iso,format=raw -device ide-cd,drive=cd,bus=ide.1 -drive if=none,id=hd,file=sam460.img,format=raw -device ide-hd,drive=hd,bus=ide.0 -boot order=c,menu=on -device rtl8139,netdev=mynet0 -netdev user,id=mynet0 -device es1370 Eventuell hat jemand eine Idee wie sich das Problem beheben lässt. AmigaOs4.1Sam460 [ - Antworten - Zitieren - Direktlink - ] |
|
29.12.2022, 13:20 Uhr thomas Posts: 7716 Nutzer |
Angeregt von diesem Thread habe ich vor einiger Zeit QEMU auf meinem Windows-Rechner ausprobiert. Von unglaublich schnell kann keine Rede sein. Es ist eher exakt genauso schnell wie WinUAE. Ich vermute, dass QEMU under MacOS die PPC-Emulation von Apple verwendet, während es unter Windows eine selbstgeschriebene Emulation benutzt, die auch bei WinUAE zum Einsatz kommt. Ich konnte die CD problemlos booten und OS 4 installieren. Die Probleme begannen bei mir nach der Installation. Offenbar bootet AmigaOS erstmal mit einem 8bit-Modus, was die emulierte Grafikkarte nicht unterstützt. Da ich quasi blind keinen Screenmode auswählen konnte, habe ich mir damit beholfen, den Treiber und screenmode.prefs von der CD zu kopieren. Anschließend konnte ich in Prefs/Screenmode einen angenehmen Bildschirmmodus einstellen. Was seltsamerweise auch nicht funktioniert, ist SmartFilesystem. Obwohl es im Kickstart-Ordner und im Kicklayout vorhanden ist und man auch die Version abfragen kann, trägt es sich nicht in die filesystem.resource ein. D.h. SFS-Partitionen werden nicht angemeldet. Wenn man SFS aus dem Kicklayout entfernt und dann die 68k-Version in den RDB schreibt, funkioniert es. Aber das geht natürlich nicht vor der Installation, weil man das Kicklayout der CD nicht ändern kann. -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
29.12.2022, 19:56 Uhr DaFreak Posts: 344 Nutzer |
apropos geschwindigkeit in winuae: Ich habe die dll (für win_x64, stand 2021) heruntergeladen und mein winuae (mit alter qemu-x64, stand 2015) aktualisiert. funktioniert - wenn auch mit umwegen (dateiumbenennungen usw.). quelle: https://github.com/frodesolheim/qemu-uae die 6 jahre differenz macht zumindest gefühlsmäßig her etwas aus. in zahlen kann ichs leider nicht belegen. ein unkompliziertes mflops/mips cpu-benchmark programm für os4 kann ich leider nicht finden. aber ein mehr als angenehmes arbeiten ist es schon. vielen dank maijestro für den tipp! -- Sam440ep + AmigaOS4.1, Raspberry Pi 400 + AmigaOS3.1 (Amiberry) [ - Antworten - Zitieren - Direktlink - ] |
|
29.12.2022, 21:51 Uhr Maijestro Posts: 397 Nutzer |
@thomas: Du hast recht die meisten Virtualisierer und Emulatoren zb. Qemu, Crossover, Parallels, Wine etc. benutzen jetzt den von Apple entwickelten Hypervisor.framework (hvf)-Accelator dadurch wird das ganze sehr gut in der Benutzung. Ein Beispiel: Über mein Mac m1 benutze ich zb. Parallels mit der aktuellen version von Windows 11 ARM zum arbeiten perfekt, aber spielen darüber ist mäßigt. Dennoch beeindruckend schnell Parallels Windows11 ARM Noch mal zum eigentlichen Thema: Der nächste versuch war jetzt Qemu selber zu kompilieren und es hat auch ohne Probleme geklappt, vorher hatte ich fertige builds für MacOs benutzt. Selbst in den kompilierten build traten die Fehler bei der Grafikdarstellung beim booten auf. Es muß am Code liegen von Qemu für ARM oder einfach nur daran das die derzeit unterstützen Grafiktreiber die Qemu unterstützt einfach nicht unter AmigaOs4.1 verfügbar sind. Ich habe das mit verschiedenen Bildschirmausgaben getestet. -device sm501 und -vga cirrus Wie schon erwähnt mit MorphOs funktioniert das ganze sehr gut. Bleibt nur die Hoffnung das es in den nächsten Builds für MacOs gefixt wird...ich gebe die Hoffnung nicht auf. [ Dieser Beitrag wurde von Maijestro am 29.12.2022 um 22:08 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
29.12.2022, 22:01 Uhr Maijestro Posts: 397 Nutzer |
@DaFreak: Auch ich hab spürbar unter WinUae eine Verbesserung feststellen können. Ich bin auch nur durch Zufall darauf gekommen, dadurch das ich mich viel mit der emulation AmigaOs4.1 beschäftigt habe. Unter WinUae hab ich mir jetzt ein perfektes System eingerichtet und es ist auch up-to date. Viele Dinge funktionieren sehr gut zb. Demos und eine gute Auswahl an spielen und natürlich die standard Software für AmigaOs4.1 die kein Compositing oder ähnliches vorrausetzen. Es macht mir viel Freude das System nach etwa 10 Jahren wieder benutzen zu können ohne teure Hardware dafür kaufen zu müssen auch wenn es nicht perfekt ist. Aber wer weis wo die reise hingeht in Zukunft.  [ Dieser Beitrag wurde von Maijestro am 29.12.2022 um 22:30 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
30.12.2022, 07:13 Uhr Primax Posts: 462 Nutzer |
Ich hatte den Amiga-QEMU-Entwickler Zoltan BALATON gebeten, hier mal mitzulesen (er kann gut deutsch lesen) und hat folgende Anmerkungen: "Ich würde auf meine http://zero.eik.bme.hu/~balaton/qemu/amiga/ Seite verweisen, wo es einige Informationen gibt, die helfen könnten, also empfehle ich, sie sorgfältig zu lesen und es gibt auch einen Kommentarbereich, um Fragen zu stellen. Die Option -boot wird wahrscheinlich in keiner dieser Befehlszeilen benötigt und kann einfach weggelassen werden. (Der sam460ex und pegasos2 werden sie wahrscheinlich ignorieren und auf dem mac99 wird die Option -prom-env boot-device sie überschreiben, sodass sie den Befehl ohne Wirkung überlagern.) Ähnlich verhält es sich mit -netdev user oder -net user, die weggelassen werden können, da dies die Standardeinstellung ist, sodass man einfach eine Netzwerkkarte als -device rtl8139 hinzufügen kann und es wird das standardmäßige user/slirp-Netzwerk ohne weitere Kommandozeilenoptionen verwendet. Das Hinzufügen eines Netzwerkgeräts ist wahrscheinlich nur auf sam460ex und pegasos2 notwendig, die keine Standard-Netzwerkkarte haben (ihre On-Chip-NICs werden nicht emuliert, sodass man ein PCI-Gerät dafür hinzufügen muss). Auf dem mac99 ist die Standardkarte sungem, die bereits standardmäßig erstellt ist, und MorphOS hat einen Treiber, der funktionieren sollte, aber es kann Probleme mit DHCP geben, sodass man die Netzwerkkonfiguration zurücksetzen und vielleicht die IP nach der Installation manuell einstellen muss. Das Hinzufügen einer weiteren rtl8139-Karte kann funktionieren, aber dann hat man zwei Netzwerkkarten und das sollte nicht nötig sein. QEMU verwendet auf allen Plattformen den gleichen Code. Es verwendet keine Apple PPC-Emulation, auch nicht unter macOS (die es wahrscheinlich gar nicht gibt, da Apple x86_64 in Rosetta 2 emuliert, nicht PPC; QEMU kann Apples Hypervisor.framework für die CPU-Virtualisierungsunterstützung verwenden, wenn es ARM-Gäste des gleichen Arches unter macOS ausführt, aber das ist wie KVM unter Linux und hilft nicht bei der Emulation anderer Arches wie PPC, die immer dynamisch von QEMU mit TCG übersetzt werden, dem JIT-Compiler von QEMU). Aber einige Leute im emaculation.com Forum sagten auch, dass es gut auf dem Apple M1 zu laufen scheint, also vielleicht ist diese CPU einfach so schnell. QEMU emuliert nur NG-Amiga-Maschinen ohne Legacy-Hardware, während WinUAE einen klassischen Amiga mit einem PPC-Beschleuniger emuliert, wobei die PPC-Emulation eine ältere Version von QEMU verwendet, sodass es aus zwei Gründen langsamer sein könnte: wegen der Weiterentwicklung von QEMU im Vergleich zu der alten Version, die in WinUAE verwendet wird, oder wegen der zusätzlichen Komplexität der Ausführung von Software mit Einschränkungen, die durch die klassische Amiga-Architektur auferlegt werden, wo der PPC eher ein Zusatz als die Haupt-CPU ist, aber ich weiß nicht viel über klassische Amiga-Emulation oder klassische PPC-Beschleuniger, sodass ich das nicht mit Sicherheit sagen kann. Es könnte auch sein, dass der Poster die x86_64-Version von WinUAE mit der nativen ARM-Version von QEMU auf dem M1 Mac verglichen hat, also gibt es hier eine Menge Faktoren. Das Grafikproblem mit AmigaOS 4.1 auf dem M1 Mac wurde auch auf meiner Amiga-Seite berichtet (siehe die Diskussion in den Kommentaren dort), aber ich weiß nicht, was es verursacht und kann nicht über x86_64 berichten, also kann ich es auch nicht beheben, bis jemand den Commit findet, der es zerstört hat. Wenn es vorher funktioniert hat, könnte es durch eine Optimierung in QEMU v5.1 oder später kaputt gegangen sein, sodass man zuerst mit v5.0 testen und dann von dort aus aufwärts gehen könnte, um herauszufinden, wann es kaputt gegangen ist. Das macht am besten jemand, der es aus git auf einem M1 Mac kompilieren kann und dann v5.0.0 Tag oder andere Versionen zum Testen auschecken kann und dann einen git bisect zwischen den Versionen macht, wo es kaputt ging, um den Commit zu finden, der genauer betrachtet werden sollte. Ich kann das nicht tun, da ich keinen M1 Mac habe, also will ich es auch nicht darauf laufen lassen, also sollte jemand, der sich dafür interessiert, etwas Zeit investieren und herausfinden, wo es kaputt ist. Wenn es niemanden gibt, der es kompilieren kann, könnte man die Builds von emaculation.com ausprobieren, um eine ungefähre Vorstellung davon zu bekommen, wo das Problem zu suchen ist. Auch die neueste Version 7.2 von dort unterstützt alle Display-Backends unter macOS, d.h. cocoa, sdl und gtk, die man mit der Option -display auswählen kann. Diese zu testen könnte zumindest einen Hinweis darauf geben, ob das Problem mit der Kartenemulation oder mit der Anzeige von Grafikkarten auf dem Host liegt. Die Art und Weise, wie es grob funktioniert, ist, dass das Gastbetriebssystem die emulierte Karte programmiert, um Grafiken im Speicher der Karte zu rendern, die dann in das Host-Grafikformat konvertiert und angezeigt werden; es gibt eine Optimierung, um nur die Teile während der Anzeige zu aktualisieren, die sich geändert haben. Es könnte also überall scheitern, sei es, dass die Karte nicht korrekt emuliert wird, Aktualisierungen fehlen oder die Karte auf der Host-Seite falsch angezeigt wird. Da es unter Linux und Windows und anscheinend auch unter x86 macOS funktioniert, weiß ich nicht, was ohne weitere Informationen falsch sein könnte. Es sieht so aus, als ob einige Updates fehlen, aber es gab auch Änderungen im Cocoa Display Backend, sodass das auch die Ursache sein könnte, oder die sm501-Emulation oder sogar externe Bibliotheken, die unter macOS verwendet werden, oder sogar einige unzusammenhängende Änderungen weder im sm501- noch im Cocoa UI-Teil, z.B. im Dirty Tracking, um zu prüfen, was sich geändert hat. Ist das Grafikproblem unter Windows, das im letzten Beitrag beschrieben wurde, dasselbe wie das bekannte Problem Nr. 1 auf http://zero.eik.bme.hu/~balaton/qemu/amiga/#amigaos ? Wenn ja, gibt es dort einige Lösungen dafür, aber der Poster konnte es anscheinend schon lösen. Ich habe keine Ahnung von SFS, obwohl ich glaube, dass einige Leute etwas darüber in der Kommentarsektion gesagt haben, aber ich kann mich nicht erinnern, was oder ob es eine Lösung gab. In Problem #4 wird erwähnt, dass die Blockgröße beim Formatieren einer Partition standardmäßig zu groß ist, aber ich weiß nicht, ob das damit zusammenhängt, wahrscheinlich nicht. Zum Ausführen von MorphOS ist es wahrscheinlich am besten, qemu-system-ppc -machine pegasos2 -device ati-vga,romfile="" -serial stdio zu verwenden. Der mac99 funktioniert auch, nachdem man die temperature.sensor Aufgabe beendet hat, die ihn sonst ausbremst, aber leider geben die MorphOS-Entwickler nur Lizenzen für echte Hardware heraus, sodass man ihn nicht wirklich auf einer QEMU-emulierten Maschine benutzen kann, sondern nur testen. MorphOS bootet auch auf sam460ex, aber es ist dort viel langsamer, also frage ich mich, ob AmigaOS die gleiche Einschränkung hat und auf Pegasos2 schneller wäre, aber um es zu booten, muss man entweder die Boot-CD modifizieren, um den sm502-Treiber hinzuzufügen, oder man braucht eine Pegasos-II-Maschine, um ihn zu installieren und dann zu modifizieren, bevor man versucht, mit QEMU zu booten. Im Gegensatz zu MorphOS hat AmigaOS keinen ATI Rage128-Treiber und die Radeon-Chips sind komplexer, sodass sie noch nicht genug emuliert sind, um AmigaOS mit ati-vga zu booten. (Alternativ könnte man, wenn man eine echte PCI-Radeon-Karte hat (die, um sie mit moderner Hardware zu verbinden, wahrscheinlich auch eine PCIe-zu-PCI-Brücke benötigt), versuchen, PCI mit vfio unter Linux an das Gastbetriebssystem durchzureichen, aber ich habe noch von niemandem gehört, der das getan hat. Auch dies erfordert zusätzliche Hardware und wahrscheinlich einen Linux-Host, sodass es eingeschränkter ist als eine emulierte Karte sein könnte, aber auf der anderen Seite sollte native Geschwindigkeit sein, wenn es funktioniert. Ich weiß, dass es nicht mit mac99 funktioniert, aber vielleicht mit pegasos2 könnte es funktionieren. Eine PCIe-Karte zu verwenden und sie als PCI-Karte durchzugeben, funktioniert wahrscheinlich auch nicht, also bräuchte man eine echte PCI-Karte, die von AmigaOS 4.1 auf dem Pegasos II unterstützt wird, der kein PCIe hatte. Sam460ex hatte PCIe, aber es ist nicht korrekt emuliert, sodass das Durchreichen dort wahrscheinlich nicht funktioniert). Auch in diesem Befehl: qemu-system-ppc -M sam460ex -m 2048 -rtc base=localtime -vga none -device sm501 Die Option -vga none -device sm501 sollte für den sam460ex nicht benötigt werden, da dieser bereits einen sm501 an Bord hat, sodass eine weitere sm501 PCI-Karte hinzugefügt wird. Es funktioniert wahrscheinlich trotzdem, aber dann haben Sie zwei sm501-Geräte. Möglicherweise müssen Sie den sm501 nur auf mac99 oder pegasos2 hinzufügen, wo es standardmäßig keinen gibt, aber sam460ex hat ihn an Bord und QEMU emuliert ihn. [ - Antworten - Zitieren - Direktlink - ] |
|
30.12.2022, 10:05 Uhr Maijestro Posts: 397 Nutzer |
@Primax: Vielen lieben Dank! Ich hab jetzt einige Informationen mehr und kann anfangen alles Schritt für Schritt abzuarbeiten. Sicherlich könnte ich einige Bulids selber kompilieren aber das ist sehr Zeit intensiv. Aber ich verstehe auch wenn niemand versucht zu helfen um dieses Problem zu lösen wird es ein Problem bleiben. So bald es Fortschritte gibt melde ich mich wieder. [ - Antworten - Zitieren - Direktlink - ] |
|
30.12.2022, 22:17 Uhr Maijestro Posts: 397 Nutzer |
Heute habe ich viele Qemu Builds für MacOs getestet. Dabei bin ich bis Version 4 runtergegangen....alle Builds entahlten die selben Fehler bei der Grafikausgabe. Es waren alles speziell angepasste Versionen für MacOs. Bezogen habe ich das ganze von: Mac Qemu Ich habe mein Problem selber dort auch noch mal geschildert, jetzt heißt es Daumen drücken eventuell wird es Hilfe geben. Mehr geht erstmal nicht...heißt abwarten das irgendwann eine Verbesserung stattfindet. Solange begnüge ich mich mit WinUae mit dem ich auch recht zu frieden bin abgesehen von der etwas fehlenden 3D Beschleunigung. Es ist halt kein echter AmigaNG  [ Dieser Beitrag wurde von Maijestro am 30.12.2022 um 22:18 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2023, 08:07 Uhr Primax Posts: 462 Nutzer |
@Maijestro: Hatte Zoltan nochmal deine Infos weitergegeben und er hat folgendermaßen geantwortet: "Das scheint darauf hinzudeuten, dass das Problem nicht von QEMU selbst kommt, sondern vielleicht von einer Änderung in macOS oder den Bibliotheken, die QEMU verwendet (falls es vorher wirklich funktioniert hat, wie jemand sagte, aber da bin ich mir nicht sicher; es könnte auch sein, dass es auf M1-Macs immer kaputt war). Ich habe es jetzt auf einem älteren macOS 10.15 Catalina mit x86_64 getestet, welches das einzige macOS ist, das ich im Moment habe, und zumindest dort gab es keine Probleme: Die AmigaOS4-Installations-ISO hat keine fehlenden Display-Updates wie im Video in den Fehlerberichten. Ich bin mir immer noch nicht sicher, was das Problem für diejenigen, die es bekommen, verursachen könnte, aber ein Workaround zum Testen könnte sein, die Erkennung von Display-Updates zu deaktivieren und jedes Mal ein vollständiges Update des gesamten Displays zu erzwingen. Dies wird das System wahrscheinlich noch mehr verlangsamen, aber wenn das Problem mit der Erkennung von Änderungen zusammenhängt, könnte dies das Problem vermeiden. Man kann das mit diesem Patch machen (d.h. den Anfangswert von full_update auf 1 in qemu/hw/display/sm501.c::sm501_update_display() am Anfang der Funktion ändern und dann QEMU kompilieren): diff --git a/hw/display/sm501.c b/hw/display/sm501.c --- a/hw/display/sm501.c +++ b/hw/display/sm501.c @@ -1655,7 +1655,7 @@ static void sm501_update_display(void *opaque) int dst_bpp = surface_bytes_per_pixel(surface); draw_line_func *draw_line = NULL; draw_hwc_line_func *draw_hwc_line = NULL; - int full_update = 0; + int full_update = 1; int y_start = -1; ram_addr_t offset; uint32_t *palette; [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2023, 20:12 Uhr Maijestro Posts: 397 Nutzer |
@Primax: Ich muss mich noch mal ganz lieb bei dir bedanken für deine Unterstützung! Folgendes Problem: Ich habe mir den letzen Source Code Qemu 7.2.0 von der offiziellen Seite Qemu.org runtergeladen und das ganze wie folgt Kompiliert: ./configure make Das ganze läuft ohne Fehlermeldung und sauber durch und ein fertiges Build wird erstellt. Wenn ich jetzt die ppc Maschine "qemu-system-ppc" starte, startet sie zwar aber ohne Rückmeldung wie bei anderen Maschinen das sie nicht konfiguriert sind. Auch das einfügen meiner Befehlszeile womit ich AmigaOs4.1 sonst starte über Qemu funktioniert nicht mit dem selber Kompilierten Build. Den patch selber hab ich noch nicht eingefügt es handelt sich um den unveränderten Source Code von Qemu. Bevor ich nicht ein Funktionierendes Build erstellt habe wäre es auch nicht nützlich weiter zu testen. Andere Maschinen funktionieren! Gibt es eine spezielle Konfiguration die ich vor dem Kompilieren setzen muss damit die Maschine "qemu-system-ppc" ordnungsgemäß arbeitet.? Gelöst: Der Befehlszeile muß -display cocoa mit angehangen werden sonst gibt es keine Fensterausgabe. Ich habe die Änderungen wie hier beschrieben durchgeführt und das ganze dann Kompiliert. Es führt leider nicht zum gewünschten erfolg die Kaputte Grafikdarstellungen bleibt leider weiterhin bestehen. Qemu veränderte Sourcen [ Dieser Beitrag wurde von Maijestro am 02.01.2023 um 06:00 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
02.01.2023, 14:46 Uhr Primax Posts: 462 Nutzer |
@Maijestro: Zoltan: "Damit ist zumindest bestätigt, dass das Diry Tracking funktioniert und das Problem nicht dort liegt. Dann kann es bereits im RAM der emulierten Karte defekt sein (in diesem Fall ist es ein Rendering-Problem) oder es bricht während der Anzeige auf der Host-Seite. Um das Problem weiter einzugrenzen, können Sie noch ein paar Dinge testen: - Probieren Sie verschiedene Display-Backends aus: Das letzte emaculation.com-Build hat cocoa, sdl und gtk, also schauen Sie, ob das Problem mit allen von ihnen auftritt. Wenn ja, dann liegt es auch nicht im Backend-Teil, also müssen wir die sm501-Emulation weiter überprüfen, da wir dann die Update- und UI-Backend-Teile ausschließen können. - Werden die fehlenden Teile angezeigt, wenn der Gast-Mauszeiger über sie fährt? Der Hardware-Cursor, der von der Maus verwendet wird, bewirkt eine Aktualisierung der Zeilen, auf denen er sich befindet. Wenn also das Überfahren der fehlenden Anzeige das Problem behebt, dann ist es nur ein Problem mit der Aktualisierung der Host-Anzeige. Aber ich denke, das Video hat gezeigt, dass es sich nicht mit der Mausbewegung ändert und das Erzwingen der Aktualisierung des gesamten Bildschirms hat es auch nicht behoben, was bedeutet, dass es wahrscheinlich schon nicht richtig gerendert wird. - Die 2D-Beschleunigung in sm501 verwendet die pixman-Bibliothek, wenn diese also nicht wie erwartet funktioniert, könnte das ein Problem sein, aber Versionen vor QEMU 5.1 haben pixman nicht verwendet (es wurde in Commit b15a22bbcbe6a hinzugefügt) und emaculation.com-Builds verwenden möglicherweise ihre eigenen Bibliotheken, wenn es also auch mit diesen nicht funktioniert, weiß ich nicht, woher das Problem kommen könnte. Ich habe das libpixman-devel-Paket von macports zum Testen verwendet und zumindest das funktionierte auf x86_64 macOS. - Es ist auch seltsam, dass einige Teile der Anzeige korrekt wiedergegeben werden, aber einige fehlen. Wenn wir wüssten, was der Unterschied zwischen den beiden ist, hätten wir vielleicht einen Anhaltspunkt, wo das Problem liegt. Kann das Problem mit einem anderen Gastbetriebssystem wie AROS oder Linux reproduziert werden? Auf diese Weise könnten wir es der QEMU-Liste melden, da andere, die kein AmigaOS4 haben, es dann reproduzieren könnten (obwohl wahrscheinlich niemand an sam460ex interessiert ist, sodass ich nicht erwarte, dass sich jemand darum kümmert, aber es wäre zumindest einen Versuch wert, um das Problem zu dokumentieren) oder da diese Betriebssysteme Open Source sind, könnten wir herausfinden, woher die fehlenden Updates kommen. Ich habe im Moment keine bessere Idee, wie man das Problem beheben kann." [ - Antworten - Zitieren - Direktlink - ] |
|
02.01.2023, 23:35 Uhr Maijestro Posts: 397 Nutzer |
Zitat: Aros PPC Sam460 [ Dieser Beitrag wurde von Maijestro am 03.01.2023 um 15:51 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2023, 18:14 Uhr Primax Posts: 462 Nutzer |
@Maijestro: Zoltan: "OK, danke für den ausführlichen Test, das hilft, das Problem zu lokalisieren. Nur eine Vermutung, aber die Option -display gtk könnte einen X-Server benötigen, je nachdem, wie die gtk-Bibliotheken kompiliert wurden. Unter macOS kann gtk auch verschiedene Grafik-Backends verwenden, von denen einer der native Quarz ist, der ohne zusätzliche Software funktionieren sollte, aber es ist auch möglich, es so zu kompilieren, um X zu verwenden. In diesem Fall muss man X11.app installieren, das früher Teil der devel-Diskette war, aber heutzutage wahrscheinlich in brew enthalten ist. Wie auch immer, es ist jetzt nicht benötigt, da das Testen mit Cocoa und sdl bestätigt, dass es nicht am UI Backand-Teil liegt. Das Update Parch hat bestätigt, dass es nicht an der Änderungsverfolgung oder an Updates liegt und dass es mit AROS und MorphOS funktioniert, was darauf hindeutet, dass das Problem entweder in der 2D-Beschleunigung oder in der DMA-Controller-Emulation liegt, da nur AmigaOS diese auf dem sam460ex verwendet, während AROS und MorphOS nur die CPU zum Rendern verwenden, da ihre SM502-Treiber ziemlich minimal sind. Leider weiß ich immer noch nicht, was falsch ist und warum es nur auf Apple-Silizium-Macs versagt, während es auf x86_64 funktioniert, aber zumindest gibt es eine Idee, wo das Problem weiter zu suchen ist. Dass das Testen mit der Vor-5.1-Version immer noch das gleiche Problem hervorruft, zeigt auch, dass es nicht an pixman liegt, also vielleicht liegt es doch in QEMU. Es könnte aber auch etwas nicht-triviales sein wie Interaktion zwischen den Interna von QEMU sein, daher bin ich mir nicht sicher, wie man das Problem beheben kann. Vielleicht könnten Sie versuchen, nach der Konfiguration mit der Konfigurationsoption --enable-debug neu zu kompilieren, die es viel langsamer machen wird, aber es deaktiviert einige Optimierungen und aktiviert einige Prüfungen, so könnte man die Theorie überprüfen, wenn es ein Problem mit Optimierungen in QEMU oder Clang ist oder wirklich etwas falsch mit den Geräteemulationen ist." [ Dieser Beitrag wurde von Primax am 03.01.2023 um 18:15 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2023, 22:06 Uhr Maijestro Posts: 397 Nutzer |
Vielen dank noch mal für die Hilfe. Qemu 7.2.0 aus den offiziellen Source Code von Qemu.org Kompiliert mit: ./configure --target-list=ppc-softmmu --enable-slirp --enable-cocoa --enable-debug Ich weis nicht genau wie ich das Debugging starten muß es gibt im internet nur wenig Informationen darüber. [ - Antworten - Zitieren - Direktlink - ] |
|
04.01.2023, 07:40 Uhr Primax Posts: 462 Nutzer |
@Maijestro: Zoltan: "Es ist nicht notwendig, irgendetwas mit einem Debugger zu tun, testen Sie einfach, ob der Build mit --enable-debug das gleiche Problem wie vorher hat, indem Sie den gleichen Befehl verwenden. Die Option --enable-debug deaktiviert die Compiler-Optimierungen und einige QEMU-Optimierungen, sodass dies zeigen sollte, ob das Problem mit diesen oder etwas anderem zusammenhängt. Mit der Hilfe eines AmigaOS-Entwicklers, der schon einmal dabei geholfen hat, denke ich nun, dass das Problem mit der 2D-Beschleunigung in sm501 zusammenhängt, die nur AmigaOS verwendet (vielleicht auch einige Linux X-Server, aber ich kenne keine einfach zu testende Live-CD, die auf dem sam460ex mit sm501 funktioniert, die meisten benötigen eine Radeon-Karte). Mit den bisherigen Tests können wir auch pixman ausschließen, da das Problem auch bei alten Versionen auftritt, die es nicht verwendet haben. Es sieht also so aus, als ob Daten, die in qemu/hw/display/sm501.c::sm501_2d_operation() geschrieben werden sollten, nicht von sm501_update_display() in derselben Datei gesehen werden. Die Funktion sm501_2d_operation() wird aufgerufen, wenn der Gast die 2D-Engine der sm501-Karte programmiert, die für Blits und Fills verwendet wird und die Pixeldaten im Ram der Karte ablegen soll. Dann ruft das UI-Backend periodisch die Funktion sm501_update_display() auf, um das Bild aus dem Ram der Karte zu holen und es auf die Anzeigefläche zu kopieren, die auf dem Host angezeigt wird. All dies geschieht außerhalb des Codes, den ich jetzt habe, also sehe ich nicht, warum es fehlschlagen könnte. Entweder werden die Daten aus irgendeinem Grund nicht in sm501_2d_operation() geschrieben, oder die Aktualisierungsfunktion sieht nicht denselben Speicher, den die Schreibvorgänge verändert haben (was passieren kann, wenn Hardware-Caching und verschiedene Threads involviert sind, bei denen die Schreibvorgänge nicht richtig synchronisiert werden, was etwas ist, das ARM und PPC brauchen, x86 aber nicht, aber ich weiß nicht, ob das wirklich der Grund ist und wo man es beheben kann). Sobald wir das Problem gefunden haben und eine bessere Vorstellung davon haben, was passiert, werde ich versuchen, in der QEMU-Liste nachzufragen. Um zusätzliche Debug-Meldungen zu erhalten, können Sie die folgenden Kommandozeilenoptionen hinzufügen: -d unimp,guest_errors -trace enable="sm501_2d*", was einige Zeilen über nicht implementierte Teile und Zugriffe auf die sm501 2d Funktion ausgibt, was mehr sein wird, als man auf einem Screen sehen kann, also sollte man in eine Datei umleiten, um es zu speichern und einen Link dazu zu posten. Diese Optionen funktionieren auch ohne --enable-debug, wenn also der --enable-debug-Build funktioniert, kann man das gleiche ohne --enable-debug testen und sehen, ob die Logs die gleichen sind. Wenn es auch mit --enable-debug fehlschlägt, ist es nicht nötig, beide Optionen zu testen, da das Problem nicht mit der Optimierung zusammenhängt, sondern wahrscheinlich ARM- oder M1-spezifisch ist." [ - Antworten - Zitieren - Direktlink - ] |
|
04.01.2023, 12:00 Uhr Maijestro Posts: 397 Nutzer |
@Primax: @Zoltan: OK verstehe, auch mit dem selber kompilierten Build und mit der Konfiguration --enable-debug gibt es keine Verbesserungen der Grafikdarstellung. Wie sie schon schrieben könnte es mit den Apple silicon chip zusammenhängen der ja etwas anders funktioniert wie auf Intel Maschinen. Ich kenne auch niemanden der AmigaOs4.1 mit Qemu zum laufen gebracht hat, alles was man so liest und auch sieht an Videos findet immer auf Mac`s mit Intel-Chipsatz statt. Mir hat es spaß gemacht das ganze zu testen, auch wenn es nicht zum gewünschten erfolg geführt hat. Leider sind auch meine Möglichkeiten begrenzt dabei zu helfen es lauffähig zu machen unter Qemu für Mac M1. Ich danke euch beiden dennoch das wir es zu mindestens versucht haben. Ich hätte das sehr gerne getestet mit ein voll installiertes AmigaOs4.1 System, der Ansatz sah vielversprechend aus und auch die Geschwindigkeit unter Qemu scheint hier auf meine Maschine gut zu sein. Wenn ihnen noch irgendwas einfallen sollte bin ich sehr gerne bereit weitere tests durchzuführen. Ansonsten heißt es nur noch Daumen drücken das sich in kommenden Builds irgendwas ändert tut zu Gunsten für Apple Silicon Chips in Zusammenspiel mit Qemu. [ Dieser Beitrag wurde von Maijestro am 04.01.2023 um 12:06 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
20.01.2023, 05:47 Uhr Primax Posts: 462 Nutzer |
@Maijestro: Zoltan hatte mit deiner Hilfe das Problem etwas eingegrenzt und eine Nachfrage auf QEMU-List veröffentlicht: https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg04313.html Vielleicht kannst du mit Hilfe eines Übersetzungs-Tools dir das mal ansehen und das "commenting out memory_region_snapshot_and_clear_dirty() and memory_region_snapshot_get_dirty()" mal ausprobieren, falls dir das was sagt... [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 3 4 5 6 >> Letzte | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > AROS und Amiga-Emulatoren > Qemu AmigaOs4.1/Morphos | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|