Fixed, Pre-Built, Win32 PS2SDK :)

[JCDes]

We got to it work... ffgriever pointed out lines that needed to be added to libjpg.c and worked like a charm... Once again thanks to ffgriever...

[Lazy Bastard]

Interesting, but as I noted at PSX-Scene, I won't be adding that modification to GSHI_PS2SDK, and hope that a better solution is found. Perhaps I'll put together a copy of FMCB that uses the modified libjpg libraries locally (within the same directory as FMCB), so it will compile properly, but users don't have to mangle their SDKs.

[JCDes]

Thanks a million for the GSHI_PS2SDK download...

[Lazy Bastard]

It's my pleasure. It was needed, since as far as I can tell, there isn't a proper way of setting up a PS2SDK in Windows right now.

[JCDes]

It happened to me on another project (not related) where my friend had linux environment and I have windows, we almost ended up with two sources for the same program! LOL...

[Lazy Bastard]

Ah. Well, there should be no difference between a Linux PS2SDK and a Win32 PS2SDK, except that there a few utilities that only work in Linux (ROMFS, Libito, etc), and that in Linux, you won't need anything like Cygwin or msys/MinGW. Transferring files between Linux and Win32 doesn't have an effect on the files, and it definitely doesn't modify the source of a project itself, so the only issue you may run into when working on a project with a friend who's using Linux is that he may be able to use a few utilities that you may not, and as such, you may not be able to compile some source that he can.

The reason I mentioned using a Linux build of PS2SDK was to clear GSHI_PS2SDK's name as a culprit of the issue you were experiencing. ie, if you weren't able to compile the source on a Linux PS2SDK (which you wouldn't have been able to do, in this case), then obviously the problem is with either FMCB, or the PS2SDK in general, but not with the GSHI_PS2SDK build. In this case, it turned out to be an issue with libjpg, which would have occurred no matter which SDK you were using, unless you had the exact libjpg libraries the FMCB authors had, or modified libjpg as was laid out by ffgriever and dlanor (which is just a choppy hack, as they both mentioned, and not really a proper fix...not to mention the fact that it will cause serious problems with other source, if you don't recompile libjpg from the original source afterward, and replace the modified files).

Anyway, I've asked jimmikaelkael if he used a modified libjpg, and to take a look at the libjpg issue, and see if he can help. He's already been quite helpful, providing a makefile that solves the missing directory issues (though I could have made that myself, it's the thought that counts, and I think he'll be quite willing to help answer questions concerning his source). He's going to be releasing v1.8 soon apparently, with some fixes.

[JCDes]

Cool!

[leonidas08]

Hi,
When trying to compile Pukka´s dumpbios source from ps2dev I get the following error

make
ee-as -mcpu-5900 EL crt0.s -o crt0.o
c:\mysys\1.0\localps2dev\ee\bin\ee-as.exe: unrecognized option ´mcpu-5900´
make: ***  [crt0.o] Error 1

Any ideas?
Pgen says a similar error when compiling but the unrecognized option is mcpu-r5900.
I know your busy with Artemis and other things so if you don´t have time to look it over I understand. i was just wondering if this was a simple fix.
bye.

[Lazy Bastard]

Most of the responses I've gotten concerning those deprecated or retired options have been either to omit them and see what happens, or replace them with the newer version (which I forget, in this case). The answer, however, is somewhere at forums.PS2Dev.org. Rather than use their unbecoming built-in search function, I'd recommend using the Google search I've created:

http://www.google.com/coop/cse?cx=00...31ipwaaa&hl=en

Let me know what works in this case

[Lazy Bastard]

For the record, in the post several pages back which started with,

"OK; I've fixed that issue, by replacing the old dmaKit_init code in FMCB's draw.c..."

...I later noticed that FMCB's authors had left a commented out line with the alternate code (obviously in preparation for this issue). I never thought to go back and revise my comment, but just so it doesn't seem as if I've fixed an issue that the original author didn't consider, I thought I'd make that note.