forums.ps2dev.org

[boman666]

Hello,

When I try to compile ps2menu, the assembler barks on the cfc2.ni $3, $28 and ctc2.ni $3, $28 instructions. I've never seen the .ni modifier before but then again I've only been programming R3000. Is .ni a legal modifier and if it is, what does it mean?

[pixel]

I know I don't answer directly to your questions, but those 4 instructions were added lately to the binutils-2.13.2.1's mips r5900 instruction set patch:

cfc2.i
cfc2.ni
ctc2.i
ctc2.ni

Here is the patch to apply on your binutils's source in order to provide those instructions:

http://www.nobis-crew.org/~pixel/mips-opc.c.diff
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[Oobles]

You should fix up your compiler by adding those instructions, however, if you're really lazy. You can change the instructions in your ps2menu source to cfc and ctc instead. I was told that this will produce the same output.

[boman666]

Thanks guys, ps2menu compiles now but the assembler is emitting warnings saying "Loop length is too short for r5900". I hope they are spurious.

Anyways, I've prb getting any prg running on the PS2. I'm using the Linuxkit, but I can't even get the pre-compiled .elf's in reload1-0.1 to execute. Since that seems so trivial, I'm starting to suspect that it's not due to me screwing up but some other prb, maybe some incompatibility with my PS2. I got the SPCH-50004 model (unmodded by the way). I don't know how long that model has been around but I bought it brand new a copule of days ago. Any hints what the culprit can be and what should I do about it?

[Oobles]

I'm not familiar with model numbers.. but I noticed this thread discussing changes required to reload for v9 ps2.

http://forums.ps2dev.org/viewtopic.php?t=29

Hope it helps.
Oobles.

[boman666]

Ok, with that change I got reload to work. However, I also had to change asm ("j\t%0" : : "i" (0xa0001000)); in reload1.c to asm ("j\t%0" : : "i" (0x00001000));. AFAICT, that must be a bug. I find it a little bit strange that it has slipped through unnoticed, but I guess the author has a different toolchain which just ignores the overflow.

[pixel]

I think you'd better change the

asm ("j\t%0" : : "i" (0xa0001000));

into:

asm ("li\t$31, %0\njr\t$31" : : "i" (0xa0001000));

Well, it seems to have more sense to me :)
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[boman666]

Agreed, that's a better solution since that's probably what the author intended. By the way, what's the purpose of the KSeg0/KSeg1?

[mrbrown]

[boman666]

Thanks for the clarification. I haven't written any mipsassembler in about 6 years and I didn't remember j was a macro. Anyways, my toolchain, as you suggested, was probably broken in some way because the address became negative when I compiled ps2menu.