atari-home.de - Foren
Hardware => Emulatoren => Thema gestartet von: Dabbeljubie am Mi 16.03.2022, 23:13:54
-
Moin,
an alle ganz alten Atari-User, noch aus dem Maus-Netz: Vielleicht erinnert ihr euch noch an mich, Dabbeljubie, aus der Maus F und der Maus OF und Maus OF2. Seid alle herzlich gegrüßt - zurück in die 90er! :) Ich war GFA-Programmierer und damals auch Betatester für alles mögliche auf dem Atari-Bereich und kannte Gott und die (Atari-)Welt.
And now for something completely different, nämlich das Problem:
Ich nutzte in der Folge der 90er von Anbeginn der Welt an auch sofort Magic:PC, als es rauskam, jetzt praktisch fast ein Vierteljahrhundert lang. Immer die Version 6.00 mit immer dem gleichen Problem: Die verd*mmte Prozessorlast dieses Programmes! Der Proz geht hoch auf Volldampf und Karacho und je schneller die Rechner wurden, umso stärker musste ich mit Tuning-Tools auf der Win-Ebene vor dem Start von Magic_PC die Intels auf etwa 600 mHz runterknüppeln. Alles andere hätte den Rechner verkocht und es war keine vernünftige Tastenbetätigung möglich, ohne dass zig Tastendrücke gedrückt worden wären. Die Atari-Uhr rannte wie verrückt und ich schrieb mir deshalb eine Workaround-ACC, damit sie alle 30 Sekunden über einen GEMDOS-Aufruf wieder aktualisiert wurde.
Jetzt, nach zig Jahren, habe ich heute endlich mal auf 6.20 aktualisiert, weil ich vor zig Jahren schon hörte, dass da sehr viel von meinem Problemen gelöst wären, aber dem ist leider nicht so. Die Zeit und das Timing sind jetzt bei 6.2 scheinbar etwas besser, aber die Prozessorlast ist immer noch sehr hoch. Und wenn ich unter MAGXDESK einen Doppelklick auf Laufwerk C mache, geht C:\ gleich zigmal auf, alles schweineschnell. SO schnell kann ich die Maus nach DClick gar nicht loslassen.
Ich habe bei beiden, 6.0 wie 6.2, die Prio auf 'sehr niedrig', 'Compilieren' ist aus, aber die Prozessor-Temperatur nebst Lüfter gehen da recht schnell hoch, was sehr nervt. Auflösung nur 1024 x 768 x 2, also schwarz/weiß (Absicht), Refresh bei 70 ms.
Meine Rechner arbeiten üblicherweise immer unter 10 % Last und bleiben bei kühlen 55 Grad, aber bei Magic_PC drehen sie permanent auf 60% hoch und gehen auf über 80 Grad.
Solltet ihr das hier schon behandelt haben, bitte ich um Entschuldigung, denn ich habe es nicht gefunden. Was kann ich probieren, damit ich unter 6.2 nicht de Prozessoren auch wieder künstlich einbremsen muss?
-
an alle ganz alten Atari-User, noch aus dem Maus-Netz: Vielleicht erinnert ihr euch noch an mich, Dabbeljubie, aus der Maus F und der Maus OF und Maus OF2.
Ah, noch jemand aus dem MausNet, willkommen! (ex @FR).
'Compilieren' ist aus,
Ist das wirklich das richtige? Hat da die CPU nicht mehr zu tun, wenn sie nicht vorcompilierten Code ausführt, sondern immer neu interpretieren muss?
-
Mensch ist das schon lange her... an das Problem kann ich mich aber auch noch erinnern. Gab es da nicht auch den Trick statt des linken Doppelklicks einfach einen Rechtsklick zu tun? Doch einfach mal eine andere Frage... welche Windows Version benutzt du und was machst du unter MagicPC was nicht auch unter Hatari, Steem, Stemulator oder Aranym etc. vielleicht sogar komfortabler geht? Was meinst du mit Refresch =70ms... Einstellung für ein Screenupdate in MagicPC?
-
Erstmal herzlich willkommen ! (ex @DO)
Ja, das Problem mit dem Click ist bekannt. Kann man entweder so beheben wie von Arthur beschrieben (doppelklick auf mittlere oder rechte Maustaste legen), oder teilweise auch, indem man die Doppelklick-Geschwindigkeit im GENERAL.CPX auf 1 setzt. Da es offensichtlich hauptsächlich bei MagxDesk auftritt, könnte man evtl. auch versuchen das dort zu beheben (ich weiss nicht ob es dir schon bekannt ist, aber die Sourcen vom MagiC-Kernel und allen apps, sind mittlerweile freigegeben, und ich habe auch schon einige Sachen behoben, siehe https://github.com/th-otto/MagicMac).
Das Problem mit der Prozessorlast nervt mich auch (auch wenn die sonstige Arbeit auf einem multi-Kern Prozessor davon nicht gross beeinträchtigt wird). Habe dafür bisher noch keine Lösung gefunden (normalerweise würde man dafür die STOP instruction nehmen wenn auf Ereignisse gewartet wird, aber MagicPC scheint die nicht zu emulieren). Möglicherweise könnte man dafür eine DLL verwenden (es gibt da bei MagiCPC so eine Erweiterungs-Möglichkeit).
-
Hey, das ist ja klasse, dass es hier noch so viele Enthusiasten gibt! :)
Danke für eure Antworten. Zumindest weiß ich jetzt, dass ich mit meinen "Sorgen" nicht alleine bin und die Probleme bei euch verifizierbar sind.
Ja, das Problem mit dem Click ist bekannt. Kann man entweder so beheben wie von Arthur beschrieben (doppelklick auf mittlere oder rechte Maustaste legen), oder teilweise auch, indem man die Doppelklick-Geschwindigkeit im GENERAL.CPX auf 1 setzt.
Naja, die rechte Maustaste würde ich ja schon gerne auch noch per evnt_multi() etc. abfragen können. Wenn das nicht mehr ginge? Aber das verändern der Clickzeit könnte natürlich eine Lösung sein. Ich benutze eigentlich (schon immer) Gemini als Desktop und habe seit Magic_PC den Doppelklick eigentlich nicht mehr genutzt. Stattdessen habe ich Icons nur selektiert und dann Return gedrückt! :)
Das Problem mit der Prozessorlast nervt mich auch (auch wenn die sonstige Arbeit auf einem multi-Kern Prozessor davon nicht gross beeinträchtigt wird).
Alle meine Rechner der letzten Jahre (große 17-Zoll Workstations von HP) mussten für Magic_PC nach wenigen Sekunden bereits den Lüfter anwerfen, daher habe ich diesen Hack mit der vorherigen Umschaltung auf das Energie-Schema "power-save" unter dem Programm RightMark CPU Clock Utility gewählt. Das Nervige daran ist, dass unter heutigen Windows-Systemen das runtertakten auf etwa 600 mHz praktisch einer Stilllegung gleich kommt. Ein paralleles Arbeiten unter Windows 7, 8, 10, xx, ist sozusagen gar nicht möglich.
Meine Nutzung
Ich benutze Atari unter Magic_PC vor allem für zwei selbstgeschriebene GFA 3.6-Programme: Eines macht meine Steuer. Es bucht meine Firmen-Bankkonten vor und verteilt diese Buchungen bereits auf die Felder der EÜRs. Es wirft die Inhalte für die Elster-Formulare aus, die ich brauche. Und das andere Programm ist eine CAD-Spezial-Software, die ich schrieb. Sie ist eine Branchenlösung nur für mich. Ich habe keine Lust mehr, diese beiden Programme, die ich tatsächlich auch seit 30 Jahren brauche und oft stundenlang am Stück nutze, in GFA32 für Windows umzuschreiben, das ich eigentlich seit 20 Jahren ebenfalls nutze und das als Programmiersprache bei mir das Atari-GFA schon lange ablöste.
Mein Werdegang ist eigentlich klassisch: 1983 C-64 Basic und Assembler (t.ex.as). Dann Atari GFA 3.07, dann GFA 3.5, dann GFA 3.6(TT), ohne je einen TT besessen zu haben. Dann GFA-Win 16 und dann GFA-Win 32 bis heute. Durch die schnellen Basic-Ausführungen habe ich nie C vermisst.
Wenn ich jetzt meine beiden alten Atari-Programme nutze und währenddessen auch mal auf der Win-Ebene etwas brauche, haue ich MPC auf "Pause" und wechsle den Computer auf Energie-Schema "normal". Und dann wieder auf "power save" zurück, wenn ich auf MPC wieder weitermache. Sehr umständlich. >:(
Hat da die CPU nicht mehr zu tun, wenn sie nicht vorcompilierten Code ausführt, sondern immer neu interpretieren muss?
Ich hatte sehr gehofft, dass mit diesem Feature ab 6.1 alles besser werden würde, weil ich dachte, es müsste weniger emuliert werden. Leider war das nicht so, stattdessen ruckelte die Maus und alles lief noch schneller ab. Auch in 6.2 ruckelt immer noch die Maus, was sie ohne "compilieren" nicht tut. Keine Ahnung, was da fabriziert wurde. Ich nutze übrigens NVDI, aber wohl nicht NVDI_PC, obwohl ich es als Version 4 habe (2 Disks).
was nicht auch unter Hatari, Steem, Stemulator oder Aranym etc. vielleicht sogar komfortabler geht?
Ich hatte mal ein paar kleine andere Emulatoren versucht, aber das klappte alles nicht, weil damit meine Gemini-Umgebung nicht lief oder ich konnte nicht damit programmieren, weil der GFA-Interpreter nicht ging und der Dinge mehr. Keine Ahnung, ob aktuelle Emulatoren wie die erwähnten eine Alternative wären, denn ich kenne die alle nicht.
Was meinst du mit Refresch =70ms... Einstellung für ein Screenupdate in MagicPC?
Ja!
Ich finde eine Sache ja faszinierend: Wenn ich nur die MPC-Öberfläche starte, aber noch nicht den Atari, sind die Prozessoren trotzdem sofort bei 60 % beschäftigt. Man tut eigentlich noch gar nix, null. Man ist nur in MPC, kann alles mögliche einstellen und verändern und tut eigentlich überhaupt nichts großartiges auf der Windows-Ebene und trotzdem ist das System schlagartig hoch, wie wenn der Emulator bereits laufen würde und schon Höchstleistungen erbringen müsste. Der ist aber, wie erwähnt, noch gar nicht gestartet?!?! Das versteht doch kein Mensch, oder? Ich jedenfalls nicht. Sobald man z. B. ein MPC-Menü runterklappen lässt (Datei, Einstellungen, Hilfe), geht die Last sofort in den Keller. Klappt man das Menü wieder weg, geht die Last sofort wieder auf seine 60% hoch. Irgend etwas ziemlich blödsinniges tut MPC während dem "Nichtstun", was die Prozessoren fordert. Ich habe kein Windows-Programm, das so etwas tun, während es nichts tut.
Ich habe normalerweise mein Energie-Profil auf "Performance on demand", was wohl üblich ist, daher merke ich sofort, ob ein Programm "Däumchen" dreht, weil man nix tut, denn Proz-Lasten beider Kerne dümpeln bei 0 bis 3 % herum.
Keine Ahnung, ob das alles bei MagicMac auch so passiert, denn die alten MACs kamen ja eigentlich schon immer (bis 2005?) mit 68x-Prozessoren und sollten damals nicht viel emulieren müssen, oder?
-
Hier eine interessante Seite mit einigen nützlichen Infos. Evtl. gibt es da auch eine Lösung für das Zeitproblem...
http://www.albersdoerfer.de/magicpc_mein_setup.htm
-
Ich finde eine Sache ja faszinierend: Wenn ich nur die MPC-Öberfläche starte, aber noch nicht den Atari, sind die Prozessoren trotzdem sofort bei 60 % beschäftigt. Man tut eigentlich noch gar nix, null. Man ist nur in MPC, kann alles mögliche einstellen und verändern und tut eigentlich überhaupt nichts großartiges auf der Windows-Ebene und trotzdem ist das System schlagartig hoch,
Hm, stimmt, hatte ich noch gar nicht drauf geachtet. Das ist natürlich blöd, aber da wird man wenig dran ändern können. Daß während der Emulation die CPU auf 100% läuft, ist leider normal (AES hängt da zZ. in einer Busy-Loop während es auf Ereignisse wartet). Ob mit oder ohne Compiler dürfte da auch keinen grossen Unterschied machen.
Eine Möglichkeit vlt: Ich benutze MagiCPC hier unter WIndows7 innerhalb von VirtualBox, das selber nur einen Prozessorkern benutzt. Dann läuft VirtualBox zwar auf 100%, aber die anderen Kerne sind frei, wodurch sich eigentlich ganz normal weiterarbeiten lässt. Wenn ich mich recht erinnere, müsste es bei WIndows selber auch eine Möglichkeit geben, die Anzahl der dem Programm zur Verfügung gestellten Kerne zu reduzieren. Vielleicht hilft das ja etwas.
Ich nutze übrigens NVDI, aber wohl nicht NVDI_PC, obwohl ich es als Version 4 habe (2 Disks).
NVDI_PC wäre auf jedenfall empfehlenswert (uA hast du dann auch höhere Auflösungen, ich hoffe doch sehr daß deine eigenen Programme damit zurecht kommen ;)). An deinem Problem dürfte das aber nichts ändern.
-
Hier eine interessante Seite mit einigen nützlichen Infos. Evtl. gibt es da auch eine Lösung für das Zeitproblem...
http://www.albersdoerfer.de/magicpc_mein_setup.htm
Da steht auch folgender interessanter Satz.
Die MagiCPC Installation auf dem USB Stick, funktioniert bei mir auf Rechnern mit Windows 7 und am Besten auf Windows 10 (da die Prozessorauslastung niedriger ist)
-
Das ist natürlich blöd, aber da wird man wenig dran ändern können. Daß während der Emulation die CPU auf 100% läuft, ist leider normal
Eben nicht und das ist ja genau der Punkt. Bei mir spielt es eben keine Rolle, ob der Emulator auch schon läuft oder noch nicht. Es reicht, dass die MagiC_PC.exe läuft! Die Proz-Last geht überhaupt nicht weiter hoch, wenn der Emulator dann auch noch läuft, daher gehe ich davon aus, dass da etwas außerhalb des Emulators bereits schief geht und völlig falsch programmiert ist. Und es spielt auch im Emulator selbst keine Rolle, ob ich da z. B. was 'böses' unter GFA mache oder saubere AES-Event-Programmierung nehme - ändert bei mir nichts an der Proz-Last.
Die Albersdörfer-Seite hat leider auch keine Ideen im Zusammenhang bei diesem Problem.
Eine Möglichkeit vlt: Ich benutze MagiCPC hier unter WIndows7 innerhalb von VirtualBox, das selber nur einen Prozessorkern benutzt
Das geht auch ohne VirtualBox. Ich habe überall den Prozess-Explorer von sysinternals statt dem Task-Manager laufen und der kann für jeden Prozess mit "Set Affinity ..." die Prozessorkerne beliebig beschränken. Wenn man da auf nur noch einen geht, ist dieser tatsächlich dauernd bei 100% und genau das kann dann auch diesen Prozessor killen. Bei mir geht bei Beschränkung auf nur einen die Temperatur noch höher als wenn beide Kerne nur auf 60 % wären. Das mit nur einem Kern kann somit auch schiefgehen, befürchte ich.
NVDI_PC wäre auf jedenfalls empfehlenswert (uA hast du dann auch höhere Auflösungen
Wie geschrieben: Ich habe ja NVDI, aber ich glaube nicht, dass es NVDI_PC ist. Und ich nutze ja schon eh und je 1024x768x2.und habe testweise gestern alle möglichen Auflösungen mit verschiedenen Farbtiefen erfolgreich ausprobiert.
Ich hatte auch wahrlich keine Probleme mit einer zu langsamen grafischen Darstellung, nie, auch vor mehr als 20 Jahren nicht und heute noch weniger. Eigentlich ist alles viel zu schnell. :) Und wird zu schnell warm. Vielleicht ist das ja diese Klimaerwärmung, von der alle reden.
Wer hat denn jetzt Magic_PC programmiert? Andreas Kromke?
-
Ich nutze übrigens NVDI, aber wohl nicht NVDI_PC
Ah, oh. Wie war das, kopiert dann nicht MagiCPC den Screenbuffer dauernd um? Und NVDI PC oder NVDI 5 geht an die MagiCPC-Schnittstelle um GDI anzusprechen und somit a) Geschwindigkeit und b) Entlastung zu bringen? War das so? Oder verwechsle ich das mit der SM124-Emulation mit Framebufferkopierererei?
-
daher gehe ich davon aus, dass da etwas außerhalb des Emulators bereits schief geht und völlig falsch programmiert ist.
Ja, das sehe ich auch so. Aber das wird man kaum ändern können (ausser du analysierst ~3MB x86 Programmcode und patcht den). Während der Emulator läuft, wird man evtl. was ändern können. Der kernel (magic_pc.os) lässt sich problemlos austauschen. Die Stellen dafür sind auch bekannt, es gibt sogar schon eine Funktion dafür https://github.com/th-otto/MagicMac/blob/adafe66634c57d592dc021f1f401e34a992adcd1/kernel/bios/atari/magibios.s#L4017, ich muss nur mal testen wie man das realisieren kann.
Wenn man da auf nur noch einen geht, ist dieser tatsächlich dauernd bei 100% und genau das kann dann auch diesen Prozessor killen. Bei mir geht bei Beschränkung auf nur einen die Temperatur noch höher als wenn beide Kerne nur auf 60 % wären.
Bei mir geht nur der eine Kerne auf ~60°, das dürfte dem eigentlich nichts ausmachen. Falls da kritische Werte überschritten werden, schreitet sowieso das BIOS ein.
Wer hat denn jetzt Magic_PC programmiert? Andreas Kromke?
Von Andreas Kromke ist im wesentlichen der MagiC-Kernel. Die PC Version ist, wenn ich mich nicht täusche, hauptsächlich von Franz Schmerbeck.
-
Ah, oh. Wie war das, kopiert dann nicht MagiCPC den Screenbuffer dauernd um?
Ich denke eher nicht, allerdings werden dann sämtliche Ausgaben vom 68k-Code durchgeführt. Wie genau das aussieht kann ich allerdings nicht sagen, bei MagicMac stellt der Emulator dafür eine Pixmap zur Verfügung. Aber selbst wenns umkopiert wird, auf modernen Rechnern erzeugt das wohl nur ein müdes Lächeln bei der CPU.
Und NVDI PC oder NVDI 5 geht an die MagiCPC-Schnittstelle um GDI anzusprechen
Ja, das ist definitiv so. Die genaue Schnittstelle ist natürlich unbekannt, aber die Sourcen der nfpc*.sys habe ich mittlerweile fertig, und die rufen über den opcode 0x41bf Funktionen in der NVDI_PC.DLL auf.
-
Auf meinem Win10 PC/AMD 5800X CPU konnte ich bei der Installation von Magic PC (Version 6.0) auf USB Stick keine Vorteile verbuchen... alles in allem bleibt es bei rund 8% CPU-Auslastung und das ist doch schon recht viel für ein Programm das nur gestartet ist. Die Prioeinstellungen im Programm bringen auch überhaupt nichts.
Ich werde jetzt mal NVDI4 PC installieren und schauen obs was bringt.
-
NVDI4 PC bringt mehr als 256 Farben bis zu 32Bit Farbtiefe... die (% Auslastung sind wie fest genagelt. Zum installieren war es notwendig die Tastatureinstellungen über das entsprechende CPX-Kontrollfeld zu bremsen und selbst dann ist es nicht leicht die benötigten Daten in den Installationsdialog einzugeben.
MagiC ist von Andreas Kromke, Sven & Wilfried Behne.
-
Zu NVDI_PC:
Ich habe zwei ZIPs, wohl eine pro Disk für NVDI 4.1. Eine Disk ist vom 10.08.1996 und eine neuere vom 15.09.1996, also nur 5 Wochen später. Ihr redet aber alle von NVDI 5?
-
Wenn ich mich recht erinnere enthält NVDI5.xx alles für Atari auch ET4000 und auch MagiC _PC und _MAC.
-
Ich habe jetzt von ASH ( https://www.application-systems.de/nvdi/download.html (https://www.application-systems.de/nvdi/download.html) ) mal dieses FRESHUP.TOS runtergeladen.
Arthur, du hast doch vorhin NVDI 4 installiert. Kannst du mal schauen, welches Install-Paket du hattest (s. beide Anhänge)?
Sch*ße, das ist alles irgendwie ein Vierteljahrhundert her und ich merke gerade, dass ich ja lauter alte Leut' kenne ... :D
-
Das obere.
-
Für das Freshup ist nvdi 5xx nötig... mit nvdi 4.x dürfte es nicht funktionieren.
-
Ich hab da jetzt mal ein paar Sachen versucht bzgl Prozessorlast, aber alles noch nicht das wahre.
- Statt einer STOP-Instruktion auszuführen (die MagicPC scheinbar nicht mag), hab ich jetzt eine spezielle DLL geschriebn die dort aufgerufen wird.
- Versuch 1: Sleep(0) aufrufen (gibt die restliche Rechenzeit ab). Wird auch aufgerufen (mit debug-ausgaben getestet), bringt nur nix, Prozessortlast ist immer noch bei 99%.
- Versuch 2: Sleep(1) aufrufen (1 millisekunde warten). Funktioniert, drückt die Prozessorlast auch ein bisschen, allerdings reagiert MagicPC dann extrem zäh auf Mausklicks. Leider in der Form unbrauchbar.
Was mir sonst noch aufgefallen ist: wenn ich MagiC unter Aranym ausführe, ist auch dort die Prozessorlast deutlich höher als normal, allerdings nicht so extrem (ca. 20%, wenn ich MiNT oder EmuTOS benutze liegt sie bei 4-5%). Dort hat es geholfen, die Timeslice mittels des CPX zu ändern, bei 1:2 liegt die Last dann nur noch bei ca 6%. Der Rest könnte auch mit der Konfiguration zusammen hängen: Programme wie OLGA, APPLINE, T-Con, WHEEL.APP, StartMeUp, MPC_ACC etc. sind immer wieder aktiv, auch wenn sie eigentlich nichts machen.
Sonst noch Vorschläge was man versuchen könnte?
-
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"!
-
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.
-
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.)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.?!?
-
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.
-
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?
-
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.
-
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. >:(
-
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.
-
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!
-
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.