Developers wanted for PCSX Revival!

[Squall-Leonhart]

Peops Dsound needs a look at, to determine why its failing to force audio sync with high compatibility mode.

[shalma]

PROBLEM:
http://forums.ngemu.com/psx-plugin-q...ml#post1871834

(Partial?) Fix for PEOPS DSound Async mode:

void SetupTimer(void)

#ifdef _WINDOWS
 if(iUseTimer==2)                      // windows: use timer
  {
   timeBeginPeriod(1);
  }
 if(iUseTimer==1)                      // windows: use timer
  {
   timeBeginPeriod(1);
   timeSetEvent(1,1,MAINProc,0,TIME_ONESHOT);
  }

void RemoveTimer(void)

#ifdef _WINDOWS

 if(iUseTimer==1) timeEndPeriod(1);                    // windows timer? stop it
 if(iUseTimer==2) timeEndPeriod(1);                    // windows timer? stop it

That comes closer to Modes 0-1. Have to check that video again - still seems a little laggy.


EDIT:
This solution may be incomplete.

---

Last edited by shalma; June 21st, 2010 at 17:34..

[the_randomizer]

Originally Posted by shalma

PROBLEM:
http://forums.ngemu.com/psx-plugin-q...ml#post1871834

(Partial?) Fix for PEOPS DSound Async mode:

void SetupTimer(void)

#ifdef _WINDOWS
 if(iUseTimer==2)                      // windows: use timer
  {
   timeBeginPeriod(1);
  }
 if(iUseTimer==1)                      // windows: use timer
  {
   timeBeginPeriod(1);
   timeSetEvent(1,1,MAINProc,0,TIME_ONESHOT);
  }

void RemoveTimer(void)

#ifdef _WINDOWS

 if(iUseTimer==1) timeEndPeriod(1);                    // windows timer? stop it
 if(iUseTimer==2) timeEndPeriod(1);                    // windows timer? stop it

That comes closer to Modes 0-1. Have to check that video again - still seems a little laggy.

