Magic_PC mit zu hoher Prozessorlast

[Dabbeljubie]

Ich finde es toll, dass du das Prob immer noch angehst! 

Das größte Problem sehe ich darin, dass das Problem bereits vor dem Start der Emultation besteht, sobald die EXE läuft. Daher kann es egal sein, was man unter der Atari-Umgebung macht. Gemini und MAGXDESK, wie jede 'saubere' Atari-App auch, machen ja beim Nixtun tatsächlich nix außer der Ausführung eines evnt_multi(). Ich hatte das wirklich mal vor Jahrzehnten mit dem Sysmon gecheckt, ist echt so.

Hast du mal probiert, statt der Atari-Emulation (MagiC_PC.os) Magic_PC irgendwas gar nichts tuendes unterzuschieben? Ich habe eben mal die MagiC_PC.os verschwinden lassen und auch da dreht MPC während des Mecker-Dialogs "am Rad"!

[Thorsten Otto]

Wie schon gesagt, daß die exe auch ohne Emulation schon 100% CPU braucht, wird man wohl nicht ändern können. Sehe ich aber als das geringere Problem an, schliesslich sollte das nur kurze Zeit passieren.

Daß mit dem evnt_multi ist richtig, und ist auch genau die Stelle wo MagicPC gebremst werden soll.

[Dabbeljubie]

Sehe ich aber als das geringere Problem an, schliesslich sollte das nur kurze Zeit passieren.

Was meinst du mit "kurze Zeit"?

Es gibt nur drei Phasen, in welcher MagicC_PC keine Überlast fährt:

1. Ohne Emulation, aber mit einem heruntergeklappten Fenster-Menü (Für Datei, Einstellungen oder Hilfe). Klappt das Menü wieder weg, dann auch sofort wieder Dampf.
2. Während der Emulation im Pause-Modus.
3. Während der Emulation, bei dem heruntergeklappten Windows-Fenster-Menü links oben (Für Verschieben, Minimieren, Schließen, ... etc.)

[Thorsten Otto]

Mit kurze Zeit meine ich, daß man normalerweise nicht mehr viel an den Einstellungen ändert, wenn es einmal läuft, und daher das Fenster nur solange aktiv ist, bis man die Emulation startet (wenn man das nicht sowieso schon automatisch machen lässt).

Im "Pause"-Modus ist allerdings ein Problem.

Aber wie gesagt, das ist ein Problem vom Emulator selber. Wenn du nicht 3.5MB x86 code analysieren willst, dürfte sich das schwerlich ändern lassen.

[Dabbeljubie]

und daher das Fenster nur solange aktiv ist, bis man die Emulation startet

Leider spielt das keine Rolle, ob die Emulation gestartet ist oder noch nicht. Die EXE läuft ja immer, mit oder ohne Emulation und daher ist auch das Problem immer, mit und ohne Emulation. Nur wenn "Pause" in der Emulation aktiv ist oder ein Windowsfenster-Menü runterklappt, dann geht die Last auf normalen 'Idle'-Modus und dreht Däumchen.

Die EXE selbst ist das Problem, unabhängig von der Emulation, die geladen wird, und diese EXE dürfte Ende der 90er programmiert worden sein und hat sich nie verändert, da das Verhalten bei allen drei mir bekannten MPC-Versionen von 6.0 über 6.1 bis 6.2 immer das gleiche ist.

[Thorsten Otto]

Ah, mit Pause hatte ich falsch verstanden, wenns da idle ist, ist ja gut.

Ob mit oder ohne Emulation ist schon ein Unterschied (zumindest solange MagiC geladen wird und nicht ein anderes OS). Den MagiC Kernel kann ich ändern, da gibt es Sourcen für. Also zumindest theoretisch, wie schon beschrieben haben die bisherigen Versuche nicht den gewünschten Erfolg gebracht.

Was der Emulator sonst macht, wenn (noch) nichts emuliert wird, kann ich leider nicht beeinflussen, aber das erachte ich als das kleinere Problem.

[Dabbeljubie]

Ah, mit Pause hatte ich falsch verstanden, wenns da idle ist, ist ja gut.

Ja, das habe ich gemerkt. Also, die drei Phasen/Zustände, die ich dort oben beschrieb, sind die Programmzustände, in denen MPC keine Proz-Überlast hat, also Däumchen dreht, alles gut.

Du suchst vermutlich dort, wo das Problem gar nicht ist. Das, was du veränderst, ist MagiC_PC.os Wenn du das mal wegläßt (aus dem Verzeichnis entfernst) oder die Magic_PC.exe ganz allein in einem ansonsten komplett leeren Verzeichnis startest -> hohe Last! Klappe dann ein Fenster-Menü runter -> Däumchen-Modus.

