From mint-bounce@lists.fishpool.fi  Fri Feb 15 19:29:11 2008
Cc: mint <mint@fishpool.com>
Message-Id: <10C0116C-65F4-4326-8B86-227CDFFD8A67@gmail.com>
From: Peter Persson <pep.fishmoose@gmail.com>
To: "Olivier.Landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>
In-Reply-To: <1203086395.47b5a43bb5e8d@webmail.utbm.fr>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: [MiNT] 68k binary emulator
Date: Fri, 15 Feb 2008 15:55:48 +0100
References: <BBDD5A0E-C8A5-4432-A926-CC38249FC5D8@gmail.com> <1203086395.47b5a43bb5e8d@webmail.utbm.fr>
X-Mailer: Apple Mail (2.919.2)
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-to: mint-bounce@lists.fishpool.fi
X-original-sender: pep.fishmoose@gmail.com
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
List-subscribe: <mailto:mint-request@lists.fishpool.fi?Subject=subscribe>
List-owner: <mailto:tjhukkan@fishpool.fi>
List-post: <mailto:mint@lists.fishpool.fi>

> Notice if it's slow its not very important because new CPU are fast  
> enough even
> without 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  
> related
> with 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


