HD Homebrew Project Developement (Old Thread)

**Ex-Cyber** · 05-21-2007,05:15 AM

The C99 TC2 draft standard says:

argv[argc] shall be a null pointer.

I don't know how far back this goes (C89? standard practice on UNIX?) or how many runtimes actually behave this way, but I guess that code is, in some sense, valid.

edit: poked around a bit, and it looks like this wording has been in the standard since at least C89, and I suspect that at that time it was codifying existing practice...

**suloku** · 05-21-2007,07:12 AM

Originally Posted by barf

Anyone got a ps2link that will work as boot.elf in the independence exploit.

This one works for me http://ps2dev.org/ps2/Loaders/PS2_si.../PS2Link_v1.46

If not, just load it as default in ulaunchelf and set the timer to 1.

**Polo35** · 05-21-2007,12:04 PM

Originally Posted by dlanor

load irx from an other elf...

I made some test but i'm not able to pass more then 252 bytes of an irx through argv, i think it's due to "LF_ARG_MAX 252".

Originally Posted by dlanor

Delay gsKit...

I'm totaly agree that it must be gskit which test if it's current operation is finish before beginning a new one.
But as i state before, i found where is the problem and found something to have an accepable printing result in our gui.
I don't want to spend more time debuging gsKit fontm for now, i've lot of other thing to do and to debug.

argv[argc] = NULL...

I think it's better to set argv[argc] to NULL after setting all args we want to pass, because i found some code from $ony with same code romz post above.
"for (i = 0; argv[i] != NULL; i ++)".

Best regards

Polo

**dlanor** · 05-21-2007,07:04 PM

Originally Posted by Ex-Cyber

The C99 TC2 draft standard says:

I don't know how far back this goes (C89? standard practice on UNIX?) or how many runtimes actually behave this way, but I guess that code is, in some sense, valid.

edit: poked around a bit, and it looks like this wording has been in the standard since at least C89, and I suspect that at that time it was codifying existing practice...

Thanks for the info. Apparently I was wrong about how this is defined, but I still think it would be a mistake to rely on that null terminator in code of our own. Since the argc index is available there is no reason not to use it.

Even so, I also agree that this definition does make it mandatory to place a null terminator after the valid pointers in the argv arrays we prepare. I still think this rule is redundant nonsense of course, but as that nonsense appears to be an established standard we have no real choice about it.

Best regards: dlanor

**dlanor** · 05-21-2007,07:23 PM

Originally Posted by Polo35

I made some test but i'm not able to pass more then 252 bytes of an irx through argv, i think it's due to "LF_ARG_MAX 252".

I'm not sure if I understand you correctly, but I certainly did NOT mean that you should pass any entire IRX files as argv parameters. What I meant was only for the GUI to load the IRX files into some part of EE RAM and then tell mcemuloader.elf where to find them through some new argument passing the RAM address.

I'm totaly agree that it must be gskit which test if it's current operation is finish before beginning a new one.
But as i state before, i found where is the problem and found something to have an accepable printing result in our gui.
I don't want to spend more time debuging gsKit fontm for now, i've lot of other thing to do and to debug.

Sure, but we should keep this stuff in mind for later then, when we may have more time to implement a proper fix.

I think it's better to set argv[argc] to NULL after setting all args we want to pass, because i found some code from $ony with same code romz post above.
"for (i = 0; argv[i] != NULL; i ++)".

Apparently some people use that method, as part of some ancient standard. Probably before someone came up with the idea for argc, so that only the string pointer array was available. Whatever the reason, we too must then use that method in creating argv arrays, for compatibility.

Best regards: dlanor

**romz** · 05-22-2007,07:19 PM

Temporary page for the project:
http://www.cdvdmania.com.ru/misc/mcsioemu.html

**Polo35** · 05-23-2007,07:49 AM

Originally Posted by romz

Temporary page for the project:
http://www.cdvdmania.com.ru/misc/mcsioemu.html

Great, that's nice to have a web page with our work.

Really Romz you're a boss. Take a look to the free size:

A 128Mb virtual mc.

And there is no limit when using infofile in romz module. ( Access time ? )

Mc create fonction is nearly finish, with choise to make an empty vmc, or a formatted vmc, but formatted one have a maximum size.

( for the moment, i'm able to make a 8Mb vmc, i've to study a bit more stucture of vmc i made )

