Non-HLE Emulators?

[dcook32p]

Are there any emulators for the Nintendo 64 that do not use high-level emulation (HLE)?

 

[ScottJC]

Why don't people try finding this out themselves...
I can name a few: 1964, Project64, Mupen64

 

[Lillymon]

Umm... actually, all major Nintendo 64 emulators use HLE. A pure LLE emulator would just be too slow.

Parts (like the sound) can be emulated in LLE for added accuracy, but at the expense of speed. The core and graphics have to be emulate in HLE to get decent speed.

 

[ShadowPrince]

All major n64 emulators use LLE for core .Pj64 rsp supports LLE sound ,but there are HLE sound and rsp plugins as well. Video is HLE in all of them .

 

[dcook32p]

Thank you!

Thank you, ShadowPrince and Lillymon.

I've been getting bored lately at nights, so I decided to start a low-level Nintendo 64 emulator. Being the open source advocate that I am, I was wondering if I could contribute to an existing LLE project, but I can see now that one does not exist.

I know that the end result will not be very fast (or even playable), but I would like to develop it for pure academic reasons. The project will be a great learning experience for me, and when our hardware has advanced sufficiently then everyone can appreciate an emulator that (hopefully) runs all Nintendo 64 ROMs flawlessly.

 

[pandamoan]

Thank you, ShadowPrince and Lillymon.

I've been getting bored lately at nights, so I decided to start a low-level Nintendo 64 emulator. Being the open source advocate that I am, I was wondering if I could contribute to an existing LLE project, but I can see now that one does not exist.

I know that the end result will not be very fast (or even playable), but I would like to develop it for pure academic reasons. The project will be a great learning experience for me, and when our hardware has advanced sufficiently then everyone can appreciate an emulator that (hopefully) runs all Nintendo 64 ROMs flawlessly.

sounds like a good, fun plan.

good luck!

jamie

 

[nephalim]

I see a major problem with your plan: the emulator would be too slow to test on your machine, and thus making debugging impossible, and thus making accurate emulation impossible.
If you could find some way to be able to accurately debug the thing (having other people bug testing in the later stages is essential too,) then all the power too you. If not, I don't think you'll be able to create what you want, and it would be impossibly dissapointing. If you still want to do it, though, just for fun and education - knock yourself out! Good luck in any case.

 

[Azimer]

I see another problem. The RDP's internal functionality is largely undocumented. No one is completely sure what all the RDP commands do. No one is completely sure what all the RSP ops do 100% accurately. They are both custom and not for public consumption.

 

[dcook32p]

Reverse Engineering Group?

I see a major problem with your plan: the emulator would be too slow to test on your machine, and thus making debugging impossible, and thus making accurate emulation impossible.

I fail to see your point. A program doesn't necessarily need to run in real-time for debugging purposes. That's the whole point behind breakpoints, exception handling, step execution, etc.

The RDP's internal functionality is largely undocumented.

Is there a group dedicated to reverse engineering this hardware?

I appreciate everyone's feedback, and I look forward to providing a design document for peer review!

 

[Doomulation]

I fail to see your point. A program doesn't necessarily need to run in real-time for debugging purposes. That's the whole point behind breakpoints, exception handling, step execution, etc.

He's referring to that it would take forever to get to a point where the error occours and break to debug the code. But it is still possible, though.