Closed GoogleCodeExporter closed 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
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
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
Can I have a savestate for this please
Original comment by sgorman07@gmail.com
on 27 May 2008 at 11:53
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
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
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
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
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
^ 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
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
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
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
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
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:
Does anyone have a savestate for this? The previous is dead.
Original comment by olejl77@gmail.com
on 18 Dec 2008 at 6:25
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
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
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
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
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
[deleted comment]
[deleted comment]
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:
[deleted comment]
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
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
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
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
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
[deleted comment]
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
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:
Cannot upload the file for pj64 as my quote is exceeded.
Original comment by sven@narfation.org
on 25 Sep 2009 at 8:44
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
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
[deleted comment]
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
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
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
[deleted comment]
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
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
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
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:
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:
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
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
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
@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:
Original issue reported on code.google.com by
doorkno...@gmail.com
on 13 Apr 2008 at 10:17