Emulating The R4300i

[yosh64]

hey

Well I've recently been looking into making an N64 emulator, and just started on an R4300i interpreter.

Anyhows I wouldn't expect much just yet, this is the first time I've done anything with a MIPS processor, and the same goes for Binary Translation and Dynamic Recompilation. So I have no idea how long this will take me, nor how things will turn out.

For now I'd be glad to hear any advise on how to go about timing on such a processor, I was told that it's largely impossible to implement cycle-exact emulation of the MIPS chips, that is because of the cache behaviour and pipelining. So if anyone has any advise on how to go about timing then that would be great.

This is the first time I've looked into Binary Translation, and I seem to be more interested in static recompilation, although it's probably better to go with dynamic. Hmm, I think corn (n64 emulator) used static recompilation, and I think it was meant to be one of the fastest n64 emulators. I've found a few docs now about such things, but I was interested in the 1964 recompilation pdf, which I can't seem to find anywhere? if anyone has it then it would be great if you could send it my way or something.

I'm very interested to hear how folks who have made dynamic recompilers for whatever emulators, such as the PSX , go about dynamic recompilation and what not, which I would assume they would use.

BTW, I also think it would be quite possible to port an existing n64 emu, such as mupen64plus, you would just have to update the recompiler to support ARM, which is probably quite a bit of work. But yea, I prefer to start from scratch, the N64 is one of my favourite systems of all time, if not the .

Hmm, I was thinking that zodttd could probably put together an N64 emu much quicker than me, that is if they had the time. It's just that the PSX also uses a MIPS processor, and I would assume they use dynamic recompilation in their PSX emulator. Hmm, although I heard that the hardest thing about the N64 to emulate is the RCP, that is the graphics and sound processor, so I dunno.

Anyhows I probably prefer to make the thing than use it, I don't even have any N64 games, but there are some cool demos and such, hehe. Hmm, actually I got Zelda Ocarina of Time and WaveRace64 on the Wii . But yea, I would be happy just to emulate the CPU, let alone the video and trying to get commercial games working.

That is enough rambling, so if anyone has any advise, information or whatever then please let me know.

cyas

 

[cb88]

yosh64 if you find anylinks to old webpages
(that have been deleted) often you can find backups from archive.org


"new" 1964 website http://1964emu.emulation64.com/contact.htm contact info

 

[Squidge]

I was interested in the 1964 recompilation pdf, which I can't seem to find anywhere?
http://1964emu.emulation64.com/download/1964_Recompiler.zip

Thanks, Google

 

[flatmush]

For now I'd be glad to hear any advise on how to go about timing on such a processor, I was told that it's largely impossible to implement cycle-exact emulation of the MIPS chips, that is because of the cache behaviour and pipelining. So if anyone has any advise on how to go about timing then that would be great.

Why would you want cycle accurate timing? All games (or almost all games) should use the processors built in timer (real time clock) so and cycle accuracy is not possible on a fast emulator normally.

 

[yosh64]

hey

Thanks Squidge , I had looked all over the place, even tried alltheweb.com, and I found references to it (in PDF form) from various other websites, and had tried the wayback machine.

flatmush: This came about after I asked about the instruction cycles for the R4300i on #emudev EFNET, where I was told as I have said earlier, and so I'm actually not interested in cycle-exact timing, but rather anything that is acceptable. Anyhows I didn't realise there was a realtime clock, so thanks for pointing this out. I was actually advised just to use educated guestimates for timing by various folks on #emudev , so what I'm interested in is how to determine the best guestimates possible, or how others went about such things in their own emus, and any other relavent information. But yea, I have come from programming gameboy and nes emus, where information such as the cycles for each instruction is available, where exact timing was very important.

cyas

 

[yonder711]

Another good bit of code to look at is this
http://www.emutalk.net/showthread.php?t=23441
Its U64 (killer instinct emulator) for Linux w/ SDL.
The cpu core code for this is a modified R4300 as KI was a 4600.

I had hoped to attempt to get this running myself but with bits of x86 assembler it may be beyond me to fix it. Either way you can use this as some reference as to a MIPS R4X00 cpu implimentaiton. But im sure looking at Project64, 1964 or deadalus would be just as good. Although i may have to make a new topic to see who wants to take up the cause as Killer instinct on Pandy would moisten me.

