forums.ps2dev.org

[Lukasz]

Update:
Tutorial and binaries now available at: http://lukasz.dk/programming/playstation-2/mingw-tutorial/

Original Post:
Today I attempted to build the PS2 Toolchains with ooPo's script in MinGW and succeeded with some minor modifications to the toolchain. I'm just gonna describe the process briefly, as I'm going on vacation in a few hours. I will probably write up a complete tutorial once I get back in a weeks time, unless someone beats me to it.

First of all you clearly need to install MinGW, MSYS and other tools. I just downloaded everything described in this thread:

http://forum.doom9.org/showthread.php?t=108215

Besides from those tools I also downloaded wget and subversion and manually installed them in the MinGW enviroment. I also renamed rxvt.exe to rxvt2.exe in the MSYS bin directory, to use sh as a shell instead of rxvt.

Then I just did a svn checkout of ooPo's toolchain script in MSYS:

[ooPo]

If it doesn't affect 'normal' building of the toolchain, I see no reason why it can't be added. Otherwise, we can figure something out. Maybe a separate patch or something...

...anything to get people from using cygwin. :)

[ooPo]

I've added it to the gcc patch in the repository, so you should be able to build it on mingw without modification now.

[cosmito]

Can one have both MinGW and Cygwin installed at same time without conflicts? I have Cygwin but I would like to evaluate MinGW too.

[radad]

ptek: That should be no problem.

Lukasz: I would love to have a build of the tools to test out.

[cosmito]

radad,

I think ragnarok2040 made available a build using MinGW here :
http://forums.ps2dev.org/viewtopic.php?t=6995

A few details :

[Lukasz]

Tutorial and binaries now available at: http://lukasz.dk/programming/playstation-2/mingw-tutorial/
_________________
Lukasz.dk

[chp]

To get it building under Vista (x86, haven't tested x64), you need to do a few things:

First, you need to use candidate instead of current for reasons that come later. If you have installed with current, uninstall and install again with candidate, and follow Lukasz's instructions as normal.

Then, download a new msys-1.0.dll, this will get rid of the heap-issues for all msys binaries:

http://prdownloads.sf.net/mingw/msys-1.0.dll-SNAP-1.0.11-2006.04.23.tar.bz2?download

Decompress this with something like WinRAR which supports bzip2 archives, then rename new-msys-1.0.dll to msys-1.0.dll and copy it into C:\msys\1.0\bin (or wherever you installed msys).

After that, go into C:\msys\1.0\postinstall\ and run pi.bat to get the postinstall step properly executed, since it never ran when you first installed (complaining about issues with cygwin heap).

When all of this is done, here's the reason for using candidate. Download http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz and decompress into your MinGW folder. This is to get rid of a nasty bug that causes GCC to not find the compiled backend. (perhaps this file should be given local hosting so we don't exploit some poor souls bandwidth?)

You should now be able to compile ps2toolchain in MinGW under Vista. You do however need to do this in a slightly different fashion than described. To not get build-errors halfway through, instead of:

[Lukasz]

I've updated the tutorial with a notice for Windows Vista and a link to chp's post. I've also mirrored the two files required in the instructions.
_________________
Lukasz.dk

[radad]

I tried option 2 in your tutorial but I didnt install mingw itself.

I get this error:

[Lukasz]

[radad]

Compiling with the -v option I get this output:

[radad]

Also got it working by adding '-isystem $(PS2DEV)/ee/ee/include' to the ee-gcc line. It would be better if we could get that directory embedded in ee-gcc rather than msys converting it to the windows path.

[chp]

The question is why it is not looking up the directories relative to the gcc executable. I have used the cygwin-build without issues with no cygwin-installation (just a few dlls in the correct location), but from what I can see in procmon it does not even try to look at the relative paths...

As a temporary fix you can add those -isystem parameters to the specs-file and you won't have to pass them on every build.
_________________
GE Dominator

[radad]

As a temporary fix I have been using the environment variables:

[radad]

Tried the gsKit samples last night with this compiler but they were not working. Tracked it down to this function from gsCore.c not returning:

[ragnarok2040]

I wonder if that is the issue I'm currently having with FCEUltra. I ported it using gsKit last year using MinGW around June, but after updating gsKit sometime last year afterwards, it stopped working. I'd forgotten which revision of gsKit I had used. I tracked it down to a function not returning in gs_queue_exec_real(); or gs_queue_exec();, back then, I believe. I'll have to go trace it back down again to make sure.

[Lukasz]

[radad]

