Announcement: Cycle-accurate N64 development underway.

[Nintendo Maniac]

I won't budge on dev-controlled plugins, sorry. One of the thing that I dislike about modular plugins is that they encourage the community to fork off each other's work. This is good for projects with large developer bases, but not something like N64 emulation given how rare it is to find N64 emulator developers anymore. All my plugins will focus entirely on accuracy first and foremost. That being said, I'm also a performance nut and have been playing some tricks that I haven't seen anyone else in the community hasn't done yet, so hopefully performance isn't a concern. If it is, well, sorry...! Maybe I'll be able to do something about it down the road, but I'm striving for accuracy at the forefront because that's what I set out to do.

Well I wasn't so much worried about performance as I was about feature-set, such as in Dolphin where the audio plays at 100% speed even if the game is at 150% speed. Performance can be made-up in time with newer hardware, but features are gone forever.

Probably won't be too hard; don't see why I couldn't have compatibility with other save states.

Err, I was referring to actual game save data, not save states. As I stated with my Wii64 example, just because the file extensions are the same doesn't mean they're compatible.

 

[Zuzma]

bsnes is a Cycle-Accurate Emulator (like this one), not a Low Level Emulator. They are 2 different things, Low Level Emulation is basically the in-between accuracy of High Level Emulation (Like PJ64) and Cycle-Accurate Emulation (like this emulator).

I thought low level just meant the software tries to replicate more how the real system does it and cycle accurate has to do with the CPU emulator timing. If that's the case then bsnes would be both of those.

 

[Fanatic 64]

I thought low level just meant the software tries to replicate more how the real system does it and cycle accurate has to do with the CPU emulator timing. If that's the case then bsnes would be both of those.

Yeah pretty much that. That's why I say it's the in-between accuracy, because Cycle-Accuracy replicates the hardware timing while Low Level Emulation doesn't, but it is still more accurate than High Level Emulation.

Well I wasn't so much worried about performance as I was about feature-set, such as in Dolphin where the audio plays at 100% speed even if the game is at 150% speed. Performance can be made-up in time with newer hardware, but features are gone forever.

Well, I suppose if you know how to code, and the emulator's source code is released, you could readd the plugin/feature you want, right?

 

[Nintendo Maniac]

Well, I suppose if you know how to code

yeah, about that... coding has always been my weak point. I can remove a CPU IHS and make XP run on 256MB of RAM with no pagefile without having a program crash, but give me a line of code and I'll be lost.

(I can however read some HTML along with do some basic command line stuff, and can make simple .BAT files )

 

[Zuzma]

Yeah pretty much that. That's why I say it's the in-between accuracy, because Cycle-Accuracy replicates the hardware timing while Low Level Emulation doesn't, but it is still more accurate than High Level Emulation.

I agree with that. Pure HLE is an interesting way to get games working, but in the long run it can't run all the software on the system in an emulated enviroment. A combination of HLE and LLE or pure LLE is nice too though you'd still be stuck with some odd bugs in games. Cycle accuracy is really the final step as I see it and can be better, but isn't always feasible either.

Edit: This is how I see it as a user not a programmer or an engineer. I honestly wish I knew more about it, but I'm an expert at wasting my own time.

 

[Rich_T]

I too want to add my voice in approval of this thread, I very much hope we see a working build.

This would no doubt bring much need life back into the scene.

Keep up the great work!

 

[squall_leonhart]

Cycle accurate is low level, but not all low level is cycle accurate.

Please stop attempting to create a new tier of emulation.

 

[didado]

squall.. so no one must try it because your brains says its useless.. Or you say he's saying things that aren't possible?

 

[Nintendo Maniac]

I think he is saying that "cycle accurate" is a tier WITHIN "low level emulation" and therefore cannot be viewed as separate tier unto itself.

 

[zoinkity]

Okay, if we really want to get nitpicky about this, it's a kind of low-level emulation.
Typically when we think low-level we think of something like Mame's amazing hardware emulation. They emulate the behaviour of each of the chips used in a given arcade game. This is low-level hardware emulation.
Technically, you don't have to be cycle accurate when doing this kind of emulation, but chances are you will be. The reason has to do with how your software must interpret the number of cycles each emulated opcode/process should take and count it itself. If you're off, don't account for something, or just don't bother to keep track then it isn't cycle-accurate, since you aren't accurately tracking cycles.

Then there's the flip side. It is possible to be cycle-accurate without being hardware accurate. For a working case of this look at old Speccy emulators, from back in the snapshot days. They weren't running original media, weren't emulating quirks in the CPU or external hardware, half of the tech stuff wasn't even worked out, but they did keep accurate track of cycles (in most cases ;*)). Why? Mainly because the things actually needed to know the current cycle count.

So, what would be the point of a theoretical HLE cycle-accurate N64 emu? Well, how many cycles does each of these eat:
1) ADDIU R0,R0,0000; ADDIU R0,R0,0000; ADDIU R0,R0,0000
2) SLL R0,R0,0x0; SLL R0,R0,0x0; SLL R0,R0,0x0
3) OR R0,R0,R0; OR R0,R0,R0; OR R0,R0,R0
Might not seem pertinent to most users, but it was very pertinent to the developers of the Quagmire engine. Different types of opcode combinations can be executed simultaneously (here meaning within the same cycle), leading to final optimization. They were very careful what kinds of NOPs they put where. To be fair, there's more at work here than mere cycle counts, but anything leading in that direction would greatly assist new developers.

 

[Zuzma]

Cycle accurate is low level, but not all low level is cycle accurate.

Please stop attempting to create a new tier of emulation.

I know that squall. I was trying to be nice. But yeah I guess I should have just corrected it rather then do that. It was a dumb thing to do.

 

[Rich_T]

Can I ask, what tools and software are you using to go about this task,
I'm genuinely interested to understand more and want to know how an ideal, i.e. 'make a N64 cycle-accurate emu' actually turns into something usable.

 

[MarathonMan]

Can I ask, what tools and software are you using to go about this task,
I'm genuinely interested to understand more and want to know how an ideal, i.e. 'make a N64 cycle-accurate emu' actually turns into something usable.

Sure, a C compiler (gcc, to be exact). That's it.

Oh, and a LOT of documentation that I've gathered.

Sorry I couldn't be more specific/have details. Shoot any other questions you may have, though.

 

[Fanatic 64]

You know, I don't want to sound impatient at all but I just wonder, how likely is that this thing reaches mature development stages before 2020?

Again, just wondering :saint:

 

[Nintendo Maniac]

TBH, assuming you have the necessary documentation, I would think a LLE emulator could actually reach usable status earlier than an HLE emulator for the same system. The idea here is that LLE code, in theory, can have things "just work".

...of course, I could be way off on that assessment since I can't actually code myself. >_>

 

[DETOMINE]

You know, I don't want to sound impatient

You totally sound impatient :teehee: .

 

[MarathonMan]

You know, I don't want to sound impatient at all but I just wonder, how likely is that this thing reaches mature development stages before 2020?

Again, just wondering :saint:

Heh, no offense taken. I honestly don't get a lot of time to work on it, but I'm guessing it'll take _at least_ a year at the rate things are progressing now. My job and degree always come first, and don't seem to leave me with a lot of time as of late.

 

[Fanatic 64]

You totally sound impatient :teehee: .

I was just curious. The attack wasn't necessary.

 

[Nintendo Maniac]

I just had a thought. Since this doesn't have a GUI let alone an actual true full-on emulation core yet, would it not be optimal to leverage RetroArch so that development can focus mainly on actual cycle accuracy emulation?

 

[Fanatic 64]

I just had a thought. Since this doesn't have a GUI let alone an actual true full-on emulation core yet, would it not be optimal to leverage RetroArch so that development can focus mainly on actual cycle accuracy emulation?

http://themaister.net/retroarch.html

I suppose it depends on wherever MarathonMan wants to give his work to the RetroArch guys, or if he wants to make his own emulator (based on his comments I think he wants the 2nd option, but you never know).