(Help) How to add Icons to HDLoader/KERMIT Games on PS2 HDD-OSD

HDL stores settings inside the game partition. OPL uses a memory card save or +OPL partition on the HDD depending on the version. It can use either or both.

MINI-OPL has fixed settings.

 

Thanks!

I tried different configurations of the fixed mini-opl settings. No changes.
As you said before, it seems to be the CDVDMAN.

Sad, i have not the time to do such complex modifications...


Rgds.

 

In MINI OPL I wanted it to work with most games. I didn't care for speed. Also it seems some OPL source branches are using my modifications on CDVDMAN so they will be just as slow.

 

Yes, i know.

I would like to use single minis for different games.



Rgds.

UPDATE:
@Leonard
I found the "no delay"-files in the source.
Made a new build with that but there's no difference.
Any idea?

Thanks a lot and have a nice day!

 

Hi!

A big respect for the mini and the work to embed SilverBull's timer delay.


Currently i try to understand what will cause the extreme long loading times.
The opl build i use has the delay patches and the loading is quick.
I would like to understand the mini default settings.
Where are these defined?


Thanks!

 

Silverbull's change work by adding a programmable delay on a very specific case during CDVDMAN operation (I can't remember right now without looking the discussion thread or the sources) but it's something that get called on a specific stream read situation. The resulting slower read effect isn't very noticeable as the change is affecting such specific cases.

On my patch I choose to slow down everything CDVDMAN does. I implemented a simple flag or token system (similar to the "sync_flag" thing that already existed) which toggles if the EE side send SIF request throuch sceCdRead() or sceCdRead0(). If sceCdRead() is used, a delay called "th_delay" is applied to the thread. The IOP kernel detects that the thread is halted and allows the IOP to work on other threads while the read thread is stopped, which is why the problems are alleviated.

On the REAL CDVDMAN, the delay happens in a similar way but it's because the IOP is obligated to wait for the drive hardware to mechanically find, read and decode the data from the optical disc.

So you see, the IOP is extremely busy running the game already, if you drown it in data the game will suffer and you will get all those odd glitches. Reading faster from the HDD is a problem, not a solution.

 

Hi and thanks for the quick reply!

So the opl has the preferences delay option "CDVD functions (0 is default)" and the mini has a "cdvdman_timer 500".
Is this the same delay?

And, as i read your words i can't really understand why a stripped version of the same source code make such different results.
For my understanding you said the delays are a result of the business of the machine.
So, to get a comparable result i will try to start opl in the same conditions as the mini.
If there are no delays we should talk about the mini. Loading times that are 3x, 4x, or more longer from the same partition are really strange.


Rgds.

 

Yes. Hard coded as "500". I am not sure how OPL deals with the number input by the user at the UI.
But I think 500 has the same effect as the default value on OPL.

Original OPL with unchanged CDVDMAN does not slow down the data transfer thread when sceCdRead() is called. Mine does.

Put "modules" folder from mini on your OPL source and compile it. Then you will have the CDVDMAN with my changes in it. Try it out then.

Also MINI has SMB and USB stuff completely removed from EE CORE which makes it smaller, so more memory is free for the game on the EE side.

 

Meanwhile i have read the bitbucket opl changes (the delay ones):
"The GUI variable define the timer to apply (the real value applied to CDVDMAN is multiplied by 250, so a value in GUI of 50, apply a 12500 timer to CDVDMAN)."
Now i think i am lost.
:dejection:

Interesting.
I was thinking of starting the opl via patinfo or starting mini as like the opl elf to get first results.
Okay, i'll give the opl with the mini modules a try...


Have a nice day!

 

Sorry for noob post but in almost every tutorial i've read about installing HDD-OSD there's mention about MAX size of HDD (about 120GB). Is there any way to install HDD-OSD on bigger HDD? (400GB)

 

The current method for installing a LBA48 modified HDD-OSD is to write a dump of it to your HDD (with your HDD hooked to your PC). It's failproof, but overwrites the first 512MB of your HDD.

Once you wrote HDD_DUMP.IMG to your HDD, don't forget to restore your partitions (with WinHIIP "Scan / Repair PS2 Drive" utility).