[Thorsten Otto]

Du verstehst mich nicht. Ist mir schon klar daß das Problem in der exe liegt, nur kann ich es dort nicht beheben. Ich kann lediglich versuchen es im MagicOS-Kernel zu beheben.

[Dabbeljubie]

Ich denke/glaube schon, dass wir uns gegenseitig verstehen.

Für mich ist allerdings nicht ersichtlich, wie du ein Problem, das in der Magic_PC.exe besteht, dann in MagiC_PC.os lösen willst?

Ich denke, man müsste den Programmierer der MagiC_PC.exe fragen, ob er einen Tipp geben kann. Ich persönlich habe mich auf Assembler-Ebene nur am 68k (Atari) und 6502 (C64) betätigt. Den x86 kenne ich überhaupt nicht, daher ist reassemblieren für mich keine Option.

[Thorsten Otto]

Ich versuch es so ähnlich zu lösen wie in Aranym auch. Es gibt im wesentlichen zwei Stellen im OS bei denen der Atari in einer busy-loop ist, deren Zustand sich lediglich durch auftreten eines Interrupts ändern kann: bei Bconin(), und im AES wenn alle Prozesse auf Ereignisse warten, aber keines verfügbar ist.

Aranym emuliert an dieser Stelle die STOP-Instruktion, die MINT/EmuTOS ausführen. MagicPC verkraftet das offensichtlich nicht, aber es gibt die Möglichkeit eigene DLLs einzubinden und vom Atari aus aufzurufen, das habe ich versucht, und rufe dort WIndows-Funktionen die eigentlich CPU zeit abgeben sollen. Klappt nur bisher nicht wie erwünscht.

Aber das alles hatte ich oben schon beschrieben.

[Dabbeljubie]

Das habe ich oben schon verstanden. Aber wenn der Aufrufteil (MagiC_PC.exe) bereits die Prozessoren zu sehr beschäftigt, kann doch etwas Zusätzliches (deine MagiC_PC.os) die Gesamt-Belastung doch nicht auch noch senken? Wie gesagt: Wenn es gar keine MagiC_PC.os gibt, gibt es auch keine zusätzliche Last und trotzdem schafft sich ja die MagiC_PC.exe schon ganz allein müd' und kaputt.?!?

[gh-baden]

Das habe ich oben schon verstanden. Aber wenn der Aufrufteil (MagiC_PC.exe) bereits die Prozessoren zu sehr beschäftigt, kann doch etwas Zusätzliches (deine MagiC_PC.os) die Gesamt-Belastung doch nicht auch noch senken? Wie gesagt: Wenn es gar keine MagiC_PC.os gibt, gibt es auch keine zusätzliche Last und trotzdem schafft sich ja die MagiC_PC.exe schon ganz allein müd' und kaputt.?!?

Ich denke dein Nachfragen invalidiert den ersten Satz, wenn ich den VP richtig verstanden habe Code (MagiCPC) + Code (MagiC-OS) = mehr Code, meinst du? Nicht wenn man im zweiten Teil Code einbaut der der CPU Zeit zum verschnaufen gibt.

[Dabbeljubie]

Nicht wenn man im zweiten Teil Code einbaut der der CPU Zeit zum verschnaufen gibt.

Wenn, und nur wenn tatsächlich anstelle des "Stresscodes" im Windows-Teil ein "Verschnauf-Code" im Atari-Teil ausgeführt wird. Da wir aber bei Windows ebenfalls präemptiv mit und in interrupts unterwegs sind, habe ich Zweifel, dass da Emulationscode die Situation verbessern kann. Wie gesagt: Was während der Emulation hilft, ist der Pausen-Mode oder wenn ein Windowsfenster-Menü runtergeklappt wird. Bei den Menüs ist es dann wohl so, dass MPC alles stehen und liegen lässt und Windows selbst recourcenschonend (nur) die Bedienbarkeit der Menüs gewährleisten muss. Daher die 2 % Last oder so.

In welcher Sprache sind denn die freigegebenen Sourcen für den Kernel?

[Thorsten Otto]

Ich bin es echt ein bisschen leid das immer wieder zu erklären. Glaub mir einfach mal daß ich (normalerweise) weiss was ich da tue.