PS. This is the best info i have seen specific to R4300i
http://www.datasheetarchive.com/pdf-datash...pdf-8/23798.pdf

 

[DesktopMan]

I wouldn't mind working on adding ARM to an existing recompiler, consider me interested. Would be best to have an up and running in interpreter mode first though, at least the cpu and sound so you know stuff is working. Mupen64 is a good choice as there's a GUI less version.

I'm still researching Jazelle, might be something useful there too. Update: they mention Java, Python, .net "and other" acceleration. Might be chip specific thus not configurable / usable for us. Docs are hard to come by though.

Graphics might be more work for OpenGL ES but I'm a cpu guy not a gfx guy.

 

[ldesnogu]

I'm still researching Jazelle, might be something useful there too. Update: they mention Java, Python, .net "and other" acceleration. Might be chip specific thus not configurable / usable for us. Docs are hard to come by though.

You won't get any documentation about Jazelle.

The main point to note is that there are two variants of Jazelle:

- Jazelle DBX that implements many JVM opcodes in HW
- Jazelle RCT that adds some extensions of ARM instruction sets that help making more efficient VM

Cortex-A8 only implements Jazelle RCT.

 

[DesktopMan]

You won't get any documentation about Jazelle.

The main point to note is that there are two variants of Jazelle:

- Jazelle DBX that implements many JVM opcodes in HW
- Jazelle RCT that adds some extensions of ARM instruction sets that help making more efficient VM

Cortex-A8 only implements Jazelle RCT.

http://www.arm.com/pdfs/JazelleRCTWhitePaper_final1-0_.pdf

This doc wasn't too bad (had to look around) but doesn't seem all that useful for this. So scratch that.

Thumb-2 is interesting, should probably agree on a standard before any work starts. Might depend on target tool chain also.

 

[Zoxc]

I might be interested in helping. I got bored yesterday and started on a R4300i interpreter =P

Since it doesn't have seperate 32 bit instructions, I'd like to know how the emulator(s) figure out when to use 64 bit operations?

I'm also wondering how much NEON could be used for 64bit re-compilation. Is there a neat list of NEON instructions published somewhere?

 

[shiny`]

A year or so ago I started looking at a R4300i/RCP -> IA64 recompiler. I found this zip (I forget where), if you dig around in the docs directory there is LOTS of useful stuff.
I've upped it here:
http://ado.is-a-geek.net/~tom/n64demo.zip

 

[Zoxc]

The zip seems to lack a docs folder

Anyway I put my tiny interpreter on github
http://github.com/Zoxc/nano64/tree/master

 

[Exophase]

Squidge found the 1964 doc. I haven't seen that on the internet in years (and have looked before).

Anyhow, MIPS is one of the easiest core ISAs to emulate, and easy to emulate means easier to dynarec than other platforms. Which is why most of the PS1 and N64 emulators ever made have one. Bear in mind, Corn isn't a real static recompiler - the guy was somewhat munging terms (by his reasoning gpSP is a static recompiler too). But static recompilation doesn't actually offer substantial benefits and it's more or less impossible, especially for a platform that routinely loads/runs/modifies code in RAM (N64 is one of them).

You can do cycle accurate timing for a platform like this, it'd just be substantially slower. Archs with much more complex pipelines have reasonably accurate emulators - if you're shooting for 100% exact accuracy then you will have your work cut out for you, but it's not too hard to come close. It's just not something that'd be worthwhile for you to do.

I personally wouldn't feel good doing an N64 emulator, because the performance bar has been set for emulators that will probably never emulate certain games because of a lot of (roughly) software specific techniques.

 

[yosh64]

hey

shiny`, I think you might be mistaken that n64demo.zip with something else, I actually already had that and I forget where I got it, but I remember it was the source code of some n64demo, hehe.

Zoxc, thanks for posting ya code, I'll check it out soon.

Exophase, nice to know, I don't think I'll worry to much about accurate timing.

Anyhows I haven't been working on it the last few days or so, been doing revision for exams. I was a bit baffled trying to figure out the memory map, I think it maps over the space of a virtual 4GB??? no, I don't mean 4MB!!! and although I see from n64ops11 docs where what goes where (at least I think this is what it says), I don't know how big each section is. So I'm quite confused about this, and any info would be great.

BTW, I've just updated my website recently, and now working on getting my old wiki engine up and running on it so I can document how I go about things with the N64 emulator, and some other things . But yea, I don't feel like hijacking the Pandora wiki or any others for my personal docs or whatever, hehe.

Thanks

Zoxc
Maybe we can work together in the sense of working everything out, rather than code wise. I will hopefully have my wiki up soon and would welcome anyone to add to it about what they know about emulating the N64 and such. BTW, I found some little conflicts in the n64ops11 docs for the CPU instructions, compared to those in the MIPS IV Instruction Set PDF.

cyas

 

[EdCa22]

Don't know if it's useful but I've always had a soft spot for SGIs and I speak to this guy Ian from SGI depo occasionally and I noticed he's got a page on his website about N64 hardware info: http://www.sgidepot.co.uk/n64.html

Maybe you can make a simple SGI emu while you're at it? (God knows why we'd want to run IRIX..but anyway!)

 

