What's new

Big Endian support?

Flea

New member
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

Emulator Developer
Moderator
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.
 
OP
F

Flea

New member
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.
 
OP
F

Flea

New member
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

Emulator Developer
Moderator
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

New member
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
 

Hacktarux

Emulator Developer
Moderator
lint said:
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 :)

lint said:

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

Emulator Developer
Moderator
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. :)
 
OP
F

Flea

New member
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?
 

Hacktarux

Emulator Developer
Moderator
Can you post the files you have modified and your makefile in a PC readable format ? And can you say me if it crashes exactly at the same point or if it executes more instructions before hitting this point ?
 
OP
F

Flea

New member
The code I have is 99.9% code you have posted (the exception being making the global variable 'i' static in several files and changing rom_read(argc *argv) in main() to rom_read("file.rom")). The compiler I am using is CodeWarrior 7.2 for Mac OS, and therefore I don't have a makefile to show to you. In a couple of minutes I'm going to go through and check the registers before and after the endian fixes to see if the values have actually changed. Hopefully I will be able to get a copy of the emulator running on a different platform and run them in parallel to see exactly what values change where and why they differ. I'll let you know what develops.
-Flea
 

Hacktarux

Emulator Developer
Moderator
Don't forget to define the BIG_ENDIAN macro. If you don't know how to do this with your compiler, add #define BIG_ENDIAN in memory.h. If you don't do this, all the modifications i have made will not take effect !
 
OP
F

Flea

New member
I know to define #BIG_ENDIAN ;) After stepping through some code with the different endian-ness versions running parallel, it appears that the program counter is actually slightly different, but apparently not correct yet. I am testing with fire.bin and both versions go SLL, SLL, RESERVED, at which point they stop, of course. To be honest, I'm fresh out of ideas to fix it.
 

Hacktarux

Emulator Developer
Moderator
The first instruction must be MTC0 and not SLL but i don't know why i's wrong, i will search tomorrow...
 

Hacktarux

Emulator Developer
Moderator
The first instruction at the 0xa4000040 address is 0x40806800 (mtc0) whatever the rom you use. If you flip this to 0x00688040 you obtain a sll opcode.
Can you display what is contain at this address when the emulator stop ?

Add a line like this:
printf("%x\n", SPDMEM[0x40/4]);

Say me also what are the sizes of the standard data types on MACOS X.

Without these infos, it is hard for me to understand what is wrong...
 
OP
F

Flea

New member
You were correct, the output of the SP_DMEM is 0x00688040 at the location you gave me. I have implemented some swapping code that swaps 32-bit integers and it prints the correct value for MTC0 (0x40806800) but it still goes to SLL. Is there anyway to swap all of SP_DMEM at once? Or is there another value I need to swap? I am swapping right before PC->ops(); Is there a better place to swap? Here's the swapping code I am using:

typedef unsigned char UINT8;
typedef unsigned short int UINT16;
typedef unsigned long int UINT32;
#define SWAP16(val) (((UINT16)val << 8) | ((UINT16)val >> 8))
#define SWAP32(val) (((UINT32)val << 24) | (((UINT32)val << 8) & 0xff0000) | (((UINT32)val >> 8) & 0xff00) | ((UINT32)val >> 24))

...etc...etc...

SP_DMEM[0x40/4] = SWAP32(SP_DMEM[0x40/4]);
printf("%x\n", SP_DMEM[0x40/4]);
PC->ops();
update_system();

Any suggestions?
 

Hacktarux

Emulator Developer
Moderator
No, you don't have to swap each opcode, you have to swap the rom when it is loaded.
When the rom_read function has finished to load the rom, it swap the rom in order that it is in a correct big endian format (even in a x86) because there is various way to store a n64 rom. When this function is finished the rom area must begin with 0x80371240.
Then, in the first 2 lines of the init_memory function, you can see that the rom is swap (32 bits swap) by the sl macro on a little endian machine. This is why i asked you if you have defined correctly the BIG_ENDIAN macro. Now can you check before and after these first 2 lines how the rom begin ?
If you need to modify something with this macro, it is defined in the momory.h file.
 
OP
F

Flea

New member
Thanks for your help. Mupen now runs the correct opcodes, but it is crashing at some points.

It is having problems in the LW opcode at sign_extended(lsrt);
Here's some console output...do you have any insight?

lecture d'un mot mi l'addrese a4300004 PC=a4000140
lecture d'un mot mi l'addrese a4001e9c PC=a4000ac4
TLB refill exception
[crash]

My problems never stop, do they? ;)
 
Last edited:

Hacktarux

Emulator Developer
Moderator
I found another bug, try this patch...

And yes your problems will stop one day (Every thing is possible :) )
 

Top