Yeah, please look at the video again; I think changing that made the audio playback smoother, but the video/audio sync still lags (listen to Square Enix games, that's where you can notice it the most).

[Searinox]

FF9 crashes the emu as soon as a battle starts, when using HLE BIOS. This stops happening if using a BIOS image. Issue's been around for a month's worth of builds I think.

Problem Event Name: APPCRASH
Application Name: pcsx.exe
Application Version: 1.0.0.1
Application Timestamp: 4c220675
Fault Module Name: pcsx.exe
Fault Module Version: 1.0.0.1
Fault Module Timestamp: 4c220675
Exception Code: c0000005
Exception Offset: 000190f9
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[shalma]

ePSXe calls SPUasync every $10C40 = 68672 CPU cycles (exactly every time) --> 493-494 times

PCSX-r (old SPUasync) every $C000-C100 = 49152 CPU cycles (varies every time)

Haven't tried edgbla's new async timing fix yet.


EDIT:
Ideally we'd SPUasync( CLKRATE / 44100 ) to create 1 audio packet per APU cycle. Which requires at least a 1.4 GHz machine.

So the emu authors use a scaled value (x50, x60, x64, x100) but we could miss out on ADSR, Noise, Fmod changes within that window; we might accidentally uniformly apply those updates to the -whole- 1ms data (~45 frames) (ex. PEOPS..?). Eternal maybe has a better way to handle it though.

If we had a way to log the cycle time for every SPU register write, then we could do our own event-system for updating the sound envelopes within the plugin. And keep the higher async rates = more FPS.

But, eh.

---

Last edited by shalma; June 24th, 2010 at 19:08..

[the_randomizer]

Originally Posted by shalma

ePSXe calls SPUasync every $10C40 = 68672 CPU cycles (exactly every time) --> 493-494 times

PCSX-r (old SPUasync) every $C000-C100 = 49152 CPU cycles (varies every time)

Haven't tried edgbla's new async timing fix yet.


EDIT:
Ideally we'd SPUasync( CLKRATE / 44100 ) to create 1 audio packet per APU cycle. Which requires at least a 1.4 GHz machine.

So the emu authors use a scaled value (x50, x60, x64, x100) but we could miss out on ADSR, Noise, Fmod changes within that window; we might accidentally uniformly apply those updates to the -whole- 1ms data (~45 frames) (ex. PEOPS..?). Eternal maybe has a better way to handle it though.

If we had a way to log the cycle time for every SPU register write, then we could do our own event-system for updating the sound envelopes within the plugin. And keep the higher async rates = more FPS.

But, eh.

What exactly is the problem? Would this code be injected into an already available plugin (like Eternal)?

[Whistler]

Originally Posted by Searinox

FF9 crashes the emu as soon as a battle starts, when using HLE BIOS. This stops happening if using a BIOS image. Issue's been around for a month's worth of builds I think.

fixed this, it was a typo I made previously.

Haven't tried edgbla's new async timing fix yet.

afaik edgbla just changed counting cpu cycles into counting hsyncs about the spuasync stuff, which shouldn't make much difference.

__________________

---

Last edited by Whistler; June 28th, 2010 at 01:58..

[Whistler]

lilypad "hijacks" all of the WM_KEYDOWN and WM_SYSKEYDOWN events if Windows Messaging is used, which disables all keys used in PCSX.

ExtraWndProcResult WindowsMessagingWndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT *output) {
	if (wmk) {
		if (uMsg == WM_KEYDOWN || uMsg == WM_SYSKEYDOWN || uMsg == WM_KEYUP || uMsg == WM_SYSKEYUP) {
			if (wParam == VK_SHIFT) {
				wmk->CheckKey(VK_RSHIFT);
				wmk->CheckKey(VK_LSHIFT);
			}
			else if (wParam == VK_CONTROL) {
				wmk->CheckKey(VK_RCONTROL);
				wmk->CheckKey(VK_LCONTROL);
			}
			else if (wParam == VK_MENU) {
				wmk->CheckKey(VK_RMENU);
				wmk->CheckKey(VK_LMENU);
			}
			else
				wmk->UpdateKey(wParam, (uMsg == WM_KEYDOWN || uMsg == WM_SYSKEYDOWN));
			//return NO_WND_PROC; Don't hijack all of the keyboard events
			return CONTINUE_BLISSFULLY;
		}

the crash issue can be fixed by closing pad plugins before other plugins, otherwise lilypad messes up the window handle.

__________________

[shalma]

Documenting Skullmonkeys delay slot mayhem


case #1

00004088 : 15C10016  BNE     0000000a (t6), 0000000a (at), 000040e4,
0000408c : 93B90018  LBU     00000000 (t9), 0018 (801ffba0 (sp)) [801ffbb8]

NO_JMP:
00004090 : 0C00101B  JAL     0000406c, bfc00e6c (ra),
00004094 : 2404000D  ADDIU   0000000a (a0), 00000000 (r0), 000d (13),

JMP:
000040e4 : 3C080000  LUI     0000406c (t0), 0000 (0),
000040e8 : 01194021  ADDU    00000000 (t0), 00000000 (t0), 0000000d (t9),

Personally I was expecting BNE - LBU - JAL - ADDIU - JMP/NO JMP (this would crash the game).

Here's what really happens:
1) Run BNE
2) Detect LBU (delay opcode)
2a) Check opcode @ $40e4 = LUI
2b) No delay r/w found
4) Run only LBU - there's no delay slot for this opcode in this slot (!!)
5) JMP or NO JMP

PCSX gets this right. ePSXe probably should also.


case #2

800131f8 : 03E00008  JR      80013280 (ra),

FUNCTION_2:
800131fc : 93820006  LBU     800131fc (v0), 0006 (800a59b0 (gp)) [800a59b6]
80013200 : 27BDFFE8  ADDIU   8009f3e4 (sp), 8009f3e4 (sp), ffe8 (65512),