@romz: can you tell me if there is some restiction with PageSize, BlockSize, and CardSize. I mean if Pagesize can be 1024 or 2048, or only 512 ( 0x200 ), what is exacly BlockSize ( i know it's the page number per block, but ... ), ...
Thanks.

Best regards

Polo

**romz** · 05-23-2007,09:06 AM

Originally Posted by Polo35

Take a look to the free size:

A 128Mb virtual mc.

And there is no limit when using infofile in romz module. ( Access time ? )

What is that program?

Originally Posted by Polo35

Mc create fonction is nearly finish, with choise to make an empty vmc, or a formatted vmc, but formatted one have a maximum size.

( for the moment, i'm able to make a 8Mb vmc, i've to study a bit more stucture of vmc i made )

I believe it is possible to create an empty virtual memory card of larger size and then call MCMAN to format it. However, this will require MCSIOEMU installed within the GUI itself.

Originally Posted by Polo35

@romz: can you tell me if there is some restiction with PageSize, BlockSize, and CardSize. I mean if Pagesize can be 1024 or 2048, or only 512 ( 0x200 ), what is exacly BlockSize ( i know it's the page number per block, but ... ), ...
Thanks.

Actually, PageSize maximum value is limited to 1024 bytes due to MCMAN design. MCMAN reads memory card page by using a number of DMA transfers while SIO2 packet allows to store up to sixteen control codes. MCMAN gets 128 bytes per a single DMA transfer and this size is fixed. Furthermore, MCMAN has its own hardcoded limit for SIO2 packet so it can send only ten SIO2 commands at once. The page reading sequnce consists of "Start Reading" command, N * "Read Data" commands and an unknown command (may be "Reading Complete" or something like that) so it will have six commands for cards with PageSize set to 512 bytes ("Start Reading [PageNumber]" + 512/128 * "Read Data" + "Reading Complete" ). It's obvious the reading sequence will contain ten commands (1 + 1024/128 + 1) for cards with PageSize set to 1024 bytes and it will reach MCMAN's internal command limit. Not to mention that latest MCMAN modules appear to assume the PageSize is always equal to 512 bytes as I wrote before.

As for BlockSize, the NAND memory pages are grouped into blocks and "erase" operation works on block basic. You can read the datasheet for NAND chip: http://www.samsung.com/Products/Semi...8u0c_rev11.pdf to get further details. AFAIK, Sony uses K9F6408U0C chip for official memory cards. Therefore, NAND driver erases whole block of pages in order to rewrite a single page. I'm not sure on how many pages can be "cached" by MCMAN to save their contents during a block erase operation since MCMAN modules don't use dynamic memory allocation but I believe the BlockSize is actually limited to 16 (may be 32) pages. I believe the reducing BlockSize (for a new virtual memory card) to 2 will be increase writing speed a lot (I think BlockSize should be 2 (or even 4) at least to avoid problems with memory card format).

**ssjkakaroto** · 05-23-2007,09:26 AM

I think that's inside some Winning Eleven/Pro Evolution Soccer game, not a program.

**Polo35** · 05-23-2007,05:41 PM

Originally Posted by romz

What is that program?

It's the mc manager inside PES6.

Originally Posted by romz

I believe it is possible to create an empty virtual memory card of larger size and then call MCMAN to format it. However, this will require MCSIOEMU installed within the GUI itself.

I believe it too, but i didn't have any success with this way for the moment.

Originally Posted by romz

Actually, PageSize maximum value is limited to 1024 bytes...

Thanks for those infos.

When i saw NAND chip, i remember something:
In ps2sdk, under iop/dev9, there is source code of an irx name extflash.

Here a part of the readme file:
"The PS2 50000 series BIOS introduced a new expansion (Dev9) device driver for NAND (serial) flash and a method for booting off of this device - the "External Flash ROM". This flash is the same type as the 64Mbit flash found in the PS2 memory card."

Maybe you can find some interesting thing.

Best regards

Polo

User Tag List

Thread: HD Homebrew Project Developement (Old Thread)

Tweet

LinkBack

Thread Tools

Display


	Would you like to get all the new info from PSX-Scene in your email each day? Subscribe to our Daily Digest! Want to learn more about the team keeping you up to date with the latest scene news? Read about them now! Check out our Developer bios, too!