it doesn't work with that console, unless you have an earlier model with older bios (check the thread on it).
|
Would you like to get all the new info from
PSX-Scene in your email each day?
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! | ||
|
|
it doesn't work with that console, unless you have an earlier model with older bios (check the thread on it).
that is very good program
but why this verision didnt format and instaler for mc old ? itry this in 5 old mc and cant succf!
and (fmc noobile pack) good format old and new in same 5 card
did help me?
As the title says, I found a design fault that should have caused data corruption that could affect everything (From memory card dumps to even multi-installs).
Fortunately, the bug never occurs.![]()
(Therefore, I won't have to feel guilty of causing the memory cards and dumps of the 220 downloaders to be corrupted.)
Long story:
I did *fix* the DMA alignment issue in v0.93A, but forgot to increment the source buffer offset before sending the DMA transfer parameters to the function that performs the DMA transfers. The result would be that the data would not be transferred properly to EE RAM.
However, that bug never occurs because my usual *creativity* (lol... never knew that I was ever creative!) caused me to align all buffers to 64-byte boundaries on the EE.
(Hence, the buggy part of the DMA transfer alignment code in the IOP-side modules are never run at all).
Well, so I patched this bug, along with an old update to MCTOOLS to allow further installs after a faulty/corrupted card is inserted (E.g. a corrupted MC was inserted and causes MCTOOLS to attempt to allocate an erraneous amount of memory, causing MCTOOLS to fail further requests after that since the request to allocate memory failed).
Any further comments, suggestions and requests?

@SP193,
A bug that your code accounted for already, eh? Wow, even your mistakes fix themselves ;-) Honestly, I don't know what you can add to your installer to top it. It worked great for the installs I've done. It does what it needs to do, and in the least space needed. Excellent coding. If you have extra coding cycles to spare, hmmm, ever think about the homebrew tcpip stack fix for dma? Could I dream? ;-)
Thanks.
Coincidentally, I got some free time since 2 days ago because the final presentation for this schooling year (for me) had ended.
Today, I was trying to get a stable TCP/IP stack (With or without DMA support) working as I needed a way to backup the contents of my SCPH-20400 HDD unit (Which belongs to my SCPH-10000 console).
Unfortunately... it seems like even the good old port of LWIP v1.1.1 is.... unstable.
I could transfer about ~100MB of data off the 80GB HDD in my SCPH-39006 console with it, but something usually causes the connection between my PC and the console to be lost after that.
My port of LWIP v1.3.2 actually seems less stable that I had originally thought: It can be used to initiate connections... but it causes the PS2 to lock up once larger amounts of data is sent (Or maybe, only just after 2 or 3 send() + recv() operations).
The stack used with my modified HDL dump server v0.86 locks up after about a minute of operation... and the stack used with v0.92A crashes once it hits about 2.30MB/s.... (Which means that it doesn't work for very long either)
I guess that it also depends on the traffic on your network, as I have my MSN client and Bittorrent downloads running today.
I don't know what to do now.... maybe it's a problem with the design and general stability of the LWIP protocol stack on slower processors (Has anyone actually gotten a LWIP stack working on a ~33MHz system that supports multithreading?).
If I do get some time again, maybe I'll try using the WATTCP TCP/IP stack and see what happens....
Or maybe, I'll see how stable the SMS TCP/IP stack is and see whether I can get it to work outside of SMS on it's own... since I know that EEUG got (The faster half of) DMA transfers half-implemented.
EDIT: I think that I must have done something wrong, because my HDD management tool locks up regardless of the stack used... so whatever I've mentioned might not be correct (In other words, my previous tests are now probably inconclusive).
EDIT 2: I think that I did confuse myself: It seems like the LWIP v1.1.1 stack I used might not have been a pure LWIP v1.1.1 stack. It belongs to my custom version of PS2LINK... and I don't remember whether I had made any modifications to it. :X
All other stacks lock up at the same spot (Including the regular LWIP v1.1.1 stack from the PS2SDK), with the only difference being whether I need to hold the PS2's power button to switch it off or not....
On a side note, I should probably mention that accept() and select() in PS2IPS (The RPC server for the PS2IP/LWIP-based protocol stacks) appear to be broken.
Some functions like closesocket() and shutdown() are missing too... which means that the network portion of the PS2SDK is actually more broken and less completed than it appears. :X
Last edited by SP193; 02-08-2012 at 05:02 AM.

what is the good for me and stabelid
Unofficial FMCB v1.8C installer ----b
Unofficial FMCB v1.8C installe----A
FMCB v1.8b NOBILPACK
please after using the fcmb 1.8c 093a, there are no elf files like hdloader etc on the menu screen or in the boot folder in my mc, what should i do pls.
there should be ulaunchelf and configuration tool, though.
please hw do i get the elf files like opl,esr and d rest to be part of an installation bcos after running an installatn wit this package thos files r not on d screen or boot folder in d mc,i placed them in d app folder frm an earlier installer and it says writing hdloader elf etc but after d they dnt show on d menu or in the boot folder of my mc and secondly i ran this installer on my 10000k model but after puting the mc in slot 1 it doesnt boot freemcboot, wat is wrong or which other installer do i use for my 10k model pls. Thanks
You have to modify FREEMCB.CNF to add additional menu entries.
The programs will be copied to the APPS folder on your memory card, not BOOT. The BOOT folder is for uLaunchELF.
So if I understand you correctly, you are saying that pressing RESET on your SCPH-10000 after installing FMCB will cause the PS2 to boot normally, without booting FMCB?
I haven't had any issues with running this installer on my SCPH-10000, so it's probably a problem with what you are doing or with your hardware. Try using original Sony 8MB cards, as some compatible cards don't work well with fat PS2s.

| « Previous Thread | Next Thread » |
| Tags for this Thread |