forums.ps2dev.org

is there any one developing a n64 emu ?
maybe i can help ,just give me the src and any helpful stuff.

Hi fakiro,

One n64 emu source : http://1964emu.emulation64.com/

helpful stuff : http://ps2dev.org/kb.x?T=993

Good luck, and keep us informed of you progress !

thanks man,so i have to make appropriate modifications to that 1964 emu
to make run on the ps2, right?
if someone has already tried,please tell me ,it seems to be a hard work
since no body managed to release a n64 emu on ps2 despite there are one on game cube and on x-box.
people say that ps2 is weak but i do believe it can do it with a good programmation.

I dont think anyone has bothered to do it, and I do beleive the reason is that nobody has cared to do it rather than it being a supposedly difficult task.

fakiro wrote: people say that ps2 is weak but i do believe it can do it with a good programmation.

It can be done, there are a lot of hurdles in the way but it can be done. No one has cared enough to put that much effort into it though.
Even if I wanted to put that much effort into it, I have not yet found a good enough open soure n64 emu core that is open source to start from.

Seeing as the N64 uses the same CPU (generally speaking) as the PS2 (a 64bit MIPS CPU), you're better off to make the CPU core copy most of the instructions straight, only replacing those instructions that need it - namely load/store instructions, flow control instructions, and system instructions. It would be similar to how PC virtual environments work.

I've intended to look into this myself, but there are other things (easier things) I wish to work on first, like a conversion of Doomsday. I am willing to help provide advice on it. I've done work on emulators on other platforms (Mac and PowerMac emu on Amiga, Mac emu on PC, PC emu on Amiga and PowerMac). Many of the principles used are the same, even if the machines are completely different.

