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

Alright, I found my old 48bit hacked HDDOSD ELF and ran it.


The HDD is a Hitachi Deskstar HDT725032VLAT80 (ATA/IDE), 320 GB, 7200 RPM, jumpers set to Master. The NA is a genuine SCPH-10350.
http://youtu.be/18vLuFTYUag?hd=1
I saw how slow the HDD browser is so I hooked the HDD to my PC, ran WinHIIP and found that installed games suffer of a rather outrageous fragmentation.
http://youtu.be/0F6Cqb_pihM?hd=1
Then I had a look to the HddManager of uLe and oh jeez, it took 25 MINUTES for the indexation to finish.
http://youtu.be/QNAPuNqMNnE?hd=1

Now I doubt that the HDD OSD slowness issue is caused by a bad xDMA tweak in the driver. I have more confidence that my HDD is so messy it makes the HDD OSD seek like a maniac. Or perhaps it has something to do with the partition HDL namings.
So, I'm gonna have to release that patched HDDOSD somewhere one of these days for testers... All my other HDDs are full and I can't do deeper tests with that one.

I'm rewriting "S.U.D. Mutilator". There are several ways to get the CDVDkey (via CDVDMAN export #35 or RPC 0x80000595 for example). I personally prefer to use the N-Cmd 0x0c because my coding skills are low and IOP side stuff isn't my thing.
Then I get the CDVDkey @ 0xbf402020. 0xbf402020 to 0xbf402025 are XORed against 0xbf402039.

 

I now Know what I was doing wrong in WinHex, The Icon in WinHex starts like this "00 00 01" and you need make sure you copy it on to the same "00 00 01" that's for the HD Loader/KERMIT game icon. It works the same as installing ELFs to the HDD.

Wow, you can use 48bit... slow or not I love to use it.

Also, if someone can help. I must be doing it wrong. (This is for installing ELF/KELF) I tried to name it "Open PS2 Loader" on title0 but I'm only getting up to 10 (like this "Open PS2 L") If I do more then 10, it goes to blue cube for Corrupted Data. This is what I'm editing
PS2X
title0 = uLaunchELF
title1 = Version 4.42b
bgcola = 64
bgcol0 = 22, 47, 92
bgcol1 = 3, 10, 28
bgcol2 = 3, 10, 28
bgcol3 = 22, 47, 92
lightdir0 = 0.5, 0.5, 0.5
lightdir1 = 0.0, -0.4, -1.0
lightdir2 = -0.5, -0.5, 0.5
lightcolamb = 31, 31, 31
lightcol0 = 62, 62, 55
lightcol1 = 33, 42, 64
lightcol2 = 18, 18, 49
uninstallmes0 =
uninstallmes1 =
uninstallmes2 =

 

Nope. The HDD OSD works like that. Press triangle to open the menu. That's because the HDD osd has an added function which brings a software keyboard. That would allow you to rename some items.

Actually that "header" is identical on all PS2 3D-ICON files.

There is a limit of 16 characters (UTF8). ASCII happens to work too but SONY does not recommend using it. I think you can put about 20 characters per line using ASCII. Some ASCII characters cause it to glitch. So if you need to use accented characters or such you might want to stick to UTF8.

 

I've tested some things and switched booting between fmcb and hdd-osd.
Never recognize this difference...

And the kanji thing...



Rgds.

 

There's no "and the kanji thing" because UTF8 supports Japanese. So basically, UTF8 uses three bytes per character.

 

No. It depends on the Unicode character itself. It can be anything from 1-4 bytes.

ASCII characters below 128 (0x80) will be recorded "as-is" (ASCII characters).

It seems like English titles are not restricted to 16 characters, but I don't know the actual limit for that. Exceeding the 16 character limit for Japanese titles will automatically trigger the "corrupted data" syndrome.

 

When I find the time, I'll make a maintenance release that allows installing your own icon. Maybe similar to how you specify HDDLOAD.KELF now.

As l_oliveira wrote above, you may want to download the official PS2SDK and read in there. The file hdd_rule_3.0.2.pdf describes in detail how and what to write into the partition's attribute area.

Did you update the length field for system.cnf in the partition header? If not, so HDDOSD will cut the last entry ("uninstallmes2 =") and then run into a parser error.

It may work for english titles, but the official SDK clearly states that the maximum is 16 characters per line:

 

Also, on using PS2 Icons for HD Loader/KERMIT games it same that some icons do not work and just get a blue cube for Corrupted Data and the ones that do work have errors. (Errors are mostly just a black top of end of the icon) Does any one know info on this and may know how to fix it.

If you can, that may help the errors I'm getting on the icons (I can upload a photo of the errors if you like)

