notaz said:Started but not finished:
- Gun support - guncon investigated, shalma's code read, need to do own implementation for pandora..
- Tenka memcards - fix available in pcsxr ngemu thread, need to check it (maybe validate it on hardware)
- STAR WARS The Phantom Menace corruption - some investigation done, state uploaded to hardware recovers geometry, so it's not one-time corruption thing. Could not boot it on pcsxr at all for comparison.
Todo:
- Gamera 2000 (JP) - voice
- Final Doom - loading hang
Updated list. I'll only sync git after r9 release, sorry (I like rebasing/messing with the history).Bonapart said:notaz: miss: ninja: shadow of darkness(post)
Threads of Fate: tnx for this game
p.s. hoping git update will be soon
ok, removing from list until evidence (savestate) is provided.crow_riot said:just that you are aware off - i've finished crash bandicoot 1, no crash for me.
Will take a look, thanks.gretar said:(our work = guess stuff. so unreliable in many ways)
(DW7 = $04/$08 flags)
(sio.c) http://www.sendspace.com/file/pj2p97
Gamera 2000 looks something like this (cdxa_attenuation)
- some speed hit (maybe you can optimize for $80 - $00 / $80 - $00 (normal volume)?)
(cdrom.c) http://www.sendspace.com/file/4b7h7t
Doom - Final Doom 'LOADING' hang may be related AddIrqQueue reschedule (nasty piece code)
More like gun and screen variations, I tried Time Crisis on the real thing and it was offset quite a bit to bottom-right, so ingame calibration was needed..gretar said:If you need help understanding basics Guncon, please ask. Calibration is a pita though - every game handles differently (slightly). Probably distance from TV screen.
looks good. On a related note I've seen ff7 aborting DMA chain by forcing bit24 to 0, then resubmiting the list again. This has no visible effects but causes severe slowdowns on ARM because the scene ends up rendered twice by GPU plugin..gretar said:You may need add this (useful!)
http://pcsxr.codeplex.com/workitem/8867
Yeah but that eventually ends up with all 24 channels running, annihilating performance on ARM..gretar said:- PS: Did you see DSound win32 Tron Bonne fix? Leave channel running + silent envelope volume.
Same here, we are already too slow in many cases, maybe make it optional someday..gretar said:Timing is juggling game - must send BIAS 1 (psxcommon.h) --> SLOWDOWN.
- Then set RAM = 4 (average) + IO = 4 (average) + Scratchpad = 1
- Fixes some game speed problems (MML1, UMKT speech, blah blah)
I don't know how CDDA is stored in eboots, so I'm just ignoring it, likely causing these problems. I need to make testing file for this, do you know any eboot tools that handle cdda correctly?Blue Protoman said:And DoDonPachi has no music (tried two different ISOs), as well as taking an abnormally long time to load the first level. The levels after load quickly. It's in EBOOT format (as are all my other games), dunno if that has anything to do with it.
notaz said:I don't know how CDDA is stored in eboots, so I'm just ignoring it, likely causing these problems. I need to make testing file for this, do you know any eboot tools that handle cdda correctly?Blue Protoman said:And DoDonPachi has no music (tried two different ISOs), as well as taking an abnormally long time to load the first level. The levels after load quickly. It's in EBOOT format (as are all my other games), dunno if that has anything to do with it.
Thanks for all those ideas, reverb indeed causes noticeable slowdown and noise uses division that's bad thing on ARM. Not sure about Tron Bonne hack, but it's temptinggretar said:
Luckily there are enough cycles for that one, even without overclock.gretar said:As a thought, have you tried 'optimizing' the MDEC code? The pandora has a 'small' screen, enough that maybe you could reduce the MDEC quality for speed hacks?
http://jpsxdec.blogspot.com/
He says that pcsx-r quality is > real console. So you could get away with it.
Already helped with useful advice, this also has N900 port and is used as a base of psx4droid, so I think it's worth the effort.gretar said:Wish we could help you get more speed out of that device.
I didn't do anything fancy, it just counts 1 cycle per instruction. I think notaz underclocked it by half though (ie 16.9 million instructions per second).gretar said:We took a look at ePSXe's dynarec some more. Don't know how this compares with Ari64 recompiler
1- They directly dynarec rewrote the memmap cycle penalties into custom x86. Little register usage in that subroutine other than some dynarec temp vars. Plus no register trashing.
Gives them a nice speed boost (until we dll hacked it to fix the scratchpad cycles).
Is that sort of timing really necessary for anything newer than SNES? Checking after every instruction contributes to code bloat and L1 cache misses. Also handling interrupts in delay slots is annoying, so I avoided doing that.gretar said:2- They run the system in roughly $862 / 86D (ntsc/pal) system clock interrupt cycles. Which is when they drop out to take care of counters and such. They use 16-bit dec method.
Turns out they directly embedded interrupt checks into dynarec also after each opcode runs.
I think they added an alternative interrupt handler on top embedded in dynarec also though (runs after every branch i.t.)
It's very sophisticated and easily the best MIPS->ARM recompiler available (from open ones at least), you can read about it here:gretar said:We took a look at ePSXe's dynarec some more. Don't know how this compares with Ari64 recompiler
I just use 2 penalty cycles for writes anywhere and cop2 loads/stores, doing penalties on reads is causing problems on PCSX as you probably know.gretar said:1- They directly dynarec rewrote the memmap cycle penalties into custom x86. Little register usage in that subroutine other than some dynarec temp vars. Plus no register trashing.
I just run it until next scheduled event, which is set by PCSX core. The recompiler is maintaining cycle counter (usually in a register) and calls the emu back after it expires. It does counter checks after branches. The counter is reloaded after a write (as that may result in new event, like new DMA to expire and such).gretar said:2- They run the system in roughly $862 / 86D (ntsc/pal) system clock interrupt cycles. Which is when they drop out to take care of counters and such. They use 16-bit dec method.
Hm that doesn't sound good for performance? Doing checks on branches seems good enough, the ARM version of Mupen64plus and even PCSX interpreter works this way.gretar said:Turns out they directly embedded interrupt checks into dynarec also after each opcode runs.
Saw this before but not merged for some reason, I guess will do it this time.gretar said:Bump HSyncTotal 262->263, 312->313
(fixes Wipeout 2 rotation models)
I'm already doing it on SPU side, see SPUasync()gretar said:You _might_ be able to play around with a variable SpuUpdInterval
Some games are more tolerant of higher values (longer call stretches)
Unless the game is reprogramming the counters like crazy or polling them a lot it shouldn't really be needed, at least somehow root counters don't pop up in the profiles.gretar said:There's enough DIV code here.
- Clock is often '1' (use an if check to bypass DIV)
- When clock is '8', optimize a bitshift
- Maybe optimize _psxRcntRcount -> 0,1,2,3 versions (???) for custom optimization
What do you mean?gretar said:4-
(Optional)
- Give option to swap vsync irq hits (There's 2 games iirc that benefit - Chrono Cross + ?)
I was sent the original Namco Guncon and a clone called Scorpion, which has a button for guncon/justifier modes. Not sure how faithful the clone is, in guncon mode it reacts different to unused commands compared to real guncon, for example. I'll see if it's detected by Silent Hill.gretar said:By random chance, do you have a G-Con 45 to test with? Kinda Justifier-related (Silent Hill hyperblaster detection).
Hey this also fixed Spyro, nice!gretar said:http://pcsxr.codeplex.com/workitem/8874
- This will fix the Soul Reaver missing souls problem - GTE RTPS / RTPT
okgretar said:Also in cdrom.c, you'll want a 'faster' version of the Ape Escape fix for Specter Land theme park
Divisions by constant are also not a big deal, compiler knows how to convert this to multiplication + shift, and ARM can multiply fast.gretar said:615 sval = (MixADSR(ch) * fa) / 1023; // mix adsr
==>
615 sval = (MixADSR(ch) * fa) / 1024; // mix adsr
No point, it knows constant vars too.gretar said:(2)
675 d = SSumLR[ns] / voldiv; SSumLR[ns] = 0;
682 d = SSumLR[ns] / voldiv; SSumLR[ns] = 0;
note: hard-code a /2 here. unless compiler is smart enough to optimize the const var.
ok thanks.gretar said:<some SPU stuff>
I just use 2 penalty cycles for writes anywhere and cop2 loads/stores, doing penalties on reads is causing problems on PCSX as you probably know.
Alerino said:gretar, just to let you know we also have a N64 emulator, that's getting love from Ari,notaz, bzfrank and others . More love is always welcome.