search

beepbeepimatrain / mupen64plus

Automatically exported from code.google.com/p/mupen64plus
0 stars 0 forks source link

Collision problems in Banjo-Tooie #51

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
System Info:
Ubuntu 8.04 Beta
Mupen64plus 1.3 stable

What's Wrong:
In Banjo-Tooie, some collisions just don't work. One for example is
shooting the Fire Egg at the button near Glitter Gulch Mine, but theres
quite a few others, often involving eggs, but sometimes Talon Torpedo and
Taxi Pack. This is a pretty common problem in emulators but it would be
nice to be able to play it well in Linux :)

Plugins:
Rice Video 1.3
Jttl audio plugin
blight input plugin
hacktarux hle rsp plugin

Original issue reported on code.google.com by doorkno...@gmail.com on 13 Apr 2008 at 10:17

GoogleCodeExporter commented 8 years ago 
RARE has a lot of little things built in the games to stop piracy. For example 
Donkey
Kong 64 doesn't even boot on Mupen64

Original comment by sgorman07@gmail.com on 14 Apr 2008 at 4:00

GoogleCodeExporter commented 8 years ago 
Doesn't mean it's not possible to fix though, 1964 version 0.8.5 with the right
plugins runs it perfectly :) Maybe you could take a look at the source for it, I
would but I'm not much of a programmer.

Original comment by doorkno...@gmail.com on 15 Apr 2008 at 4:51

GoogleCodeExporter commented 8 years ago 
Yes, i got the same problem. I think that you should maybe take code on 1964 
v0.8.5
(AND NOT v0.9.9, 'cause it has the same problem) and put it in mupen64plus, as
dooknob64 said. B-T is a GREAT game ant it's so disappointing mupen64plus can't 
run
it well.

Original comment by Aer...@gmail.com on 20 Apr 2008 at 3:37

GoogleCodeExporter commented 8 years ago 
Can I have a savestate for this please

Original comment by sgorman07@gmail.com on 27 May 2008 at 11:53

GoogleCodeExporter commented 8 years ago 
Yeah, as soon as I get my new motherboard and CPU (can't play 3D stuff on the 
peice 
of Junk I'm using right now lol). The parts should be here by Friday 
(hopefully), 
then I gotta get everything running smoothly, then I can get a savestate 
probably 
by Saturday or Sunday. If someone else can get one sooner (you only have to 
unlock 
the fire eggs and go by the switch where you shoot the egg at it), then feel 
free 
to do so.

Original comment by doorkno...@gmail.com on 27 May 2008 at 11:59

GoogleCodeExporter commented 8 years ago 
Hmm, my hardware came, but I didn't think about the fact that DDR RAM doesn't 
work 
in a DDR2 slot :P, but my parent's laptop has decent specs, so I can use it 
maybe. 
Busy for a lot of today though.

Original comment by doorkno...@gmail.com on 31 May 2008 at 7:51

GoogleCodeExporter commented 8 years ago 
Here's a save state: http://rapidshare.com/files/119455867/BTcollisionbug.html

Here's a link to the ROM I used: http://romhustler.net/rom/n64/25/banjo-tooie 
(I 
used the (E) rom inside the 7zip archive)

Just load the rom, load the save state, press Z, and watch the fire egg fail to 
activate the switch.

Original comment by doorkno...@gmail.com on 2 Jun 2008 at 3:31

GoogleCodeExporter commented 8 years ago 
I'm having this same issue. Could someone please fix this? This game is 
unplayable
without shooting the fire egg switch!

Original comment by blenheim...@gmail.com on 30 Oct 2008 at 4:22

GoogleCodeExporter commented 8 years ago 
This is likely caused by lack of floating-point accuracy. Many emulators use
inaccurate or less precise floating-point or even integers (very bad) to 
increase
speed. On a modern computer this is a very bad idea because most modern 
computers
experience little or no slowdown with increased precision floating-point. The 
bugs
that it causes (like this one very likely) are simply not worth it.

Original comment by blenheim...@gmail.com on 23 Nov 2008 at 1:20

GoogleCodeExporter commented 8 years ago 
^ Nice, and how easily fixable would this be? (No hurry any more, I'm using 
PJ64 via
Wine which should work according to sites)

Original comment by doorkno...@gmail.com on 23 Nov 2008 at 6:30

GoogleCodeExporter commented 8 years ago 
For the record, I consider PJ64 an unacceptable substitute because it's closed 
source
and must be run in Wine. (Not to mention, it's not as feature-rich as 
Mupen64plus...
for example, the lack of support for high-res texture packs)

Original comment by stephan....@gmail.com on 23 Nov 2008 at 9:59

GoogleCodeExporter commented 8 years ago 
This is not caused by 'lack of floating point accuracy'.  Mupen64plus does not 
use
less precise floating point or integers to gain speed.  All floating point math 
is
handled by the x87 FPU, which uses 80-bit values internally.  All 32-bit and 
64-bit
r4300 floating point instructions are emulated properly.  It could actually be 
due to
'too much' precision due to the 80-bit partial products, though that's not very
likely since the calculated values get rounded to the output precision and 
stored
after every instruction.  Or maybe the r4300 COP1 FPU wasn't IEEE compliant. 
Floating point stuff is notoriously hard to make 'bit-exact' - that's why 
MPEG-2 had
floating point arithmetic in it but H.264 doesn't.  If you take generic C code 
with
some sensitive floating point calculations in it you can get different results
depending upon the optimization flags that you use to compile it.

Can someone test and verify that this problem occurs with both the dynarec and 
the
interpreter?

Original comment by richard...@gmail.com on 23 Nov 2008 at 4:29

GoogleCodeExporter commented 8 years ago 
I believe I tried both interpreter and dynamic recompiler (as well as pure
interpreter) all with the same results. Also, as a side note, if anyone is 
getting
random crashes playing this, set it as interpreter, dynamic recompiler gets 
random
crashes (as does PJ64 without proper setup). Of course I could always test again
though :) And stephen, I know it's not the greatest solution, but until this 
bug is
fixed, it's my best temporary solution without booting into Windows. (it works 
in
1964, which is open source, but doesn't work in Wine well enough to play. And I 
don't
wanna simply not play it either :P)