I also pumped out a MBR containing the 48-bit modified hosdsys, but trashed the dl link since I realised that the HDD-OSD was totally mute:moody:...

 

I forgot to ask you about this, but why does the user have to write a dump to their HDDs? Why can't they just copy the patched HDDOSD files over? :S

 

Writing a dump is not a requirement. Like you said, the user can create partitions and copy the patched files, or copy patched files to the existing system partition. But the package in question does not contain KELFs, just a HDD dump (for those with no mod/softmod) and decrypted ELFs (for users with uLe and all the stuff needed to test/inject the patched HDD-OSD).
The idea of spreading dumps went on me when someone couldn't install the PSBBN from the DVD (the DVD was badly burnt). I published ready-to-use HDD-OSD/PSBBN HDD dumps then later, it turned into a PSBBN customisation ORGY:very_drunk:.


This patch : "PlayStation BB Navigator Version 0.32, OSD for PS2 Memory Card, osd110.elf & osd130.elf (KELFs)"
has been tested by someone with a PCMCIA Jap PS2 (SCPH 15000) and an unofficial HDD. It worked LOLOLOLOLOLOL:encouragement:.
Still in contact with the tester and I requested him a dump of his PSBBN 0.32 disc, in the hope I could crack it and release a proper "A3" build.


EDIT : The LBA48 mod is just the replacement of 5ony's ATAD IRX with a homebrewn ATAD IRX, quite simple to do :
- Decrypt and unpack the hosdsys.elf
- Rip the ATAD IRX out of uLe 4.40_ev
- Replace the hosdsys ATAD IRX with the one you ripped out of uLe 4.40_ev.

The decrypted ELFs of the said "48BITEST.RAR" archive have a surplus of test-mods :

... not really needed/wanted by the end user.

 

I love to use the mbr-writing tool.

First: Creating the the needed standard partitions i.e. via ule.
Second: Writing the needed mbr to the hdd.
Third and last: Copying the needed system files.
Et voila: Ready to take off...


Rgds.

 

SP193's MBR writing tool. The tool itself states that...

 

Is it from SP193?
I was thinking you two were working on that.
And to be more precise it's the fixmbr.elf i am talking about.


Rgds.

 

I don't give credit for things if the authors specifically ask me to not do so. And even then I don't claim them as being my ideas to begin with...

 

Understood.

 

Hmm... would you want to allow the users to have a nice installer that doesn't require them to backup their HDDs?

While I probably cannot commit time for writing such an installer (You, or someone else has to do it), I can share my own personal MBR program with you, so that you can boot the HDDOSD without the Sony MBR .

It's a clone based off the Sony MBR, and does what the Sony MBR does. But since it's ours, we can get it to boot KELFs or just normal ELFs.

And it'll be able to boot off normal, unmodified consoles (Without FMCB and modchips).

Wow, that's great news!

One more question: Why must it be the ATAD module from 4.40_ev? If it's because of that weird limitation imposed by a certain programmer many years ago which causes the password-protected Sony partitions to not be accessible... it affects the APA driver (PS2HDD.IRX).

If you do have an option to totally disable the button swapping, I'll use it anyway.

Circle should have always been the select button.

LOL!

While it's true the that MBR writing tool was written by me for my SCPH-10000, the ideas originated from you. Do feel proud of it...

I think that someday, I'll write a better tool that will write to the first (__mbr?) partition instead. I think that it's bad to assume that the first partition is at 0x2000 (Unless Sony does that...).

If I didn't mention you in that old README file, it's because the file was solely about the tool itself. Any larger projects will surely have your name in it.

 

Actually, at the first sector of the harddrive you should see this:

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

000000130 00 20 00 00 A2 01 00 00 00 00 00 00 00 00 00 00

Where red is the offset in sectors where the MBR KELF is put at and how big it is, again in sectors on blue. :encouragement:

So SONY does put it at different places, just depends on their mood at the time. PSBBN installer disc like to put the MBR at a different place than the HDD Utility disc. It's just their mood, honest.