Building PS2 Toolchains In MinGW

Lukasz · Post by **Lukasz** » Sun Jul 01, 2007 2:50 am

Update:
Tutorial and binaries now available at: http://lukasz.dk/programming/playstatio ... -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:

Code: Select all

svn checkout svn&#58;//svn.ps2dev.org/ps2/trunk/ps2toolchain

You can add the PS2DEV enviroment variables to msys/1.0/etc/profile.

The binutils for EE, IOP og DVP will build fine, however GCC will fail. In order to fix this you need alter the following file after patching, but before configuring the toolchains. This is not a completely trivial task, so people who are unexperienced with these kind of tasks, might wanna wait for a easier solution.

The file you need to alter is gcc-3.2.2/gcc/fixinc/mkfixinc.sh

Locate the following part of the file, around line 82

Code: Select all

mips-sgi-irix5cross64 | \
powerpc-*-eabiaix* | \

and insert two lines so it now contains this.

Code: Select all

mips-sgi-irix5cross64 | \
mips64r5900el-scei-elf | \
mipsel-scei-irx | \
powerpc-*-eabiaix* | \

This will fix the problem with fixinc (skipping the step), for which there is no MinGW support. More information available here:

http://www.mingw.org/MinGWiki/index.php ... 20compiler

Once you've altered this file, gcc will build for EE and IOP aswell as newlib, ee-g++ and ps2sdk.

Maybe ooPo can include the patch to the mkfixinc.sh in his toolchain patches, if MinGW is detected.

I havn't actually tested any of the ps2sdk samples built these toolchains, as I dont have a PS2 available at the moment, but I dont there should be any problems.

Post by **ooPo** » Tue Jul 03, 2007 9:32 am

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. :)

Post by **ooPo** » Tue Jul 03, 2007 12:57 pm

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 · Post by **cosmito** » Tue Jul 03, 2007 11:22 pm

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 · Post by **radad** » Wed Jul 04, 2007 9:37 am

ptek: That should be no problem.

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

cosmito · Post by **cosmito** » Wed Jul 04, 2007 10:01 am

radad,

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

A few details :

Precompiled toolchain, http://d.turboupload.com/d/1219902/ps2dev.exe.html
I've uploaded a ps2 toolchain compiled in mingw, includes a compiled ps2sdk, revision 1358.

Notes about mingw built toolchain:
Patched with the latest patches from the svn repository
IOP toolchain is built with binutils-2.14/gcc-3.2.2, not the older version of the iop toolchain
GCC (all targets) fixinc was not built, it's not needed for anything that's ps2dev dependent
It was also patched with the __restrict enable patch for inline functions, located at http://forums.ps2dev.org/viewtopic.php?t=4938

Lukasz · Post by **Lukasz** » Mon Jul 09, 2007 8:05 pm

Tutorial and binaries now available at: http://lukasz.dk/programming/playstatio ... -tutorial/

chp · Post by **chp** » Mon Jul 09, 2007 9:06 pm

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. ... 2?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- ... 7-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:

Code: Select all

sh toolchain.sh

you write:

Code: Select all

CFLAGS="-D__USE_MINGW_ACCESS" sh toolchain.sh

NOTE:Even if you build this on XP but intend to use the toolchain under Vista you still need to pass this flag due to a bug with the normal access() called by the gcc frontend.

All done!

Lukasz · Post by **Lukasz** » Tue Jul 10, 2007 6:20 pm

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.

radad · Post by **radad** » Wed Jul 11, 2007 10:52 am

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

I get this error:

Code: Select all

ee-gcc -D_EE -G0 -O2 -Wall   -I/home/adam/ps2devsrc/ps2sdk/ee/kernel/include -I/home/adam/ps2devsrc/ps2sdk/common/include -I/home/adam/ps2devsrc/ps2sdk/ee/libc/include -I/home/adam/ps2devsrc/ps2sdk/ee/erl/include -Iinclude -DF_sio_init src/sio.c -c -o obj/sio_init.o
In file included from src/sio.c&#58;14&#58;
C&#58;/msys/home/adam/ps2devsrc/ps2sdk/ee/libc/include/stdio.h&#58;21&#58;23&#58; sys/types.h&#58; No such file or directory

ee-gcc is at /usr/local/ps2dev/ee/bin/ee-gcc
and types.h exists in /usr/local/ps2dev/ee/ee/include/sys/
Shouldnt ee-gcc be able to find it there?

Lukasz · Post by **Lukasz** » Wed Jul 11, 2007 6:19 pm

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

Since you didn't install MinGW, I cannot help you, as I did install MinGW and it works for me.