80013280 : 2442000F  ADDIU   800ae448 (v0), 800ae448 (v0), 000f (15),

ePSXe uses a hack to detect Skullmonkeys and performs JR - NOP. Or basically just JR.

PCSX gets this right:
1) Run JR
2) LBU detected in branch delay slot
2a) Check opcode @ $80013280 = ADDIU sp,sp
2b) Because reg_src = reg_dst, we have a r/w delay
3) -Do not- run opcode in branch delay slot (LBU)
4) JMP to ra

Note that JR - LBU destroys the boot sequence. Failure.
JR = golden. (:


There's some more delay slot chaos but these are the two that caught my eye.

Whoever did the research for PCSX on branch delays should get a medal!!!

---

Last edited by shalma; July 6th, 2010 at 15:01..

[shalma]

PCSX hacking note about memory I/O cycle penalties:
- add 1 for 1f80xxxx
- add 4 for other (r/w)
--> Shadow Madness began to stop functioning for new game / load game.

A combo of 1 + 2 works okay for now
- UPDATE: This breaks the post-battle status screens

Better use 0 + 0 for now. Bad timing game.

---

Last edited by shalma; July 6th, 2010 at 05:10..

[shalma]

Found the problem with Shadow Madness: CDROM timing.
- Affects world map, some battles, many indoor maps

SRC: If you check the CDROM logs, using faster CDROM times will load more sectors (2 -> 20) but will --endless loop--. Same with default time.


Note that game sets mode to $A0
- $80 = Double speed
- $20 = 2340 bytes


NOTE: I set BIAS to 1 + memory penalties off. My testing build.
WARNING: MUST use Parasite Eve 2 fix or hangs continue (ex. world map)

// 1x = 75 sectors per second
// PSXCLK = 1 sec in the ps
// so (PSXCLK / 75) / BIAS = cdr read time (linuzappz)
#define cdReadTime ((PSXCLK / 75) / BIAS)

// Unbreaks: Shadow Madness
#define cdReadTime ((PSXCLK / (75/2)) / BIAS)

Game does not hang on me anymore - even with mini-games and cutscenes.


EDIT:
Hangs in the Hexite Mines.

Using 75/2 CDtime always breaks 'Fade to Black' - keeps trying to reload file MENU.EXE.
Using 75/1 works unless you use Inuyasha fix. Then it keeps trying to reload file MENU.EXE.

---

Last edited by shalma; July 20th, 2010 at 19:26..

[shalma]

Out of curiosity, I'm testing the NTSC VBlank ratings for ePSXe vs pcsx-r vs pcsx-r (shalma). Haven't gotten to pSX yet.

org $80028000

; counter
ori v0,r0,0

; IRQs
lui a0,$1f80

; RAM storage
lui a1,$8003


LOOP:

; check IRQ = 1 + x / 1
; - ePSXe: 4
; - pSX: ?
; - pcsx-r r54133: 0
; - pcsx-r shalma: 2/0/4

lw v1,$1070(a0)


; ePSXe
;addiu v0,v0,2+4

; pcsx-reloaded r54133
;addiu v0,v0,2+0

; pcsx-reloaded (shalma)
addiu v0,v0,2+2
;addiu v0,v0,2+0
;addiu v0,v0,2+4



; check VBlank - 3 cycles
andi v1,v1,1
beq v1,r0,LOOP
addiu v0,v0,3

; ===================================
; ===================================
; ===================================
; ===================================

; min: 7 (I/O = 0)
; max: 15 (I/O = 4)

; clear IRQ
sw r0,$1070(a0)

; save counter to RAM
addiu a2,a2,4
andi a2,a2,$ffff
addu a3,a2,a1
sw v0,0(a3)

beq r0,r0,LOOP
ori v0,r0,0

Results so far:

; ePSXe
;
; NTSC = 204B8C8 (33863880)
; - 89CAE (60 fps)
;
; program:
; vsync = 89C9D-89CA6

This comes pretty close to their target rate. Add about 15 cycles for saving the counter and it's about accurate + precise.


; pcsx-reloaded r54133
;
; NTSC = 204CC00 (33868800)
; - 89D00 (60 fps)
;
; program:
; vsync = 44E3500 (??!!!)

I don't understand why this happens. :o


; pcsx-reloaded (shalma)
;
; NTSC = 204CC00 (33868800)
; - 89D00 (60 fps)
;
; program:
; vsync = 89C6D-89C74 (2)
; vsync = 89C74-89C79 (0)
; vsync = 89C67-89C70 (4)
;
; BIAS = 1
; Blade_Arma's counters

Note that I'm off by ~147 cycles (-11 cycles for writing to RAM).


Rounding errors?

   // rcnt base.
   rcnts[3].rate   = 1;
   rcnts[3].mode   = RcCountToTarget;
   rcnts[3].target = (PSXCLK / (FrameRate[Config.PsxType] * HSyncTotal[Config.PsxType]));

Maybe we need to 'hard-code' the real targets we want instead of relying on the compiler math.


UPDATE:

; pSX 1.13
;
; NTSC = ?
; - ? (60 fps)
;
; program:
; vsync = 8E798 (2) --> 35014560 NTSC / 0x21647A0 NTSC
; vsync = 7A1F0 (1)
; vsync = B72E8 (4)
; vsync = A2D40 (3)

I take that pSX uses 2 cycles for I/O. Which implies 35 MHz.
Could that be right? :o :o


UPDATE #2:
Forgot that 33.8688 MHz = 2^20 * 33.8688 = 35514010.8288

Total pSX time will be a little flat - have to add RAM write cycles.
So the real value is higher than 35014560 cycles.

---

Last edited by shalma; July 30th, 2010 at 14:04..

[shalma]

Again, I'd like to thank the ePSXe team for creating a high compatibility emulator. They've done a great job on feature accuracy which makes my work possible.

Add another game to the unbroken - working category: Shadow Madness.

mdec.c

if (mdec.reg0 & MDEC0_RGB24) { // 15-b decoding
{
    // 16-bit in --> 24-bit out / 32-bit transfer size
    dmacnt = ((size / 2) * 3) / 4;
    MDECOUTDMA_INT(dmacnt / BIAS);
..
..
..
}
else
{
    // 24-bit in --> 24-bit out / 32-bit transfer size
    dmacnt = (size) / 4;
    MDECOUTDMA_INT(dmacnt / BIAS);
..
..
..
}


void mdec1Interrupt() {
if (HW_DMA1_CHCR & SWAP32(0x01000000)) {
    // 1-time DMA transfer
    HW_DMA1_CHCR &= SWAP32(~0x01000000);

    MDECOUTDMA_INT(PSXCLK / 1000 * BIAS);
    DMA_INTERRUPT(1);
}

// MDEC is already done (!!) - turn off busy flag
mdec.reg1 &= ~MDEC1_BUSY;



Memory Penalty = 2  (all RAM + I/O regions) (does this matter?)

HACKS = off

BIAS = 1  (is this important for fix?)

CDROM = normal time
#define cdReadTime ((PSXCLK / 75) / BIAS)

Doesn't seem to matter:
//#define PSXCLK	33868800	/* 33.8688 Mhz */
//#define PSXCLK 35514010 //.8288
#define PSXCLK 33863880  // ePSXe 1.7.0

Turns out the game was hanging on the MDEC chip. It sees that it's still busy and waits. Eventually it panics from waiting too long and hammers the MDEC1 read register. By that time, the game dies and gives up.

Overworld + cities + battles = MDEC timing fixes (thank you ePSXe!)
Hexite mines = MDEC busy flag off (thank you 'me'! )

I'm just happy this bugger is over with. Hopefully it doesn't break anything.

ref:

8002e58c : 8C620000  LW      00100000 (v0), 0000 (1f801098 (v1)) [1f801098]
8002e590 : 3C030100  LUI     1f801098 (v1), 0100 (256),
8002e594 : 00431024  AND     00000200 (v0), 00000200 (v0), 01000000 (v1),
8002e598 : 10400017  BEQ     00000000 (v0), 00000000 (r0), 8002e5f8,
8002e59c : 00001021  ADDU    00000000 (v0), 00000000 (r0), 00000000 (r0),

 28:25.60 [1F329]
 28:25.61 [1F32A]
 29:21.43 [20380]
 8:15.35 [9092]

; start new MDEC
8002e5a0 : 2404FFFF  ADDIU   00000000 (a0), 00000000 (r0), ffff (65535),
8002e5a4 : 8FA20010  LW      00000000 (v0), 0010 (801ffe00 (sp)) [801ffe10]
8002e5a8 : 00000000  NOP    
8002e5ac : 2442FFFF  ADDIU   00100000 (v0), 00100000 (v0), ffff (65535),

[JohnJack]

Hi guys, since this appears to be the only active forum with PSX emu developers, I'm wondering if anyone can help me with understanding PSX texture emulation, with respect to the PSEmu Pro spec. I've discussed it in this thread:
http://forums.ngemu.com/psx-plugin-q...s-lurking.html

[shalma]

Try asking Blade_Arma:
edgbla - CodePlex

edgbla knows more about the PSX than the other working devs - SIO / GTE / SPU / VBlank / (..) / counter fixes, SIO1 interface, experimental GPU plugin (**)

[shalma]

DMA Timing Fixes

PCSX sometimes transfers 10000000+ bytes / cycle.
Really it should be 4 bytes / cycle.


DMA-1 = MDEC OUT (see Shadow Madness fix)


DMA-4 = SPU (thanks edgbla!)

psxdma.c


void spuInterrupt() {
   HW_DMA4_CHCR &= SWAP32(~0x01000000);
   DMA_INTERRUPT(4);
}



void psxDma4(u32 madr, u32 bcr, u32 chcr) { // SPU

case 0x01000201: //cpu to spu transfer
  ..
  SPU_writeDMAMem(ptr, (bcr >> 16) * (bcr & 0xffff) * 2);


  SPUDMA_INT( ((bcr >> 16) * (bcr & 0xffff) / 2) / BIAS);
  return;



case 0x01000200: //spu to cpu transfer
  ..
  size = (bcr >> 16) * (bcr & 0xffff) * 2;

  SPU_readDMAMem(ptr, size);
  psxCpu->Clear(madr, size);

  SPUDMA_INT( ((bcr >> 16) * (bcr & 0xffff) / 2) / BIAS);
  return;

DMA-2 = GPU

psxdma.c


void psxDma2(u32 madr, u32 bcr, u32 chcr) { // GPU

case 0x01000200: // vram2mem
  ..
 
  size = (bcr >> 16) * (bcr & 0xffff);
  GPU_readDataMem(ptr, size);
  psxCpu->Clear(madr, size);

  GPUDMA_INT((size / 4) / BIAS);
  return;


case 0x01000201: // mem2vram
  ..
  size = (bcr >> 16) * (bcr & 0xffff);

  GPU_writeDataMem(ptr, size);

  GPUDMA_INT((size / 4) / BIAS);
  return;



case 0x01000401: // dma chain
  ..
  GPU_dmaChain((u32 *)psxM, madr & 0x1fffff);


  // FIXME!!! Walk through DMA chain and add the cycles
  GPUDMA_INT( (0x4000 / 4) / BIAS);
  return;

DMA chain will fix Rebel Assault 2 timeouts!

This is a temporary fix until someone creates the chain walking code.


DMA-6 = RAM DMA

psxdma.c


void psxDma6(u32 madr, u32 bcr, u32 chcr) {
  ..
  // already 32-bit size
  size = bcr;

  while (bcr--) {
  ..
  }
  mem++; *mem = 0xffffff;


  RAMDMA_INT( size / BIAS);
  return;
}



void ramInterrupt()
{
  HW_DMA6_CHCR &= SWAP32(~0x01000000);
  DMA_INTERRUPT(6);
}

More of a structural rewrite to handle new interrupts.
Breaks save states.

r3000a.h
  ..

  u32 cycle;
  u32 interrupt;
  u32 intCycle[32*2];
} psxRegisters;

sio.c

#define SIO_INT(eCycle) { \
  if (!Config.Sio) { \
    psxRegs.interrupt|= 0x80; \
    psxRegs.intCycle[(7+0)*2 +1] = eCycle; \
    psxRegs.intCycle[(7+0)*2 +0] = psxRegs.cycle; \
  } \
}




// Is this really a fixed value?

// ePSXe 1.6.0
SIO_INT(535)

// ePSXe 1.7.0
//SIO_INT(635)

cdrom.c


#define CDR_INT(eCycle) { \
	psxRegs.interrupt |= 0x4; \
	psxRegs.intCycle[(2+0)*2 +1] = eCycle; \
	psxRegs.intCycle[(2+0)*2 +0] = psxRegs.cycle; }

#define CDREAD_INT(eCycle) { \
	psxRegs.interrupt |= 0x40000; \
	psxRegs.intCycle[(2+16)*2 +1] = eCycle; \
	psxRegs.intCycle[(2+16)*2 +0] = psxRegs.cycle; }

psxdma.h


#define MDECINDMA_INT(eCycle) { \
    psxRegs.interrupt |= 0x10000000; \
    psxRegs.intCycle[(4+24)*2 +1] = eCycle; \
    psxRegs.intCycle[(4+24)*2 +0] = psxRegs.cycle; \
}

