[$threadinfo[title]]

[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?

[Hacktarux]

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 ?

[Flea]

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]

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 !

[Flea]

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]

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

[Hacktarux]

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...

[Flea]

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]

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.

[Flea]

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? ;)

[Hacktarux]

I found another bug, try this patch...

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

[Flea]

[Edit: Fixed the first bug.]

Ok, now the cpu runs great and all is well, except for one thing. Mupen64 does not display any video. The SDL code is executing fine as far as I can tell, but still no video. It's possible this is a problem with the SDL implementation on MacOS X. I will test some more and let you know.

Also, I got this in my console window - "Ècriture d'un mot pi ‡ l'addresse a4600000 PC=8000001c". The best translation I can get is 'Writing of one word ---'. What exactly does that mean?

[Hacktarux]

What is the first bug ? Is it the display problem or is it something that you have deleted ?
I think that the writing error is the reason of the display problem but...
This error message means that the rom is trying to write a word at the 0xa46000000 (which is a pi register). The instruction that cause this error is located at 0x8000001c. This message appear when a memory address is not implemented but i know that this one is. I will try to find out why it is happening in your port....

[Hacktarux]

Just to know, do you have a little endian machine to test some stuffs ?

[Flea]

Unfortunately, no. But I may be able to get someone to do it for me if it's just about running some code. It's also possible I could run a virtual environment for little endian testing. I will look into setting on up sometime soon.

[Hacktarux]

Arghh, i can't find the reason of this bug. Can you try to know how it comes in this function (write_pi), it is hard for me to understand this since i can't test anything... ?
And if you can try to compare the results of the boot code on a little endian and on a big endian mahine.

[Flea]

I now have a virtual environment running Mupen in Windows98SE (very slowly, I might add). Do you have a debug version of Mupen I could run and step through the code to compare it to the big endian version?

[Hacktarux]

I don't have any debug version for windows. Firstly because the debugger is currently being written in a gtk interface (incompatible with windows). Secondly, if you want to debug as i am doing until now, (display vars in console) you need to have a compiler and display what you want to compare (i know it is not very convenient but someone is working on this :) ). Try the devcpp compiler (10 Mb), you can find it at http://www.bloodshed.net/devcpp.html

Important thing, if you want to be able to use the console, you have to disable all the sdl code and linkage. Comment the content of the graphic functions and comment the #include <sdl.h> lines.

I'm sorry for all these manipulations (maybe just for one little stupid thing) but i don't see any other easy way to debug it.
Maybe you have a better idea....

[Hacktarux]

Just a suggestion, Muad have compiled a QNX version and i don't know why, he had problems until he add a line in the beginning of the main function :
munlockall();
Since it is a posix function, you can try it in the MacOS version and see what it does....
Hope that this will help :)

[Flea]

I have moved over to a new compiler that should be more SDL friendly...here's some things I have noticed:

etc...
recompilation d'un block... 97/%
recompilation d'un block... 98/%
recompilation d'un block... 99/%
recompilation d'un block... 100%
lecture d'un mot ri ‡ l'addrese a470000c PC=a4000058
Ècriture d'un mot ri ‡ l'addresse a4700004 PC=a4000098
Ècriture d'un mot ri ‡ l'addresse a4700008 PC=a40000b0
Ècriture d'un mot ri ‡ l'addresse a470000c PC=a40000b8
Ècriture d'un mot ri ‡ l'addresse a4700000 PC=a40000bc
Ècriture d'un mot ri ‡ l'addresse a4700000 PC=a40000d8
Ècriture d'un mot mi ‡ l'addresse a4300000 PC=a40000ec
lecture d'un mot mi ‡ l'addrese a4300004 PC=a4000140
lecture d'un mot ‡ l'addrese a4001e9c PC=a4000ac4
TLB refill exception
Fatal signal: Bus Error (SDL Parachute Deployed)

This occurs when "unsigned short *addresseh = (unsigned short *)(&addresse);" is compiled. When I compile with "unsigned short *addresseh = (unsigned short *)(&addresse)+1;" I get:

...etc...
recompilation d'un block... 99/%
recompilation d'un block... 100%
Ècriture d'un mot pi ‡ l'addresse a4600000 PC=8000001c

Now what I'm wondering is why the value of addresseh is being deleted, because there should be some sort of value besides 1, shouldn't there? I will test a little further and report back.

[Muad]

Hi all
I done a port to the qnx OS.
For info, in the QNX OS , the function munlockall() allows the os to use all the memory ( swap and ram ).
QNX don't use swap unless you notice it.
But this has some limitations , and it don't work all th time.
With my config ( 64 Mo Ram ) , I cant load a rom > 12Mo.

[Hacktarux]

With the infos you gave, i can say that with "unsigned short *addresseh = (unsigned short *)(&addresse)+1", the boot code seems to be executed right. I have also found that we should not use the BIG_ENDIAN macro because it is already defined in some compilers, replace it with _BIG_ENDIAN.
But i still can't understand what is the problem. Try to display *addresseh in the write_pi funtion and say me what you get.
Can you say me how much ram do you have and if you have tried the munlockall function ?