radad · Post by **radad** » Thu Jul 12, 2007 11:18 am

Compiling with the -v option I get this output:

Code: Select all

ignoring nonexistent directory "/usr/local/ps2dev/ee/include"
ignoring nonexistent directory "C&#58;/msys/1.0/local/ps2dev/ee/lib/gcc-lib/ee/3.2.2/include"
ignoring nonexistent directory "C&#58;/msys/1.0/local/ps2dev/ee/ee/sys-include"
ignoring nonexistent directory "C&#58;/msys/1.0/local/ps2dev/ee/ee/include"

I had installed msys to C:\msys and not C:\msys\1.0. I moved the installation to C:\msys\1.0 and it now works. Is there any way to have these paths not hard-coded, relative paths would be much better?

radad · Post by **radad** » Thu Jul 12, 2007 1:52 pm

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 · Post by **chp** » Sat Jul 14, 2007 3:21 am

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.

radad · Post by **radad** » Mon Jul 16, 2007 10:25 am

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

Code: Select all

export C_INCLUDE_PATH=$PS2DEV/ee/ee/include
export CPLUS_INCLUDE_PATH=$C_INCLUDE_PATH&#58;$PS2DEV/ee/include/c++/3.2.2&#58;$PS2DEV/ee/include/c++/3.2.2/ee

The difference with msys is that it modifies the command line parameters for binaries that are not in the /bin directory. In this case when we call mingw with a parameter of /usr/local/ps2dev it changes it to the real directory assuming that the program is a standard win32 binary and doesn't understand the msys directories. Unfortunately this means the real directory is built into the ee-gcc binary.

radad · Post by **radad** » Wed Jul 18, 2007 10:31 am

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:

Code: Select all

/// GS CSR &#40;GS System Status&#41; Register
#define GS_CSR &#40;volatile u64 *&#41;0x12001000

/// CSR FINISH Register Access Routine
#define GS_CSR_FINISH &#40;&#40;*GS_CSR&#41; >> 1&#41;&1

void gsKit_finish&#40;void&#41;
&#123;
	while&#40;!&#40;GS_CSR_FINISH&#41;&#41;;
&#125;

Is this working for others? Maybe its the volatile keyword not working?

ragnarok2040 · Post by **ragnarok2040** » Wed Jul 18, 2007 3:42 pm

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 · Post by **Lukasz** » Wed Jul 18, 2007 6:40 pm

radad wrote: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:
Code: Select all
/// GS CSR &#40;GS System Status&#41; Register
#define GS_CSR &#40;volatile u64 *&#41;0x12001000

/// CSR FINISH Register Access Routine
#define GS_CSR_FINISH &#40;&#40;*GS_CSR&#41; >> 1&#41;&1

void gsKit_finish&#40;void&#41;
&#123;
	while&#40;!&#40;GS_CSR_FINISH&#41;&#41;;
&#125;
Is this working for others? Maybe its the volatile keyword not working?

Try to disassmble the function when compiled with the MinGW toolchains and whatever toolchains you used before and compare the results, to see if there actually is a difference in codegeneration.

radad · Post by **radad** » Thu Jul 19, 2007 11:08 am

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

Code: Select all

00000230 <gsKit_finish>&#58;
 230&#58;   3c031200        lui     v1,0x1200
 234&#58;   34631000        ori     v1,v1,0x1000
 238&#58;   dc620000        ld      v0,0&#40;v1&#41;
 23c&#58;   0002107a        dsrl    v0,v0,0x1
 240&#58;   30420001        andi    v0,v0,0x1
 244&#58;   00000000        nop
 248&#58;   1040fffb        beqz    v0,238 <gsKit_finish+0x8>
 24c&#58;   00000000        nop
 250&#58;   03e00008        jr      ra
 254&#58;   00000000        nop

And this is what I get from cygwin:

Code: Select all

00000238 <gsKit_finish>&#58;
 238&#58;   3c031200        lui     v1,0x1200
 23c&#58;   34631000        ori     v1,v1,0x1000
 240&#58;   dc620000        ld      v0,0&#40;v1&#41;
 244&#58;   0002107a        dsrl    v0,v0,0x1
 248&#58;   30420001        andi    v0,v0,0x1
 24c&#58;   00000000        nop
 250&#58;   1040fffb        beqz    v0,240 <gsKit_finish+0x8>
 254&#58;   00000000        nop
 258&#58;   03e00008        jr      ra
 25c&#58;   00000000        nop

I didn't build either of these compilers so I am not completely sure if they are from the same source.

