Re: [stella] The future of emulation

Subject: Re: [stella] The future of emulation
From: Julian Squires <tek@xxxxxxx>
Date: Sun, 27 Aug 2000 16:44:06 -0230
On Sat, Aug 26, 2000 at 07:29:08PM -0700, Glenn Saunders wrote:
> The problem with Java is that it would be two layers of emulation.  Java is 
> a virtual machine, which in and of itself is like an emulator, running an 
> emulator for the 2600.  You'd probably need at least a 1GHZ machine to get 
> it to 1:1 throughput.  Arcade emus are a different story.  You can precook 
> the audio for that individual game with sample triggers, and the 
> architectures tend to be more straightforward bitmap-based systems.  Plus I 
> think Phoenix and Space Invaders both use Z80/8080 chips which is the core 
> of the x86 lineage and is probably simpler to emulate than the 6502.  Plus, 
> I don't thinK Java's 2D Graphics engine is as robust as DirectX.  Java runs 
> as fast as it can.  Implementing system timing functions and intelligent 
> frame skipping is tricky in Java.  I saw a fairly good Java emulation of 
> Battlezone at E3, but I think vector graphics are easier to do because it's 
> just drawing lines, not refreshing the entire bitmap.

While I don't completely disagree, there are a few important points
about java I'd like to bring up before it gets dismissed completely:

JIT emulation provides much better performance than the pure-interpretive
style of emulation used by most of the default JVMs for browsers of which I
know (iirc).

A lot of implementors of java I've seen (particularly wrt applets) make
no effort what-so-ever to optimize the code. There is quite frequently a
large amount of improvement possible - when implementing a real-time
video games in java, i discovered that there are huge optimizations available.
(see any of the n webpages on the subject)
I was also surprised to find that even my old 486/66 could pull off
a reasonable framerate after some optimization.

Also, until PCs are ready to handle the generic code, JNI is wonderful
for the speed-critical portions of the code. At least with JNI, it's
likely it wouldn't be too difficult to port the speed-critical portions
between different systems. If you lock yourself into some disgusting
proprietary thing, you're shutting a lot of people out at the same time.

Not that I'm a big fan of java, actually, but java bytecode is
pretty open compared to the alternatives. (Plus, you don't have
to code in java - there are plenty of languages which compile
into java bytecode these days)

 |/|  Julian Squires <tek@xxxxxxx>

Archives (includes files) at
Unsub & more at

Current Thread