Er, the CPU used in the N64 and the R5900 are like apples and oranges when it comes to emulation. One of the more obvious differences (besides the coprocessors which are nothing alike) is that COP1 on the N64 supports hardware doubles. Another blaring difference is that N64 is hardwired to the big endian data format while the PS2 is hardwired to little endian (I say hardwired because on some MIPS systems, you can switch endianess in software, on these two, they are set in hardware and can't be changed).

I don't think you could get away with running N64 code by just changing a few instructions here and there - you would actually have to reverse the instruction (because the format is different in RAM) and then try to execute it - so you're still stuck with dynamic recompilation. But then maybe you could reverse the endianess after you've loaded the ROM (if it even fits) into PS2 RAM. Man, that's nasty :P.

J.F. wrote:Seeing as the N64 uses the same CPU (generally speaking) as the PS2 (a 64bit MIPS CPU), you're better off to make the CPU core copy most of the instructions straight, only replacing those instructions that need it - namely load/store instructions, flow control instructions, and system instructions. It would be similar to how PC virtual environments work.

It's called virtualization, and would require starting more or less from scratch, which is a lot of work to say the least ;) Saying they are the "same" CPU isn't quite correct, among other things the PS2 uses a mips4 instruction set and n64 uses mips3 (IIRC, might have those wrongs...), but thankfully mips4 contains everything mips3 does, so virtualization should be possible (although TBH I haven't looked into the virtualization path much because of the work involved.)

The EE is only partially MIPS IV compliant. It is technically a MIPS III chip, with some extra MIPS IV instructions, and a bunch of special EE instructions.

But, like mrbown said, the endian format is going to be a big roadblock in doing any straight processing without virtualization.

Regards,
Neovanglist

Woah, somehow mrbrown's post didn't show up for me, even though I posted 10min after him apparently...

mrbrown wrote:Er, the CPU used in the N64 and the R5900 are like apples and oranges when it comes to emulation. One of the more obvious differences (besides the coprocessors which are nothing alike) is that COP1 on the N64 supports hardware doubles. Another blaring difference is that N64 is hardwired to the big endian data format while the PS2 is hardwired to little endian (I say hardwired because on some MIPS systems, you can switch endianess in software, on these two, they are set in hardware and can't be changed).

I guess there must be a lot of bad info out there then, as there is tons of information referring to little-endian on N64.
If you were doing virtualization, the COP would probably have to be one of those things you catch and handle specially.

after you've loaded the ROM (if it even fits) into PS2 RAM. Man, that's nasty :P.

They'll almost never fit, thats one of the big hurdles I was talking about ;) There is a solution, but it could easily be a lot of work to really get it working.

Of course, if it was me, I wouldn't bother to do virtualization, just a full emulator.

I wasn't aware of the endianness of the N64 chip... I need to go back and double-check that. I was under the impression it was LE. That's why N64 emus work so much better on PCs than Macs - the endianness was the same. At least that was what I was lead to believe by the current N64 emus for the PC. Like I said, I'll double check that.

I knew that the N64 supported doubles and that can be a problem, but the N64 had a mode you could set that made the registers into singles, and my understanding was that many (most) games used that for speed and space issues. I really need to look into the cores of the emus for the PC a little more closely.

Edit: I checked a bit and it seems it IS big endian. However, it's not as big a deal given the MIPS is a true RISC chip. The instructions are all 32 bits, and memory is only accessed through load/store instructions. Most opcodes can still just be copied with a simple byte swap. You were going to have to do load/stores through emulation anyway. The idea is to do as many instructions as possible without emulation for speed given that the PS2 is 300 MHz and the N64 is 90 MHz. You are going to need all the speed you can get.

J.F. wrote:I wasn't aware of the endianness of the N64 chip... I need to go back and double-check that. I was under the impression it was LE. That's why N64 emus work so much better on PCs than Macs - the endianness was the same. At least that was what I was lead to believe by the current N64 emus for the PC. Like I said, I'll double check that.

Please.... IBM-PCs are Little Endian, and Macs are Big Endian.

Whilst I'm certainly no expert on the subject (or any other for that matter!) it did pip my interest...

With the endian-ness issues and stuff, to avoid emulation and fixing the addressing, can you just ship some utility with the emulator which 'fixes' the rom file so that it ends up in a format PS2 knows more natively?
Not so much a suggestion, more a question of my own...

I know tha it'd drop compatability with exact copies of a cartridge, but (although i've never really emualted much ... vmware excepted) I know I'd prefer to do a one-off conversion if it means the game runs better and is easier to code...

Well thats another $0.02 in the pot...

N64 is very much big-endian. That's one of the things that confused me moving from N64 to PS2.
What PC emulators (at least Project 64) do on the topic is do byteswapping during the PI DMA (read from cartridge). So long as everything else reads and writes in the same units it shouldn't matter that everything is backwards, should it? i.e. if you've got a big endian program writing and reading words on a little endian processor shouldn't it behave the same so long as it doesn't access individual bytes?

hcs wrote:N64 is very much big-endian. That's one of the things that confused me moving from N64 to PS2.
What PC emulators (at least Project 64) do on the topic is do byteswapping during the PI DMA (read from cartridge). So long as everything else reads and writes in the same units it shouldn't matter that everything is backwards, should it? i.e. if you've got a big endian program writing and reading words on a little endian processor shouldn't it behave the same so long as it doesn't access individual bytes?

You've got it backwords (pun intended), anything over a byte has to be swapped when reading or writing between endian formats - 16-bit, 32-bit, 64-bit, etc. Individual bytes do not have to be byte-swapped.

It doesn't matter if it's a big endian (BE) program running on a little endian (LE) CPU - the LE CPU still has to convert the big endian data to LE data when accessed. Anything running on the LE CPU is LE, so there's really no notion of a BE program :).

Between formats, yes you have to swap, but the point I was making was that it doesn't matter if a word is stored as MSB first or LSB first so long as you do all load/store operations on that word with the same endianness and as a word. If you're expecting MSB first and you want to get the MSB of a word you might read the first byte in memory, if the system is actually LSB first there will be problems.

It sounded like you were asking if a N64 program running on PS2 could access data in it's native, big endian format, to which I was responding no, because the N64 program is no longer "big endian" once it's running on the PS2. It's the CPU that dictates byte order, not the software. In any case N64 program data (and instructions) would always have to be byte swapped, whether it's before the program is run or while it's being run it makes no difference.

Ok, I think I see where we differ; I defined a big endian program as one written with a big-endian processor in mind, you define it as the byte order the program is stored in.

Endianness has to do with the way data and code is stored in memory. While it is possible to reverse all the code and data in memory, you run into trouble where data structures are accessed by the program using different sizes. In that case, you need to look for offsets into structures and reverse them as well. It can get pretty messy.

In an emulation, it's usually easier to just use code to access the data in the original endian manner - make BE code to access LE data or vice versa. It's what virtually all emus do.

There's a star hidden in the waterfall, and the metal suit is invincible. However, be careful as it doesn't last long and you may find yourself in a bad situation with one of Bowser's minions.

Say hi to Toad for me!

ooPo: you working on getting the title "ps2dev forum pouet" or what ?

What does 'pouet' mean anyway?

bd: I think ooPo's trying to get J.F. to stop regurgitating every post in the same thread ad nauseum.

"Pouet" is a french onomatope. We typically use it for a trumpet sound (http://pouet.net/gfx/trumpet.gif)

But some nasty people also associate it with a farting sound.

ooPo: www.pouet.net the land of useless posts :)

mrb: yeah could be :)

Farts are pretty!

:D

How about something useful then. Accessing memory backwards is the same as accessing it in the reverse endianness. 8) I once wrote a PC emulator for the Amiga that did that. Although memory fetches are now easy and fast, you still run slower than if you access the memory normally and then byte swap the data. Why? Cacheing. Modern CPUs are designed to "run ahead" of the current process fetching data it THINKS it might need in the future. Since all CPUs execute in the forwards direction, they are geared towards cacheing in the forward direction. As a result, you are fetching data which is generally not cached, and the cacheing which is occuring is generally wasted.

I rewrote the exact same code, but going forwards and using ror.w #8,dn; swap dn; ror.w #8,dn (e.g. on long fetches) and it turned out faster overall than accessing data backwards. If you do try out the backwards memory, remember that your data buffers for things like video are also backwards, so you have to copy from descending order to your output buffer in ascending order. On an x86, this means you can't use repeat moves as the direction is the same for both source and destination (only one direction flag).

Is that sufficiently "new" info ooPo? :wink: :lol:

Edit: uh - why are smilies and html off when my profile says that both are enabled? Just curious...

That will suffice, and smilies are turned off for the entire site.

Have a nice day!