What's new

Big Endian support?

OP
F

Flea

New member
[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?
 
Last edited:

Hacktarux

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

Flea

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

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

Flea

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

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

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

Flea

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

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

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

Hacktarux

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

Flea

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

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

Flea

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

Hacktarux

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

Flea

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

for (i=0; i<(0x10000); i++) readai = 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.
 
OP
F

Flea

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

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

Top