Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #181  
Old 10th May 2013, 04:46 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
Ah, I might have forgotten something.

In RunRSP you applied this:
Code:
void RunRSP()
{
	unsigned int TaskType;

	// clear all registers
	memset(&RspRegs, 0, sizeof(RspRegs));
...
Again, I have no HLE-in-the-plugins experience here, but this raises a couple questions to me.

First, most of the RSP registers are powered on to a randomized/undefined state and value. The exceptions include the 8 RSP accumulator segments and some bits of the system control (CP0) registers and status flags.
The game software is always responsible for initializing these registers after system startup, or else their value is undefined (not necessarily zero'd).

So is it really necessary to zero the memory for RspRegs every time there is an RSP task to execute?

--------

Second, I'm not sure whether this check is really necessary.
Code:
	TaskType = *((unsigned int *)(RSP.DMEM + 0xFC0));

	if (TaskType == 2)
		run_microcode();
When the CPU host knows there is a SP task, it tells the RSP plugin first.
If the RSP plugin judges it to be a audio task, it can request your audio plugin to HLE it.

So you're checking here to make sure it's an audio task in case the RSP plugin was wrong about it being an audio task.
This is stable and safe and fine, but slower because your if() causes an extra branch every time we want to run something in HLE.

The branch frame could be worked around like this:
Code:
if (TaskType != 2)
    // MessageBoxA(NULL, "RSP thought this task was aud?", NULL, 0x00000030);
    return;
else
    run_microcode(); // Rename this to `run_task()` for my next release
Some of that other code (clear SP_STATUS_HALT, reset the program counter) might also be obsolete/redundant since the main CPU (pj64) or indirectly the RSP plugin itself is responsible for maintaining that security, but again you might keep it there just to be safe.
Thanks, got it.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit
Reply With Quote
  #182  
Old 10th May 2013, 04:53 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
The implementation seems simple enough to secure, though I don't really know any experience with setting up audio HLE from a LLE RSP.

I see you based off a new template of zilmar's InitiateRSP off the one from the plugin specs, using only the elementary pointer symbols needed for audio, DMA and such.

I was curious if this would work in your audio HLE plugin?

Code:
// #undef  SEMAPHORE_LOCK_CORRECTIONS
/* The CPU-RSP semaphore is a lock defining synchronization with the host.
 * As of the time in which bpoint reversed the RSP, host interpretation of
 * this lock was incorrect.  The problem has been inherent for a very long
 * time until a rather recent update applied between Project64 1.7:2.0.
 *
 * If this is on, 1964 and Mupen64 will have no sound for [any?] games.
 * It will be almost completely useless on Project64 1.6 or older.
 * The exception is HLE audio, where it will work for almost every game.
 *
 * Keep this off when using audio LLE or playing games booting off the NUS-
 * CIC-6105 chip (also uses the semaphore); keep it on with Project64 2.0.
 */

#define SEMAPHORE_LOCK_CORRECTIONS // Recommended only for CPUs supporting it
To execute on LLE it needs Project64 2.x's CPU, but I'm not sure what happens if you try it in HLE...

For your own analysis, this macro is only used in $(rsp)/su/cop0/mfc0.h, reading from SP_SEMAPHORE_REG.
I have question for this part. Inside audio plugin, there are no way to get the rsp context. Since at InitiateAudio (AUDIO_INFO Audio_Info), all the information passed to audio plugin has nothing to do with RSP.

Code:
typedef struct {
	HWND hwnd;
	HINSTANCE hinst;

	BOOL MemoryBswaped;    // If this is set to TRUE, then the memory has been pre
	                       //   bswap on a dword (32 bits) boundry 
						   //	eg. the first 8 bytes are stored like this:
	                       //        4 3 2 1   8 7 6 5
	BYTE * HEADER;	// This is the rom header (first 40h bytes of the rom
					// This will be in the same memory format as the rest of the memory.
	BYTE * RDRAM;
	BYTE * DMEM;
	BYTE * IMEM;

	DWORD * MI_INTR_REG;

	DWORD * AI_DRAM_ADDR_REG;
	DWORD * AI_LEN_REG;
	DWORD * AI_CONTROL_REG;
	DWORD * AI_STATUS_REG;
	DWORD * AI_DACRATE_REG;
	DWORD * AI_BITRATE_REG;

	void (*CheckInterrupts)( void );
} AUDIO_INFO;
So if audio plugin wants to take advantage of SP_SEMAPHORE_REG, no matter to use LLE RSP or not, how to get that semaphore register?
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit

Last edited by shunyuan; 10th May 2013 at 04:56 PM.
Reply With Quote
  #183  
Old 10th May 2013, 04:57 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Honestly I don't know lmao

But, in `mfc0.h` where your HLE audio pre-compiles the microcodes for doing HLE, are already several instances of the RSP registers being read from.

Somehow (I really don't know how.) your audio HLE plugin is already simulating those reads from the SP system control registers, so whatever method was already being done for that, maybe it could be done for updating the SP_SEMAPHORE_REG lock algorithm in the manner defined in that file.
Reply With Quote
  #184  
Old 10th May 2013, 05:07 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
Honestly I don't know lmao

But, in `mfc0.h` where your HLE audio pre-compiles the microcodes for doing HLE, are already several instances of the RSP registers being read from.

Somehow (I really don't know how.) your audio HLE plugin is already simulating those reads from the SP system control registers, so whatever method was already being done for that, maybe it could be done for updating the SP_SEMAPHORE_REG lock algorithm in the manner defined in that file.
Because I have my own copy of RSP registers in audio plugin, defined at rsp_interface.c.

Code:
/************************************************************************** 
 * rsp_interface by Shunyuan
 *
 * A simple interface for LLE RSP to make other module can use RSP engine
 * 
 * NOTE: The LLE RSP is written by CDX4 (Iconoclast).
 ***************************************************************************/
#include <Windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "rsp.h"

RSP_REGS	RspRegs;
RSP_INFO	RSP;

static void DummyFunc(void) {}

void InitiateRSP(unsigned char *RDRAM, unsigned char *DMEM, unsigned char *IMEM)
{
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit

Last edited by shunyuan; 10th May 2013 at 05:10 PM.
Reply With Quote
  #185  
Old 10th May 2013, 05:19 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Yeah I saw that; I just didn't think how audio plugin would access it.
I guess RspRegs is meant to be more than just some virtual typedef; it should be an entirely separate machine instance for replicating on the audio.

So it would be: `*RspRegs.SP_SEMAPHORE_REG`.

But all you would have to do is un-comment the #define by `// #define SEMAPHORE_LOCK_CORRECTIONS` in config.h, and I think it would apply the change for you in the HLE audio compiler.

If it does the whole thing out in LLE first while compiling though then it might still be broken....
Reply With Quote
  #186  
Old 10th May 2013, 05:30 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
Yeah I saw that; I just didn't think how audio plugin would access it.
I guess RspRegs is meant to be more than just some virtual typedef; it should be an entirely separate machine instance for replicating on the audio.

So it would be: `*RspRegs.SP_SEMAPHORE_REG`.

But all you would have to do is un-comment the #define by `// #define SEMAPHORE_LOCK_CORRECTIONS` in config.h, and I think it would apply the change for you in the HLE audio compiler.

If it does the whole thing out in LLE first while compiling though then it might still be broken....
Thanks, I got it.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit
Reply With Quote
  #187  
Old 10th May 2013, 07:22 PM
mesk14's Avatar
mesk14 mesk14 is offline
Junior Member
 
Join Date: Sep 2010
Posts: 19
Default

Quote:
Originally Posted by FatCat View Post
I actually just finished doing that a few days ago. But feel free to play OOT anyway, haven't done MM yet.
No problems? Were you able yo complete the game? Did you use z64gl? Ill probably play MM instead,as I was only going to play OoT to help test the plugin.
__________________
Intel core i5 3470 @ 3.9
8gb ddr 3 ram
GTX 460 1gb
Reply With Quote
  #188  
Old 11th May 2013, 12:13 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by mesk14 View Post
No problems? Were you able yo complete the game? Did you use z64gl? Ill probably play MM instead,as I was only going to play OoT to help test the plugin.
I did use z64gl, though atm it seems that packing my computer up and taking it with me to another state might have interfered somehow...I can only start games using Jabo's Direct3D LLE and not z64gl LLE.

Haven't worried about it much to isolate why.

I was able to complete the game just fine.
I did run into some "Weird addr." warning messages along the way, but they turned out to be unpredictable/random because re-loading saved states to try to get the errors to pop up again failed. They were probably caused by the VR4300 host CPU recompiler core and not my RSP interpreter.

So yes, completely playable.

But Zelda Majora's Mask!
My favorite game, didn't run it yet to find out.

Zelda MM however is unplayable on ziggy's RSP plugin for z64gl.
He and Ville Linde of MAME omitted the almost-never-used BLTZAL scalar operation, but angrylion eventually added it back in. I based my implementation off the official MIPS R4000 manual at the time.

So !
Can't play Zelda MM in LLE without using my RSP plugin or maybe zilmar's RSP (recompiler/interpreter?).
Reply With Quote
  #189  
Old 12th May 2013, 01:36 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Studies show that assembly output is optimized better when I vectorize the split steps in a vector operation.

For example, a traditional Vector Multiply emulator, does
Code:
VMUL.cond ::

for (int i = 0; i < 8; i++) {
    multiplyElements();
    storeProductToAccumulator();
    WBAccToVRFile();
    UpdateVCF(); // set/clear vector control flag registers, if needed
}
Parallelization of the simultaneous vector hits is better achieved and optimized by splitting the loops:
Code:
register int i;

for (i = 0; i < 8; i++)
    multiplyElements();
for (i = 0; i < 8; i++)
    storeProductToAccumulator();
for (i = 0; i < 8; i++)
    WBAccToVRFile();
for (i = 0; i < 8; i++)
    UpdateVCF(); // again, only if non-SGI VU uses these in VMUL
While some of the SGI versions convert from the scalar-limited Intel PCs easily enough (Vector Logical :: [N]AND/OR/XOR), others (Vector Select/Clip and the Vector Add group :: VADD/VADDC/VSUB/VSUBC/VABS/VSAR) do not.

Code:
static void VADDC(int vd, int vs, int vt, int e)
{
    unsigned int result[8];
    register int i;

    VCO = 0x0000;
    for (i = 0; i < 8; i++)
        result[i] = (unsigned short)VR[vs][i] + (unsigned short)VR_T(i);
    for (i = 0; i < 8; i++)
        VACC[i].s[LO] = (short)result;
    for (i = 0; i < 8; i++)
        VCO |= (result[i] > 0x0000FFFF) << i; /* (result[i] >> 16) << i */
    for (i = 0; i < 8; i++)
        VR[vd][i] = VACC[i].s[LO];
    return;
}
Let `result` be a software vector register of n=8 elements, 32 bits wide, storing the additive computational result of the zero-extended 16-bit shorts VS and VT, of two vector registers respectively of the n=8 elements =16b wide vector register file.

If the `VR_T(i)` macro is defined to indicate a shuffled vector/scalar coefficient, the compiler could optimize the very first loop to be a single SSEz vector instruction on the Intel machine.

This is the accurate way to do it because the documentation says so. Obviously it would be faster (but less accurate) to say, shift `result[i]` over by 16 bits. The result is either going to be 0 or 1, so mask that into VCO.

Only because, summation of 2 non-sign-extended 16-bit-wide registers, can never exceed 0x0001FFFE.
Reply With Quote
  #190  
Old 12th May 2013, 03:21 AM
the_randomizer's Avatar
the_randomizer the_randomizer is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Sep 2008
Location: USA
Posts: 1,136
Default

If you need more testing, just say the word
__________________
My rig:
CPU: Intel Core i7 4470 3.4 GHz to 3.9 GHz
Video card:: MSI nVidia GTX 970 4 GB GDDR5
OS: Windows 7 Professional 64-bit
RAM: 16 GB DDR3 SDRAM 10600
HDD: 2 x Western Digital 1 TB HDDs
Monitor: 23" Asus Full HD LED

Oh, and Snes9x > Zsnes in every way
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 02:14 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.