Developers wanted for PCSX Revival!

[shalma]

Whistler made this find:
PCSX-Reloaded - View Issue #3759: Final Fantasy 8 - Analogue sticks are busted in Menu's

(pcsxr-1.9.91\plugins\dfinput\analog.c)


Lilypad doesn't seem to rely on a 'hard' centering value - uses lots of saturate limits / rounding math. Perchance comes out okay using those methods.

The other two have that +128 value like the doc suggests. Then again, the official SNES / SMS docs aren't all that accurate (to a point).

I guess if we had someone who understands the console write an app, we'd be done. (darn)

I'm curious what the FF8 asm trace code does differently when 127->128. Don't have any analog joysticks to try it out though.

[shalma]

Kind of interesting (and maddening) change of pace from disc kits.
Maybe I _can_ use my current hacking abilities for this stuff.


Here's what I've found out about Syphon Filter lockups:
- Game does 'CdlSetloc'
- Game does 'CdlSeekL'
- CD1 reg returns 0x22
- Infinite loop waiting for (?) to happen


Now if we do this:
- Game does 'CdlSetloc'
- Game does 'CdlSeekL'
- CD1 reg returns 0x02
- Plays REMAINING movies PLUS gameplay




WORKING FIX:

libpcsxcore\cdrom.c


#define StopReading() { \
	if (cdr.Reading) { \
		cdr.Reading = 0; \
		psxRegs.interrupt&=~0x40000; \
	} \
        //Turns off CDROM 'read busy' flag
	cdr.StatP &= ~0x20;\
}

Backup src:
ePSXe 170

---

Last edited by shalma; February 11th, 2010 at 15:38.. Reason: syphon filter fix

[Kaizen]

Originally Posted by shalma

Whistler made this find:
PCSX-Reloaded - View Issue #3759: Final Fantasy 8 - Analogue sticks are busted in Menu's

(pcsxr-1.9.91\plugins\dfinput\analog.c)


Lilypad doesn't seem to rely on a 'hard' centering value - uses lots of saturate limits / rounding math. Perchance comes out okay using those methods.

The other two have that +128 value like the doc suggests. Then again, the official SNES / SMS docs aren't all that accurate (to a point).

I guess if we had someone who understands the console write an app, we'd be done. (darn)

I'm curious what the FF8 asm trace code does differently when 127->128. Don't have any analog joysticks to try it out though.

...Final Fantasy 8 doesn't use analog sticks in the menu.

__________________
OCHRE YELLOW.

[Squall-Leonhart]

Yes it does.


ah, finally a reason it does that...

---

Last edited by Squall-Leonhart; February 10th, 2010 at 23:27.. Reason: Automerged Doublepost

[Squall-Leonhart]

Physically the range is 0 - 255. However the Axis correct range is 0 - 254 as the psx and games rely on a whole 127 in this case as the true center.

---

Last edited by Squall-Leonhart; March 10th, 2010 at 08:26..

[shalma]

Simple math.

Thanks! I'll save that explanation in my own PCSX diaries. (:

[shalma]

Syphon Filter fix finalized:
http://forums.ngemu.com/pcsx-discuss...ml#post1799445

Verified with ePSXe 170.


Harvest Moon is waiting for a GPU DMA transfer. Not sure why it misses - timing or hidden DMA trigger?


NOTE:
SF1 problems is that reading from CDROM triggers $20 flag (read busy).
Syphon Filter is waiting for the flag to lower (no more CD reading).
PCSX needs to fix that.

---

Last edited by shalma; February 11th, 2010 at 17:17..

[Squall-Leonhart]

which cd plugin?

[shalma]