[Flea]

My addresseh value is 299182. munlockall() does not seem to affect anything.

[Hacktarux]

Have you displayed addresseh or *addresseh
You should get a zero value and not 299182. The addresseh variable represent the lower half (16 bits) of the addresse variable as you may have noticed if you understand how pointers work... You have to find out when the *addresseh value doesn't represent the lower bits of the addresse variable...

[Flea]

The value of *addresseh is 0 while the value of addresseh is 299182, which I assume from your post are the correct values. After going through the write_pi function and printing "Ècriture d'un mot pi ‡ l'addresse a4600000 PC=8000001c" it apparently runs through the function again twice and the value of *addresseh goes to 4, and then to 12. Is this correct?

[Hacktarux]

So, we know that *addresseh has the correct value. Now, we have to check the readpi[0] value. It must be the address of pi_register.pi_dram_addr_reg;
Try to print these two values by adding at different point:
printf("%x\n", (int)readpi[0]);
printf("%x\n", (int)(& pi_register.pi_dram_addr_reg);

Initialy, it should be initialized in the init_memory function and should not be changed then but you have to check this...

[Flea]

Both values ar consistant at various points all over the program (0 and 66110088 respectively). Any other values that could have gone wrong?

[Hacktarux]

No, these two values should be equals ! Check in the memory funtion there's a line like:
readpi[0] = & pi_register.pi_dram_addr_reg;
And then readpi should be constant !

[Flea]

Finally tracked down the offending line of code that changes the value...

for (i=0; i<(0x10000); i++) readai[i] = NULL;

in the ai register init. I have no idea why this would affect it though. I'm going to try to rearrange the order of inits and see if I can maintain the value.

[Flea]

Ok, rearranged some stuff and now the value of the pi stuff should be ok. Here's some more errors that cropped up.

Ècriture d'un mot ri ‡ l'addresse a4700000 PC=a40000bc
Ècriture d'un mot ri ‡ l'addresse a4700000 PC=a40000d8

And I got '*** malloc[724]: error: Can't allocate region' at the last recompilation.

[Hacktarux]

I think that this is the same error but with the readri array. It seems that your compiler manage memory allocation very strangely.
I think that the problems come from these definitions:
void (*readmem[0xFFFF])();
void (*readmemb[0xFFFF])();
void (*readmemh[0xFFFF])();
void (*readmemd[0xFFFF])();
unsigned long *readrdramreg[0xFFFF];
unsigned long *readrspreg[0xFFFF];
unsigned long *readrsp[0xFFFF];
unsigned long *readmi[0xFFFF];
unsigned long *readvi[0xFFFF];
unsigned long *readai[0xFFFF];
unsigned long *readpi[0xFFFF];
unsigned long *readri[0xFFFF];
unsigned long *readsi[0xFFFF];
void (*writemem[0xFFFF])();
void (*writememb[0xFFFF])();
void (*writememd[0xFFFF])();
void (*writememh[0xFFFF])();

unsigned long *var[0xFFFF] define an array of pointer
and void (*var[0xFFFF])() define an array of function pointer

maybe the syntax is slightly different with you compiler and/or os.

[Flea]

Hey Hacktarux, could you send me the .03 sources? I'm going to try to start over, and maybe some things will go right this time ;) You can e-mail them to me at flea@emuscene.com if you don't want to post them on the board.

[Hacktarux]

Don't worry, the source will be published within a week, i will try to translate all my error messages and variables before and to clean some stuffs.

[Hacktarux]

Flea, i have a few questions :
Is CodeWarrioir just a front end of a gcc compiler or is it a compiler.

I've heard that there's a gcc version included with MacOSX (renamed cc but it is gcc), have you tried to compile mupen64 with it ?

[Flea]

I've switched from CodeWarrior to ProjectBuilder, which is basically a frontend for gcc 2.95.3 (or 3.1). This is what I compile Mupen with, so it's basically a gcc environment.

[Hacktarux]

Flea, you can try to compile the new source code now :)

[Flea]

I'll try ;)

[Flea]

Looks like all the old problems are fixed...would you be so kind as to post up the source for your graphic plugin or icepir8's OpenGL plugin so I can recompile it for my system?

Edit: I may not have been clear. If you have removed the dependencies of <windows.h> from icepir8's plugin, I'd like that source. I can do it myself but if you have already done it (I assume you have) then there's no reason to do the same thing twice ;)

[Hacktarux]

I've just send it to your mail box :)

[Flea]

Damn, the old problems have cropped back up...I give up :/

...
memory initialized
demarrage r4300
error : writing a word at a4600000 (pi) PC=40c00000
execution ‡ l'addresse :80400000
PC=80400004:3f000000
...

[Hacktarux]

Too bad :(
This time, i can't help you.
Maybe you can ask in a forum dedicated to mac programming.

If you don't understand what's exactly the problem i can eventually try to redescribe it but that's the only thing i can do.