radad · Post by **radad** » Thu Jul 19, 2007 2:02 pm

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 · Post by **Lukasz** » Thu Jul 19, 2007 8:55 pm

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:

Code: Select all

u64 val = 0;
val = 1 << 60;

This could explain the gsKit_finish function not returning, since the GIF packets contain data which is 64 and 128 bit wide, so it is very likely there is some shifting going on somewhere to build the GIF packet. Meaning that the GIF packet is incorrectly built and therefor the GS acts in unpredictable ways.

This was how I discovered the shift bug, as the graphics didn't appear when I build code with the bugged Cygwin toolchain.

ragnarok2040 · Post by **ragnarok2040** » Fri Jul 20, 2007 5:56 pm

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.

Code: Select all

#include <stdio.h>
#include <limits.h>
#include <tamtypes.h>

int main&#40;&#41; &#123;
	u64 val = 0;
	val = 1 << 60;


	return 0;
&#125;

int value = sizeof(u64) * CHAR_BIT; reports that u64 is 64-bits long

http://rafb.net/p/AU4bbX26.html MingW disassembly
http://rafb.net/p/V5jAIk76.html Cygwin diassembly

I used diff on them but it didn't report any differences except for the filenames.

This might be in relation to bug #3325. The bugs reported in relation to this seem similar.

Lukasz · Post by **Lukasz** » Fri Jul 20, 2007 6:55 pm

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.

ragnarok2040 · Post by **ragnarok2040** » Sat Jul 21, 2007 12:27 am

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 · Post by **Lukasz** » Sat Jul 21, 2007 8:14 am

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.

ragnarok2040 · Post by **ragnarok2040** » Sat Jul 21, 2007 2:19 pm

Code: Select all

Initializing the DMAC&#58; RELE=0 MFD=0 STS=0 STD=0 RCYC=0
DMAC Initialized.
Initilizating DMA Channel 2 - GIF
DMA Channel Initialized.
Initilizating DMA Channel 8 - fromSPR
DMA Channel Initialized.
Initilizating DMA Channel 9 - toSPR
DMA Channel Initialized.
NTSC
NTSC
CurrentPointer Before&#58;	0x00000000
CurrentPointer After&#58;	0x00118000
CurrentPointer Before&#58;	0x00118000
CurrentPointer After&#58;	0x00230000
Sending to DMA Channel 2 - GIF
Sent to DMA Channel
CurrentPointer Before&#58;	0x00230000
CurrentPointer After&#58;	0x00270000
Sending to DMA Channel in Chain Mode 2 - GIF
Sent to DMA Channel in Chain Mode
Sending to DMA Channel 2 - GIF
Sent to DMA Channel
Sending to DMA Channel in Chain Mode from UCAB 2 - GIF
Sent to DMA Channel in Chain Mode from UCAB
Sending to DMA Channel in Chain Mode 2 - GIF
Sent to DMA Channel in Chain Mode
Sending to DMA Channel 2 - GIF
Sent to DMA Channel

Here's the gsKit debug output. I removed the output from init code for IOP drivers and from FCEUltra internal stuff. It doesn't look that helpful.

I went through using WinMerge on the disassembly output on gsCore.o. I compiled gsKit with the same cygwin ps2sdk, but with the different toolchains. I'll list the first block of changed assembly. The first paste is Cygwin and the second is Mingw. 1a0: is where the changes start occurring.

Code: Select all

