From: Torne Wuff <torne_at_wolfpuppy.org.uk>
Date: Thu, 8 Mar 2012 14:40:18 +0000

On 7 March 2012 16:33, Jason Taylor <jasontaylor_at_rcn.com> wrote:
> You are obviously correct and I'm sorry to have suggested something impractical although not on the technological basis which is what I was speaking to.

I don't mean to offend by any of this, but I *do* know about the
technological basis of what you're talking about and therefore wanted
to comment: what you suggested is also technologically impractical as
well as impractical as a GSoC project.

You suggested the overhead for emulation is 2-5 times; this isn't
entirely unreasonable, though most people tend to say a number more
like 10 times (and this is only true for "typical" emulation, which is
not 100% accurate). So, even if your numbers are maybe a bit off, your
premise starts off reasonable.

However, what you aren't taking into account is that there's more than
just the CPU to be emulated. Yes, the gameboy has a 4.2MHz Z80-alike
processor, and it's possible to emulate that CPU in isolation on a
modern ARM core very easily (though the gameboy color CPU is twice as
fast, and thus twice as expensive to emulate). However, it's not
really the CPU that's the problem. The gameboy's graphics hardware is
a pretty complex and powerful tile-and-sprite 2d rendering system
which is several times more expensive to emulate than the CPU, even in
isolation; then on top of that, the fact that both the CPU and
graphics hardware are accessing the same state at once means they have
to be synchronised (e.g. so that effects involving the CPU modifying
the graphics hardware state in the middle of drawing a scanline can
work), and the synchronisation between the different parts of the
emulation involves even more overhead. The timing may need to be very
precise for certain games to work correctly. There's also the sound
hardware, which is not as complicated as graphics but has its own set
of synchronisation issues.

So, you need to take your 4.2MHz starting value, double it to make
sure CGB games work, then multiply it by probably 5-10 to take the
graphics/sound hardware and sync between them into account, and *then*
multiply it by 2-5 (or 10) for the emulation overhead. Then we arrive
at a much higher estimate: more like 200-400MHz as a bare minimum,
depending what numbers you pick :) (obviously this is a rough
back-of-envelope calculation, but you can't work it out precisely
without actually writing the code and testing it).

This is already approaching the performance of even our fastest
targets, and is leaving a lot of the older targets in the dust.

But even that's not done yet, because there's another factor still to
consider: the gameboy's graphics hardware outputs directly to the LCD,
but an emulated version outputs to memory. This output has to be
copied to the actual LCD framebuffer, which on many of our targets is
expensive and slow (because the LCD controller is attached via a slow
bus). So, you might need to multiply the time to emulate one frame by
a factor as large as two..

Then, even worse: many of our targets either have screens that are
much bigger or somewhat smaller than the gameboy's screen resolution,
which means that the image needs to be processed to stretch or squash
it. Even for trivial row/column doubling/skipping as we currently do
will multiply the time per frame by some factor, and you're proposing
adding high quality retro-specialised scaling algorithms like 2xSaI,
which multiply it by probably three or four times at minimum (hq4x
scaling on my actual desktop PC causes some emulators to use over 1GHz
of processing power, and that's on a powerful 64-bit x86 system with
giant amounts of memory bandwdith, not an embedded ARM device).

So, while it's probably true that with work, Rockboy could be improved
in some ways, especially on the more powerful ARM targets, you are
asking for the moon to a large degree. You can make the emulation a
bit faster, probably; you can make it a bit more accurate to reduce
crashing, probably; you might even be able to make it do, say, a
bilinear scale of the image on the most powerful devices we support
instead of the dumb scaling it currently uses, but this is a long way
from what you are asking for and even on the most powerful targets
there will still be plenty of games that are unplayably slow, or
broken, or which can't comfortably be played because of scaling
artifacts. The amount of work this would be is probably quite high,
and nobody has volunteered to do it because of the limited reward.

The suggestion that we should be able to emulate all the machines
before 1997 is just ridiculous, unfortunately; you realise this
includes the PlayStation in 1994, which has actual 3D rendering
hardware? :) 1992 or thereabouts is a slightly more reasonable cutoff
when discussing emulation in general (since it excludes pretty much
all the 3D systems), but our devices are still much less powerful than
the typical portable emulation target, and so I'd be more inclined to
say 1990 and exclude the SNES, which is probably too much to emulate
decently for even our most powerful current targets.

If you want to get an idea of what's realistically possible, look at
the state of emulation on, say, the original GP32. Its CPU is slower
than some of our fastest targets, but it has graphics hardware which
makes up for it in many respects, and it has comparable amounts of
RAM. Then, note that the emulators for that platform were very highly
optimised for it even to get the performance they did... some of this
work might be reusable if it's open source, but it won't all apply to
our hardware..

Ultimately it boils down to: a 240MHz ARM core doesn't count for much
if it's in an MP3 player with a painfully slow, totally unaccelerated
framebuffer display, no L2 cache and slow SDRAM. The people with the
skills to get our emulators to work a little better than they
currently do have little motivation to do so, because even if they do
the best they possibly can it still isn't going to be fast enough,
stable enough or nice looking enough in many cases, and ultimately you
are still playing the same games you can emulate on any other device
you happen to have, but probably with even worse controls. If someone
wants to do this anyway they are welcome to contribute a patch, but
asking Google to pay for a project that has little hope of significant
successes, limited value to the community, and little interest from
potential mentors would be an irresponsible use of the GSoC "offer".

Hope this is informative,

-- 
Torne Wuff
torne_at_wolfpuppy.org.uk

Received on 2012-03-08