Zophar's Message Domain

Go Back   Zophar's Message Domain > Emulation Talk > General Emulation

Reply
 
Thread Tools Display Modes
Old 08-30-2004, 05:41 AM   #1
imnonoitall
Junior Member
 
Join Date: May 2004
Posts: 29
Default Newbie Question LLE and HLE

Kind of an emulation newbie question, but can someone explain the main differences between low level emulation and high level emulation. I know there are trade-offs when it comes to accuracy and speed, but I'm wondering more how they use ROM information to emulate games. Again, sorry if this question is a bit newbish.

<P ID="signature"></P>
imnonoitall is offline   Reply With Quote
Old 08-30-2004, 06:11 AM   #2
Lobster Cowboy
Senior Member
 
Join Date: Oct 2002
Posts: 2,836
Default Re: Newbie Question LLE and HLE

i know moogle and lilly can answer this very well, but let be take a crack...

low level emulation, moogle correct me if i'm wrong, is the type they use in projects like MAME, and is extremely accurate to the original hardware. all data from ROMs are processed as it would be on the real machine.

high level emulation uses things like dynamic recompilation, and sacrifices accuracy for speed. i believe this takes ROM information, and uses it in a way that's opimised for things like direct X. instead of the emulator handling rendering, it's turned into something an API can handle. certain things can be lost in this translation. for example, the way an N64 anti-aliases polygon info might be different than how an API would do it.

am i close?

<P ID="signature"><img src=http://www.lobsterstudios.com/images/lobsterranx.jpg>
</img></P>
Lobster Cowboy is offline   Reply With Quote
Old 08-30-2004, 07:42 AM   #3
Lillymon
Senior Member
 
Lillymon's Avatar
 
Join Date: Apr 2002
Location: England
Posts: 2,379
Default Re: Newbie Question LLE and HLE

> i know moogle and lilly can answer this very well, but let
> be take a crack...

I don't fully understand the differences either really. I just know HLE is faster but more accurate, and LLE is slower but more accurate.

> high level emulation uses things like dynamic recompilation

Actually, dynamic recompilation isn't specifically a part of HLE. I believe the Killer Instinct driver in MAME uses a dynamic recompiler core.

<P ID="signature"><marquee direction=left scrollamount=8><img src=http://home.graffiti.net/lillymon:graffiti.net/images/keletav.gif></marquee>
!luos ruoy tae lliw stelek ehT</P>
__________________
Amelia Explains It All - Eventually. Probably.
Lillymon is offline   Reply With Quote
Old 08-30-2004, 03:42 PM   #4
MegaManJuno
Senior Member
 
Join Date: Jan 2003
Location: WV
Posts: 626
Default Re: Newbie Question LLE and HLE

As far as I understood it, LLE's goal is to actually emulate every last piece of hardware, the actual instruction set(s) of the processor(s), etc. - in order to actually have a "virtual clone" of sorts of the hardware in question.

HLE on the other hand, looks at what the hardware would try to do with a given instruction and attempts to find a way to mimic the behavior without necessarily having a true "virtual clone" of the hardware.



<P ID="signature"></P>
MegaManJuno is offline   Reply With Quote
Old 08-30-2004, 04:24 PM   #5
MooglyGuy
Senior Member
 
Join Date: Mar 2002
Location: Albany, NY
Posts: 4,014
Default Re: Newbie Question LLE and HLE

> HLE on the other hand, looks at what the hardware would try
> to do with a given instruction and attempts to find a way to
> mimic the behavior without necessarily having a true
> "virtual clone" of the hardware.

Almost, see my above response.

<P ID="signature"></P>
MooglyGuy is offline   Reply With Quote
Old 08-30-2004, 04:47 PM   #6
MooglyGuy
Senior Member
 
Join Date: Mar 2002
Location: Albany, NY
Posts: 4,014
Default Re: Newbie Question LLE and HLE

> 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>
MooglyGuy is offline   Reply With Quote
Old 08-30-2004, 10:32 PM   #7
MegaManJuno
Senior Member
 
Join Date: Jan 2003
Location: WV
Posts: 626
Default Re: Newbie Question LLE and HLE

> Almost, see my above response.
>

Well, it's good to know I was at least on the right track. Thanks for the clarification.<img src=smilies/thumb.gif>

<P ID="signature"></P>
MegaManJuno is offline   Reply With Quote
Old 08-31-2004, 09:46 AM   #8
imnonoitall
Junior Member
 
Join Date: May 2004
Posts: 29
Default Re: Newbie Question LLE and HLE

Thanks for the quick and very helpful info. (TheOtherMoogle is very smart!) So, to review, LLE is an exact (or at least as exact as possible) true emulation of the ROM's instructions, and HLE is more like using an educated guess (based on existing microcodes) to figure out just how information on the ROM should be used (hence a lot of processing is saved because much of the processing can be done natively as opposed to truely emulating the original instructions). Did I pretty much get the gist of it?

Then, another question: does anyone know of any active N64 emulator projects - most that I've seen are discontinued.

<P ID="signature"></P>
imnonoitall is offline   Reply With Quote
Old 08-31-2004, 12:13 PM   #9
MooglyGuy
Senior Member
 
Join Date: Mar 2002
Location: Albany, NY
Posts: 4,014
Default Re: Newbie Question LLE and HLE

> Did I pretty much get the gist of it?

Yep!

<P ID="signature"></P>
MooglyGuy is offline   Reply With Quote
Old 08-31-2004, 02:20 PM   #10
Lillymon
Senior Member
 
Lillymon's Avatar
 
Join Date: Apr 2002
Location: England
Posts: 2,379
Default Re: Newbie Question LLE and HLE

> Then, another question: does anyone know of any active N64
> emulator projects - most that I've seen are discontinued.

I believe 1964 is still working towards the 1.0.0 'Final Release'. Daedalus may or may not still be alive (the news page never was updated frequently). Mupen64 is probably still active. icepir8, the author of TR64, is still going so updates on that are possible. Finally, UltraHLE 2064 seemed very active for a while but has now gone silent...

Nintendo 64 HLE has probably gone about as far as it can go now. A Nintendo 64 emulator mostly using LLE would probably get a fair bit of attention now.

<P ID="signature"><marquee direction=left scrollamount=8><img src=http://home.graffiti.net/lillymon:graffiti.net/images/keletav.gif></marquee>
!luos ruoy tae lliw stelek ehT</P>
__________________
Amelia Explains It All - Eventually. Probably.
Lillymon is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 01:26 PM.

Contact Us - Zophar's Domain - Archive - Top

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.