00000158 <gsKit_setactive>&#58;
 158&#58;	27bdffe0 	addiu	sp,sp,-32
 15c&#58;	ffbf0010 	sd	ra,16&#40;sp&#41;
 160&#58;	ffb00000 	sd	s0,0&#40;sp&#41;
 164&#58;	8c820020 	lw	v0,32&#40;a0&#41;
 168&#58;	8c830024 	lw	v1,36&#40;a0&#41;
 16c&#58;	30420001 	andi	v0,v0,0x1
 170&#58;	8c900080 	lw	s0,128&#40;a0&#41;
 174&#58;	00021080 	sll	v0,v0,0x2
 178&#58;	246a003f 	addiu	t2,v1,63
 17c&#58;	00441021 	addu	v0,v0,a0
 180&#58;	28660000 	slti	a2,v1,0
 184&#58;	8c450010 	lw	a1,16&#40;v0&#41;
 188&#58;	2469ffff 	addiu	t1,v1,-1
 18c&#58;	0146180b 	movn	v1,t2,a2
 190&#58;	8c870028 	lw	a3,40&#40;a0&#41;
 194&#58;	00052b42 	srl	a1,a1,0xd
 198&#58;	00031983 	sra	v1,v1,0x6
 19c&#58;	8c880084 	lw	t0,132&#40;a0&#41;
 1a0&#58;	3c021000 	lui	v0,0x1000
 1a4&#58;	0002103c 	dsll32	v0,v0,0x0
 1a8&#58;	34428004 	ori	v0,v0,0x8004
 1ac&#58;	0005283c 	dsll32	a1,a1,0x0
 1b0&#58;	fe020000 	sd	v0,0&#40;s0&#41;
 1b4&#58;	00031c38 	dsll	v1,v1,0x10
 1b8&#58;	24020040 	li	v0,64
 1bc&#58;	24e7ffff 	addiu	a3,a3,-1
 1c0&#58;	0005283e 	dsrl32	a1,a1,0x0
 1c4&#58;	00073c3c 	dsll32	a3,a3,0x10
 1c8&#58;	00084638 	dsll	t0,t0,0x18
 1cc&#58;	fe020018 	sd	v0,24&#40;s0&#41;
 1d0&#58;	00a32825 	or	a1,a1,v1
 1d4&#58;	00094c38 	dsll	t1,t1,0x10
 1d8&#58;	2403000e 	li	v1,14
 1dc&#58;	24020041 	li	v0,65
 1e0&#58;	00a82825 	or	a1,a1,t0
 1e4&#58;	01274825 	or	t1,t1,a3
 1e8&#58;	fe030008 	sd	v1,8&#40;s0&#41;
 1ec&#58;	2403004c 	li	v1,76
 1f0&#58;	fe020038 	sd	v0,56&#40;s0&#41;
 1f4&#58;	2402004d 	li	v0,77
 1f8&#58;	fe030028 	sd	v1,40&#40;s0&#41;
 1fc&#58;	fe090030 	sd	t1,48&#40;s0&#41;
 200&#58;	fe020048 	sd	v0,72&#40;s0&#41;
 204&#58;	fe090010 	sd	t1,16&#40;s0&#41;
 208&#58;	fe050040 	sd	a1,64&#40;s0&#41;
 20c&#58;	0c000000 	jal	0 <gsKit_vram_alloc>
 210&#58;	fe050020 	sd	a1,32&#40;s0&#41;
 214&#58;	24040002 	li	a0,2
 218&#58;	0200282d 	move	a1,s0
 21c&#58;	0c000000 	jal	0 <gsKit_vram_alloc>
 220&#58;	24060005 	li	a2,5
 224&#58;	dfb00000 	ld	s0,0&#40;sp&#41;
 228&#58;	dfbf0010 	ld	ra,16&#40;sp&#41;
 22c&#58;	03e00008 	jr	ra
 230&#58;	27bd0020 	addiu	sp,sp,32
 234&#58;	00000000 	nop

00000238 <gsKit_finish>&#58;
 238&#58;	3c031200 	lui	v1,0x1200
 23c&#58;	34631000 	ori	v1,v1,0x1000
 240&#58;	dc620000 	ld	v0,0&#40;v1&#41;
 244&#58;	0002107a 	dsrl	v0,v0,0x1
 248&#58;	30420001 	andi	v0,v0,0x1
 24c&#58;	00000000 	nop
 250&#58;	1040fffb 	beqz	v0,240 <gsKit_finish+0x8>
 254&#58;	00000000 	nop
 258&#58;	03e00008 	jr	ra
 25c&#58;	00000000 	nop

Code: Select all

