rsp_hle doesn't work on big endian systems

[GoogleCodeExporter]

I'm a developer on a fork of mupen64 0.5 for the GC/Wii: Wii64.  A lot of
our work involves working around memory constraints since for the most part
mupen64 is rather endian-neutral.  Until recently, we've been using an old
RSP plugin, rsp_hle-ppc, which was the only option for big endian systems.
 Unfortunately, the plugin was based on old code and generated low quality
sound.

We've recently have began working on fixing up rsp_hle to be endian
neutral.  We'd like to see users of big endian PCs benefit from our efforts
too so hopefully this patch can be incorporated into your code as well. 
Its possible that we've introduced regressions in little endian code.  This
code was tested very little, if at all, on little endian systems, but I did
my best to maintain the semantics on little endian systems.  Hopefully
these patches will apply to your rsp_hle, but if not, I can try to get ones
that will apply cleanly to your code.

Original issue reported on code.google.com by tehp...@gmail.com on 8 Oct 2009 at 11:39

Attachments:

• rsp_hle.diff

[GoogleCodeExporter]

I looked through it and I think it will not apply cleanly, but it shouldn't be 
too
hard to get that stuff fixed.

There is currently work done to get everything more modular. This means that 
the core
is a plugin by itself. Do you think that it could be possible to share the core
between the two projects? It would be the perfect help to get this thing 
working on
big endian and could also help you to get some emulation core bugs fixed.
I haven't looked at your project so cannot tell how many things you had to 
change to
get it running on GC/Wii.

Original comment by sven@narfation.org on 9 Oct 2009 at 8:16

[GoogleCodeExporter]

Sorry about the incompatibility, our plugins may have drifted a little bit, but 
the
logic part should be the same unless you guys have made any significant changes.

As for the PPC core: in an effort to save memory, I had to break away from some
aspects of the mupen64 dynarec core and rework its infrastructure myself.  This 
may
be less of an issue for you guys once you've separated out the r4300 core as a
separate entity, but its something to consider.

I think the core is pretty endian neutral, at least in mupen64 0.5.  The 
majority of
our changes for endianness were involving the RSP and graphics plugins.

Our project can be found at http://code.google.com/p/mupen64gc.  Recently, our 
work
has been in another repository and we're in the process of migrating the 
history into
google code's SVN now.  You'll want to grab the Beta 1 source download fow now. 
Hopefully within a week or so, the SVN will be up to speed with the source 
archive
though.

Original comment by tehp...@gmail.com on 9 Oct 2009 at 12:19

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 13 Jan 2010 at 1:21

• Added labels: Component-RSP-HLE, Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I applied your patch by hand and it is currently part of my for as 
38:9386d1dad330 -
I will go further through your repository and then request a merge into 
mainline.

I removed parts of the patch which only removed whitespaces or changed 
whitespaces.
Most parts look like straight forward changes, but some not really 

{{{
-            VolRamp_Right = *(s32*)&inst2; // 0x48/0x4A
+            VolRamp_Right = (s32)inst2; // 0x48/0x4A
}}}

(and other changes to the SETVOL and ENVMIXER3 functions). They are correct, 
but had
to think about it for a moment. The same with

{{{
-        location = (Accum >> 0xa) << 0x3;
-        lut = (s16 *)(((u8 *)ResampleLUT) + location);
+       // location is the fractional position between two samples
+        location = (Accum >> 0xa) * 4;
+        lut = (s16*)ResampleLUT + location;
}}}

You also had some changes in your repos which weren't included in that patch. 
It is
now part of 199ec8223923 (hope I didn't overlooked some interesting change). I 
will
add some kind of normalised diff so someone can guess if there is anything 
valuable
left for either mupen64gc or us.

Original comment by sven@narfation.org on 19 Apr 2010 at 8:24

[GoogleCodeExporter]

I tried to normalize the coding style of m64p and m64gc and to create a diff 
without
checking to much the whitespace problems. This of course created files which 
have a
complete different coding style than the original files - but I only wanted to 
get
the valuable differences and not a real patch which could be applied somewhere.

Base of the diff was mupen64gc rsp_hle from r947 and new files are from my m64p
rsp_hle fork 41:199ec8223923.

Original comment by sven@narfation.org on 19 Apr 2010 at 8:57

Attachments:

• m64gc_vs_m64p.normalised_diff

[GoogleCodeExporter]

Change I would recommend to m64gc would be the fix for issue 178 (is commit 
r1247
inside the old svn).

{{{
@@ -61,8 +50,11 @@ void jpg_uncompress(OSTask_t *task)
     short* data = (short*)(rsp.RDRAM + task->ucode_data);
     short m[8*32];

-    if (!task->flags & 1) {
-        memcpy(&jpg_data, rsp.RDRAM + task->data_ptr, task->data_size);
+    if (!(task->flags & 1)) {
+        int copysize = task->data_size;
+        if (copysize > sizeof(jpg_data))
+            copysize = sizeof(jpg_data);
+        memcpy(&jpg_data, rsp.RDRAM + task->data_ptr, copysize);
         q[0] = (short*)(rsp.RDRAM + jpg_data.m1);
         q[1] = (short*)(rsp.RDRAM + jpg_data.m2);
         q[2] = (short*)(rsp.RDRAM + jpg_data.m3);
}}}

The rest is more or less cleanup stuff or changes to the new api.

Original comment by sven@narfation.org on 22 Apr 2010 at 9:11

[GoogleCodeExporter]

@muellhierrein:
Yes, I had noticed that and was planning on porting over that change.  Thanks 
for
pointing it out though.

Original comment by tehp...@gmail.com on 22 Apr 2010 at 9:37

[GoogleCodeExporter]

I believe all of the endian bugs have been fixed in RSP-HLE, courtesy of 
Lazhur.  Please re-open if this is not the case.

Original comment by richard...@gmail.com on 29 Dec 2010 at 1:21

• Changed state: Fixed