--- In gbadev@y..., Pete Gonzalez <gonz@r...> wrote:
> Does anyone have code for detecting the presence of an emulator?

Easy.

dir /s /b \visualboyadvance.exe

Oh, you mean you want the GBA program to detect which GBA model
or emulator it's running on. In other words, you seek emulation
inaccuracies visible to the running program. I can think of two
reasons why you'd want to do this:
1. to present a simplified display to compensate for slow
computers or inaccurate but popular emulators, or
2. to discourage unauthorized redistribution of proprietary
game software.

Theoretically, it should be impossible for game console software
to determine whether it's running on Nintendo brand hardware or
Gateway brand hardware. As emulators mature, the simple tricks
used to distinguish environments begin to fail. For example, in
the early days of NES emulation, four lines of 6502 code could
distinguish the popular emulators from the Nintendo hardware (see
http://everything2.com/?node=nesticle). But now, as NES emulators
have matured, it's much harder for NES code to tell where it's
running.

I don't really know where the GBA emulators stand on inaccuracies
visible to the running program, but I do know some things about
recent builds of VisualBoyAdvance:
* tone generator volumes are wrong in some cases, and envelopes
aren't smooth enough
* a busy loop in ROM or EWRAM runs two to three times faster on
VBA than on hardware because VBA doesn't emulate wait-states
except in DMA
* default keyboard binding puts A to the left of B, which
causes confusion in games that bind "fire left" to B and
"fire right" to A, such as Lode Runner and Paperboy
* out-of-order writes to affine registers have some slight bugs
on hardware but not on VBA; I haven't characterized them yet
* GBA buttons A and B are bouncy; DirectX buttons aren't

Also try looking at initial values of readable registers that
may be set differently by the Nintendo release BIOS vs. the
clone BIOS built into an emulator.

--
Damian