Technically any CD plugin will work (I'm using SaPu 1.3) - it's the core cdrom behavior that needed fixing up on the emu side.

Short summary:
- CdlReadN is issued
- Emu raises $20 flag (reading from CDROM)
- CdlSetloc stops CDROM reading (for playing new movie)
- Bug: PCSX fails to lower the $20 flag
- Game keeps issuing CdlSetloc until PCSX tells game that the CDROM is ready for new commands

So we add that fix and the game works great!

Or am I misunderstanding something..? :confused:


EDIT:
If you mean Harvest Moon, SaPu 1.3 works with pSX 1.13, ePSXe 1.7.0, and PCSX 1.4 but not PCSX 1.1,1.5+

---

Last edited by shalma; February 11th, 2010 at 17:16..

[shalma]

PROBLEM:
Harvest Moon writes a DMA. Doesn't intentionally start it.
Reads the -value- it wrote into HW_DMA2_CHCR to verify its working.

PCSX doesn't update HW_DMA2_CHCR so game thinks DMA is broken.



FIX:

libpcsxcore\psxhw.c

#define DmaExec(n) { \
  if (SWAPu32(HW_DMA##n##_CHCR) & 0x01000000) \
  { \
    HW_DMA##n##_CHCR = SWAPu32(value); \
    return; \
  }\
  HW_DMA##n##_CHCR = SWAPu32(value); \
 \
  if (SWAPu32(HW_DMA##n##_CHCR) & 0x01000000 && SWAPu32(HW_DMA_PCR) & (8 << (n * 4))) { \
    psxDma##n(HW_DMA##n##_MADR, HW_DMA##n##_BCR, HW_DMA##n##_CHCR); \
  } \
}

backup src: ePSXe 170



QUESTION:
Now here's where ePSXe differs:

#define DmaExec(n) { \
  HW_DMA##n##_CHCR = SWAPu32(value); \
 \
  if (SWAPu32(HW_DMA##n##_CHCR) & 0x01000000 && SWAPu32(HW_DMA_PCR) & (8 << (n * 4))) { \
    psxDma##n(HW_DMA##n##_MADR, HW_DMA##n##_BCR, HW_DMA##n##_CHCR); \
  } \

It may not actually matter but I'm sticking with the above version for now.
If something breaks, let us know!!

But yeah, the game works now.

[Squall-Leonhart]

Dude, you might end up fixing the issue where sapu cdr doesn't boot pal/protected games in pcsx (disk reads subchannel then pauses waiting for data?)

[Whistler]

good job shalma

as for the PAL versions of FF8/FF9, I think there is an error in the subq struct in the original PCSX but it still can't get around of that protection with that error corrected.

__________________

[nhyone]

shalma, looks like you have fixed two bugs.

Just wondering, do you have the ePSXe source or did you reverse engineered it and present it in PCSX source style?

I'm still digesting PCSX's code. So far, I haven't seen any obvious hacks except for the root counters. (Which is good.)

Also, it seems to me PCSX does not detect self-modifying code, so such code will fail for the recompiler. Is such code common?

__________________
(void *) &NHY;

[shalma]

Thanks everyone

I've RE'd several parts of the ePSXe emulator (since I had to hack it for a pseudo-DVD5 support).

Self-modifying code.. I don't remember seeing any yet. I wouldn't be surprised though - from hearsay experience, it'd usually be the Japan games that do some oddball, undocumented trickery.

If the interpreter works but the recompiler fails, that'd be a good place to start.

[shalma]

I'll explain the FF9 PAL problem this way:


First PCSX has to return the correct sub-q data. Which is correct with pcsx-r (and not the old pcsx build).

backup src: ePSXe


Now here's the biggie:

(PCSX)
- Cdlsetloc 3:8:2
- Reads
- ACK = Reads 3:8:2
- ACK = Reads 3:8:3
- CdlGetlocP gets sub-q @ 3:8:3
- ACK = Reads 3:8:4
- CdlGetlocP gets sub-q @ 3:8:4


(ePSXe)
- Cdlsetloc 3:8:2
- Reads
- ACK = Reads 3:8:2
- CdlGetlocP gets sub-q @ 3:8:2
- ACK = Reads 3:8:3
- CdlGetlocP gets sub-q @ 3:8:3
- ACK = Reads 3:8:4
- CdlGetlocP gets sub-q @ 3:8:4


Which is why our fail occurs.
That looks like a timing issue to me (atm). xx(

[nhyone]

Originally Posted by shalma

(PCSX)
- Cdlsetloc 3:8:2
- Reads
- ACK = Reads 3:8:2
- ACK = Reads 3:8:3
- CdlGetlocP gets sub-q @ 3:8:3
- ACK = Reads 3:8:4
- CdlGetlocP gets sub-q @ 3:8:4

Is it possible to see the code around that region? The first thing that comes to mind is that PCSX only updates the interrupt status at branches.

__________________
(void *) &NHY;

[nhyone]

Since I'm still trying to find my feet around PSX emulation, I thought I'll see how the various sub-systems are used.

During a standard 3D scene, interpreter mode:

    instr/s   cop0/s    cop2/s     mdec       gpu      spu
15092142.00  1895.72 487292.19     0.00   8971.93   510.49

      mdec      mdec       gpu    cdrom      spu      pio      gpu
      dma0      dma1      dma2     dma3     dma4     dma5     dma6
      0.00      0.00    985.82     0.00     0.00     0.00   107.53

My 1.2 GHz CULV CPU could only emulate 15M instructions/s (including COP0 and COP2). I'm surprised that there are COP0 instructions. I thought COP0 is used for memory management.

COP2 = GTE.

GPU, MDEC, SPU and DMA are #request/s.

During a movie playback, interpreter mode:

    instr/s   cop0/s    cop2/s     mdec       gpu      spu
27749778.00  8575.50 181931.02    48.89  14404.13   205.87

      mdec      mdec       gpu    cdrom      spu      pio      gpu
      dma0      dma1      dma2     dma3     dma4     dma5     dma6
     24.44    977.73   1442.15   456.82     5.16     0.00    97.77

MDEC is used, obviously. But I am surprised the GTE and GPUs are used too. (May be scene specific -- I only checked this scene.)

We are able to emulate 27M instructions here. I suspect it is because fewer GTE instructions are used -- they are more computational intensive.

Some of the values seem excessively high: 8k GPU calls? 1k GPU DMAs? (1,000 = once per ms. That's very high.)

__________________
(void *) &NHY;

[shalma]

MDEC requires DMA-in from RAM + DMA-out to GPU. GTE = shrug

COP0 is sometimes used to 'hide' data or put them in scratchpad RAM (1f region).

DMA2 = GPU mem2vram, vram2mem


FF9 PAL - it may just be that PCSX is pre-caching the data too early. Still can't get it to boot yet.



EDIT:
I see what's going on. Still don't know where ePSXe handles interrupts yet.

PCSX:

 3:14.30 [385E]
 3:14.31 [385F]
 3:14.32 [3860]
 3:14.33 [3861]
 3:14.34 [3862]
 (===========================)
 3:15.21 [38A0]
 3:15.22 [38A1]
 3:15.23 [38A2]
 3:15.24 [38A3]
 3:15.25 [38A4]
 3:15.26 [38A5]
 3:15.27 [38A6]
 3:15.28 [38A7]
 3:15.29 [38A8]
 (===========================)
 3:18.46 [399A]
 3:18.47 [399B]
 3:18.48 [399C]
 3:18.49 [399D]

ePSXe

[PEOPS] 3:14:30
[PEOPS] 3:14:31
[PEOPS] 3:14:32
[PEOPS] 3:14:33
[PEOPS] 3:14:34
[PEOPS] 3:14:35 (===========================)
[PEOPS] 3:15:21
[PEOPS] 3:15:22
[PEOPS] 3:15:23
[PEOPS] 3:15:24
[PEOPS] 3:15:25
[PEOPS] 3:15:26
[PEOPS] 3:15:27
[PEOPS] 3:15:28
[PEOPS] 3:15:29
[PEOPS] 3:15:30 (===========================)
[PEOPS] 3:18:46
[PEOPS] 3:18:47
[PEOPS] 3:18:48
[PEOPS] 3:18:49

---

Last edited by shalma; February 13th, 2010 at 13:37..

[shalma]

FIX: LibCrypt subchannel protection (FF8/FF9/PAL/Soul Reaver/..)


GetlocP subQ data is not returned correctly
Also if the subQ times are bad, then return 'invalid' data

libpcsxcore\plugins.h

struct SubQ {
  char res0[12];                         // 00-0B
  unsigned char ControlAndADR;           // 0C
  unsigned char TrackNumber;             // 0D
  unsigned char IndexNumber;             // 0E
  unsigned char TrackRelativeAddress[3]; // 0F-11
  unsigned char Filler;                  // 12
  unsigned char AbsoluteAddress[3];      // 13-16
  char res1[71];
};

src: ePSXe 170

libpcsxcore\cdrom.cpp



static char cdr_localTime[3];
void Convert_LocalTime( char *time )
{
  cdr_localTime[0] = btoi(time[0]);
  cdr_localTime[1] = btoi(time[1]) - 2;
  cdr_localTime[2] = time[2];

  // m:s adjustment
  if( cdr_localTime[1] < 0 )
  {
    cdr_localTime[1] += 60;
    cdr_localTime[0] -= 1;
  }

  cdr_localTime[1] = itob(cdr_localTime[1]);
  cdr_localTime[0] = itob(cdr_localTime[0]);
}




      case CdlGetlocP:
      SetResultSize(8);
      subq = (struct SubQ*) CDR_getBufferSub();

      Convert_LocalTime( cdr.Prev );

      if (subq != NULL) {
        cdr.Result[0] = subq->TrackNumber;
        cdr.Result[1] = subq->IndexNumber;
        memcpy(cdr.Result+2, subq->TrackRelativeAddress, 3);
        memcpy(cdr.Result+5, subq->AbsoluteAddress, 3);


        // subQ integrity check
        if( cdr_localTime[0] != cdr.Result[2] ||
            cdr_localTime[1] != cdr.Result[3] ||
            cdr_localTime[2] != cdr.Result[4] ||
            cdr.Prev[0] != cdr.Result[5] ||
            cdr.Prev[1] != cdr.Result[6] ||
            cdr.Prev[2] != cdr.Result[7] )
        {
          // wipe out time data
          memset( cdr.Result+2, 0, 3+3 );
        }
      } else {
          cdr.Result[0] = 1;
          cdr.Result[1] = 1;
          memcpy( cdr.Result+2, cdr_localTime, 3 );
          memcpy( cdr.Result+5, cdr.Prev, 3 );
      }

      cdr.Stat = Acknowledge;
      break;

src: ePSXe 170




Here's the next part:

PCSX is updating the CDROM pointer -too early-, causing subchannel data
to return LBA+1 data

libpcsxcore\cdrom.c

Remove all calls to
//ReadTrack();


Now update this:
void cdrReadInterrupt()

ReadTrack();
buf = CDR_getBuffer();
if (buf == NULL) cdr.RErr = -1;

src: ePSXe 170



And PCSX is loading Square Europe logo.

Which reminds me that the ending crashed PCSX before when I was working on a disc kit.

EDIT:
MDEC crash. Figures. :|

---

Last edited by shalma; February 14th, 2010 at 03:24..

[Squall-Leonhart]

it wasn't just FF9 btw FF8 also paused when doing the subchannel reads