[Official Comment Thread] Pcsx2 svn snapshots and user-compiled svn revs

[Icieles]

Trickbox. The plugin settings moved. It's all good.

[Bositman]

Can you take a screenshot? All icons show fine here.

[Icieles]

The plugins used to have an icon under config > emulation settings. They have been moved to Config > Plugin/Bios Selector.

[seemees]

I complile last snapshot via Visual Studio 2008. Then I try to start pcsx2_deb.exe in debug mode (F5). All ok. Then I open ISO image for game (SIlent Hill Origins U NTSC). And try to start this ISO in full mode.
Video plugin is in window mode. After video window appearing I get an error. Program try to write in protected address. I check address of instruction that goes in error. It is a compiled code from PS2 compiler.
In the code I see many instruction like this:

mov eax, ds:[addr]

or mov ds:[addr], eax

and so on. But ds point to address 0x00000000. I think that in the start of all compiled codes you must set ds address always. Like this:

mov ax, csAVEDS
push ax
pop ds

and before call compiled thread we must set csAVEDS to original ds.
This error appears after switch from one thread to another. OS Windows XP SP3.

Please check out all compiled blocks and before call them from start set right ds register.

With best regards, seemees

[Air]

[...] After video window appearing I get an error. Program try to write in protected address. I check address of instruction that goes in error. It is a compiled code from PS2 compiler.
In the code I see many instruction like this:

mov eax, ds:[addr]

or mov ds:[addr], eax

and so on. But ds point to address 0x00000000. I think that in the start of all compiled codes you must set ds address always. Like this:

mov ax, csAVEDS
push ax
pop ds

and before call compiled thread we must set csAVEDS to original ds.
This error appears after switch from one thread to another. OS Windows XP SP3.

Please check out all compiled blocks and before call them from start set right ds register.

Modern 32 and 64 bit "protected mode" operating systems (Linux and Windows 2000 / XP / Vista / 7 /and beyond!!) use the CPU's virtual memory mapping features (aka TLB or MMU). In 32 bit modes the CS and DS registers both point to 0x00000000 for all processes (applications!) running on the computer. In 64 bit modes these registers are simply missing, since they were long since useless anyway.

Then it gets complicated: Each process has its own virtual memory map, so if you have PCSX2 and Visual Studio running, for example, each program has its own unique 4GB map of memory, starting at 0x00000000. Where and how this virtual memory is mapped to the actual physical ram of your computer depends on approximately 236 million things.

In any case, the bottom line is that your code sample is for programs written in 16 bit DOS. You'll need to time machine back about 20 years for it to be relevant to modern computing.

[vsub]

The data base(GameIndex.dbf) says that the game Sphinx and the Cursed Mummy NTSC don't work at all(status Nothing)but the game work fine on r3596 and the newest official beta plugins.

[seemees]

Modern 32 and 64 bit "protected mode" operating systems (Linux and Windows 2000 / XP / Vista / 7 /and beyond!!) use the CPU's virtual memory mapping features (aka TLB or MMU). In 32 bit modes the CS and DS registers both point to 0x00000000 for all processes (applications!) running on the computer. In 64 bit modes these registers are simply missing, since they were long since useless anyway.

In any case, the bottom line is that your code sample is for programs written in 16 bit DOS. You'll need to time machine back about 20 years for it to be relevant to modern computing.

ok, I check out configuration pcsx2 and find, that really happens in my case. The ds register sometimes destroys and we need to restore it. But ss register is correct, and now we can easy try this:

push ss
pop ds

its work (on my machine). But I faced up with another error:
in JIT code i'll see that (only if we set "Super VU recompiler [Legacy]" in options):

mov eax,ds:[0x30c]

if ds correct, 0x30c bad address any way. I shocked, but this code is from SuperVU recompiler. In it I see this (file microVU.cpp):

// Caches Micro Program
_mVUt __fi void mVUcacheProg(microProgram& prog) {
microVU* mVU = mVUx;
if (!vuIndex) memcpy_const(prog.data, mVU->regs->Micro, 0x1000);
else memcpy_const(prog.data, mVU->regs->Micro, 0x4000);
mVUdumpProg(prog);
}


In this function we use mVU->regs->Micro, but mVU->regs = 0x0 (regs is
stay uninitialized and show to nothing or to NULL). And this string goes to error: Bad read ptr. I try to find initialization of mVU:

But in file microVU.cpp in function mVUInit regs not initialized. Only regAlloc.

// Only run this once per VU!
static __ri void mVUinit(int vuIndex) {
...
mVU->regAlloc = new microRegAlloc();
....
}
I think that mVU->regs stay uninitialized here, and thats why it point at
0x0 address (or any error address). May be try this string in this function?

mVU->regs = new VURegs();


Thanks for answer.
And please check out file pthread_mutex_destroy.c
and same files. Right in function

int
pthread_mutex_destroy (pthread_mutex_t * mutex)
{
....
{
mx = *mutex; // Here sometimes *mutex=0x0!

//We need here check if(mx == 0) return 0; //or INVAL?
//Cause next string goes to error - bad read/write ptr 0x0!


result = pthread_mutex_trylock (&mx);


....
}


Between mx = ... and result = ... I suggest insert if instruction:

if(mx==NULL)
return 0;


This eliminate error. Same error can be in all pthread files. Easy to find in
3rdparty\w32pthreads directory with search string "mx =" (with space after mx).

With best regards, seemees

[vsub]

Just wanted to mention something(if no one saw this)
"Config=>Game Database Editor" opens the memory card manager.
I don't know on which rev this problem started(or if it's actually a problem because this is new menu)

BTW thanks for the fixed memory address,now cheating on newer revs won't be a problems

[Shadow Lady]

Right... game database editor shouldn't be there in the first place, must have been added in the newhostvm merge

[leostrife]

Bug in the textures of god of war, the last revisions in version 1.0.0 runs without bug.
This bug has been tested on SNV r5402.

http://img526.imageshack.us/slideshow/we...462768.png