atari-home.de - Foren
Hardware => Firebee => Thema gestartet von: Arthur am So 21.12.2014, 14:07:15
-
Hallo zusammen. Ich hab zwar noch keine Firebee bin aber trotzdem daran interessiert, besonders wie oder was man tun muss damit die 68K-Emulation optimal genutzt werden kann. Ich habe schon gelesen das zum Beispiel bei User A das eine Programm läuft während es bei User B nicht läuft. Welche Komponenten und TOS-Versionen sind davon abhängig und wie gut funktioniert das... bzw. wird das in Zukunft noch besser funktionieren und wo sind der Emulation Grenzen gesetzt? Ich finde das ist ein interessantes Thema das einen Thread verdient.
-
Meinst du das -> http://vincent.riviere.free.fr/soft/68kemu/
Schau dir mal das Firebee CF Karten Image an ...
-
Das ist schon mal ein Anfang... erklärt aber trotzdem nicht wieso bei User A das eine 68K-Program läuft und bei B nicht. Was ich auch nicht verstehe (hab ich mal hier im Forum irgendwo gelesen) ist wenn ich in irgend einen Ordner das 68KEMU.PRG kopiere und es für *.68K im Desktop anmelde... wieso es dann auch mit der Endung *.PRG funktionieren soll bzw. tut? Oder ich hab da was falsch verstanden...
-
Was meinst du denn genau?
Bei Mathias läuft nach seiner Aussage z.B. PhotoLine, bei mir läuft es nicht, weder direkt noch mit Hilfe des 68k Emus als photoline.68k ...
Meine Firebee hat glaube ich die letzten Versionen vom FireTOS etc. vielleicht hat Mathias eine neuere nicht öffentliche Version, keine Ahnung ...
Bei mir gab es keinen Fall in dem mir dieser 68k Emu irgendetwas gebracht hätte !?!
-
Ist bei mir auch so. Photoline läuft nicht. 68k-Emu bringt meist nichts
-
Dito bei mir!
Auch Chagall bekomme ich nicht zum laufen.
Irgendwie hat Matthias da eine Sonderbiene! Grmmblll!
-
Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert. An dieser Stelle könnte man generell noch viel an der Kompatibilität schrauben, und einen eigenen 68k-Handler schreiben, der dann als Lib für TOS oder auch MiNT direkt zur Verfügung steht. Wenn man dann noch einen JIT für die ganz wenigen (2?) Fälle wo sich der CF anders als der 68k verhält dazuprogrammiert, dann wären wir bei den geplanten 95% Kompatibilität, die den Hades und Milan übertreffen würde.
Leider hat sich der eine Programmierer der das übernommen hat als Blender rausgestellt, und der Andere der das Wissen und die Skills hätte ist seit bald 3 Jahren unmotiviert (ich bleibe aber dran).
Vincents 68kemu ist eine ganz andere Abteilung. das ist eine "Soft-CPU" wo schlicht und einfach der ganze Prozessor emuliert wird (während die Systemaufrufe usw. native bleiben). Das ist ein Programm, und wenn man im Desktop ".68k" Programme auf 68kemu.PRG angemeldet hat, dann wird eben das Programm 68kemu aufgerufen um das jeweilige Programm laufen zu lassen. Dazu muß man aber vorher das Programm von ".PRG" oder ".APP" auf ".68k" umbenennen.
Photoline läuft mittlerweile nicht nur bei mir, sondern auch bei ein paar anderen Leuten mit 68kemu. Es bleibt aber ein kleines Mysterium warum das so ist. Und das wird leider auch solange so bleiben, bis sich ein guter Programmierer hinsetzt und das rausfinden will. Und bei mir laufen schon einige Programme, die ohne 68kemu gar nicht gehen (Porthos, Texel, ...) selbst wenn VIncent es definitiv nur als Proove Of Concept betitelt, und natürlich auch da noch viel machbar wäre bei dementsprechender Motivation und Tagesverlängerungen für Vincent. ;-)
-
Irgendwie hat Matthias da eine Sonderbiene! Grmmblll!
;)
Ja, die geheime Spezialbiene mit Extraschalter "Wahnsinnige Komatibilität", die haben wir nach den ersten 3000 Verkäufen finanzieren können (Fredi mußte 17 Monate dran entwickeln), aber wir behalten das jetzt Alles strenggeheim für uns. Es gibt nur 2 dieser Spezialbienen, und eine habe ich um euch mit den Kompatibilitätsmeldungen in die Verzweiflung zu treiben!!! :-p
-
Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert. An dieser Stelle könnte man generell noch viel an der Kompatibilität schrauben, und einen eigenen 68k-Handler schreiben, der dann als Lib für TOS oder auch MiNT direkt zur Verfügung steht ...
Ich persönlich würde mir sowas im nächsten Jahr wünschen, ich hätte lieber eine langsame Firebee und dafür umso kompatibler ...
-
Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert. An dieser Stelle könnte man generell noch viel an der Kompatibilität schrauben, und einen eigenen 68k-Handler schreiben, der dann als Lib für TOS oder auch MiNT direkt zur Verfügung steht ...
Ich persönlich würde mir sowas im nächsten Jahr wünschen, ich hätte lieber eine langsame Firebee und dafür umso kompatibler ...
Die FireBee wäre dann natürlich flotter als jetzt!
Die Problematik ist, daß wir bei so einem Task schon sehr viel Wissen brauchen. Da schrumpft der Kreis von fähigen aktiven Programmierern auf ein bis zwei Handvoll zusammen. Und wie immer sind die die wirklich was können schon so mit Arbeit oder anderen Projekten eingedeckt, daß eigentlich nichts mehr geht. Aber wer weiß, vielleicht gibt es auch noch "Externe" die sich da reinhängen würden, zu denen ich bis jetzt keinen Zugang hatte?
-
... An dieser Stelle könnte man generell noch viel an der Kompatibilität schrauben, und einen eigenen 68k-Handler schreiben, der dann als Lib für TOS oder auch MiNT direkt zur Verfügung steht. Wenn man dann noch einen JIT für die ganz wenigen (2?) Fälle wo sich der CF anders als der 68k verhält dazuprogrammiert, dann wären wir bei den geplanten 95% Kompatibilität, die den Hades und Milan übertreffen würde...
Hallo Mathias,
ob die Zahlen ("Kompatibilitätsgrad"), die Du genannt hast, so stimmen, weiß ich nicht. Was ich aber zu glauben weiß: viel besser, als die cf68klib das heute macht, wird's wohl nicht werden.
Die cf68klib fängt alle m68k-Befehle, die unmittelbar eine Prozessor-Exception bewirken, ab und schreibt sie "im Flug" in Coldfire-Befehle um. Die inkompatiblen Instruktionen, die sie heute nicht abfängt, bewirken eben keinen unmittelbaren Fehler, sondern einen, der sich erst im späteren Programmablauf durch falsche Ergebnisse und mehr oder weniger mysteriöse Abstürze auswirkt.
Das Ganze wird mit einem Preis erkauft: es gibt keinen "echten" Supervisor-Mode mehr (weil die cf68klib den emuliert, um inkompatible Befehle auch im OS "zu erwischen"). In der Konsequenz bedeutet das dann eben auch: kein echter Speicherschutz in MiNT (wenn MiNT im Usermode abläuft, kann es seine Prozesse nicht so kontrollieren, wie das dazu nötig wäre).
Der angesprochene "JIT" wäre ein ganz anderes Kaliber.
Sehr viel eher zu vergleichen mit einem "aufgebohrten" Aranym. Zwar wäre es möglich, große Teile des "übersetzten" Programms als "echte" Coldfire-Anwendung laufen zu lassen, einen großer Unterschied zu Aranym gäb's aber nicht - der JIT müsste sich trotzdem jeden einzelnen Befehl "anschauen", kompatible Codestrecken eben kennzeichnen, den Rest emulieren.
Technisch nicht unmöglich, aber nicht ganz einfach. Nichtsdestotrotz ein Emulator.
Einen wesentlichen Vorteil zu einem PC mit Aranym kann ich da nicht entdecken, zumal der trotz allem sicherlich günstiger und schneller wäre, obwohl er keinen "halbwegs kompatiblen" Prozessor hat.
Gruß,
Markus
-
Da sind einige interessante Infos wobei ich jetzt nicht genau weis ob die 68K-Emulation jetzt im TOS bzw. FireTOS eingebaut ist oder durch Benutzung des von Frank verlinkten 68KEMU.PRG bewerkstelligt wird.
Die cf68klib fängt alle m68k-Befehle, die unmittelbar eine Prozessor-Exception bewirken, ab und schreibt sie "im Flug" in Coldfire-Befehle um. Die inkompatiblen Instruktionen, die sie heute nicht abfängt, bewirken eben keinen unmittelbaren Fehler, sondern einen, der sich erst im späteren Programmablauf durch falsche Ergebnisse und mehr oder weniger mysteriöse Abstürze auswirkt.
Das Ganze wird mit einem Preis erkauft: es gibt keinen "echten" Supervisor-Mode mehr (weil die cf68klib den emuliert, um inkompatible Befehle auch im OS "zu erwischen"). In der Konsequenz bedeutet das dann eben auch: kein echter Speicherschutz in MiNT (wenn MiNT im Usermode abläuft, kann es seine Prozesse nicht so kontrollieren, wie das dazu nötig wäre).
Zu der Problematik die Markus/mfro erwähnt hat... mit dem Supervisor-Mode Problem... würde ich sagen das die Programme die mit der 68K-Emulation bzw. Lib laufen dann einfach mit einem "68KEMU-Übersetzer" als Coldfire-gepatchtes-Programm auf der Platte gespeichert werden müssten (dann wäre das neue Binary schon Compatible) um das Problem zu beheben damit dann der 68KEMU für den Supervisor-Modus z.B. MiNT wieder normal verfügbar wäre da der EMU dann nicht immer aktiv sein müsste... ist aber nur so ein Gedanke...
-
würde ich sagen das die Programme die mit der 68K-Emulation bzw. Lib laufen dann einfach mit einem "68KEMU-Übersetzer" als Coldfire-gepatchtes-Programm auf der Platte gespeichert werden müssten (dann wäre das neue Binary schon Compatible) um das Problem zu beheben damit dann der 68KEMU für den Supervisor-Modus z.B. MiNT wieder normal verfügbar wäre da der EMU dann nicht immer aktiv sein müsste... ist aber nur so ein Gedanke...
Das könnte funktionieren - nur leider kann man 68k-Programme nicht "statisch" umsetzen, weil nicht erkennbar ist, was Daten und was Programm ist. Der Emulator müsste also so lange aktiv bleiben, bis wirklich alle Codepfade mindestens einmal durchlaufen sind und das wiederum ist nicht wirklich final festzustellen (schließlich könnte immer noch irgendwo bislang als Daten betrachteter Binärcode sich plötzlich in irgendeiner speziellen Situation doch noch als Code entpuppen).
HP hat übrigens an solch einem System mit "dynamischer Laufzeit-Codepath-Analyse" jahrelang geforscht und auch einige Patente auf dabei verwendete Techniken: http://www.hpl.hp.com/techreports/1999/HPL-1999-78.pdf . Nicht um Prozessor-Inkompatibilitäten umzuschreiben, sondern um Code zur Laufzeit zu optimieren. Das Prinzip wäre aber durchaus geeignet, um 68k-Programme auf Coldfire-Prozessoren umzusetzen. Falls also jemand nicht weiß, was er die nächsten paar Jährchen so mit sich und seiner Zeit anfangen soll : nur zu! ;)
Nicht unmöglich, aber nichts was man an ein paar Samstagnachmittagen in seiner Freizeit macht.
-
Das hast Du gut erklärt... sogar ich verstehe das dies nicht mal ebend umzusetzen ist. ;o)
Nicht um Prozessor-Inkompatibilitäten umzuschreiben, sondern um Code zur Laufzeit zu optimieren.
Für die Alpha-CPU gabe es auch eine Compaq's FX!32 x86 Emulation wo die 32Bit Befehle zur Laufzeit von x86-Code in Alpha-Code übersetzt wurden (für Compaq Server mit NT4.0 und Alpha CPU's statt einer X86 CPU). Damals gab es ja NT 4.0 native als Alpha-Version und nur wenig native Software dafür... also fast wie auf der Biene.
-
Oder einen 68k Softcore in den FPGA reinnehmen, oder ist das aufwändiger?
-
Es soll doch mal Falcon kompatibel werden, wenn das so sein sollte fehlt ja noch der DSP und eventuell die ganzen Hardware Schnittstellen die so alle auf dem Board vorhanden sind ...
-
Oder einen 68k Softcore in den FPGA reinnehmen, oder ist das aufwändiger?
Es soll doch mal Falcon kompatibel werden, wenn das so sein sollte fehlt ja noch der DSP und eventuell die ganzen Hardware Schnittstellen die so alle auf dem Board vorhanden sind ...
Also bitte, wir sind hier doch nicht bei Wünsch Dir was... nur weil es gerade so weihnachtlich ist. :D >:D
-
Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert.
Was hilft bzw. kommen sich die Lib von MicroAPL oder der 68KEMU.PRG ins Gehege oder hat beides seine Berechtigung? Wer benutzt eigentlich noch zusätzlich das 68KEMU.PRG von Vincent?
-
Hallo Markus!
ob die Zahlen ("Kompatibilitätsgrad"), die Du genannt hast, so stimmen, weiß ich nicht.
Ich kann das auch nicht mit Bestimmtheit sagen, aber die Zahlen stammen von Fredi und VIncent. Ich kann halt nur wiedergeben, was mit Entwickler an Infos geben. Jedenfalls war die Idee ja soweit fortgeschritten, daß ein ungepatchtes Falcon TOS laufen sollte.
Was ich aber zu glauben weiß: viel besser, als die cf68klib das heute macht, wird's wohl nicht werden.
Laut meinen Informationen ist die cf68klib schon so alt, daß sie nicht für den V4e optimiert ist, und soweit ich die anderen Entwickler verstanden habe, gibt es da schon diesbezüglich ein paar Optimierungsmöglichkeiten.
Die andere Idee war ja daß der "Illegal Instruction Handler" eigentlich ins BaS eingebaut wird, und eben exzessiv mit Sprungtabellen gearbeitet wird, was dann wiederum um Häuser flotter gehen sollte als die derzeitige Konstruktion mit FreeRTOS, der cf68klib und dem TOS als task davon, ...
Jedenfalls wäre es schön, wenn wir uns der Sache auch im Entwicklerforum wieder mal widmen (z.B. Thread Software -> Kompatiblität gelöst!) und womöglich was in die Richtung anstoßen. ;-) Auch Henks Idee des "virtual memory manager" in dem das OS dann läuft könnte man weiterdenken.
Über den JIT, oder die Idee eines "Teilweisen JIT" kann ich noch weniger sagen, weil ich nichtmal verstanden habe wie ein JIT "teilweise" klappen könnte. Aber das sollten Leute wie Mikro schon wissen, wenn sie meinen daß es "gar nicht soo kompliziert wäre".
Auch ist mir noch immer nicht ganz klar wie Didiers "Pure-C patcher" funktioniert, der ja im Speicher scannt und die Programme patcht, was ja in etlichen Fällen sehr gut läuft momentan, zumindestens bei move.b xx,-(sp) wenn ich das richtig verstanden habe. Aber grundsätzlich habe ich schon den Endruck daß da Einiges gehen würde.
Und abschließend zu Börr noch; die Idee eines kompletten CPU-Cores im FPGA gabs natürlich auch immer schon, als zusätzliche Kompatibilitäts-Schicht. Bis uns halt die FPGA-Entwickler abhanden gekommen sind, ...
-
Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert.
Was hilft bzw. kommen sich die Lib von MicroAPL oder der 68KEMU.PRG ins Gehege oder hat beides seine Berechtigung? Wer benutzt eigentlich noch zusätzlich das 68KEMU.PRG von Vincent?
Du hast das grundsätzlich noch nicht verstanden. Ließ mein obiges Posting nochmal.
Ich versuchs auch nochmal anders. DIe cf68klib ist im FireTOS eingebaut und läuft noch vor dem Betreibssystem und fängt die Befehle die es nicht mehr gibt ab. Davon bekommt kein Programm was mit.
68kEMU.PRG ist ein TOS Programm. Ein kompletter CPU-Emulator. Um den zu nutzen nennt man ein belibiges ".PRG" in ".68k" um und sagt somit dem Programm 68kemu daß es das Programm xy emuliert ausführen soll. Das macht aber nur bedingt sinn, weil es langsam ist, und eben eine volle Emulation. Zum ernsthaft Arbeiten ist das aber nichts, weil es eben eine Software-Emulation ist. Da wäre Aranym oder so wirklich schlauer. Ist als Zusatz für zickige Programme gedacht, oder derzeit als einzige Möglichkeit 68k-Code mit EmuTOS zu ntuzen.
Die beiden Methoden haben natürlich NICHTS miteinander zu tun und kommen sich auch nicht ins Gehege.
-
Ich versuchs auch nochmal anders. DIe cf68klib ist im FireTOS eingebaut und läuft noch vor dem Betreibssystem und fängt die Befehle die es nicht mehr gibt ab. Davon bekommt kein Programm was mit.
Alles klar... bedeutet das jetzt auch das Festplattentreiber theoretisch problemlos laufen oder gibt es da völlig andere Probleme?
68kEMU.PRG ist ein TOS Programm. Ein kompletter CPU-Emulator. Um den zu nutzen nennt man ein belibiges ".PRG" in ".68k" um und sagt somit dem Programm 68kemu daß es das Programm xy emuliert ausführen soll. Das macht aber nur bedingt sinn, weil es langsam ist, und eben eine volle Emulation. Zum ernsthaft Arbeiten ist das aber nichts, weil es eben eine Software-Emulation ist. Da wäre Aranym oder so wirklich schlauer. Ist als Zusatz für zickige Programme gedacht, oder derzeit als einzige Möglichkeit 68k-Code mit EmuTOS zu ntuzen.
Das mit der *.68K Anmeldung hatte ich ja weiter oben, vor deinem Post, schon vermutet und erwähnt. Das die Emulation durch den 68KEMU so langsam sein soll kann ich nicht ganz nachvollziehen (der Vergleich passt vielleicht nicht ganz) da unter Magic auf dem alten Mac's mit 680x0 CPU doch auch eine 68K emuliert wurde und das Tempo abgeblich hervorragent war.
Wird eigentlich verhindert das auch CF-Code durch die cf68klib ist im FireTOS ausgeführt wird oder macht das gar nichts aus bzw. werden da irgendwelche Programm-Flags benutzt um das zu verhindern?
-
...Laut meinen Informationen ist die cf68klib schon so alt, daß sie nicht für den V4e optimiert ist, und soweit ich die anderen Entwickler verstanden habe, gibt es da schon diesbezüglich ein paar Optimierungsmöglichkeiten.
Ich weiß natürlich nicht, wo Du das her hast, aber die cf68klib, wie sie im FireTOS eingebaut ist, verwendet durchaus ISA_B-Instruktionen (und die kann nur der v4e). Meist sogar "händisch" dekodiert (dc.w xxx) - also mit Hirnschmalz -, weil manche Assembler wohl die Befehle nicht beherrschen.
Die andere Idee war ja daß der "Illegal Instruction Handler" eigentlich ins BaS eingebaut wird, und eben exzessiv mit Sprungtabellen gearbeitet wird, was dann wiederum um Häuser flotter gehen sollte als die derzeitige Konstruktion mit FreeRTOS, der cf68klib und dem TOS als task davon, ...
Das kann ich nicht nachvollziehen. Die cf68klib arbeitet bereits mit Sprungtabellen und hängt mit ihren Ausnahmebehandlungsroutinen direkt in der Vektor-Table des Coldfires (da spielt der FreeRTOS Task Switcher und die TOS-Task keine Rolle). Die meisten Fixes laufen in 5, höchstens 10 Taktzyklen und ich wüsste nicht was man da - verglichen damit, daß die Exception selbst (nur Exception + RTE) größenordnungsmäßig bereits etwa 50 Taktzyklen braucht - viel besser machen sollte. Generell ist die cf68klib meiner Ansicht nach ein Musterbeispiel an "schlauem" Coldfire-Assembler, ich jedenfalls könnte das nicht besser.
Auch ist mir noch immer nicht ganz klar wie Didiers "Pure-C patcher" funktioniert, der ja im Speicher scannt und die Programme patcht, was ja in etlichen Fällen sehr gut läuft momentan, zumindestens bei move.b xx,-(sp) wenn ich das richtig verstanden habe. Aber grundsätzlich habe ich schon den Endruck daß da Einiges gehen würde.
Das ist eigentlich ganz simpel. PureC hat eine Eigenart (damals als "Optimierung" gehandelt) um möglichst schnell ein 16-Bit-Wort mit 256 zu multiplizieren (also um 8 Bit nach links zu schieben):
move.b d0,-(sp)
move.w (sp)+,d0
Das nutzt die "Angewohnheit" der m68k-Prozessoren aus, den Stack automatisch auf Wortgrenzen auszurichten, indem sie bei einem Byte-Push immer eine 0 hinterherschieben (sonst gäb's einen Adressfehler). Dem Coldfire-Prozessor ist es egal, wenn der Stack "schief" liegt (die "Korrektur" gibt's da nicht mehr), wenn man ein Byte pusht und anschließend ein Wort wieder vom Stack holt, multipliziert man mit 1 und holt zusätzlich das letzte Byte der Rücksprungadresse (die anschließend kaputt ist). Spätestens beim rts kracht's dann.
Der "Pure-C"-Patcher sucht beim Programmstart nach den von PureC geschriebenen Bytemustern dieser Library-Routine und überschreibt sie mit einem passenden "Coldfire-Ersatz". Das funktioniert aber nur für diesen speziellen Fall und paßt schon dann nicht mehr, wenn man bloß ein anderes Register verwendet (glücklicherweise macht PureC das immer gleich). Theoretisch gibt's auch hier die Möglichkeit, daß dieselben Bytemuster auch mal als Daten gebraucht werden (dann ginge das schief), aber das ist wohl bislang noch nicht passiert.
Es gäbe übrigens noch eine weitere (meines Wissens nach noch nirgends diskutierte), zumindest theoretisch mögliche Art, der Firebee m68k-Code "beizubiegen": das FPGA hängt zwischen Coldfire und "FPGA-Speicher". Würde man den als ST-RAM anmelden, müsste es möglich sein, nach Abschalten des Datencaches (mit weiterhin eingeschaltetem Befehlscache) Instruction-Fetches an den Burst-Reads zu erkennen, mit denen der Coldfire seinen Befehls-Cachelines füllt. Datenzugriffe würden am Cache vorbei stattfinden und keine Burst-Reads verursachen. Das FPGA hätte damit die Möglichkeit, Daten- und Codezugriffe auseinanderzuhalten.
Anstatt nun die Befehlsbytes einfach "durchzureichen", wie es das heute tut, könnte es den Datenstrom dann nach "m68k-only"-Befehlen scannen und entsprechend umkodieren.
Besonders schnell wär's allerdings nicht. Der FlexBus hat nur 33 MHz, die sich der Prozessor mit dem Videospeicher teilen muß, zusätzlich müsste der Data-Cache ausgeschaltet werden - wahrscheinlich kaum schneller als ein Falcon.
Das ist bei weitem nicht fertig überlegt, aber könnte eine Möglichkeit sein. Bloß: ohne FPGA-Entwickler nicht zu machen.
-
PhotoLine ist doch ein Pure-C Programm soweit ich weiss, so wie sehr viele Atari Programme ...
Wo bekommt man denn diesen "Pure-C -Patcher" her oder ist der im FireTOS eingebaut ?
-
@mfro, danke Markus, das ist sehr interessant, auch wenn ich nur eine Anwendungsentwicklerin bin und so tief noch nie drin war.
-
PhotoLine ist doch ein Pure-C Programm soweit ich weiss, so wie sehr viele Atari Programme ...
Wo bekommt man denn diesen "Pure-C -Patcher" her oder ist der im FireTOS eingebaut ?
Wie beim Metzger, wenn Du nach einem zweiten Brötchen zu deiner Frikadelle fragst:
"ist schon drin" ;)
-
Wie beim Metzger, wenn Du nach einem zweiten Brötchen zu deiner Frikadelle fragst:
"ist schon drin" ;)
>:D :D
-
Die neue Version von MyAES soll ja nochmal Optimierungen für das ausführen von SDL Applikationen beinhalten... evtl. reichts ja diesmal für Hatari, um einen normalen ST mit 8 Mhz flüssig darzustellen :) ?
...und hatari soll ja laufen, und so wie ich das verstanden habe ist der Fullscreen Modus auch schneller (aber der GEM Fenster Modus dafür kompatibler und der funktioniert auch so wie er soll auf der Firebee - nur etwas zu langsam)... Gibt aber noch Probleme mit der FPGA beim Fullscreen Modus (oder anderer treibender Komponenten?), wenn das behoben wäre (und ich glaube, wenn es einen FPGA Programmierer geben würde der das kann, dann wäre das der kleinste Aufwand), dann ist die Firebee doch wohl schnell genug um einen 8 Mhz Atari mit hatari flüssig zu emulieren? Ich gehe start davon aus... Immerhin ist die Firebee rund 30x schneller... also eigentlich genug zeit pro 8mhz CPU Befehl diversen Kram abzuarbeiten, oder?
-
Alles klar... bedeutet das jetzt auch das Festplattentreiber teoretisch problemlos laufen oder gibt es da völlig andere Probleme?
Theoretisch Ja - praktisch gibt es da völlig andere Probleme ;) Ich glaube im thread wurde erwähnt das 98% der möglichkeiten durch cf68klib und solche Techniken "korrigiert" werden... aber das bedeutet bei einem 100k großen Programm immer noch 2k an Querschläger Befehlen... Kann man sich bei einem Festplattentreiber dann ja ausrechnen was passiert.Aber davon abgesehen, weiss ich nicht ob der Festplattentreiber nicht auch schon seine Arbeit machen muss, bevor die m68k Emulation gestartet ist?
-
...Und das wird leider auch solange so bleiben, bis sich ein guter Programmierer hinsetzt und das rausfinden will. Und bei mir laufen schon einige Programme, die ohne 68kemu gar nicht gehen (Porthos, Texel, ...) selbst wenn VIncent es definitiv nur als Proove Of Concept betitelt, und natürlich auch da noch viel machbar wäre bei dementsprechender Motivation und Tagesverlängerungen für Vincent. ;-)
Da ist übrigens nicht besonders viel zu machen, an Vincent's Emulator. Einer der wesentlichen Gründe, warum manche Programme laufen und andere nicht, liegt darin begründet, daß der Emulator Betriebssystemaufrufe nicht emuliert, sondern 1:1 ans (Coldfire-) Betriebssystem durchreicht.
Das macht die Geschichte zwar nett flott, scheitert aber da, wo das Betriebssystem irgendwann per Callback m68k-Routinen in der Anwendung aufruft (die dann ja wieder potentiell einen Absturz verursachen). Für den "Supexec()" Betriebssystemaufruf ist das schon gemacht, fehlt aber (noch) für VDI-Callbacks. Also beispielsweise für VDI-Erweiterungen über G_USERDEF-Objekte oder Programme, die per vex_...() eigene Maus- oder Timer-Routinen ins VDI basteln.
Das dürfte der wesentliche Grund sein, warum insbesondere "moderne" GEM-Programme abschmieren (die ihr GUI eben meist über solche USERDEF's "aufhübschen").
Was fehlt ist ein eigener VDI-Trap-Handler im Emulator, der objc_draw()-Aufrufe abfängt, dann prüft, ob gerade ein G_USEDEF-Objekt gezeichnet werden soll und wenn ja, den entsprechenden Code im Emulator abhandelt, ansonsten (Coldfire-native) im OS. Wenn der Trap-Handler dann noch gleich die vex_...()-Routinen (die werden wahrscheinlich nicht so oft benutzt) miterledigt, gibt's ein Fleißsternchen.
Das einzubauen ist nicht besonders schwierig, es muß sich nur einer (oder eine) finden, der's macht. Ich wette, dann laufen die meisten m68k-Programme, die ansonsten nicht ins OS eingreifen.