Hardware > Firebee

Wie geht das mit der Firebee 68K Emulation?

<< < (6/6)

Arthur:

--- Zitat von: mfro am Mo 22.12.2014, 18:25:54 ---Wie beim Metzger, wenn Du nach einem zweiten Brötchen zu deiner Frikadelle fragst:

"ist schon drin" ;)

--- Ende Zitat ---

 >:D :D

m0n0:
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?

m0n0:

--- Zitat von: Arthur am Mo 22.12.2014, 17:07:23 ---
Alles klar...  bedeutet das jetzt auch das Festplattentreiber teoretisch problemlos laufen oder gibt es da völlig andere Probleme?

--- Ende Zitat ---

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?

mfro:

--- Zitat von: Mathias am So 21.12.2014, 15:17:14 ---...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. ;-)

--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[*] Vorherige Sete