> high level emulation uses things like dynamic recompilation,
> and sacrifices accuracy for speed.
Dynamic recompilation technically isn't high-level emulation - the emulator simply takes the code in blocks and converts it to optimized machine code for the sake of speed. The actual CPU is still emulated, it's just that it's much faster than straight C.
> instead of the emulator handling rendering,
> it's turned into something an API can handle.
Basically, yeah. In the N64's case, the RCP (Reality CoProcessor) is broken up into two sections, the RSP (Reality Signal Processor) and the RDP (Reality Display Processor). The RSP is a cut-down MIPS R4000 processor (effectively a cut-down version of the main processor) that only has 4 kilobytes of data memory and 4 kilobytes of code memory. The main CPU uploads
microcode to the RSP. The CPU, while running the game, sends
display lists to the RSP, detailing the desired camera transformations, model positions, and so forth. A display list effectively describes a model and/or full scene. The RSP, running its microcode, in turn parses out the display list into a list of commands ("Draw 8x8 tile, draw gouraud-shaded polygon, draw textured polygon," and so on) which it sends to the RDP. The RDP thusly accepts the commands and draws the polygons and other primitives on-screen.
The way HLE - at least in the N64's case - is that the developers of the emulators have taken the most often-used microcode programs and studied them, figuring out how each game's microcode processes the display lists. Given the fact that there were only around 10-15 (at most) microcode revisions ever in use, it isn't as difficult of a job as it may sound, since it's not game-specific. The emulator, while running, can effectively not emulate the RSP at all - saving on speed - and simply interpret the display lists and draw the scene itself. This has the added benefit of allowing the emulator to increase the resolution, since all of the geometry is being drawn and processed by the emulator itself as opposed to the emulated RSP. However, it has a downside of making certain effects - called framebuffer effects - unusable without hacks. The framebuffer is basically a portion of the N64's main memory that contains a bitmap of whatever is currently being displayed on the screen. Framebuffer effects are immensely useful for things like specialized camera effects, in-game filters (static, black and white, or whatever, if you want to simulate the scene being viewed through a CCTV camera), and "hall of mirror" effects. The HOM effect, for example, can be done by taking what's in the framebuffer, scaling it down, and then copying it back into the FB, and so on. When HLEing the RSP, generally an emulator doesn't write the frame back into the framebuffer area since the constant communication between the video card and the main CPU is terrible for speed - some video plugins even have the option, I believe it's called "Write-back". You also have the added downside where if a game uses a unique microcode or a dynamically-changing microcode, and the emulator doesn't support it, you won't be able to run the game well (if at all).
Currently, emulators such as Project 64 and 1964 have options to either send display lists or audio lists to the RSP plugin to actually be emulated properly (with the expected speed drop), or to have them sent to the video plugin to be HLE'd. In the case of audio, this works great if you LLE the audio. In the case of video, however, there are currently no video plugins that emulate the RDP to an extent that it will display anything, so the option is anomalous at best. However, I have spoken with a couple people intimately familiar with N64 emulation, and there
have been efforts to write a proper LLE video plugin, to varying degrees of success. One person was able to get Super Mario 64 running slowly and with large amounts of graphical errors. Yet another had the plugin actually fairly complete, but there were still geometry errors due to the fact that even the best RSP emulation these days is only around 95% accurate, and the plugin was never released due to speed issues.
In a general sense, however, HLE is typically figuring out what a command to specialized hardware does, and doing it emulator-side instead of actually emulating the hardware. In the case of some games in MAME, the original game used an MCU for copy-protection. Some games use them as rudimentary encryption devices, some of the MCUs actually store portions of game code without which the game cannot run, some contain data on how enemies should behave, some contain graphical data, and so on. In a case where a dump of the MCU data (either due to a lack of a board to redump it or the MCU being read-protected) cannot be obtained, sometimes someone writing a MAME driver might choose to HLE the MCU by simulating the effects of the MCU commands instead of actually emulating the MCU's instruction set and the program code running upon it. For example, command 7 might mean, "Send controller 1 state to me," and instead of the MCU doing it, the driver interprets the command and does so instead.
I hope this clarifies things a bit.
<P ID="signature">
</P>