Original comment by doorkno...@gmail.com on 23 Nov 2008 at 4:56

GoogleCodeExporter commented 8 years ago 
True. I have it kicking around in case I run out of patience waiting for Donkey 
Kong
64 and Blast Corps, but thankfully for now, Conker's Bad Fur Day, Super Mario 
64,
Banjo Kazooie, and all my DOSBox, ZSNES, and ScummVM games are more than enough 
to
keep my interest when I'm not feeling like reading or programming. (high-level 
stuff
in Python, unfortunately, or I'd contribute)

Original comment by stephan....@gmail.com on 23 Nov 2008 at 10:53

GoogleCodeExporter commented 8 years ago 
I've tried it too and it happens with all three: the dynamic recompiler, the
interpreter, and the pure interpreter. I only tried it on the 64-bit (x86_64)
version. I have attached a video of the problem for those who don't want to 
download
the ROM.

Original comment by blenheim...@gmail.com on 6 Dec 2008 at 9:01

Attachments:

GoogleCodeExporter commented 8 years ago 
Does anyone have a savestate for this? The previous is dead.

Original comment by olejl77@gmail.com on 18 Dec 2008 at 6:25

GoogleCodeExporter commented 8 years ago 
I'll try to get another one later. Sorry bout the old one being dead, but you 
took
way to long to get it so it deleted itself :P

Original comment by doorkno...@gmail.com on 18 Dec 2008 at 11:44

GoogleCodeExporter commented 8 years ago 
There's one there : http://www.mediafire.com/?w4tz50tj2jz
Just load, and press Z to shoot.

Not sure if it's compatible with the ROM posted above :/ I used the ROM from
http://www.doperoms.com/roms/nintendo_64/Banjo-Tooie%2520%2528U%2529%2520%255B!%
255D.zip.html/113101/Banjo-Tooie%20(U)%20%5B!%5D.zip.html

Original comment by auria...@gmail.com on 25 Dec 2008 at 8:13

GoogleCodeExporter commented 8 years ago 
I'm surprised nobody has fixed this yet. This is a major bug. This bug makes 
the game
unplayable.

