Big Endian support?

[Flea]

Okay, I have Mupen64 compiling on MacOSX using SDL and implemented some navigation code, but whenever I go to open a rom I get the following message: "fichier inexistant ou chemin incorect", or "the file does not exist or is way incorrect" I think (is that a good translation?). I believe this is due to the fact that the read and writes to memory are little endian. Does anyone have any tips on identifying and changing the affected read/writes to big endian? Thanks.
-Flea

[Hacktarux]

I will have to translate the messages to english.

The message means "the file does not exist or incorect path". If you look at the rom.c file it happens when the file is not find. This process does not involve any endian specific code (just string operations). I have not understood what you mean by navigation code : do you have rewritten a main file ? If you have written one, check if you have passed a valid path for the rom.

But even if you can have this working, you will have many troubles to get it working. The first thing is that you will have to disable the dynamic recompiler. You can see that the code dedicated to the dymamic recompiler is located to the r4300/x86 directory, if you want to create a recompiler for another processor, it may be possible to create a new directory and to write the equivalent for your processor.

In the interpreter core there is also some endian specific stuff but i it is not impossible to add macros defined at compilation time for these specific section of codes. I will explain it later when you will have your little problem working.

[Flea]

A little progress. I have a horrible romloading hack in because my nav code was broken. Here's the stdout.

Emulateur Nintendo64 (mupen64) version : 0.1-C
fichier trouvÈ

lecture effectuee a 100%
flipage de la rom...
rom flipee
80 37 12 40
ClockRate=f000000
Version:44140000
CRC: 4986248e 52de1c2e
nom:
Manufacturer: 0
Cartridge_ID: 0
Country Code: 0
size: 4096
PC= 2080
mode d'Èmulation:
1. interprÈtation
2. recompilation dynamique (dÈfaut)
1
mode d'Èmulation de l'affichage:
1. RSP/RDP
2. HLE
1
Rendu Soft activÈ
memoire initialisee
demarrage r4300
interprÈtation
recompilation d'un block... 100%
recompilation d'un block... 100%
opcode rÈservÈ
PC=a400004c:0
reg[ 0]: 0 0 reg[16]: 0 6
reg[ 1]: 0 1 reg[17]: 0 0
reg[ 2]: 0 ebda536 reg[18]: 0 0
reg[ 3]: 0 ebda536 reg[19]: 0 0
reg[ 4]: 0 a536 reg[20]: 0 1
reg[ 5]:ffffffffc95973d5 reg[21]: 0 0
reg[ 6]:ffffffffa4001f0c reg[22]: 0 3f
reg[ 7]:ffffffffa4001f08 reg[23]: 0 0
reg[ 8]: 0 c0 reg[24]: 0 3
reg[ 9]: 0 0 reg[25]:ffffffff9debb54f
reg[10]: 0 40 reg[26]: 0 0
reg[11]:ffffffffa4000040 reg[27]: 0 0
reg[12]:ffffffffed10d0b3 reg[28]: 0 0
reg[13]: 01402a4cc reg[29]:ffffffffa4001ff0
reg[14]: 02449a366 reg[30]: 0 0
reg[15]: 03103e121 reg[31]:ffffffffa4001550
hi: 0 0 lo: 0 0
aprËs 20484 instructions soit 5004
memoire liberee


Hey, at least it's running. Not displaying graphics atm though.

[Flea]

This may be a stupid question, but here goes...apparently all the roms are dying at this certain point in r3400.c :

void RESERVED()
{
printf("opcode rÈservÈ\n");
stop=1;
}

They all end up there for some reason, and obviously they can't get past it. Any suggestions?

[Hacktarux]

The problem is because on little endian machine, each 32 bit word of the n64 memory is flipped so it is easier to read things like tehy are on the real n64 (which is a big endian machine). You will have to redefine the sl macros in the memory.h file like this :
#define sl(word) word

It will help you to execute the first instructions but you will have other problems. I will try to modify mupen64 for big endian...

[lint]

That's cool that people are trying to compile mupen64 to other platform ....

if the macosx compile works that will be 4 supported platform... very nice... good work continue...

Im currently working on a input plugin (following zilmar specs) and will make the necessary change to source code to make it work with mupen64 ... i will maybe work on a kind of interface for plugin loading (audio, gfx and controller) ... does anyone if there is already a plugin for gfx open gl that use the sdl lib ?

thanks to let me know ...

see ya

[Slougi]

If this continues this way Mupen64 will have a very bright future

[Hacktarux]

Originally posted by lint
That's cool that people are trying to compile mupen64 to other platform ....

if the macosx compile works that will be 4 supported platform... very nice... good work continue...


see ya

No 5, someone informed me that a QNX port is starting to work

Originally posted by lint

does anyone if there is already a plugin for gfx open gl that use the sdl lib ?

No, because it is impossible to use the sdl in a zilmar spec gfx plugin on windows because it blocks the keyboard messages. But it is not a problem because with opengl we just have to change the initialisation code : wgl for windows sdl for all the other OS.

[Hacktarux]

Flea: Replace your files with the following ones. I think this could make mupen64 working with big endian machines but i can't test it...

You have to define the BIG_ENDIAN macros in your Makfile, you should have a line like this:
CC = gcc ...... -DBIG_ENDIAN .....

Hope that this will have some positive result.

[Flea]

I implemented all the endian fixes but it's still hitting that 'RESERVED' opcode. I'll try to go through it a little more tonight and see if I can find any other possible fixes. In the mean time, do you have any other ideas for endian fixes?