What? I was not doing this at all and I'm not sure how to as well, looks like I need to look at that official PS2SDK for the info. What does the system.cnf partition header look like and can it be edit in winhex.

 

Should be correct...

- Verify system.cnf/icon.sys/display.ico/delete.ico starts and lengths after the "PS2ICON3D" identifier, they must match location/size of your data.
- Make sure all system.cnf and icon.sys lines are ended with 0x0a
- system.cnf/icon.sys/display.ico/delete.ico must start at sector start (not sure, but anyway it's good looking in a hex editor)
- Fill unused sector space with 0x00 till the beginning of the next sector

 

Thank you, this will help me a lot but I'm not sure on how to update the length field... (Sorry I'm just not to good on a hex editor)
also your not use winhex are you, what's the hex editor you use?
Oh, I'm not sure what all this is 0x0a is that "0D 0A" and is 0x00 "00 00"? I'm using winhex (May not be the best) and in winhex I'm not see the "Secteur" listed like that for the "PP.", just for all of the HDD

Thank you for the help and hope to see your 48bit HDDOSD someday. (Not that I need it, 28bit is great for me)

 

It may be just the design of the Sony APA driver as well. If you know how slow OPL is when loading games from really large HDDs, you will know why this happens: The APA driver will have to scan through the entire HDD to look for partitions. On large disks, this will take... quite a while.

But your disk seriously takes quite a long time to load the contents of the disk. It may really be a problem with the transfer mode setting. @@
Was it always like that?

I've updated the homebrew SDK's libcdvd EE RPC library, so now the reading bug is fixed and I can access the system functions like sceCdReadKey(), sceCdBootCertify() and so on from the EE without manually issuing a N command to the CD/DVD drive. Would you like to have a copy of my work?

 

I meant the shift-JIS spacing character (0x8140) thing.
Most tools use the wrong value.


Rgds.

 

The hex editor I use for writing to the HDD is HxD http://mh-nexus.de/en/programs.php
The other one I use for hex editing files is HexEdit 3.0F http://www.hexedit.com/download.htm

0x0a is hex 0A, not 0D 0A (0x0d, 0x0a) like when you press enter.
For example, on my picture at offset 240 you can see "NICHDD". After "NICHDD", at offset 0x0246 there is 0x0a (hexadecimal 0A).

Another example at offset 0x0224, you can see 0x0a between "1.00" and "VMODE".
0x0a is the marker of end of lines, for the parser to handle them correctly.


0x00 is just hexadecimal 00.
Example from my picture, display.ico data is :
0x49, 0x20, 0x41, 0x4d, 0x20, 0x44, 0x49, 0x53, 0x50, 0x4c, 0x41, 0x59, 0x2e, 0x49, 0x43, 0x4f.
In ASCII : "I AM DISPLAY.ICO"
The rest (unused space of the sector) is zeroed, each byte is 0x00 till the next sector (the next sector constains delete.ico).

I'm working on it. Its ATA driver is re-written with PsIIatad 2419 libs (official SDK) so it can't be shared here as it's illegal.
Will repack the HDDOSD with a tiny loader that allows to run it from any path or native fs without the need of the MBR, then I'll post the archive somewhere and send you a PM.

 

To be precise, 0x0A is '\n', which is the newline character. In Microsoft OSes (Or just any OSes that use CR LN characters), you will have the carriage return character too (0x0D 0x0A - '\r''\n').

Unix/Linus OSes will generate only the LN character when you hit the return/enter key. The PS2's kernels seem to be based on Unix/Linux if you look at how it's IO managers were designed.

Why can't the homebrew driver be used instead? AFAIK the APIs are compatible.

 

I didn't open a physical HDD, but a file (a fragment of partition). It explains why PS2ICON3D is reported at Sector 0, which is obviously wrong.

That's what I thought first as well, but since I can't re-arrange my installed games, I can't verity that it's due to bad transfer mode settings and not to the fragmentation.

I don't remember. I think it was fine and the problem appeared after I've expanded the OPL partition "PP.0" for adding more VMCs.
Funny thing is that I ran the "Evil" build of uLe and indexing completed in 20 seconds...
http://youtu.be/iIRPhGAQqYI

Oh yes please. I'd greatly appreciate, thanks.
My code involved getStatusReg and setStatusReg from poweroff.c, an unsigned char array for cdApplyNCmd 0x0c and a thing that reads and XORs the CDVDkey from the register area. Worked but not a good job.

Good to know, thanks.
I once wrote a proggy that had an annoying bug. 0x0A was always converted to 0x0D 0x0A when memcpied to the buffer.

