What's new

Announcement: Cycle-accurate N64 development underway.

OP
MarathonMan

MarathonMan

Emulator Developer
an lle recompiler is not impossible at the end of all this.

Care to explain your thoughts a little further on this one?

I thought a recompiler core was out of the question due to the fact that you could have instances where, on one block of code, you have cache misses, whereas in another, have hits. I suppose you add x86 instructions to take that into account as well, but the gains aren't going to be as large as non-CE emulators.

I've actually been thinking about ways to possible multithread or add some compiler support way down at the end of the road.

I was almost thinking something along the lines of ROB entries, but in software. Doing this would enable me to perform speculative execution on each core and not synchronize on every cycle, as this has proven to be prohibitively expensive. If I end up having to toss out a few entries here and there, it's no big deal because there would be so much more processing power at my expense. I've writing the simulator in such a way that I can augment it with statistics to determine exactly how much communication occurs between the cores to see how plausible this idea is.

But I'm getting WAAAY ahead of myself at the moment. For now, I'm just working on getting the core implemented. :D
 
OP
MarathonMan

MarathonMan

Emulator Developer
I wonder if the undocumented DCT RSP opcodes will be added.

Again, way down at the end of the road, I might look into buying an Indy with a u64 board if it's not going to cost my heart and soul. There's simply not enough information out there to make a fully CE RSP core right now.
 
OP
MarathonMan

MarathonMan

Emulator Developer
Another bump:
Carts are booting. Tested two carts -- CIC-NUS-6102 (Super Mario 64) and CIC-NUS-6105 (Zelda: OOT). As long as the correct seed is placed in PIF RAM before the IPL2 gets control, all checks pass and the actual game code starts executing. :cool:

On to emulating another handful of instructions and possibly some basic video (within the next few weeks? No idea how long this is going to take...).
 
Last edited:

Zuzma

New member
Again, way down at the end of the road, I might look into buying an Indy with a u64 board if it's not going to cost my heart and soul. There's simply not enough information out there to make a fully CE RSP core right now.

You shouldn't have much trouble getting an indy and a U64 board though you'll probably end up spending over 350 bucks easy. If they for some reason don't have the software just ask someone who already owns one to copy it for you ( I think it's on about 8 CD's). They'd probably be more then nice enough to do it. Not sure why you'd need it for developing an emulator though. Wouldn't something like a 64drive flashcart and a used N64 suffice?
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
You shouldn't have much trouble getting an indy and a U64 board though you'll probably end up spending over 350 bucks easy. If they for some reason don't have the software just ask someone who already owns one to copy it for you ( I think it's on about 8 CD's). They'd probably be more then nice enough to do it. Not sure why you'd need it for developing an emulator though. Wouldn't something like a 64drive flashcart and a used N64 suffice?

I would imagine that having a "real" developer platform gives you a little more flexibility. Failing that, it's certainly a time-saver (and it would be nice to have, for posterity's sake :p).

Anyways, weekly update:
Not a whole lot of progress this week. Worked out some bugs, added some new instructions, etc. I've implemented enough of the VR4300 core to the point where the ROMs appear to be sticking themselves in a busy loop and waiting for the RCP and friends to respond (at least, I think that is what's occuring). hopefully I can get around to implementing some of the RSP/RDP and really getting things going sometime soon.
 

Zuzma

New member
I would imagine that having a "real" developer platform gives you a little more flexibility. Failing that, it's certainly a time-saver (and it would be nice to have, for posterity's sake :p)

It would indeed be more flexible. I was just thinking more of the price point and the fact that you wouldn't be waiting around for a U64 board (waiting for a lower price that is). Thanks for the update too! It's really interesting to see the actual code progress. Good luck with emulating this beast of a console system!
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
Lots of information undercovered about the RSP... maybe the community is aware of this, maybe not, but here's what I've been able to confirm (using a developer platform and studying ucode):

The claim that the RSP is a "R4000-based" microprocessor is a little rough on the edges. The RSP, while is does belong to the R4000 series, is much more like the R4300i-based core. It, too, has a 5-stage pipeline and is one of the "less beefy" members of the R4000 series. The primary difference between the VR4300 core and the RSP is that the RSP has a vector co-processor.

The really neat thing, that I'm not sure well known about the RSP, is that it appears to be dual-issue. It'll actually execute two instructions per cycle (if possible): one scalar instruction, and one vector instruction. It also looks like the RSP will stall the pipeline if it detects hazards (which the VR4300 does not!)... but maybe too little sleep is throwing off my brain.

If that seemed like a bunch of jibberish, no worries. I suppose the conclusion of all of this is that a cycle accurate simulator, fully modeling both the VR4300 and RCP, is absolutely possible (with enough time!). Over the last few days, the architecture of the RSP has absolutely overwhelmed me -- I had no idea that it was this impressive. I'll have to rethink my current design and hack away for quite awhile. In terms of getting something running at full speed -- this is going to be quite the challenge. Modeling a dual-issue 32-bit scalar/128-bit vector pipeline is nothing short of a large challenge.

... but it does mean that we'll eventually have an emulator that 'just works' :)
 

DETOMINE

New member
I know it may sound funny, but every time I read you, I feel like I'm participating at a forbidden and crazy experiment. It's like you're playing with powerful and unknown forces.
I still don't understand what you're doing though.

edit : keep up the magic man, it's awesome!
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
Project isn't dead! :spam: Had a busy last couple weeks...