Original comment by blenheim...@gmail.com on 4 May 2009 at 11:40

GoogleCodeExporter commented 8 years ago 
It isn't as simple as you might think,  blenheimears. It's difficult to track 
down
what exactly is causing abnormalities in games like this.

Original comment by zzt...@gmail.com on 5 May 2009 at 5:05

GoogleCodeExporter commented 8 years ago 
I am currently debugging it and I think it is related to the mtc0 STATUS
implementation. Now I have to find a good (really really really extreme good)
reference for R4300i to get it working. I have made it possible to shoot at it 
and
the thing get in flames. Now I hav to find the real reason why the current
implementation is faulty. Currenty only worked with the pure-interpreter 
version.

Original comment by sven@narfation.org on 24 Sep 2009 at 7:02

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
So if I am disappearing without any reason (eaten by a troll or something like 
this):
the current test with which I got it working - this is
just a dirty hack and doesn't proof that it is real the reason - but maybe a 
hint for it.

Don't use it to play any game or it could eat your sandwich, shave your cat and 
melt
your ice cream.

Original comment by sven@narfation.org on 24 Sep 2009 at 8:19

Attachments:

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
So just for information: This cannot be the real reason as it would just top 
super
mario from working.

Original comment by sven@narfation.org on 24 Sep 2009 at 9:54

GoogleCodeExporter commented 8 years ago 
So only if anyone thinks that it is an easy task I added a list of interesting
looking places inside that rom which needs to inspected. It doesn't mean that 
you can
find the real reason with that list. I did a check of interesting parts of the 
MIPS
architecture, but the only things I could find weren't related to that bug.

Original comment by sven@narfation.org on 25 Sep 2009 at 12:56

GoogleCodeExporter commented 8 years ago 
My current guess is that it is near 0x800ef2d4 which always does the same 
branch and
should do or otherwise the egg is just hidding the wall and not the "did we hit 
the
button?" check is made. I would like to make a snapshot but it seems that it is
currently not possible to make snapshots from the debugging session. Let's 
check if I
can quick hack a autosave into the debugger.

Ok, looks good. Just load that rom, enable debugger, add breakpoint to 
0x800ef2d4 and
start the pure interpreter and then load that file. You will see how it smashes
against the wall. If you manipulate that branch to not jump it shoult hit the 
button.

Original comment by sven@narfation.org on 25 Sep 2009 at 2:14

GoogleCodeExporter commented 8 years ago 
Same save state for project64 1.6 or so. It was tested there and the egg hit the
button. Does anyone know if there exist a debugger for that version of 
project64?

Original comment by sven@narfation.org on 25 Sep 2009 at 3:50

GoogleCodeExporter commented 8 years ago 
Ok, it seems that this jump can be taken and another check afterwards must be 
passed.
I am currently digging further

Original comment by sven@narfation.org on 25 Sep 2009 at 5:02

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Just started to look at instructions and if they are still in a good situation. 
The
first number is the number of instructions without delay slots and my "ok" == 
good
situation and crash == hit the wall and not the button must not be correct - 
but I
hope it is

162276 likely branch ok
162277 ok
324554 ok
649108 ok
1298216 ok
2596432 crash
1947324 crash
1622770 crash
1460493 crash
1379354 ok
1419923 crash
1399638 ok
1409780 ok
1414851 ok
1417387 crash
1416119 crash
1415485 crash
1415168 crash 
1415009 crash
1414930 ok
1414969 ok
1414989 ok
1414999 ok
1415004 ok
1415006 crash
1415005 ok

So I would like to conclude that the interesting instruction is located at 
position
0x80019B14 is a "lwc1 $f15, 0x0030($a)" and is executed by LWC1() inside 
pure_interp.c

Original comment by sven@narfation.org on 25 Sep 2009 at 7:35

GoogleCodeExporter commented 8 years ago 
The function looks like it was implemented as the standard says. Maybe it is a
problem when reading from 0x80127ed0. This is memory block 0x8012. As far as I 
can
see this is rdram and read using read_rdram.
As I am a little bit clueless right now I just add a savegame (mupen64plus and 
pj64)
which is exact at the position right before the "bad" instruction at 0x80019B14.
Maybe someone else has a good idea as I don't see the reason right now.

