Very nasty quick fix for sVU and VU interpreter regression in r3648. I have no idea why it's desirable to be able to move the VU registers structure after initialisation and a proper fix allowing for this is going to messy. Needs Jake's attention.

git-svn-id: http://pcsx2.googlecode.com/svn/trunk@3673 96395faa-99c1-11dd-bbfe-3dabce05a288
This commit is contained in:
sudonim1 2010-08-21 14:50:45 +00:00
parent 112800cb98
commit 8aee9f652d
3 changed files with 6 additions and 4 deletions

View File

@ -422,6 +422,8 @@ void SysClearExecutionCache()
Cpu->Reset();
psxCpu->Reset();
if (CHECK_EEREC)
((BaseVUmicroCPU*)GetCpuProviders().CpuProviders->microVU0)->Reset();
CpuVU0->Reset();
CpuVU1->Reset();

View File

@ -43,12 +43,12 @@ protected:
class SysCpuProviderPack
{
protected:
ScopedPtr<CpuInitializerSet> CpuProviders;
ScopedPtr<BaseException> m_RecExceptionEE;
ScopedPtr<BaseException> m_RecExceptionIOP;
public:
ScopedPtr<CpuInitializerSet> CpuProviders;
SysCpuProviderPack();
virtual ~SysCpuProviderPack() throw();

View File

@ -63,7 +63,7 @@ static vtlbHandler UnmappedPhyHandler1;
template< typename DataType >
DataType __fastcall vtlb_memRead(u32 addr)
{
static const uint DataSize = sizeof(DataType);
static const uint DataSize = sizeof(DataType) * 8;
u32 vmv=vtlbdata.vmap[addr>>VTLB_PAGE_BITS];
s32 ppf=addr+vmv;
@ -134,7 +134,7 @@ void __fastcall vtlb_memRead128(u32 mem, u64 (&out)[2])
template< typename DataType >
void __fastcall vtlb_memWrite(u32 addr, DataType data)
{
static const uint DataSize = sizeof(DataType);
static const uint DataSize = sizeof(DataType) * 8;
u32 vmv=vtlbdata.vmap[addr>>VTLB_PAGE_BITS];
s32 ppf=addr+vmv;