Notice if it's slow its not very important because new CPU are fast enough evenwithout JIT running correctly 68K application we use it.I would like to know about portabilility of it? Do you manage something with system address (like timer). Is it a work from scratch or something relatedwith other project.
Portability should be quite simple - It should only be a matter of porting 4 trap wrappers and 16 line-A wrappers. Atm the target system must be big-endian. I took the CPU core from CaSTaway.
Even though speed is quite low, most everyday applications won't suffer much since their performance is usually related to the speed of the VDI (which is fast).
The current implementation tries to emulate manpulation of system vectors, so some apps which detects FPU etc. through the bus error vector works. Interrupt handling isn't implemented yet, but I'm working on it (should work without too much trouble).
Low memory (<0x800) access is handled using a combination of an internal buffer and the Ssystem() call. So reading may in some cases return "real" values from the system, and accessing vectors etc. will usually return dummy routs (terminated by RTS). If the application modifies exception vectors etc, the emulator executes them. If not, it executes native code. BIOS, XBIOS, GEMDOS and XGEMDOS vectors cannot be manipulated by the application atm.
I'm very interesting in your job. I going to look for opengl crash in Kronos(there is possible bug)
Actually Kronos crashes on my ST too :) FPU usage? While on the subject - perhaps it could be a good idea to cache the bitmaps in the filesystem once converted; on a slower machine (8Mhz) it takes quite som time (minutes even) to get to the main screen... CICONS, perhaps?
By the way, impressive work on MyAES. I'm looking forward to trying the native ColdFire version soon!!
best regards -- Peter