Original comment by sven@narfation.org on 25 Sep 2009 at 8:40

Attachments:

GoogleCodeExporter commented 8 years ago 
Cannot upload the file for pj64 as my quote is exceeded.

Original comment by sven@narfation.org on 25 Sep 2009 at 8:44

GoogleCodeExporter commented 8 years ago 
Ok, maybe it is a byte order problem. 0xc59cd8000 is read. This doesnt make 
sense if
you want to have a nice value. But if you sort it to 0x00d89cc5 then you will 
get the
IEEE float representation for 0.0f.

Original comment by sven@narfation.org on 25 Sep 2009 at 9:47

GoogleCodeExporter commented 8 years ago 
Well, 0xc59cd800 (one less zero; did you write it wrong?) is -5019.

Original comment by zzt...@gmail.com on 26 Sep 2009 at 10:22

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Yes, one zero to much and and yes it is -509.0 - which seems to be also correct 
as
this is also the thing I can see in the nemu debugger (this thing has some 
really
nice debugging features). Don't have any clue was project64 does, but checked 10
times or more that the button doesn't get in flames when I process one 
instruction
more (this lwc1) in mupen64plus and then save a state for project64. This could 
also
be a fault of the pj64 savestate function, but as I don't have a debugging 
enabled
version of pj64 which also supports banjo tooie it is quite hard to guess whats 
pj64
reads here.

As far as I can see that we load from this memory position 6 times and my 
savestate
is at round 6. So you can add a memory breakpoint (only read seems to work - no
stores created a break) for 0x80127ed0 and then shoot a egg.

Original comment by sven@narfation.org on 26 Sep 2009 at 11:03

GoogleCodeExporter commented 8 years ago 
Just  did a small look through the savestate stuff and noticed that 
reg_cop0[12] aka
Status is never used to initialise reg_cop1_double and reg_cop1_simple to the 
correct
positions. This could part of the error.

Original comment by sven@narfation.org on 26 Sep 2009 at 1:10

GoogleCodeExporter commented 8 years ago 
Have added a function 

static void set_cop1_register(void)
{
    if (reg_cop0[12] & 0x04000000)
    {
        int i;
        for (i=0; i<32; i++)
        {
            reg_cop1_double[i]=(double*)®_cop1_fgr_64[i];
            reg_cop1_simple[i]=(float*)®_cop1_fgr_64[i];
        }
    }
    else
    {
        int i;
        for (i=0; i<32; i++)
        {
            reg_cop1_double[i]=(double*)®_cop1_fgr_64[i>>1];
#ifndef _BIG_ENDIAN
            reg_cop1_simple[i]=(float*)®_cop1_fgr_64[i>>1]+(i&1);
#else
            reg_cop1_simple[i]=(float*)®_cop1_fgr_64[i>>1]+(1-(i&1));
#endif
        }
    }
}

And now call it after "gzread(f, reg_cop0, 32*4);" and
"unzReadCurrentFile(zipstatefile, reg_cop0, 4*32);". The registers look better 
now,
but same "button" behaviour as before.

Original comment by sven@narfation.org on 26 Sep 2009 at 1:45

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Just little testing with nemu64 to look if something special is changed during 
the
load (register: first big endian ordered word - second big endian ordered word, 
short
float, double float):

Before:
FPR 00: 00000000 - 3F800000 1.000000000000000000    0.000000000000000000
FPR 01: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 02: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 03: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 04: 00000000 - 3F800000 1.000000000000000000    0.000000000000000000
FPR 05: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 06: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 07: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 08: 00000000 - 3F800000 1.000000000000000000    0.000000000000000000
FPR 09: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 10: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 11: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 12: 00000000 - 3E8483DA 0.258818400000000000    0.000000000000000000
FPR 13: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 14: 00000000 - 3F7746D8 0.965924700000000000    0.000000000000000000
FPR 15: 00000000 - C3E40000 -456.000000000000000000 0.000000000000000000
FPR 16: 00000000 - 3E8483DA 0.258818400000000000    0.000000000000000000
FPR 17: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 18: 00000000 - C3E40000 -456.000000000000000000 0.000000000000000000
FPR 19: 00000000 - 80000000 0.000000000000000000    0.000000000000000000
FPR 20: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 21: 00000000 - 41C00000 24.000000000000000000   0.000000000000000000
FPR 22: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 23: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 24: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 25: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 26: 00000000 - 3F800000 1.000000000000000000    0.000000000000000000
FPR 27: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 28: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 29: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 30: 00000000 - 00000000 0.000000000000000000    0.000000000000000000
FPR 31: 00000000 - 00000000 0.000000000000000000    0.000000000000000000