I have managed to implement a large portion of the RSP's cycle-accurate model. I finished the basic pipeline flow, execution unit, etc. I'm currently working on adding in delays for register hazards, pipeline bubbles, etc. and should hopefully have that finished by today. :) That'll leave me with the vector unit, and the RSP should be 90% complete.

The RSP hasn't difficult to implement at all compared to the VR4300, but it might be because I've been able to reuse so many components and there are a significantly reduced number of instructions in the RSP core. After I finish the RSP, I'll start running code through it to get an idea of how much of the RDP I need to implement based on the command lists and will hopefully get a few screenies out in a few months.

-M
 

didado

New member
Hoi!!

I <3 this project.. :D

I've been "spectating" "Emulation64" for more then 5 years now and its time for positive feedback on this project.

Because someone with this much coding knowledge must make something beautiful ;)

Like DETOMINE its the same magic for me.
Not everyone is "coding" smart alike.. (dunno if this english i type is correct lol) , although those terms like RSP's, VR4300 i always see come back.

I just hope someday (i know it takes time) "Conker bad fur day" and others will be smooth as butter with this new emu on Windows 8 and further.
Because "Project64" with the plugin "Glide64" is the only combination that works almost flawless right now..
And we need an alternative before this dies, but again these are my future thoughts :borg:.

Keep it up \:D/

Greetings
 
OP
MarathonMan

MarathonMan

Emulator Developer
I can't wait to see the first screen-shots :) .

I was wondering, does your project use some of the mame code?

Nope, since MAME wasn't designed to be cycle-accurate. I reference the code and use the built-in debugger as a resource, but I haven't actually used any substantial portion of the code (yet, anyways).
 

talker

New member
This is interesting to read! With all the info you deliver each time it sound like you've hit a milestone every time. I neither have any experience with building and coding an emulator, but by reading what you have done and what your thoughts are makes it somehow understandable for me.
I've seen things like R4300, rsp, and such metion before, but with no meaning behind it. I really like to follow this into the future and see what a 'cycle-accurate emulator' would be like!
 
OP
MarathonMan

MarathonMan

Emulator Developer
Thank you all for the kind words! It is very reassuring to know that the N64 scene isn't a total graveyard!
 

Nintendo Maniac

New member
Just an FYI, you may or may not want to consider a blog for development notes and/or any actual project releases to keep everything in one organized location. Currently this isn't an issue with only 4 pages, but it's just something you might want to keep in mind for the future.

BTW, I too am very glad to see the N64 isn't a total graveyard - it certainly seemed like it for the last 5 or so years. I mean, when Wii emulation is more accurate than N64 emulation, then you know something new needs to be done. Heck, for some N64 games it's more accurate to run the virtual console version in Dolphin than it is to play via an N64 emulator!
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
Just an FYI, you may or may not want to consider a blog for development notes and/or any actual project releases to keep everything in one organized location. Currently this isn't an issue with only 4 pages, but it's just something you might want to keep in mind for the future.

BTW, I too am very glad to see the N64 isn't a total graveyard - it certainly seemed like it for the last 5 or so years. I mean, when Wii emulation is more accurate than N64 emulation, then you know something new needs to be done. Heck, for some N64 games it's more accurate to run the virtual console version in Dolphin than it is to play via an N64 emulator!

The only issue with a blog is that it's not community-centric, not as searchable, etc. Once I get something bigger, I'll hopefully get the mods to make thread group for me so I can better organize things that way.

AFAIK, the reason why N64 emulation isn't as high-calibre is because large parts of the RCP are not fully understood (due to the fact that it was kept such a secret).

Minor status update -- did a little overhauling of the RSP core. I probably won't get a whole lot done in the coming weeks due to a lot of work-related deadlines approaching. Just wish I had more time to work on the project!
 

Nintendo Maniac

New member
I need to ask though, with such an accurate emulator, would this cause enhancements like rendering in high-res or N64 overclocking (for smooth framerates in various games) to not be possible? Because honestly, I think most of us don't want to view polygons and textures that look like a low-res jagged mess on any display newer than a CRT SDTV... Heck, even on my SDTV the 480i virtual console version of Majora's Mask looked much cleaner than the 240p N64 version.
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
I need to ask though, with such an accurate emulator, would this cause enhancements like rendering in high-res or N64 overclocking (for smooth framerates in various games) to not be possible? Because honestly, I think most of us don't want to view polygons and textures that look like a low-res jagged mess on any display newer than a CRT SDTV... Heck, even on my SDTV the 480i virtual console version of Majora's Mask looked much cleaner than the 240p N64 version.

Overclocking is extremely, extremely easy to implement (I just call a cycle() function periodically; if call it more often and the system is effectively overclocked). However, running at full speed is already taxing as it is on modern computers -- try bsnes. I doubt you'll be able to push the emulator much further unless you're highly overclocked, if at all, for awhile.

Everything will be standard resolution at first (focusing on accuracy). I'll consider visual optimizations and the like at a much later time and provide options to switch them on for those that desire to do so.
 

Nintendo Maniac

New member
Ok, on a related note then, what about the N64's integrated "hi-res" 640x480 mode? Games like World Driver Championship and Perfect Dark have such a mode as an in-game option, so proper emulation would require this function to emulated anyway. Would it not be a stretch to suggest that such a thing could be forced to run at all times as stop-gap to polygonal resolution independence?
 
Last edited:

Top