I messed up with HDDOSD's ATAD a while ago. Injecting homebrewn ATA driver caused it to crash. I'll try again because it's the easier solution and the most appropriate for patch distribution.

 

HDD OSD doesn't work if you put SHIFT-JIS on the text field. It accepts only UTF8.

SHIFT-JIS is valid only on MEMORY CARD icon.sys files...

And the wrong separator (plus garbage on random fields) at the icon.sys file is what causes the SCPH-10000 to freeze at the memory card browser when you try to see items with homebrewn files in them at memory cards.

I remember researching that in 2010 with dlanor (uLE would generate files that could crash/freeze the SCPH-10000 without a harddrive/HDD OSD installed).

 

After the fields described by krHACKen, you add 4 32 bit fields, KELF offset, KELF length, KIRX offset, KIRX length. If "BOOT2=PATINFO" then that information will be parsed and resulting data will be used to load the KELF/KIRX.

This was discovered by SilverBull.

 

Ahh, good to known. I'll have a try with a hdd-osd icon.

So that's why i said it's a ~2MB data block.



Rgds.

 

It's actually less than 2MB datablock block if you're thinking of a HDL partition due to HDL be using sectors within the PARTITION INFORMATION region for settings/inline game name and fragmentation table, which reduces the usable space for KELF/KIRX considerably. Hence why I "cleaned" OPL and made it be like a 75KB file. Only the bare minimum stuff were kept.

 

A small addition: if "BOOT2 = PATINFO", it will load the KELF. If you want to use the KIRX, you need to specify "IOPRP = PATINFO" in addition; that syntax for the IOPRP is only recognized if you are also using a KELF.

According to the Sony SDK, the attribute area header (that's the sector starting with "PS2ICON3D") contains an array describing 4 files. These do not have names, as the area does not have a true file system; however, they can be referred to by some made-up names, according to their format. The files are:

[0] system.cnf: like SYSTEM.CNF on a CD/DVD, with above-mentioned additions for BOOT2 and IOPRP.
[1] icon.sys: similar to icon.sys on memory cards, but a text file (its binary on MC). Starts with "PS2X", contains game title, uninstall messages, lighting info and so on.
[2] list.ico: the binary icon data, used for display in the partition list. Compatible to icon data found on memory cards.
[3] delete.ico: the binary icon data, used when attempting to delete the partition. Same format as list.ico.
[4] boot.kelf. A HDD-signed KELF container, housing a regular EE ELF. Used when starting the partition and "BOOT2 = PATINFO" is set in system.cnf
[5] boot.kirx. A HDD-signed KELF container, housing a replacement for rom0:UDNL. Used when starting the partition, but only if both "BOOT2" and "IOPRP" are set to PATINFO in system.cnf.

Only files 0-3 are documented by Sony.

Each file is described by a struct { u32 offset; u32 length }. Offset is in bytes, relative to the start of the attribute area header ("PS2ICON3D"), and must be a multiple of 0x200 (the sector size). Length is in bytes with no alignment restrictions. If a file does not fill a sector completely, length specifies where it ends. If there is any further data in the sector, it will be ignored by the OSD. That's the reason why you get "corrupt data" errors when title0 in icon.sys is too long: you move the last line "uninstallmes2 =" over the end-of-file marker, so the OSD only sees something like "uninsta" at the end of file. That's not a supported keyword, so the parsers aborts and the partition is flagged kaputt.

By the way: the restrictions on offset come form the fact that it is simply used in a sceLseek call on the partition fd. When opening the partition directly (that is, without mounting it), offset zero is the attribute area header, so all file's offset values can be used directly. Length is rounded to the next 0x200 bytes when reading, but anything beyond the specified length is cut out afterwards.

I assume its the same problem with a mismatched file length. Although I'm surprised the OSD does not notice the icon file is too short to contain all the data, and abort as well.

Just look for the sector starting with "PS2ICON3D". 16 bytes after the start of that signature, you should see 4*8=32 bytes, for the special 4 files mentioned above. Get their offset fields, add them to the address of the attribute header, and check what comes at that address. You should arrive at the start of the respective file. Then check the length fields. If you make any changes, to any of those files, you need to make sure the length is correct.

It's 2MB-4KB (to make up for the APA partition header), isn't it? HDL puts its data somewhere right into the middle, so it is as you say, there is not much room left for a KELF. I remember when thinking of a way to put Kermit in there and make ODEM partitions startable from the OSD. The only solution I got working was to use a small bootloader KELF (using Neme's hack of injecting a payload into a DVDPLAYER), which then loads Kermit from memory card. Kind of ugly, but works :cool-new:.