After:
FPR 00: 00000000 - 3F800000 1.000000000000000000     0.000000000000000000
FPR 01: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 02: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 03: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 04: 00000000 - 3F800000 1.000000000000000000     0.000000000000000000
FPR 05: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 06: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 07: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 08: 00000000 - 3F800000 1.000000000000000000     0.000000000000000000
FPR 09: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 10: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 11: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 12: 00000000 - 3E8483DA 0.258818400000000000     0.000000000000000000
FPR 13: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 14: 00000000 - 3F7746D8 0.965924700000000000     0.000000000000000000
FPR 15: 00000000 - C59CD800 -5019.000000000000000000 0.000000000000000000
FPR 16: 00000000 - 3E8483DA 0.258818400000000000     0.000000000000000000
FPR 17: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 18: 00000000 - C3E40000 -456.000000000000000000  0.000000000000000000
FPR 19: 00000000 - 80000000 0.000000000000000000     0.000000000000000000
FPR 20: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 21: 00000000 - 41C00000 24.000000000000000000    0.000000000000000000
FPR 22: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 23: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 24: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 25: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 26: 00000000 - 3F800000 1.000000000000000000     0.000000000000000000
FPR 27: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 28: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 29: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 30: 00000000 - 00000000 0.000000000000000000     0.000000000000000000
FPR 31: 00000000 - 00000000 0.000000000000000000     0.000000000000000000

