amiga-news 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 - ]

Erste 1 2 3 4 5 -6- 7 8 9 10 11 Letzte [ - Beitrag schreiben - ]

15.04.2023, 19:55 Uhr

Reth
Posts: 1858
Nutzer
@Falke_34:
Super! Vielen Dank! Damit kann ich nun auch ohne Crash der ramlib von CD in die WB booten! Klasse!

"Leider" ist die Schrift etwas pixelig beim CD-Boot, kann man da noch was an den QEmu-Parametern ändern oder wird das "nur" durch die Screenmode-Einstellungen der WB gesteuert.

Bzgl. der Partitionen hätte ich auch noch die Frage, ob man denn nun welche überhaupt auf Boot und/oder Automount setzt oder alle nicht? (Das kam für mich nicht so ganz aus der Anleitung heraus.)

Das Booten der installierten AOS4.1 Installation klappt leider auch noch nicht. Es erscheint der Fehler: filesystem not supported - habe für die BOOT-Partition "Standardfilesyste" + "FastFilesystem" +
"Long filenames" eingestellt, so wie auf einem der Screenshots weiter oben in diesem Thread gezeigt.

Da die Boot-Partition nicht angemeldet und nicht formatiert wurde hab ich das manuell gemacht (von CD in die WB gebootet). Danach hab ich die Installation nochmal gestartet.

In keinem der Versuche wird mir aber die Installation der Boot-Partition angezeigt, so dass ich diese nie installieren kann.

Muss ich da noch was ändern? (Hab mich eigentlich durch die ganze Anleitung von dem amiga-news Beitrag gehangelt.)

[ Dieser Beitrag wurde von Reth am 15.04.2023 um 20:26 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.04.2023, 21:46 Uhr

DaFreak
Posts: 354
Nutzer
Hinweis: Warp3D-Demo "Cow3D" (aus dem Aminet) funktioniert mit installierten Wazp3D für OS4.
Da der SM502 emuliert wird, ist natürlich wie auf echter Hardware keine 3D-Beschleunigung möglich.

Wäre aber eine gute Möglichkeit zum Benchmarken, wenn die FPS-Angabe in der Titelzeile funktionieren würde. ;) Da werden leider 0 FPS angezeigt.

--
Sam440ep + AmigaOS4.1, Raspberry Pi 400 + AmigaOS3.1 (Amiberry), PC-i7_9700 + AmigaOS4.1 (QEmu)

[ - Antworten - Zitieren - Direktlink - ]

15.04.2023, 22:17 Uhr

Maijestro
Posts: 408
Nutzer
@Reth:

Warum befolgen Sie nicht den Weg meiner Anleitung, ich zeige hier detailliert wie man Partitionen vor der installation einrichten tut. AmigaOs4.1 verhält sich unter jeden System gleich Linux/MacOs/Windows.

Die BOOT (FFS) Partition dient nur dafür das AmigaOs4.1 von der eigentlichen Installations Partition SFS booten tut. Hier noch mal das Video der Einrichtung von Partitionen vor der eigentlichen installation.

Installieren Sie AmigaOs4.1 nicht auf der Boot Partition, sondern auf die erste mit SFS angelegte Partition. Und fügen Sie bitte ihre Qemu Befehlszeile -cpu 7447 hinzu, wenn sie das nicht bereits getan haben, damit können Sie auch Partitionen mit SFS problemlos nutzen wie es im Video zu sehen ist.

AmigaOs4.1 Partitionierung SFS

