gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS Misc > Technical discussion on N64 emulation

#137828 - simonjhall - Thu Aug 16, 2007 12:01 pm

To cut the story short, the idea of N64 emulation on the DS has been gnawing away at me for many months now and I’d just like to sound out some ideas with you guys, basically so you can talk me out of it! I really would like to write a dynamically-recompiling emulator though, since the last emulator I wrote was for work and the focus was not on speed but on ease-of-development (eg it allowed you to run emulated code backwards etc).

Anyway, my concerns re: N64 emulation on the DS and some thoughts
1) There’s a fat MHz deficit. Emulating a cheap 93MHz processor with a cheap 66MHz part from a different architecture is never going to yield full-speed emulation even if there was no overheard incurred by the emulation (ie a 1:1 mapping from MIPS to ARM instructions and no cost associated with the translation). I do realise that there’s a second processor in the DS but you can’t just push them together and treat them as a single 99MHz processor!

2) There’s a floating-point unit in the N64, and there’s no such thing in the DS. Floating-point emulation with integers isn’t going to give good speed.

3) The N64 has 250MHz DDR memory, accessed over an 8-bit bus. That sounds like 500 MB/s to me and I’ve never got bandwidth like that out of the DS! However I doubt there are memory accesses every clock cycle and I’m sure a good chunk of that would be taken by rendering (eg framebuffer, texture reads etc) and that wouldn’t be so necessary on the DS due to the 3D hardware. Also if the PSP can emulate an N64 then I’m not so worried about the memory bandwidth being such an issue.

4) I seem to remember that the MIPS architecture sports 32 registers (or is it 16?), if so there’s definitely no chance of doing a simple translation of MIPS to ARM since there are only 16 (really 15 + $pc) registers available in ARM mode. This would mean that some kind of register allocation system would be needed (more overhead) and since the N64’s main CPU is a 64-bit processor I’d guess that its registers are 64-bits wide too. Since ARM registers are 32-bits wide two registers would be needed to represent a since N64 register in a recompiling system. Plus additional instructions (and temporary registers too?) would be needed to perform these 64-bit calculations and stitch the results together. More overhead.

5) I don’t see the amount of memory available being a problem, assuming the use of a slot-2 card. It’s a shame that the 4MB of main memory can’t fit wholly within the DS internal memory (well you technically could…) but I suppose parts of the memory could be switched in an out.

6) The RCP is an interesting one, since I’ve read that it’s a vector processor and emulating this would be a right pain on the DS. However if it’s used just for graphics then hopefully it could just be handle by the 2D/3D hardware.

7) There’s the legal angle – I’m scared by what happened with UltraHLE and if that were to happen again there would be no chance I’d even consider writing/releasing it.

But…it does sound like a fun project.
Thoughts?

PS: non-techy people could we refrain from “OMG N64 would be sooooo cool! Please write it! I’ll love you!”
_________________
Big thanks to everyone who donated for Quake2

#137829 - kusma - Thu Aug 16, 2007 12:06 pm

It sounds extremely tiresome :)

#137841 - Ant6n - Thu Aug 16, 2007 3:41 pm

i've been thinking about the same thing too. dynamic recompilation might be the way to go. another way might be a mix of dynamic and static recompilation. emm, something like this: one plays a rom on a magic n64 emulator on pc, after a couple of hours of playing that emulator probably visited most of the code. while playing, the pc emulator recompiles all encountered code to mips. in the end the ds side emulator basicly runs that code, but the moment it jumps to something that wasn't recompiled it either emulates it or recompiles it on the machine. that way one can use all sorts of optimization techniques, that one wouldn't have the time for on the ds.
2) who needs exact floating point emulation, anyway. emulating the basic idea of floating point with less accuracy and fewer of this nan,infinity,denormalized etc stuff might work. if there's dynamic recompilation, it might be possible to see what is actually used
4) yeah, 32 regs. and yeah wiki says its 64big (gnarg)
5) well, one would have all that shared ram and vram to work with, but where would all the recompiled code live? does the n64 run its code from cartridge?

#137850 - simonjhall - Thu Aug 16, 2007 6:36 pm

Ant6n wrote:
one plays a rom on a magic n64 emulator on pc, after a couple of hours of playing that emulator probably visited most of the code. while playing, the pc emulator recompiles all encountered code to mips.
Yeah I was thinking of something like that too. That'd hide some of the cost of translating the code, but I'd imagine it could be quite hard in practice due to self-modifying code etc. Could be worth a shot..
Quote:
4) yeah, 32 regs. and yeah wiki says its 64big (gnarg)
MIPS is little-endian, right? If so, that's one less thing to worry about!
Quote:
5) well, one would have all that shared ram and vram to work with, but where would all the recompiled code live? does the n64 run its code from cartridge?
I'd love to see the N64 equivalent of gbatek to find this stuff out! I think the cartridge is mapped into the address space, but I don't know if the main CPU can see it. I doubt code is run from ROM tbh, but since the RAM is high-latency (but high-bandwidth) that doesn't seem too good a place to put code either. Maybe there's some on-chip/fast RAM or something?

Quote:
It sounds extremely tiresome :)
This is the curse we, the Nation of Programmers are given when we are born :-p
I've seriously thought that it'd be worth losing my memory in order to forget how to program...
_________________
Big thanks to everyone who donated for Quake2

#137861 - Dood77 - Thu Aug 16, 2007 8:31 pm

simonjhall wrote:
non-techy people could we refrain from ?OMG N64 would be sooooo cool! Please write it! I?ll love you!?


Something tells me you could of picked another word that would fit better than non-techy... :P

I think ant6n's idea sounds cool, even though I'm pretty sure I hardly have an idea of what he's talking about...

I'm probably wrong on many levels here... but if you ran a '64 emulator with a dynamic core on the PC, and ran that under some kind of x86 emulator for ARM, and then captured the code produced...? "OMG some1 should make a n64 to ds convreter!!1"

And as for the legal issues, never call it an emulator, just a debugger, and when it comes time to actually render stuff on the screen, just use some fancy programming to render it, but not actually show it. Like overlay it with a bunch of hex code for debugging. It might also keep stupid people emailing you asking to increase the framerate :)

EDIT: Oh, and I almost forgot. It seems like this should be possible with HLE, if each game would have to have its own programmed HLE elements. (Like, one game requires NDS-style 2D tiling, but the other needs... something else, I dunno :P)
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

#137864 - Ant6n - Thu Aug 16, 2007 8:36 pm

I don't know how much self-modifying code one would expect in a console game, maybe not too much. One would need a pretty good system to be able to take plain memory and differentiate between code (which is potentially already translated), and plain data, anyway; one could double check writes/reads with some array that denotes i.e. for every 8bytes what the type of data is.
If a pc emulator 'visits' most executed code, then one could also start making assumptions about the data being processed, for example the maximum value of arguments/registers (and process them in 32bit), etc
(this really is 'starter' talk)
also if one is watching emulation, then one could watch which registers are being used how, and build some general hle around it..

it's always hard to find a gbatek equivalent for other devices; the gba is one of the best documented devices, which makes it much more fun
oh yeah, according to gbatek somehwere, if i remember right, the arm9 can be run in both endian formats

#137869 - ps2aich - Thu Aug 16, 2007 9:13 pm

This blog may be interesting.

It talks much about dynarec in the N64 Emulator Daedalus (on PSP).

It's for sure a technically challenging task ...