So nothing fancy, but it looks quite clean. Or should I say. To clean for me. 
If it
would share the same register bank for both modes it should be little more 
messy. So
if I look at a mtc0 with switch (rare games do that very often) it shows me
completely different values. So maybe we must split them and project64 just 
does some
cleanup when lwc1 is run.... or just doesn't polite the other fp register 
banks. B.3
of MIPS 4 (i know it isn't a MIPS4) instruction set reference describes the 
register
banks as "two seperate coprocessor 1 (CP1) register sets". (So MIPS III is 
shown as
having 64 bit wide registers on the next page). I will implement this later to 
test
if it works. The save format must be changed so make this possible.

Original comment by sven@narfation.org on 26 Sep 2009 at 3:38

GoogleCodeExporter commented 8 years ago 
Just for everyone: This was the problem (as far as I can say) and I currently 
testing
it and it seems to work quite well. Tested also other roms and still seems to 
work
(beside some small hacks for debugging I still have to remove). It seems that I
cannot save it for pj64 as I don't have a specification with MIPS2 floatingpoint
register bank support.

Original comment by sven@narfation.org on 26 Sep 2009 at 6:46

GoogleCodeExporter commented 8 years ago 
Really? Does this mean we're close to a fix? If so, I'd be really happy :D

Original comment by doorkno...@gmail.com on 26 Sep 2009 at 6:51

GoogleCodeExporter commented 8 years ago 
If you find a mentor for that patch..... I wanted to wait for a pj64 before
publishing my patch, but if you want to test it... please do. You need to use 
the
savestate converter to convert to new savestate version. Please note that this 
isn't
accepted yet and so the savestate format isn't fixed. It is also a bad idea to
convert as you will maybe miss information and crashes are to expect due to the
missing information (not more than before.... but still possible crashes). It 
is a
better idea to start the game from a save of the game (so one of the three save 
slots
in banjo tooie for example)

Original comment by sven@narfation.org on 26 Sep 2009 at 8:40

Attachments:

GoogleCodeExporter commented 8 years ago 
Have done some research and have some other idea about it. If we just arrange 
the
layout of the fpr64 for mode 0 ((status & 0x04000000) == 0) we get a similar 
result
(egg hits button, button opens gate and gets in fire), but don't need a real 
distinct
register bank. As I couldn't find the extra register bank in the savestates of 
pj64 I
would guess that they do it that way.

Following naming scheme in the examples. fpr.s[x] == single float at position x.
fpr.d[x] == double float at position x. rb[x] == 32 bit word in register bank at
position x.

So in mode 1 everything is like expected:
fpr.d[0] == rb[0] and rb[1]
fpr.d[1] == rb[2] and rb[3]
fpr.d[2] == rb[4] and rb[5]
fpr.d[3] == rb[6] and rb[7]

fpr.s[0] == rb[0]
fpr.s[1] == rb[2]
fpr.s[2] == rb[4]
fpr.s[3] == rb[6]

in mode 0 it looks like:
fpr.d[0] == rb[0] and rb[1]
fpr.d[2] == rb[1] and rb[2]

fpr.s[0] == rb[0]
fpr.s[1] == rb[1]
fpr.s[2] == rb[2]
fpr.s[3] == rb[3]

Another idea would be to leave everything as it is in mode 1 and in mode change 
it to:
fpr.d[0] == rb[0] and rb[1]
fpr.d[2] == rb[3] and rb[4]

fpr.s[0] == rb[0]
fpr.s[1] == rb[1]
fpr.s[2] == rb[3]
fpr.s[3] == rb[4]

This is quite possible, but I cannot say for sure. Maybe someone can test it 
with
real hardware to ensure that it is done right as I am currently unsure who is it
doing right.

Just as reference. The linux cp1 emulator does it that way instead of the 
complete
separated registers.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/m
ips/math-emu/cp1emu.c;h=890f77927d628b0c203c92c7712415a9c52a819f;hb=74fca6a42863
ffacaf7ba6f1936a9f228950f657#l164

I attached a patch with the needed changes.

Original comment by sven@narfation.org on 29 Sep 2009 at 11:54

Attachments:

GoogleCodeExporter commented 8 years ago 
http://groups.csail.mit.edu/cag/raw/documents/R4400_Uman_book_Ed2.pdf has a 
small
hint on pdf page 184 and 661. But if it is really implemented in that way then
everything gets more complex.

Original comment by sven@narfation.org on 30 Sep 2009 at 12:48

GoogleCodeExporter commented 8 years ago 
I think the diagram on p185 explains almost everything you need to know; it 
agrees
with the spec on p661.  The only behavior that seems undefined is what happens 
to the
upper 32 bits of the FGRs during 32-bit operations (in mode 0), and when the CPU
switches from mode 0 to mode 1.

It should be possible to emulate this without too much trouble.  All 32 of the 
FGRs
need to be 64 bits wide, and you just need to move the pointers and data around 
when
the mode gets switched.  When it switches from mode 1 to mode 0, pack them into
adjacent 32-bit slots.  When it switches from mode 0 to mode 1, unpack them into
64-bit slots.  The only unfortunate thing is that the format of the data in the
savestate file will depend upon the value of the FR bit.

Original comment by richard...@gmail.com on 30 Sep 2009 at 1:59

GoogleCodeExporter commented 8 years ago 
No, the format can be mapped to the 64-bit on save and back on load. This isn't 
real
the problem. Just have to check out what imperas said as they have the only 
open MIPS
certified architecture I know.

Original comment by sven@narfation.org on 30 Sep 2009 at 8:31

GoogleCodeExporter commented 8 years ago 
@richard42g: Just as sidenote. It doesn't explain if the fgrs just gets reduced 
to 32
bit for all operations and lower 32 bits are kept or it just switches to extra
registers which are 32 bit wide.

Just implemented the behavior which we think are correct while reading the
documentation with shared FGRs for 32 bit and 64 bit mode. The emulator has 
separate
register banks for 32 bit and 64 bit, but they get synced on switch, load and 
save. I
think it is currently the easiest way to implement the behavior we think that is
correct at the moment.

Original comment by sven@narfation.org on 30 Sep 2009 at 11:14

Attachments: