Recent Posts

Pages: [1] 2 3 ... 10
Reverse Engineering / Re: ECCHI PROJECT - the road Accessory Port to and OTG
« Last post by cuevavirus on July 11, 2020, 09:47:04 PM »
I can confirm that DS3/DS4 controllers can be used in the same way as on the PSTV using an OTG y cable, the same syscon patch, and minivitatv. Controller can be used while wired and will automatically pair.

Alot of people are asking about how to use Thread Optimizer so I'll try as best I can because there's no one way to do it as every game is different.

Before I start, I have no prior knowledge of CPU Thread Optimization. Its Mostly trial and error and since every game is different with its own limitations and unique structure and threads it means there's alot of fumbling in the dark until you can work out where the light switch is. So Here goes...

On a new game I know nothing about any of the threads so I need to find out where the goal posts are, because otherwise I dont know when I've scored. I need to know where I'm starting from so this is what I do...

1. run the game as stock
2. Pick a level or area (usually the start of the game because it runs slowest, its not always the case but its a good starting point, also a good reason to pick a game you're familiar with, you'll know where it plays worst, hence why I've done wipeout and Killzone )
3. 3 markers to look for when evaluating improvements: remember where the highest FPS was and at what points, take note of how the game feels (especially fluidity of FPS, really good sign of average FPS increase), how reactive it is, where major slowdowns are, etc and CPU usage, more specifically what cores its using and what ones it isnt.


From there, I start messing with the core affinity because its super wuick and has a great chance of immediate improvements.

1. add 4th cores to threads already using 3 cores - there's more chance of the game freezing or not booting or sound problems with threads that use a single core by default and adding a 4th to it
2. If you get a big improvement from a change, stay on that thread and try releasing each of the 3 main cores in turn to try to capitalize on it
3. if one core is heavily utilized, try releasing that core from threads - This is good for understanding where each thread stands in terms of load. this is super useful. Look at what happens, the released core could reduce usage and pass that on to the other two cores and increase FPS because its gained CPU slices back to push on with another more important thread that its assigned to OR you could have just removed the core from a thread that really needed it and FPS drops.

That last point is the majority of what I do at the start of any profile. Carry on doing that with every thread and by the end of it you'll have a better idea of where each thread stands and what ones really have potential to get some FPS.

I'm going to use Wipeout 2048 as an example. This is really important to do. ALWAYS save EVERY positive change to the profile. I make a folder in data/ The way I do it is to number them and include the change I made in the file name. The reason I do this is because there are no permanent 'good' settings. Like in Wipeout, there's a thread called NEW THREAD, I added a 4th core to it giving me 1 FPS in most areas and really smoothing out gameplay, WIN. But later on when I'd changed other threads priorities and core affinities I removed the 4th core and got an FPS boost.

This was because every change affects every thread. The 4th core on NEW THREAD was now getting in the way and holding up other threads where their higher priority settings were waiting on NEW THREAD at its default priority. So I removed the 4th core and it bumped up FPS but it had lost ALOT of smoothness. Then I thought about it...

IMPORTANT/ more cores needs a higher priority \IMPORTANT- sometimes not all the time - I looked to the default highest priority threads for reference, ALL 64's, long story short, 66 turned out to be the best setting from a default of over 128, it was a total long shot but it paid off

I can only talk about the multithreaded approach because thats the way I've tackled it. If you want a really good example of optimizing for single core threads, the Jak and Daxter profile made by ZeeThirtyTwo plays really well compared to stock, that'd be a really good place to start

I've found Multithreaded can handle bigger and busier scenes. The only thing I keep an eye on is when enabling all four cores - depending on the threads perceived load bias - on a thread, it can seem like you're losing FPS but in some cases it actually increases AVERAGE FPS. This is what I look for, its good having a good max FPS but if it happens for a millisecond its no use. This is where taking note of how smooth and fluid the action are can give a better sign of marked improvement.

In the video for the Wipeout Ultrasmooth profile(, if you look at the FPS counter, 90% of the time the FPS moves by 1 FPS at most. This is why its really smooth, the FPS jumps around very little. Basically its better to have 45 FPS for 5 seconds than 50 FPS for 1 second with the other 4 seconds sitting at 40 FPS. The second example has a lower overall framecount than the first.

So thats what I've observed with using more cores, for games that work better with a single core per thread scenario, ZeeThirtyTwo would be your man for that subject because when I looked at the Jak and Daxter profile I was expecting all four cores somewhere but it was all really precise changes and one or two cores per thread. Considering the way it played, thats pretty cool. My methods more of a throwing paint at the canvas and seeing if it looks good kinf of method, but once you get the first improvement from the cores, you go round every thread and try any combos for core affinity that you can think of and see what happens...


I'm not gonna lie, these are as annoying as they are fun to mess around with. The game will always tell you when it doesnt like a setting, whether thats stalling on a loading screen, not even starting, crashing when it gets into gameplay or just running like crap.

I'm gonna use Wipeout as an example again, 3 threads with default priorities and core affinities: NEW THREAD/96[|||O], TrophyInitThread/95[|||O] and Video Audio/86[OOOO]

The first two threads are using the 3 main cores while Video Audio is being decided by the system. I left this thread to one of the last because playing with it would create too many unknowns. But when I finished, the 3 threads had these Priorities and core affinities: NEW THREAD/66[||||], TrophyInitThread/64[||||] and Video Audio/66[||||]

The two threads that stick out are Video Audio and NEW THREAD. I disabled and enabled the 4th core on NEW THREAD about 4 times. This was because all of the other changes were changing the CPU's schedule and new thread was getting moved around in the CPU queue. The benefits of the 4th core showed up only when the priority was set to 66 and the CPU usage dramatically increased in the 2nd and 3rd cores, releasing the 2nd dominant core a bit for some needed headroom.

So once that was sorted I decided to try the same thing with Video Audio which at that time had the 3 main cores enabled. So I enabled the 4th core and my first attempt at the priority was 68. It played great. I then decided to change the priority to 67, even better. after that, for some reason I decided to try 64 and 65 before 66 but 66 was the smoothest but it was also the same as NEW THREAD.

Whether these two threads have a connection somewhere or they just take the exact same load and end up with the same priority, I dont know but sometimes I think there is some sort of synchronicity between certain high priority threads. Oh and dont take the default priority as an indication of significance, its very often off by a bit. its good to try out theories that you have about a profile and keep the load bias of threads in mind. you never know what'll work and what the game would work best with

I always go back and reverse changes, there's nothing wrong with it. if I go down a rabbit hole and get lost, I pick the most recent saved profile from the folder, start at that point and try something else. If you've spent an hour on one thread and got nowhere it might be better trying another thread.


In Killzone especially, there was a period of increasing priorities on certain threads. If you increase the priority on one of the high significance threads first, then tackle the others, sometimes you can get a string of improvements. I Think of using the Thread Optimizer as organizing the CPU's work into one continuous queue. If there's a gap in the queue (a process with too low a priority) the CPU has to wait (loading slowdowns) To find the offending thread, increase the priority on all of the less important threads and look for FPS increases.

Together the priorities assigned to each thread are what you use to close the gaps in the queue, but assign a low significance thread with too high a priority and thet'll cut in front of threads it should be behind which holds up everything else.

I keep going back to it but finding out what the key threads with the most significance for increasing FPS in a profile is, is the most important thing to nail down at the start.


These are thread names that I'll go straight to if they worked in a previous profile.

VideoAudio (Wipeout only): Configured this alot with NEW THREAD and gained a ton of FPS with 4 cores and 64 priority, smoothed everything out and made gameplay alot smoother.

TrophyInitThread: killzone I disabled the 3rd core and enabled the 4th core. This released it to process higher priority threads and increased FPS. I pumped the priority up as well.This thread  always seems to speed up hectic areas of the game, same with wipeout except all four cores and maximum priority (64), the difference is just what suited both games.

HavokWorkerThread: This ones in alot of games and usually the first thread I make a change in. 90 priority and 4 cores is a pretty good place to start. usually not a good idea to remove cores as performance sometimes suffers

Job Shed 000,001,003 (Killzone only): Killzone had 3 Job Shed threads along with HavockWorkerThread, between these two I gained alot of FPS. Default 160 priority, set all 3 Job Shed's to 130 and enabled 4th core. I would say it was even more important than HavokWorkerThread. Something I read said that one of the Job Shed threads can have a higher priority because of the way it works, it needs to be able to take priority over the other 2 JobShed threads... So I set Job Shed 000 to 80 priority and ended up with the combat profile, so it all worked out.

The next couple of threads are specific to Killzone.

Asset Streaming Thread: There were a few snapshots that I took that were missing this thread, I was lucky I played for 10 minutes then took a snapshot or I would've never known about it. gained decent FPS and a bit of smoothness. enabled the 4th core and reduced priority from 191 I think? to 175.

Network Threads: NetManager Worker Thread and HTTP Worker 000 and 001. These actually had a big impact on FPS. I released the 3rd core from NetManager Worker and enabled the 4th core. On HTTP worker 000 and 001, I left the core affinity at the 3 main default cores and I think I increased the priority on the HTTP Workers from 190 to 160


Low Priority threads are really handy for releasing one or more of the main cores so it can concentrate on higher priority tasks. In Killzone TrophyInitThread had less significance than in wipeout. So it runs with only the 1st and 3rd cores with a slightly increased priority to reflect the fact its using less cores. This meant the 2nd and 4th cores had more CPU slices to make more FPS from the other threads.

One thing to remember is that the significance for a thread is different in every game it seems. never assume that a thread of the same name will act the same way in another game, every thread affects every other thread and acts accordingly


This a tricky one, choose an area and make up a run. Personally, I try and find an area in the 20-30 fps range with lots going on. The more the CPU has to do, the more I can see improvements (even on 444mhz) when I make changes. busy scenes need more cores from what I've done already. This leads onto Game Characteristics and an idea I have on how this affects thread priority.

On Killzone, rendered objects dont fly at you at a hundred miles like they do on Wipeout. The difference is that Wipeouts priorities ended up at the highest priorities (64,65 and 66) and Killzones major player threads were in the 80's and 90's with more threads having 130, 160, 175,etc.

The reason I'm mentioning this is that Need For Speed has the same game structure with high speed objects. I wouldn't recommend shooting the priorities up to max but I'd guess increasing priority on the majority of threads with some core affinity testing would gain some more FPS.

Here's a list of markers to look out for:

1. Loading slowdowns: this usually means that a process doesnt have a high enough priority and its been pushed too far back by higher priority threads. Increasing the priority on lower priority threads or enabling the 4th core if its not too heavily loaded, usually remedies this. this also increases FPS because the time spent waiting is gained back by the CPU.

Stuttering: This can be caused by a thread being given too high a priority. If the thread isnt that heavy on the CPU it can cut in on more important threads CPU time. Loosening the priorities, changing what core it uses (Not all cores are created or used equally depending on the game) or enabling the 4th core, which increased smoothness in the games I've tested.

Slowdown of large or hectic scenes: In Killzone it was the high priority HavokWorkerThread and the 3 Job Shed threads that pushed throughthe hectic scenes, all I had to do was increase their priority to give them more CPU time.
In Wipeout, it was the VideoAudio Thread and NEW THREAD that I used to gain the most improvement. In these two games these threads were the most significant to me from how the game played so I focused on them. Once you work out the key threads in a profile, you're onto FPS gains.

Audio Crackling: Revelations 2 has this problem where other threads priorities and core affinities affect the audio even without changing any audio threads settings. I havent found a work around yet, only managed to reduce it slightly using priorities while trying to keep the FPS increases.


In Killzone it was the amount of enemies and what difficulty you had chosen - higher difficulty means more AI and more load on the CPU so choosing the hardest difficulty cost around 1FPS most of the time.

In Wipeout there were a few Contextual Markers and what I would call quirks. The closer a ship was to your ship the bigger the FPS would dip and still does. This is why in the video I get into 1st place as quickly as I can to rule out the unstable element affecting the FPS. I discarded the first lap FPS counts for this reason, that and every lap you completed increased the FPS, SI discounted these values as well. Especially in the third lap on the first track in the video the FPS visibly jumps up after I crossed the line and everything speeds up noticeably.

Contextual Markers, as I call them are situation dependent FPS changers. They are things you have to take out of the equation when deciding whether or not there is an improvement even if they increase FPS because nothing can be done about them. Every game will have them and as long as you can spot them you can avoid false positives where you think there is an improvement but its an aspect of the game that did it and not the profile.


Some games just dont like to be messed with. Wipeout 2048 had 3 , what looked like really fun threads to play around with. A rendering thread, loading thread and Save game thread (this also benefits from 4 cores and increased priority sometimes) but anything I tried stopped the game from loading at all. But test every thread because the second page is where 100% of the performance gains came from. They were totally fine with most adjustments... The sound threads if set to any priority over 128 would get halfway through a loading screen then just stop loading. the background was still moving but nothing loaded, so audio threads can sometimes be a pain but FPS can be gained here as well.


1. GETTING STARTED: Do core affinities first, adding 4th core to threads using 3 main cores and releasing main cores for other threads, Find out where goalposts are e.g. Thread significance in relation to every other thread, suitable testing area with alot happening for the CPU to deal with, after Core Affinities is done, use what you've learned about what threads are the most significant to start on Priorities

2. PRIORITIES: When adding 4th core increase priorities, think about increasing threads from high priority list above first, then go round the other threads to 'tighten' priorities

3. Repeat 1 and 2 repeatedly: I usually go back and forth from core affinities to Thread Priorities because each affects the other but if you focus on AVERAGE FPS gains. Take the max FPS into account but if you want FPS gains AND smooth gameplay, average FPS gains are the way to go. You usually notice the difference right away when you've increased the average FPS, it runs alot smoother all round and sometimes chops off the peaks and troffs - decreasing max FPS, increasing min FPS.

Sorry for the long spiel but hopefully there's a few strategies in this wall of text for someone to try. I'm not an expert on this at all and I could be doing it completely wrong... I'm waiting on a qualified CPU Thread Optimizer to have a look at the profiles and think, 'did the guy that made this have eyeballs?!'

anyway hope this is of some help... or at least something to get you to sleep at night
Wipeout 2048 Profiles. I've made two profiles again, this time for Wipeout 2048

EDIT: changed the name of Frantic to High Intensity, completely forgot to make a video as well... I love how smooth Ultrasmooth is but High Intensity is exactly that :) video to follow
Then there's the Ultrasmooth profile, which is Ultrasmooth :)

Link attached to post.

VIDEO @444mhz, 960x540, 60 FPS, Sharpscale Point filter, Wipeout Ultrasmooth Profile
General / Re: DolceSDK - Playstation Vita homebrew SDK
« Last post by cuevavirus on July 08, 2020, 03:33:17 AM »
Changes summary 2020-07-07

Compatibility notice: In build-2020-07-07-222810, a large number of header changes occurred relating to SCE types and threadmgr. You may need to include additional headers, rename struct fields, rename union fields, rename macros, add field for typedefs and structs that became unions, or remove duplicate definitions. Threadmgr related structs which had the wrong number of fields had also been corrected. With these changes, psp2/kernel/threadmgr.h has all constants and prototypes for thread management and synchronisation.


- Additions and changes in SceBgAppUtil, SceTriggerUtil, SceThreadmgr, SCE types, error codes, SceCodecEngine, SceJpegArm, SceModulemgr (many of these additions are thanks to Graphene)
- Items common to user and kernel modules are to be placed in psp2common. Do not include directly from psp2common.
- Added a file db_367.yml containing NIDs for firmware >=3.65. At the moment this file is for reference only.


- Bug fix related to quoting variable expansion
- Updated default install list to match available packages


- Bug fix related with dependency management (or lack thereof)


- Made LIB argument for dolce_gen_libs and dolce_create_stubs optional


- Removed various unused packages
- Added libvitaSAS and libShellAudio
- Patched most packages to build with Dolcesdk
Reverse Engineering / sceTriggerUtil - library header + how to use
« Last post by Graphene on July 06, 2020, 08:26:01 PM »
sceTriggerUtil is library used to schedule one time or daily application events.

Prerequisites to use sceTriggerUtil:

1. SCE_SYSMODULE_TRIGGER_UTIL sysmodule must be loaded
2. "Settings->System->Auto-Start Settings" for application must be enabled (enabled by default). This will only appear in setting after at least one event has been registered by the application.
3. "app/*titleid*/sce_sys/incoming_dialog.xml" must be present. Examples of this file can be found in Radiko and Wake-Up Club applications. Multilanguage is supported (ex. incoming_dialog_JP.xml)

Information about events:

1. Max 8 events per one application can be registered.
2. Events will be triggered even when system is in sleep mode.

Library header can be found here:
Kits / Understanding and using the Content Downloader.
« Last post by SilicaAndPina on July 06, 2020, 11:30:21 AM »
Some of you may have noticed a "content downloader" option under "Henkaku settings",
OG scene members will remember this from "IDU Mode", but it also exists under ★Debug Settings,

infact because its possible to have IDU Flag and Testkit flag all at the same time-
its possible for this settings option can appear twice inside the settings app. one in idu, and the other in debug
(note you have to hold L when booting settings app in IDU mode, because henkaku actually hijacks the "idu_settings.xml" file..)

but enough trivia. what does it do?
well its quite like the name implies, it allows you to download PSVita apps from an HTTP source.

Specifically the following formats:

    .PKG (fPKG and PSM Only for some reason, its possible VITA pkg works with idu flag, but i haven't tested)
    .PUP (PlaystationUPdate files.)
    .JPEG/JPG (PNG files do not show up for some reason, despite the vita being able to download them from Browser)
    .MP4 (Does not check if its a valid video file)

Content Downloader will HTTP GET whatever url you enter, and attempt to read <a href=""> html tags from the response,
it will list any that .endswith() any of the supported file types, giving you multiple choice selections

upon clicking on the download button the PSVita will go through that list and append whats specified in <a href=""> to the base URI.
it will then send an HTTP HEAD request to that in order to get information on the file (Content-Length mainly)
and then start downloading the same URI with HTTP GET.

Introducing: Meme HTTP (mHTTP):
Content Downloader implements HTTP incorrectly, and includes spaces and special characters directly in file paths UNESCAPED so no %20 on spaces,
this breaks alot of web servers >_<

Content Downloader ASSUMES relative URIs in href tags, if for example your base URI is
and it contains <a href="">when attempting to download this file, the URI that gets requested will be

Because of all these annoyances i opted to write my own "Content Downloader" server:

However careful usage of existing HTTP server software (making sure not to include spaces in filenames, having file lists inside directories as "index.html" etc) should work i guess?

- Blessed Be

PS 3 / Re: PS3 CELL CPU Eraser Mod by Naked_Snake1995
« Last post by fmudanyali on July 05, 2020, 09:11:23 PM »
Used a stiff eraser this time but didn't see much difference.
Just remembered my room is 30+ *C now.

ElevenMPV-A v3.70 Update Full Changelog:


Thanks @realusagichan for testing and helping with debug.


1. Various performance improvements.

New (and returning) features:

1.   Added back cover picture support with few improvements:
    - External cover pictures can now be displayed. Picture must be placed in the same folder as music files. Note that cover pictures embedded in metadata are prioritiezed over external cover pictures.
    - For external cover picture, following names are supported:
    - Due to memory constraints, not all cover pictures can be loaded. If your cover picture is not loading, try to reduce its resolution.

2.   Added automatic volume limitation mode option for EQ.
    - The purpose of this mode is to limit mixing volume for ElevenMPV-A with EQ modes applied to prevent digital overload on loud tracks.
    - Only software decoded formats support this mode.
    - This mode can be enabled in Settings->Audio->Limit Volume Whith EQ.
3.   Added full support for CJK characters (chinese, korean, japanese languages).
UI and controls:

1.   Added fast automatic scrolling to file browser. Hold D-pad up or down buttons to perform this operation.
2.   Long text in file browser will now be scrolled.


1. Fixed an issue where certain directory or file names would result in a file browser crash.
2. Fixed an issue where notification settings were not displayed on PS TV.
3. Fixed an issue where track count would not be displayed or calculated incorrectly.
4. Fixed an issue that caused module data corruption in xmp library.
General / Re: frame pacing performance issue PS1/adrenaline
« Last post by kristianity77 on July 05, 2020, 12:48:02 AM »
Does stuttering happen with all versions of Adrenaline? Did you try early versions from here:

Happens on every version I've been able to get work.  I think the really early versions don't work on 3.65 /68 so I went back as far as I could and the result is the same all the way back.
I messed around with Uncharted for a little bit, the problem is getting the cpu to rev up at all but I managed a bit more cpu usage. I was thinking it might be better trying single cores for each thread as multicore seems to kill cpu usage.

Pages: [1] 2 3 ... 10