#define MDECOUTDMA_INT(eCycle) { \
	psxRegs.interrupt |= 0x02000000; \
	psxRegs.intCycle[(1+24)*2 +1] = eCycle; \
	psxRegs.intCycle[(1+24)*2 +0] = psxRegs.cycle; \
}

#define GPUDMA_INT(eCycle) { \
	psxRegs.interrupt |= 0x04000000; \
	psxRegs.intCycle[(2+24)*2 +1] = eCycle; \
	psxRegs.intCycle[(2+24)*2 +0] = psxRegs.cycle; \
}

/*
#define CDRDMA_INT(eCycle) { \
	psxRegs.interrupt |= 0x08000000; \
	psxRegs.intCycle[(3+24)*2 +1] = eCycle; \
	psxRegs.intCycle[(3+24)*2 +0] = psxRegs.cycle; \
}
*/

#define SPUDMA_INT(eCycle) { \
    psxRegs.interrupt |= 0x10000000; \
    psxRegs.intCycle[(4+24)*2 +1] = eCycle; \
    psxRegs.intCycle[(4+24)*2 +0] = psxRegs.cycle; \
}

/*
DMA5 = N/A
*/

#define RAMDMA_INT(eCycle) { \
    psxRegs.interrupt |= 0x40000000; \
    psxRegs.intCycle[(6+24)*2 +1] = eCycle; \
    psxRegs.intCycle[(6+24)*2 +0] = psxRegs.cycle; \
}