Ich vermute in dem Fall sehr stark, daß dort ein anderer Thread neben der Emulation aktiv ist der die CPU Zeit verbrät (vermutlich einer der den Bildschirm aktualisiert). Das wäre blöd, weil ich da von der Emulation aus nicht dran komme ohne genau zu wissen was intern passiert, was dann wiederum auf eine Analyse der EXE hinaus läuft.

DIe Sourcen für den Kernel sind grösstenteils in Assembler.

[Dabbeljubie]

Ich bin es echt ein bisschen leid das immer wieder zu erklären.

Das musst du nicht, denn wir haben uns eigentlich gut genug verstanden.

Glaub mir einfach mal daß ich (normalerweise) weiss was ich da tue.

Es geht nicht darum, was du tust. Ich sage dir, dass es zwar ehrbar von dir ist, dass du am Kernel etwas verändern willst, was Fehler-Code wo ganz anders egalisieren soll, aber ich bezweifle, dass das klappt. Das hatte ich geschrieben und jetzt hoffe ich, dass ich Unrecht behalte und du vielleicht doch was findest, bin aber eben nicht optimistisch.

daß dort ein anderer Thread neben der Emulation aktiv ist der die CPU Zeit verbrät (vermutlich einer der den Bildschirm aktualisiert)

Das Problem bei dieser Idee ist doch, dass diese Bildschirmaktualisierung ohne die Emulation gar nichts hätte, was sie aktualisieren könnte. Fehlt die ganze Emulationsdatei, müsste die EXE eigentlich Däumchen drehen und schimpfen. Letzteres tut sie dann auch, wenn man MagiC_PC.os wegläßt, denn es kommt dann ein Dialog mit "C:\MPC_620\MagiC_PC.os nicht gefunden!", aber sie tobt dabei trotzdem weiter.

Dein Ansatz "daß dort ein anderer Thread neben der Emulation aktiv ist der die CPU Zeit verbrät", ist garantiert richtig. Vermutlich irgendwas, was dauernd laufen muss, um die Emulation an einigen Ecken zu checken. Und das passiert sogar dann, wenn gar keine Emulation da ist. 

[Thorsten Otto]

aber ich bezweifle, dass das klappt.

Es funktioniert ganz sicher, die Emulation auszubremsen. In Aranym wird das auch so gemacht; ohne das (z.B. wenn man original TOS4 verwendet) verbraucht auch Aranym 100% CPU.

Vermutlich irgendwas, was dauernd laufen muss, um die Emulation an einigen Ecken zu checken. Und das passiert sogar dann, wenn gar keine Emulation da ist. 

Kann gut sein. Wird aber schwierig das zu finden. Und noch schwieriger das anschliessend zu beheben, es gibt mindestens drei verschiedene Versionen von magicpc.exe die alle behaupten Version 6.10 zu sein, aber vom unterschiedlichen Datum sind.

[Dabbeljubie]

es gibt mindestens drei verschiedene Versionen von magicpc.exe die alle behaupten Version 6.10 zu sein, aber vom unterschiedlichen Datum sind.

Das stimmt zwar, aber das von mir beschriebene Problem haben sie alle, seit 6.00 aus 1998. Es tut nur immer weniger weh, weil die Rechner immer leistungsfähiger sind und mit solchen angezogenen Handbremsen einfach mit mehr PS besser dagegen halten können.

Ich habe noch eine alte W95-Büchse. Die bootet bis zum fertigen Desktop in etwa 15 bis 17 Sekunden hoch. Damals vor dem Einmotten Win noch frisch neuinstalliert, das machten wir damals ja öfter. Also, steinalter Rechner, steinalte Platte, wenig RAM. Trotzdem: Doppelklick auf Netscape und der war da, gleich beim ersten Mal. Office genauso. Aber mit der Zeit wurden die Programme fetter und langsamer und RAM-gieriger.

Heute brauchen wir mehr als die tausendfache Proz-Leistung und tausendfach mehr RAM und Plattenplatz, nur um, gefühlt, das gleiche wie unter W95 zu machen - ein Irrsinn!

[Dabbeljubie]

Ich habe die Woche doch mal mit ASH telefoniert und man sagte mir deutlich, dass Franz Schmerbeck zu keinen Konzessionen hinsichtlich der EXE bereit ist. War er all die Jahre nicht, auch auf deren Anfragen und Bitten nicht. Er tut nichts mehr daran, auch für Geld nicht oder auch ohne Geld nicht und er gibt auch die Sourcen nicht frei.

Wenn ihn von euch keiner näher kennt? Ich kenne ihn nicht, weil er irgendwie nach meiner aktiven Atari-Sturm-und-Drang-Zeit an MagiC-PC dran war.