Assembly isn't my strong point but they appear to be exactly the same.
This is what I get from mingw:

[radad]

I checked out gs_queue_exec_real() as well as it calls gsKit_finish() but they appear to be identical. gsKit_finish appears to be inlined within gs_queue_exec_real and optimized so its difficult to work out what it is actually doing. Some other functions in gsCore are different though.

[Lukasz]

The gsKit_finish function waits for the FINISH event interrupt, so either this interrupt is not being generated for some reason or the interrupt is not masked.

If interrupt is not being generated, then there could be problems with the GIF packets, which means any of the functions which generate data for the GIF packet could possibly contain an code(gen) error. Finding this error could take quite a while.

Checking whether the interrupt is masked is easy, this is usually done with the syscall PutIMR. You can also check it by reading the GS IMR register directly.

A very long time ago, I also had toolchain problems, this was in Cygwin though and I dont remember why it happend. The problem was that bitwise shifts over 32 bits would not work correct. So this would be worth checking out. Try to compile and compare asm for something like this:

[ragnarok2040]

I setup a cygwin-hosted toolchain and a mingw toolchain side by side. gsKit works with the cygwin toolchain. The gsKit binary built with the cygwin toolchain works with the mingw toolchain, but it won't work if the mingw toolchain builds gsKit. I'm pretty sure this bug affects p2sdk, too. For a separate project, I've noticed weird errors in regards to u64 sized numbers (I've had to append two 32-bit numbers together by using an array and casting it to u64) and fopen() having trouble opening files from the memory card.

Using your example, the mingw toolchain gives a warning
val64.c:7: warning: left shift count >= width of type
while the cygwin toolchain does not. I don't get any warnings of this type when building gsKit, though.

[Lukasz]

ragnarok2040:

Since the the variable val isn't used for anything, the code for the shift is removed (optimized) from the code. What you need to do is call some (dummy) function with the val variable, so that the code for the shift actually gets generated.
_________________
Lukasz.dk

[ragnarok2040]

Using an empty function "void dummy_func(u64 val2) {;}" and calling it in main(); using dummy_func(val); I still end up with the same assembly, though the cygwin tools give out the left shift warning now.

When I used printf("%d",val); (Not correct but it wouldn't error out), the diff output info listed some differences.

http://rafb.net/p/rTG3f633.html

[Lukasz]

I find it hard to tell what the difference is from the diff output, however it appears that sections of the code are arranged differently for the two toolchains.

This is probably related to the fact that you link against ps2sdk built in MinGW and Cygwin in their respective enviroments and it seems these are different. So if you link against Cygwin ps2sdk (since it is not bugged) in both MinGW and Cygwin, you can get a better idea of what is wrong in the MinGW toolchain.

Is it possible to build a debug version of gsKit? Maybe this would help in finding the bug.
_________________
Lukasz.dk

[ragnarok2040]

[Lukasz]

Based on your assembly output, I've located the problem. The problem is with shifting of values, as I suspected, and it seems to be the very same problem I had with the Cygwin chains a long time ago.

You can see the bug yourself if you add this printf in gsKit_setactive

[chp]

And if you don't want to spend all day just to see wether it works or not, the vista-toolchains I gave to Lukasz (so they are on the tutorial hp) are built with candidate and should give you a quick path to testing this.
_________________
GE Dominator

[ragnarok2040]

I tested the vista-toolchains you provided chp, and they produce the same error.

GIF_TAG = 0x0000000000008004
GIF_TAG = 0x0000000000008004

I used the candidate versions of mingw last year to build my toolchain, and the versions haven't changed since then except for binutils, so whereever the problem is, it seems it still exists in the latest versions.

I'm gonna try the mingw toolkit from Ogre3D's site to compile the toolchain. If that doesn't work, I noticed there were places around the web that were providing updated mingw tools. There's a thread on the forums that lists the package versions they used to build a successful cygwin toolchain, so I'll use that for comparison.

Also, do you think the problem could be located with the patch.exe that msys provides?

[Lukasz]

The best I can do to help locate the problem is guess, as I have no real experience with gcc.

The best approach would probably be find where in the gcc source these 64 bit shifts are produced and go from there, or it could be a very long journey of guessing, possibly without success.

I was hoping the MinGW toolchains would make it easier to code PS2 in Windows, it doesn't seem to be the case. I'd recommend VMWare Player and installing Ubuntu inside it, this way you can still keep your Windows installation and experiment with Linux in a closed enviroment and avoid all the hassle with Cygwin and MinGW.
_________________
Lukasz.dk