00000158 <gsKit_setactive>&#58;
 158&#58;	27bdffe0 	addiu	sp,sp,-32
 15c&#58;	ffbf0010 	sd	ra,16&#40;sp&#41;
 160&#58;	ffb00000 	sd	s0,0&#40;sp&#41;
 164&#58;	8c820020 	lw	v0,32&#40;a0&#41;
 168&#58;	8c830024 	lw	v1,36&#40;a0&#41;
 16c&#58;	30420001 	andi	v0,v0,0x1
 170&#58;	8c900080 	lw	s0,128&#40;a0&#41;
 174&#58;	00021080 	sll	v0,v0,0x2
 178&#58;	246a003f 	addiu	t2,v1,63
 17c&#58;	00441021 	addu	v0,v0,a0
 180&#58;	28660000 	slti	a2,v1,0
 184&#58;	8c450010 	lw	a1,16&#40;v0&#41;
 188&#58;	2469ffff 	addiu	t1,v1,-1
 18c&#58;	0146180b 	movn	v1,t2,a2
 190&#58;	8c870028 	lw	a3,40&#40;a0&#41;
 194&#58;	00052b42 	srl	a1,a1,0xd
 198&#58;	00031983 	sra	v1,v1,0x6
 19c&#58;	8c880084 	lw	t0,132&#40;a0&#41;
 1a0&#58;	34028004 	li	v0,0x8004
 1a4&#58;	0005283c 	dsll32	a1,a1,0x0
 1a8&#58;	fe020000 	sd	v0,0&#40;s0&#41;
 1ac&#58;	00031c38 	dsll	v1,v1,0x10
 1b0&#58;	24020040 	li	v0,64
 1b4&#58;	24e7ffff 	addiu	a3,a3,-1
 1b8&#58;	0005283e 	dsrl32	a1,a1,0x0
 1bc&#58;	00073c3c 	dsll32	a3,a3,0x10
 1c0&#58;	00084638 	dsll	t0,t0,0x18
 1c4&#58;	fe020018 	sd	v0,24&#40;s0&#41;
 1c8&#58;	00a32825 	or	a1,a1,v1
 1cc&#58;	00094c38 	dsll	t1,t1,0x10
 1d0&#58;	2403000e 	li	v1,14
 1d4&#58;	24020041 	li	v0,65
 1d8&#58;	00a82825 	or	a1,a1,t0
 1dc&#58;	01274825 	or	t1,t1,a3
 1e0&#58;	fe030008 	sd	v1,8&#40;s0&#41;
 1e4&#58;	2403004c 	li	v1,76
 1e8&#58;	fe020038 	sd	v0,56&#40;s0&#41;
 1ec&#58;	2402004d 	li	v0,77
 1f0&#58;	fe030028 	sd	v1,40&#40;s0&#41;
 1f4&#58;	fe090030 	sd	t1,48&#40;s0&#41;
 1f8&#58;	fe020048 	sd	v0,72&#40;s0&#41;
 1fc&#58;	fe090010 	sd	t1,16&#40;s0&#41;
 200&#58;	fe050040 	sd	a1,64&#40;s0&#41;
 204&#58;	0c000000 	jal	0 <gsKit_vram_alloc>
 208&#58;	fe050020 	sd	a1,32&#40;s0&#41;
 20c&#58;	24040002 	li	a0,2
 210&#58;	0200282d 	move	a1,s0
 214&#58;	0c000000 	jal	0 <gsKit_vram_alloc>
 218&#58;	24060005 	li	a2,5
 21c&#58;	dfb00000 	ld	s0,0&#40;sp&#41;
 220&#58;	dfbf0010 	ld	ra,16&#40;sp&#41;
 224&#58;	03e00008 	jr	ra
 228&#58;	27bd0020 	addiu	sp,sp,32
 22c&#58;	00000000 	nop

00000230 <gsKit_finish>&#58;
 230&#58;	3c031200 	lui	v1,0x1200
 234&#58;	34631000 	ori	v1,v1,0x1000
 238&#58;	dc620000 	ld	v0,0&#40;v1&#41;
 23c&#58;	0002107a 	dsrl	v0,v0,0x1
 240&#58;	30420001 	andi	v0,v0,0x1
 244&#58;	00000000 	nop
 248&#58;	1040fffb 	beqz	v0,238 <gsKit_finish+0x8>
 24c&#58;	00000000 	nop
 250&#58;	03e00008 	jr	ra
 254&#58;	00000000 	nop

Lukasz · Post by **Lukasz** » Sat Jul 21, 2007 7:29 pm

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

Code: Select all

*p_data++ = GIF_TAG&#40; 4, 1, 0, 0, 0, 1 &#41;;
*p_data++ = GIF_AD;
printf&#40;"GIF_TAG = 0x%016lX\n", p_data&#91;-2&#93;&#41;;

My ps2toolchain built in Ubuntu prints this for each frame:

Code: Select all

GIF_TAG = 0x1000000000008004

Where as the MinGW toolchain prints this once and hangs:

Code: Select all

GIF_TAG = 0x0000000000008004

You will notice the missing '1' at the very first position of the value, this makes the GIF interpret the GIF packet incorrectly.

As I already mentioned I had this problem in Cygwin once, but later it just disappeared, which makes me suspect that the bug was in the tools I built the toolchain with and it later got fixed when I updated Cygwin and rebuilt the toolchains.

Unfortunately I don't have the knowledge to find and fix the problem in the GCC source, so my suggestion is to try to build the toolchains again, but this time choosing 'candidate' instead of 'current' when installing MinGW and see how this goes.

chp · Post by **chp** » Sat Jul 21, 2007 9:22 pm

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.

ragnarok2040 · Post by **ragnarok2040** » Sun Jul 22, 2007 5:09 am

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 · Post by **Lukasz** » Sun Jul 22, 2007 6:45 am

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.