[ Dieser Beitrag wurde von Maijestro am 15.04.2023 um 22:17 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.04.2023, 22:22 Uhr

Maijestro
Posts: 408
Nutzer
@DaFreak:

Bereits getestet auch einige andere Anwendungen mit Wazp3D funktionieren gut zB. Cube, glGears etc. im Os4Depot gibt es einige MiniGL Anwendungen die wirklich gut laufen. Es ist natürlich kein ersatz für echte 3D Beschleunigung.

[ - Antworten - Zitieren - Direktlink - ]

15.04.2023, 22:32 Uhr

DaFreak
Posts: 354
Nutzer
Zitat:
Original von Maijestro:
Installieren Sie AmigaOs4.1 nicht auf der Boot Partition, sondern auf die erste mit SFS angelegte Partition.


Naja, man kann es sich aber auch einfacher machen und das OS direkt auf die Boot-Partition (FFS/07) installieren. Für zusätzliche Programme/Games/Demos kann man dann ja nach Belieben eine SFS-Partition anlegen. Oder gibt es entscheidende Nachteile das nicht so zu handhaben?
--
Sam440ep + AmigaOS4.1, Raspberry Pi 400 + AmigaOS3.1 (Amiberry), PC-i7_9700 + AmigaOS4.1 (QEmu)

[ - Antworten - Zitieren - Direktlink - ]

15.04.2023, 23:07 Uhr

Maijestro
Posts: 408
Nutzer
Zitat:
Original von DaFreak:
Zitat:
Original von Maijestro:
Installieren Sie AmigaOs4.1 nicht auf der Boot Partition, sondern auf die erste mit SFS angelegte Partition.


Naja, man kann es sich aber auch einfacher machen und das OS direkt auf die Boot-Partition (FFS/07) installieren. Für zusätzliche Programme/Games/Demos kann man dann ja nach Belieben eine SFS-Partition anlegen. Oder gibt es entscheidende Nachteile das nicht so zu handhaben?
--
Sam440ep + AmigaOS4.1, Raspberry Pi 400 + AmigaOS3.1 (Amiberry), PC-i7_9700 + AmigaOS4.1 (QEmu)


Ja es gibt gravierende unterschiede FFS ist etwa 40 Jahre alt und verglichen zu SFS sehr langsam. SFS ist fortgeschrittener und um einiges schneller und ist fehlerfreier gerade dann wenn das System im laufenden Prozess bzw. bei Datenübertragung einfriert und neugestartet werden muß.

AmigaOs4.1 File Systems

[ Dieser Beitrag wurde von Maijestro am 15.04.2023 um 23:08 Uhr geändert. ]

[ Dieser Beitrag wurde von Maijestro am 15.04.2023 um 23:09 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.04.2023, 23:09 Uhr

Reth
Posts: 1858
Nutzer
@Maijestro:
Das ist mir bewusst, dass man AOS4 nicht auf der Boot-Partition installiert. (Ich hatte es ja damals auch auf meinem echten Peg2 installiert.) Und ich habe die Anleitung auch befolgt. Dazu auch noch die verlinkte Anleitung (PDF) zum Einrichten der Partitionen. -cpu 7447 habe ich ebenfalls hinzugefügt (siehe meine früheren Posts).

Aber wenn ich die Installation von AOS4.1 aus dem Dock starte werde ich nach allem ganz normal abgefragt, aber die Abfrage nach der BOOT-Partition erfolgt nicht. Sie taucht einfach nicht auf.
Und die BOOT-Partition ist wie beschrieben die erste in meinem HD-Image-File mit dem beschriebenen Filesystem.

Der folgende Teil des Boot-Scriptes wird bei mir dabei leider nicht ausgeführt und ich bekomme ihn nicht angezeigt:
Bild: https://amiga.freecluster.eu/Anderes/AOS4/Boot_Intall.png

In der Anleitung hier hatte ich dazu nichts gefunden. Und es heißt dort, dass die Installation des AOS4 und des Bootloaders "wie gewöhnlich" abläuft. Daher bin ich davon ausgegangen, dass auch die BOOT-Partition mit allen benötigten Dateien im Rahmen des Installationsskriptes mit installiert wird.

In dem weiter oben verlinkten Video hab ich dann aber am Schluss gesehen, dass amigaboot.of von Hand auf die Boot-Partition kopiert werden muss, damit direkt von dort gebootet werden kann. Die Datei habe ich dann manuell auf die BOOT-Partition kopiert. Das hab ich dann ebenfalls so gemacht.

Mein Fehler war, dass ich das Kicklayout auf meinem ISO-Image verhunzt hatte und dort an beiden Orten (also im Kickstart-Verzeichnis und im System/Kickstart-Verzeichnis) das Layout-File abgelegt habe, welches System/ in den Verzeichniseinträgen hat. 8o - Ich Honk! Oh man!

Hat ne Weile gedauert, bis ich das gefunden hatte. Au backe!

Hab nun nochmal alle Partitionen formatiert, das Image angepasst und neu installiert. Danach das amigaboot.of auf die Boot-Partition kopiert. Nun hat die Installation geklappt und ich kann von der installierten AOS4-Partition booten.

Daher: Mea culpa. Stand mir selbst im Weg!

[ Dieser Beitrag wurde von Reth am 16.04.2023 um 12:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.04.2023, 23:32 Uhr

DaFreak
Posts: 354
Nutzer
Zitat:
Original von Maijestro:
Ja es gibt gravierende unterschiede FFS ist etwa 40 Jahre alt und verglichen zu SFS sehr langsam. SFS ist fortgeschrittener und um einiges schneller und ist fehlerfreier gerade dann wenn das System im laufenden Prozess bzw. bei Datenübertragung einfriert und neugestartet werden muß.


Ich meine natürlich FFS2 (= DOS/07), welches erst mit AmigaOS4.0 erschienen ist und einige entscheidende Unterschiede zum "40 Jahre alten FFS" hat aber eben kompatibel bleibt. Siehe https://thomas-rapp.homepage.t-online.de/filesyslimits.html :)

Aber okay ich kann deine Einwände nachvollziehen. SFS ist moderner. Vlt partitioniere ich mein System nochmal um.
--
Sam440ep + AmigaOS4.1, Raspberry Pi 400 + AmigaOS3.1 (Amiberry), PC-i7_9700 + AmigaOS4.1 (QEmu)

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 01:18 Uhr

smarkusg
Posts: 37
Nutzer
Ich habe eine Bitte, denn ich teste ein Problem mit SDL und ein Problem mit 7447-Amulation.

Bitte ändern Sie, statt "-cpu 7447" geben Sie die Option "-cpu g3".
- keine Programme mit AltiVec laufen lassen.
- keine Emulationen ohne "-cpu g3" laufen lassen
- überprüfen Sie Ihre Lieblingsanwendungen, Benchmarks usw.


Ich habe heute einige Zeit mit einem Problem verbracht, bei dem ein SDL-Bild nicht richtig angezeigt wurde.
Ich habe ein paar Testprogramme konvertiert, aber das Problem besteht weiterhin.
Außerdem habe ich ein Problem mit SDL2 gefunden, das ich überhaupt nicht mehr verstehe.
Zwei Versionen von SDL2 2.2 und 2.26 "teilen sich eine zeigt ein gutes Bild, die andere unscharf.

Es gibt auch einige Inkompatibilitäten bei der Emulation des 7447
---
Original Pegasos
System: bplan Pegasos 2, rev 2B
CPU: PPC 7457, ver. 0x8002, rev. 0x101

Laut QEMU
qemu/roms/u-boot-sam460ex/arch/powerpc/cpu/74xx_7xx/cpu.c
Fall 0x8002:
type = CPU_7457;
brechen;

PowerPC 7457_v1.1 PVR 80020101

Thema der Quelle -> https://forum.hyperion-entertainment.com/viewtopic.php?f=18&t=2210&start=10
--


Aber hier ist die Quintessenz.
Die Anzahl der Kerne im Host-Computer ist irrelevant. Emulation ist 1:1 - eine CPU ein Kern. Amiga bietet uns eine CPU.
Es ist möglich, dass "AltiVec" mehr Probleme als Vorteile im aktuellen Qemu verursacht. Es ist sogar möglich, dass etwas schneller laufen wird. Der Emulator muss keine unnötigen CPU-Eingriffe vornehmen.
Ich bin kein Experte auf diesem Gebiet, also bitte ich um einen Test.



Herzlichen Dank für Ihre Hilfe und Zeit



[ Dieser Beitrag wurde von smarkusg am 16.04.2023 um 01:20 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 01:47 Uhr

DaFreak
Posts: 354
Nutzer
Zitat:
Original von smarkusg:
Bitte ändern Sie, statt "-cpu 7447" geben Sie die Option "-cpu g3".

- überprüfen Sie Ihre Lieblingsanwendungen, Benchmarks usw.


Im SDLBench macht das einen größeren Unterschied, den ich auch nach mehrmaligen Versuchen verifizieren kann:

Mit CPU 7447:
sysmon6.4-sdlbench: siehe https://i.imgur.com/48q2afU.jpg
-> 320x240: 123.08 fps (+321%)
-> 640x480 21.56 fps (+473%)
sdl2.26.1-sdl2benchmark siehe https://i.imgur.com/9dVvkeV.jpg
-> compositing ist schneller
-> opengl etwa vergleichbar

Mit CPU G3:
sysmon6.4-sdlbench: siehe https://i.imgur.com/TbKbU5D.jpg
-> 320x240: 80.00 fps (+174%)
-> 640x480: 13.16 fps (+250%)
sdl2.26.1-sdl2benchmark siehe https://i.imgur.com/x8SxUzA.jpg
-> compositing ist langsamer
-> opengl etwa vergleichbar


Das heisst, die G3 Emulation ist schon deutlich langsamer bei SDL wie die 7447 Emulation. In der Praxis kann ich das noch nicht überprüfen, da ich aktuell keine SDL-Games verwende.

[ Dieser Beitrag wurde von DaFreak am 16.04.2023 um 02:09 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 07:23 Uhr

smarkusg
Posts: 37
Nutzer
@DaFreak:

Vielen Dank für Ihre Hilfe :-)

Weitere Tests sind nicht erforderlich


1. Sie haben mich auf etwas aufmerksam gemacht, das ich vergessen hatte. SDL2 (ich weiß nichts über SDL1) hat eine automatische AltiVec-Erkennung.

https://wiki.libsdl.org/SDL2/SDL_HasAltiVec

2. Meine Vermutung ist falsch und dumm.

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 11:52 Uhr

danica_talos
Posts: 78
Nutzer
Zitat:
Original von Maijestro:
Zitat:
Original von danica_talos:
@Falke_34

Wenn er beim Start versucht die Cd zu laden und dann die siliconmotion502.chip in system/kickstart nicht findet, ist dann die iso nicht bootfähig oder woran kann das liegen?
--
Mac Mini G4 1,50 GHz mit MorphOS 3.4 (registriert).
PowerBook G4 (5,8) 1,67GHz, 128MB VRAM, 2 GB DDR2 RAM mit MorphOS 3.4 (registriert).


Etwas mehr Details wären Hilfreich, wie sind Sie vorgegangen bei der Einrichtung des Installations Mediums?

Auch ohne siliconmotion502.chip ist die CD/ISO boot bar, aber es findet keine Grafikausgabe statt, da kein geeigneter Treiber gefunden bzw. geladen werden kann und so bleibt der Bildschirm schwarz.

[ Dieser Beitrag wurde von Maijestro am 15.04.2023 um 18:29 Uhr geändert. ]


Ich hatte die fehlenden Files in die Iso integriert und die Kicklayout in Kickstart und System/Kickstart bearbeitet.

Bei Start versucht er von der Amiga-CD zu starten und sagt, dass es die silicommotion502.chip nicht findet. Mehr passiert nicht...
--
Mac Mini G4 1,50 GHz mit MorphOS 3.4 (registriert).
PowerBook G4 (5,8) 1,67GHz, 128MB VRAM, 2 GB DDR2 RAM mit MorphOS 3.4 (registriert).

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 12:37 Uhr

Maijestro
Posts: 408
Nutzer
Zitat:
Original von smarkusg:
@DaFreak:

Vielen Dank für Ihre Hilfe :-)

Weitere Tests sind nicht erforderlich


1. Sie haben mich auf etwas aufmerksam gemacht, das ich vergessen hatte. SDL2 (ich weiß nichts über SDL1) hat eine automatische AltiVec-Erkennung.

https://wiki.libsdl.org/SDL2/SDL_HasAltiVec

2. Meine Vermutung ist falsch und dumm.


Es gibt nichts dummes, wir können es selber nur testen und dadurch besser machen und das tust du bereits und das finde ich sehr gut. Auch ich kann die Fehler mit SDL und -cpu 7447 reproduzieren, eine Möglichkeit wäre das man die automatische AltiVec-Erkennung in SDL deaktiviert, aber ich weis nicht wie man das macht. Ich vermute das es beim kompilieren deaktiviert werden könnte. Dafür müssten wir herausfinden wie man SDL unter AmigaOs4.1 Kompiliert oder jemand fragen der das bereits gemacht hat.

Qemu 7.2 und 6.2 enthalten die selben Fehler mit SDL, alle anderen Versionen davor konnte ich nicht testen

Sonst fällt mir leider auch nichts weiter dazu ein um das Problem zu lösen :-(

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 12:56 Uhr

Reth
Posts: 1858
Nutzer
Habe meinen letzten Post oben angepasst!

Hab den Fehler gefunden - hatte eine meiner Kicklayout-Dateien im gepatchten ISO-Image verhunzt (Details s. oben).

Nun funktioniert das Booten der installierten Version! :)

Vielen Dank!

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 16:24 Uhr

Reth
Posts: 1858
Nutzer
Ein "Problem" besteht allerdings noch: Ich habe bei der Installation eine maximale Auflösung von 1920x1080 angegeben. Allerdings wird mir bei der Auswahl des Screenmodes maximal 1280x1024 bzw. 1440x900 angezeigt. Beim Monitor der SiliconMotion ist aber ein Eintrag für 1920x1080@60Hz vorhanden.

Wie kann ich das denn noch nachträglich anpassen, so dass ich die höhere Auflösung nehmen kann?

Zusätzlich wollte ich noch ein paar Tools von der CD nachträglich installieren. Aber jedes Mal, wenn ich die Batchdatei mit eingetragenem CD Image verwende und bei der Bootkonstellation auswähle, dass AOS4 von Festplatte gebootet werden soll werden zwar von dort die Kickstartdateien geladen, aber dennoch wird dann von CD gebootet, anstatt von DH0. Muss man da noch irgendwelche Umgebungsvariablen der emulierten Firmware anpassen oder noch was im Kicklayou ändern (alles schon sehr lange her beim echten Peg2)?

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 16:59 Uhr

DaFreak
Posts: 354
Nutzer
Zitat:
Original von Reth:
Ein "Problem" besteht allerdings noch: Ich habe bei der Installation eine maximale Auflösung von 1920x1080 angegeben. Allerdings wird mir bei der Auswahl des Screenmodes maximal 1280x1024 bzw. 1440x900 angezeigt. Beim Monitor der SiliconMotion ist aber ein Eintrag für 1920x1080@60Hz vorhanden.


Hi Reth,
der SM502 kann generell nur bis max. 1280x1024 ausgeben. Zumindest laut Datasheet: https://www.digikey.de/en/htmldatasheets/production/3444235/0/0/1/sm502gx00lf00-ac.html

Zitat:
Zusätzlich wollte ich noch ein paar Tools von der CD nachträglich installieren. Aber jedes Mal, wenn ich die Batchdatei mit eingetragenem CD Image verwende und bei der Bootkonstellation auswähle, dass AOS4 von Festplatte gebootet werden soll werden zwar von dort die Kickstartdateien geladen, aber dennoch wird dann von CD gebootet, anstatt von DH0.

Das Problem habe ich auch aber konnte es umgehen, indem ich mein CD-Image nachträglich nicht bootbar gemacht, also die notwendigen Files gelöscht habe. Alternativ einfach den CD-Inhalt auf eine Partition kopieren und dann selbst manuell nachinstallieren (aus dem versteckten Ordner "Installation-Files").

[ Dieser Beitrag wurde von DaFreak am 16.04.2023 um 17:04 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 17:05 Uhr

Maijestro
Posts: 408
Nutzer
Zitat:
Original von Reth:
Ein "Problem" besteht allerdings noch: Ich habe bei der Installation eine maximale Auflösung von 1920x1080 angegeben. Allerdings wird mir bei der Auswahl des Screenmodes maximal 1280x1024 bzw. 1440x900 angezeigt. Beim Monitor der SiliconMotion ist aber ein Eintrag für 1920x1080@60Hz vorhanden.

Wie kann ich das denn noch nachträglich anpassen, so dass ich die höhere Auflösung nehmen kann?


Es gibt noch einige Einschränkungen unter Qemu Pegasos 2, der SM501 kann nur eine maximale Auflösung von 1440x900 darstellen und ist auf 16 Bit beschränkt. Das beste Ergebnis erzielt man in dem Host und Gast die selbe Auflösung verwenden, so jedenfalls auf meine Maschine.

Zitat:
Zusätzlich wollte ich noch ein paar Tools von der CD nachträglich installieren. Aber jedes Mal, wenn ich die Batchdatei mit eingetragenem CD Image verwende und bei der Bootkonstellation auswähle, dass AOS4 von Festplatte gebootet werden soll werden zwar von dort die Kickstartdateien geladen, aber dennoch wird dann von CD gebootet, anstatt von DH0. Muss man da noch irgendwelche Umgebungsvariablen der emulierten Firmware anpassen oder noch was im Kicklayou ändern (alles schon sehr lange her beim echten Peg2)?

Wenn ich mit einglegter iso boote lässt mich die Firmware wählen von wo aus gebootet werden soll. Unter MacOs ist es auch möglich ISO nachträglich einzubinden im laufenden System, das geht aber nur im Fenster Modus. Ich bin mir nicht sicher wie es unter Windows geht, aber im Fenster Modus hast du dort eventuell eine Option die das möglich macht unter Qemu?

[ Dieser Beitrag wurde von Maijestro am 16.04.2023 um 17:15 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 17:14 Uhr

Reth
Posts: 1858
Nutzer
Danke euch!

@Maijestro:
Ja, die Firmware lässt mich auch wählen, von wo gebootet werden soll. Aber selbst wenn ich die Festplattenpartition für das Booten wähle wird danach von CD gebootet. Aber keine Ahnung woran das liegt. Evtl. an der Emulation der Firmware?
Hab schon seit Jahren meinen echten Peg2 nicht mehr von Festplatte gebootet, während eine bootfähige CD eingelegt war. Müsste ich ggf. mal ausprobieren - vllt. hat das echte Gerät sogar das gleiche Problem. Dann läge es ggf. an der Firmware oder deren einstellbaren Parametern (NVRAM Variables oder wie die hießen) oder an Parametern für die loader.of Datei. Das müsste ich aber erst nochmal nachlesen.

Generell schaue ich gerade, ob ich für Codebench eine schnelle und stabile Umgebung hinbekomme, um ggf. auch mal was compilieren zu können, wenn ich nicht vor meinem Peg2 sitze (was leider fast immer der Fall ist). Darum versuche ich mich aktuell an der QEmu-Installation, da Codebench unter WinUAE und AOS4.1 leider fast immer einfriert.

Momentan wird bei mir allerdings bei jedem Start des AOS4.1 von HD angezeigt, dass der Routeneintrag DEVS:Internet/Routes Zeile 4 (Standargateway) nicht hinzugefügt werden kann, da das Netzwerk nicht erreichbar ist. Wenn ich die Netzwerkkonfiguration erneut durchführe und den bestehenden Eintrag überschreibe geht es dann meistens.
Irgend eine Idee woran das liegen könnte, dass bei jedem Neustart das Netzwerk nicht erreichbar ist?
Leider konnte dadurch Update2 nicht komplett installiert werden, da RTL8139 in Gebrauch war (die Installation hat dort direkt abgebrochen - daher hab ich nun ein halbes Update2 - werde es von Hand herunterladen und versuchen, zu installieren).

Das nächste Problem ist, dass ich bei AmiUpdate keine Einstellungen abspeichern kann. Das crasht dann immer mit einem DSI (einige Einträge in den Einstellungen sind nur kryptische Zeichen, da liegt noch was im Argen). Ist da schon jemand dran vorbei gekommen bzw. hat das Problem gelöst? (Taste mich langsam vorwärts...)

OWB von der CD friert wohl auch gern ein. Das Einfieren scheint in den Emulationen noch eher der Fall zu sein, als auf einem nativen Peg2 (aber auch dort friert er gern ein, darum bin ich auf Odyssey gewechselt, den muss ich mir aber erst noch für die Emu besorgen).

[ Dieser Beitrag wurde von Reth am 16.04.2023 um 18:59 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 18:57 Uhr

Maijestro
Posts: 408
Nutzer
@Reth:

hmm das klingt alles etwas merkwürdig, eventuell ist bei dir irgendetwas anders oder schief gelaufen und du hast dir dein System an einer stelle kaputt gemacht. Wenn man mein Weg der Installation befolgt sollte es normalerweise auch funktionieren mit etwas kleineren Abweichungen.

Ich bin so vorgegangen wie in meiner Installationsanleitung beschrieben(die derzeit aktualisiert wurde und nächste Woche veröffentlicht wird, sobald Qemu 8 den finalen status erreicht hat).

Nach der eigentlichen installation und Netzwerkeinstellungen habe ich direkt AmiUpdate gestartet Update 1 und 2 installiert, alle anderen updates unter AmiUpdate habe ich ignoriert und erst nach dem ich Update 1 und 2 installiert hatte mit installiert.

Vielleicht hast du das Netzwerk auch falsch eingerichtet unter AmigaOs4.1......

AmiUpdate sollte auf keinen fall abstürzen, dass hatte ich noch nie ! Wenn man alles richtig macht hat mein ein sehr Stabiles System. Meine Videos bestätigen das..

Wir müssen jetzt herausfinden wo die Probleme bei dir liegen, eventuell komplett von vorne anfangen und alles neu einrichten und installieren. Vielleicht kann auch noch mal jemand anderes ein rat geben wie er es unter Windows eingerichtet hat.

[ Dieser Beitrag wurde von Maijestro am 16.04.2023 um 19:07 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 19:18 Uhr

Reth
Posts: 1858
Nutzer
@Maijestro:

Habe meinen Post oben nochmal aktualisiert. Es gibt mind. so viele Systemfreezes, wie auf einem normalen Peg2 mit AOS4.1 (zumindest auf meinem :D ) - gefühlt aber noch deutlich mehr.

Ich helfe gern mit beim Herausfinden und kann die Installation gern auch nochmal komplett durchführen. Die Partitionen sind ja nun eingerichtet und das CD-Image ist korrekt gepatcht.

Einfach Bescheid geben, was ich konkret notieren soll und wovon ich Screenshots erstellen soll.
Neben den System Freezes sind das verkorkste AmiUpdate, der bei jedem Start nicht funktionierende Netzwerkzugriff und das Booten von CD, obwohl man HD angegeben hat die akutesten Probleme.

Letzteres ist nicht so wild für mich. Das AmiUpdate-Thema hatte ich früher auch schon mal, ist aber schon viele Jahre her und ich weiss nicht mehr, was da die Lösung war. Ich glaube die Katalogdateien (zwischendrin werden nämlich auch mal die Knöpfe mit falsche Beschriftung dargestellt). Aber die hatte ich auch aktualisiert (deutsche Version).

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 20:23 Uhr

hjoerg
Posts: 3854
Nutzer
@Maijestro:

DANKE für das (immer wieder) Hochladen!

Ich bleibe am Ball. Leider ist die Zeit sehr begrenzt. Nehme trotzdem gerne alles mit. :rotate:
--
WinUAE Fan, Amikit RPi400
hjörg :dance2:

Viel Spaß :)

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 20:32 Uhr

Maijestro
Posts: 408
Nutzer
Zitat:
Original von hjoerg:
@Maijestro:

DANKE für das (immer wieder) Hochladen!

Ich bleibe am Ball. Leider ist die Zeit sehr begrenzt. Nehme trotzdem gerne alles mit. :rotate:
--
WinUAE Fan, Amikit RPi400
hjörg :dance2:

Viel Spaß :)


Es gab viel Feedback und so konnte ich die Installationsanleitung verbessern und vereinfachen, mit Veröffentlichung der Finalen Version von Qemu 8 wird diese dann dazu passen. Danke für die Bereitstellung des online Ordners ,-)

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 21:31 Uhr

hjoerg
Posts: 3854
Nutzer
@Maijestro:
Wenn ich einmal hier bin...

Lt. der ersten Anleitung hat mir der Homebrew ungefragt die QEMU v7.x aufgespielt!?


--
WinUAE, AF10 OS3.2.2, Amikit12 RPi400
Gruß hjörg

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 22:26 Uhr

Reth
Posts: 1858
Nutzer
Kurzes Update:

Das Problem mit dem Netzwerk konnte ich lösen. Es darf unter DEVS:Internet/Routes kein Eintrag für den Standard-DNS enthalten sein. Einfach keine Einträge und es funzt.

Wohl zu früh gefreut. Es erscheint zwar keine Fehlermeldung mehr - aber dafür wird nicht regelmäßig ein DNS gefunden (hatte dafür wie für das Standardgateway die IP unseres DSL-Routers genommen, wie unter allen anderen AOS4.1 Installationen auch).
Selbst wenn nach dem Booten eine Netzwerkverbindung besteht, spätestens beim Start des 1. Downloads aus Odyssey heraus geht nichts mehr. Der Browser reagiert zwar noch, aber über das Netzwerk läuft gar nichts mehr.

Wollte noch Update1, 2 und Hotfix runterladen auf eine 2. Partition bevor ich neu installiere, da AmiUpdate ja wieder ins Schleudern kommen kann. Alles sehr seltsam.

Das AmiUpdate-Problem hab ich leider auch noch nicht lösen können.

[ Dieser Beitrag wurde von Reth am 16.04.2023 um 23:01 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.04.2023, 23:44 Uhr

Reth
Posts: 1858
Nutzer
So, habe nun nochmal komplett neu installiert, nachdem ich die AOS4-Partition schnellformatiert hatte. Nach erfolgter Neuinstallation hab ich ins AOS4 von der HD-Partition gebootet.

So weit so gut.

Locale eingerichtet und von Pal LowRes auf die gewünschte Auflösung in 16 Bit geschaltet.

Danach Netzwerk eingerichtet, komplett über automatisch. Standardgateway eingetragen und auf den anschließenden Editor verzichtet. Es kam direkt wieder die Fehlermeldung: "... Could not add route from "DEVS:Internet/routes" line 15 (Network is unreachable).

Der Dialer hat in Zeile 15 einfach die Standardroute eingetragen mit:
default xxx.xxx.xxx.x. Hab das geändert in default=xxx.xxx.xxx.x - aber Fehler kam erneut (natürlich enthält xxx.xxx.xxx.x die IP unseres DSL-Routers).

Keine Ahnung, was da nicht passt. Hab den Eintrag nun wieder aus DEVS:Internet/routes entfernt. Mal sehen, wie das so läuft.

[ - Antworten - Zitieren - Direktlink - ]

17.04.2023, 08:59 Uhr

Maijestro
Posts: 408
Nutzer
Zitat:
Original von hjoerg:
@Maijestro:
Wenn ich einmal hier bin...

Lt. der ersten Anleitung hat mir der Homebrew ungefragt die QEMU v7.x aufgespielt!?


--
WinUAE, AF10 OS3.2.2, Amikit12 RPi400
Gruß hjörg


Genau so steht es aber auch in Installationsanleitung, bis Homebrew seine Pakete aktualisiert hat ist es nur möglich Qemu 7.2 direkt von dort aus zu installieren. Homebrew installiert aber auch keine Apps, Programme selbstständig, dass kann nur der Benutzer.

Ich denke du wirst Homebrew mit "brew install Qemu" angewiesen haben Qemu zu installieren.

Das letzte aktuelle Qemu 8 RC 4 Build für Mac M1/2 lade ich nachher auf Dropbox hoch, du kannst es dann von dort nehmen.

[ Dieser Beitrag wurde von Maijestro am 17.04.2023 um 13:57 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

17.04.2023, 14:11 Uhr

Maijestro
Posts: 408
Nutzer
Zitat:
Original von Reth:
So, habe nun nochmal komplett neu installiert, nachdem ich die AOS4-Partition schnellformatiert hatte. Nach erfolgter Neuinstallation hab ich ins AOS4 von der HD-Partition gebootet.

So weit so gut.

Locale eingerichtet und von Pal LowRes auf die gewünschte Auflösung in 16 Bit geschaltet.

Danach Netzwerk eingerichtet, komplett über automatisch. Standardgateway eingetragen und auf den anschließenden Editor verzichtet. Es kam direkt wieder die Fehlermeldung: "... Could not add route from "DEVS:Internet/routes" line 15 (Network is unreachable).


Warum möchtest du den Standardgatway eintragen, ist das für dein Netzwerk/Router nötig?

Normalerweise wird das Netzwerk automatisch konfiguriert und über DHCP übermittelt. Ich hab manuelle Einrichtung gewählt, den Treiber rtl8139 ausgewählt ansonsten den Rest auf standard vorgaben belassen.

Netzwerk

Eventuell hilft dir das weiter dein Problem zu lösen:

Qemu Netzwerk

[ Dieser Beitrag wurde von Maijestro am 17.04.2023 um 18:56 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

18.04.2023, 00:02 Uhr

Reth
Posts: 1858
Nutzer
@Maijestro:
In meiner Startbatch-Datei ist auch folgender Eintrag vorhanden: -device rtl8139,netdev=net0 -netdev user,id=net0 (entsprechend Deinem verlinkten Dokument).

Hast Du mal bei Dir im Eintrag Routen nachgeschaut, ob die automatische Konfiguration ggf. auch das Standardgateway eingetragen hat?

Zitat:
Original von Maijestro:
Warum möchtest du den Standardgatway eintragen, ist das für dein Netzwerk/Router nötig?

Normalerweise wird das Netzwerk automatisch konfiguriert und über DHCP übermittelt. Ich hab manuelle Einrichtung gewählt, den Treiber rtl8139 ausgewählt ansonsten den Rest auf standard vorgaben belassen.


Da ich das bei meinen früheren AOS4-Installationen eingetragen hatte hab ich dies hier einfach wieder getan.
Netzwerkzugriff funktioniert ja auch, leider nur noch nicht zuverlässig. Aktuell habe ich den Fehler nicht, da ich den Routen-Eintrag entfernt habe. Dennoch hängt das Netzwerk früher oder später bei Downloads oder dem Surfen. Geht einfach nichts mehr. Keine Ahnung, was da nicht stimmt - so ist es leider kaum brauchbar.

Kenne ja Unstabilitäten vom AOS4 aus WinUAE oder auf dem Peg2 oder dem A4000 - aber hier ist die Instabilität sehr viel größer. Hatte neu installiert und dann Update 1 und 2 installiert aber Netzwerk bricht immer wieder ab.

[ - Antworten - Zitieren - Direktlink - ]

18.04.2023, 10:06 Uhr

Falke_34
Posts: 378
Nutzer
Zitat:
Original von Reth:
Da ich das bei meinen früheren AOS4-Installationen eingetragen hatte hab ich dies hier einfach wieder getan.
Netzwerkzugriff funktioniert ja auch, leider nur noch nicht zuverlässig. Aktuell habe ich den Fehler nicht, da ich den Routen-Eintrag entfernt habe. Dennoch hängt das Netzwerk früher oder später bei Downloads oder dem Surfen. Geht einfach nichts mehr. Keine Ahnung, was da nicht stimmt - so ist es leider kaum brauchbar.


Bitte den rtl8193.device (Sys/Devs/Networks) von der CD nehmen und nicht den von den Updates! Das sollte die zuverlässigkeit verbessern

[ - Antworten - Zitieren - Direktlink - ]

18.04.2023, 15:14 Uhr

Maijestro
Posts: 408
Nutzer
Zitat:
Original von Falke_34:
Zitat:
Original von Reth:
Da ich das bei meinen früheren AOS4-Installationen eingetragen hatte hab ich dies hier einfach wieder getan.
Netzwerkzugriff funktioniert ja auch, leider nur noch nicht zuverlässig. Aktuell habe ich den Fehler nicht, da ich den Routen-Eintrag entfernt habe. Dennoch hängt das Netzwerk früher oder später bei Downloads oder dem Surfen. Geht einfach nichts mehr. Keine Ahnung, was da nicht stimmt - so ist es leider kaum brauchbar.


Bitte den rtl8193.device (Sys/Devs/Networks) von der CD nehmen und nicht den von den Updates! Das sollte die zuverlässigkeit verbessern


Danke du warst schneller wie ich ,-)Es gibt noch ein Patch für Qemu, BALATON Zoltan bat mich ihn zu testen und das habe ich auch getan https://patchew.org/QEMU/20230413171946.2865726-1-stefanha@redhat.com/ der Patch bringt aber keine spürbare Verbesserung. Wie Falke schon erwähnt hat, downgrade des rtl8139 durchführen und dann sollte das Netzwerk stabile bleiben.

[ - Antworten - Zitieren - Direktlink - ]


Erste 1 2 3 4 5 -6- 7 8 9 10 11 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.
.