void gpuInterrupt();
void spuInterrupt();
void ramInterrupt();
void mdec0Interrupt();

r3000a.c


//if (psxRegs.interrupt) {
if(1) {
		if ((psxRegs.interrupt & 0x80) && (!Config.Sio)) { // sio
			if ((psxRegs.cycle - psxRegs.intCycle[(7+0)*2+0]) >= psxRegs.intCycle[(7+0)*2+1]) {
				psxRegs.interrupt&=~0x80;
				sioInterrupt();
			}
		}

		if (psxRegs.interrupt & 0x04) { // cdr
			if ((psxRegs.cycle - psxRegs.intCycle[(2+0)*2+0]) >= psxRegs.intCycle[(2+0)*2+1]) {
				psxRegs.interrupt&=~0x04;
				cdrInterrupt();
			}
		}

		if (psxRegs.interrupt & 0x040000) { // cdr read
			if ((psxRegs.cycle - psxRegs.intCycle[(2+16)*2+0]) >= psxRegs.intCycle[(2+16)*2+1]) {
				psxRegs.interrupt&=~0x040000;
				cdrReadInterrupt();
			}
		}

		if (psxRegs.interrupt & 0x01000000) { // mdec in dma
			if ((psxRegs.cycle - psxRegs.intCycle[(0+24)*2+0]) >= psxRegs.intCycle[(0+24)*2+1]) {
				psxRegs.interrupt&=~0x01000000;
				mdec0Interrupt();
			}
		}

		if (psxRegs.interrupt & 0x02000000) { // mdec out dma
			if ((psxRegs.cycle - psxRegs.intCycle[(1+24)*2+0]) >= psxRegs.intCycle[(1+24)*2+1]) {
				psxRegs.interrupt&=~0x02000000;
				mdec1Interrupt();
			}
		}

		if (psxRegs.interrupt & 0x04000000) { // gpu dma
			if ((psxRegs.cycle - psxRegs.intCycle[(2+24)*2+0]) >= psxRegs.intCycle[(2+24)*2+1]) {
				psxRegs.interrupt&=~0x04000000;
				gpuInterrupt();
			}
		}

		if (psxRegs.interrupt & 0x10000000) { // spu dma
			if ((psxRegs.cycle - psxRegs.intCycle[(4+24)*2+0]) >= psxRegs.intCycle[(4+24)*2+1]) {
				psxRegs.interrupt&=~0x10000000;
				spuInterrupt();
			}
		}

		if (psxRegs.interrupt & 0x40000000) { // ram dma
			if ((psxRegs.cycle - psxRegs.intCycle[(6+24)*2+0]) >= psxRegs.intCycle[(6+24)*2+1]) {
				psxRegs.interrupt&=~0x40000000;
				ramInterrupt();
			}
		}

mdec.c


void psxDma0(u32 adr, u32 bcr, u32 chcr) {
  case 0x3: // decode
    ..
    mdec.rlsize = mdec.reg0 & MDEC0_SIZE_MASK;

    MDECINDMA_INT( (size / 4) / BIAS );
    return;


  case 0x4: // quantization table upload
    ..
    iqtab_init(iq_y, p);
    iqtab_init(iq_uv, p + 64);

    MDECINDMA_INT( (size / 4) / BIAS );
    return;


  case 0x6: // cosine table
    ..
    //iqtab_init(iq_y, p);
    //iqtab_init(iq_uv, p + 64);

    MDECINDMA_INT( (size / 4) / BIAS );
    return;
}


void mdec0Interrupt()
{
  HW_DMA0_CHCR &= SWAP32(~0x01000000);
  DMA_INTERRUPT(0);
}

That's it. Fixes Rebel Assault 2.
And maybe other games.

I'll post the ePSXe hack later in that forum.

[shalma]

Not sure if anyone noticed this (appears to be Xebra):
NYO$B%C%H$d$m$&$<(J
Google Translate


DMA5 = PIO
DMA6 = OTC (which means..?)

I-Cache performance
No D-Cache..?

GTE reciprocal table

Timers (!!)
- The base clocks are similar to ePSXe (some bit faster)
- Don't know who can fix the Pixel / HSync / Interlace clocks

SPU
- Envelope formulas (don't know how this compares to Neill's)
- ADSR conditions
- ADPCM flags explained
- Noise / Reverb algorithms (!!!)

CDROM
- Not quite sure what to make of these times / clocks


This reminds me why I don't like working on emulators. ;p

[shalma]

PCSX-Reloaded

Release 1.9.92 available for many platforms

Release Notes
- Many fixes/changes to the core and Internal HLE BIOS.
- Root counters has been rewritten.
- Use GTE code from PCSX-Revolution Project which improved accuracy.
- Added netplay plugin for *NIX (based on netSock).
- Native support for FreeBSD and Solaris.
- Replaced HIDInput and CDDeviceInterface plugins with dfinput/dfcdrom for Mac OS X.
- Other minor bugfixes/tweaks.

Plus this:
Download - Plugins for various Emulators - PlayStation

edgbla＇s Software Rendering Plugin main features:
Unique:
• Interlace mode emulation;
• Screen settings emulation;
• Final Fantasy 8 pre battle effect emulation;
• Pixel perfect geometry ( I hope. :) );
Other features:
• 15/24-bit software renderer;
• Increased internal resolution;
• Support for gpuPeteOGL2 shaders;
• Fullscreen filters;
• High precision GPU commands emulation;
• Correct polygon cutting;
• Precise dithering;
• Correct aspect ratio;
• Screenshot creation, video recording;
Known issues:
• Increasing the internal resolution causes visual artifacts;
• The picture is rendered incorrectly when rotated 90 or 270 degrees;
• Lightgun crosshairs are incorrectly positioned when the emulator window's aspect ratio is not equal to 4:3.

---

Last edited by shalma; August 5th, 2010 at 16:01..

[Whistler]

nice job

well I'm mostly pushing the changes to the archlinux or gentoo packagers... as most of them are still packaging the previously released versions.
that shouldn't really be taken seriously

as for the otc, to quote Joshua Walker's doc:

Communication and Ordering Tables (OT).

All data regarding drawing and drawing environment are sent as packets to the GPU. Each packet tells the GPU how and where to draw one primitive, or it sets one of the drawing environment parameters. The display environment is set up through single word commands using the control port of the GPU.

Packets can be forwarded word by word through the data port of the GPU, or more efficiently for large numbers of packets through DMA. A special DMA mode was created for this so large numbers of packets can be sent and managed easily. In this mode a list of packets is sent, where each entry in the list contains a header which is one word containing the address of the next entry and the size of the packet and the packet itself. A result of this is that the packets do not need to be stored sequentially. This makes it possible to easily control the order in which packets get processed. The GPU processes the packets it gets in the order they are offered. So the first entry in the list also gets drawn first. To insert a packet into the middle of the list simply find the packet after which needs it to be processed, replace the address in that packet with the address of the new packet, and let that point to the address that was replaced.

To aid in finding a location in the list, the Ordering Table was invented. At first this is basically a linked list with entries of packet size 0, so it's a list of only list entry headers, where each entry points to to the next entry. Then as primitives are generated by your program you can then add them to the table at a certain index. Just read the address in the table entry and replace it with the address of the new packet and store the address from the table in the packet. When all packets are generated drawing will just require passing the address of the first list entry to the DMA and the packets will get drawn in the order you entered the packets to the table. Packets entered at a higher table index will get drawn after those entered at a lower table index. Packets entered at the same index will get drawn in the order they were entered, the last one first.

In 3d drawing it's most common that you want the primitives with the highest Z value to be drawn first, so it would be nice if the table would be drawn the other way around, so the Z value can be used as index. This is a simple thing, just make a table of which each entry points to the previous entry, and start the DMA with the address of the last table entry. To assist you in making such a table, a special DMA channel is available which creates it for you.

__________________

[Whistler]

void mdec1Interrupt() {
if (HW_DMA1_CHCR & SWAP32(0x01000000)) {
    // 1-time DMA transfer
    HW_DMA1_CHCR &= SWAP32(~0x01000000);

    MDECOUTDMA_INT(PSXCLK / 1000 * BIAS);
    DMA_INTERRUPT(1);
}

// MDEC is already done (!!) - turn off busy flag
mdec.reg1 &= ~MDEC1_BUSY;

this does not look correct... as scheduling another interrupt would be useless if the busy flag is removed immediately.

maybe the timing is incorrect (the PSXCLK / 1000 was intended to hackfix the FF9 dali crash by the pcsx-df guys and is obviously not an accurate way)? dunno...

__________________