[DesktopMan]

There's not really much of a point starting an interpreter from scratch. Take an existing emu that has a recompiler, and re-implement all the opcodes for ARM. That way you don't have to care about a lot of things as it's already handled. Otherwise you're looking at a year or more of development...

 

[yosh64]

hey

Ye, the thing is I like to make things from scratch, making the thing is the fun part for me, and seeing something first appear on screen, or the first time ya execute an instruction is darn cool . I'd rather take my time with my own than try and figure out some others code, especially when the programming style is far different from my own. I'd rather start from scratch, and do it how I think it should be done in my own mind .

I think it can take alot of time to properly figure out all the workings of an existing emulator before being able to implement something like adding support for recompiling for an ARM processor.

Another thing is that I'm now quite interested in binary translation, and I think making an emulator is a darn nice way to learn about such things . Hmm, and in the process of making it from scratch I think I would pick up alot more and be better able to understand and improve or optimise things for the Pandora or whatever else.

Personally, I don't think it would take a year to program the CPU and implement dynamic recompilation, I think far less (I think ya meant the entire emulator, which is more reasonable, but I think it could be done quicker ). Hmm, I guess it depends on how much time ya spend on the thing, hehe. Remember, I think there is alot more documentation out there now since N64 emulators first started being made .

Anyhows I think I've given ya enough reasons why I think there are alot of points as to start an interpreter from scratch, hehe. On another note, if your just looking to get an N64 emulator going on the Pandora, and don't wanna get too far into things or whatever then it might be wise to try port an existing emulator.

BTW, I do agree that it would probably take far less time to get an N64 emulator going on the Pandora by porting an existing one, that is with graphics and sound and whatever else. Hmm, I have looked at the sourcecode of a few existing emulators, and I would also consider porting one, but I'd also like to make my own also.

EdCa22, thanks for the link, I've actually come across that website before .

cyas

 

[Exophase]

There's not really much of a point starting an interpreter from scratch. Take an existing emu that has a recompiler, and re-implement all the opcodes for ARM. That way you don't have to care about a lot of things as it's already handled. Otherwise you're looking at a year or more of development...

I don't entirely agree, although a lot of it is for strange personal reasons.

Fortunately, in the case of N64 emulators, a lot of attention has been paid to making them speedy.

And you can do a reasonable complicated emulator, even an N64 emulator, in well under a year... if you're good enough

 

[sindbad]

It is very interesting indeed to make something from scratch, but unless there is the obvious potential for inovation, I usually don't bother.

However, I do plan to write extend the PyPy gameboy emulator (written in RPython) to take advantage of PyPy's partial evaluation and maybe even JIT. If this works, it may open the door for very easy to read/write and still quite efficient emulators.

 

[yosh64]

hey

I just wanted to let yas know that I have not now (edit: I was a bit tired, hehe) got my little wiki up, and hope anyone in the know might contribute to it, see Wiki Index, or specially the Nintendo 64 Emulator Development Notes wiki.

Hmm, it took me a few days, I recoded alot of my wiki engine and such, also took pretty much all today getting the CSS up to scratch and things to appear correctly in Internet Explorer, and also for HTML 4 strict doctype .

Anyhows it's not exactly the same as the MediaWiki (used by wikipedia.org), and you can quickly see how things are done in the New Wiki Test wiki.

Also, I have now done all my exams for the semester, and have quite a bit more time to work on things .

cyas