forums.ps2dev.org

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?

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

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.

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?

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.

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.

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

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?

boman666 wrote: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.

It could be a bug in the toolchain, as "j" is a macro, which is supposed to expand to what pixel posted above (which is itself a macro :). Did you take a look at the generated assembly?

It has to be 0xa0001000 because I don't do an I-cache flush before jumping to the kernel startup code. IIRC I don't do it because redboot, the mostly-broken tool I used to test reload1 had funny issues with both caches (it had a bug that disabled both caches).

That sequence in reload1 is very finnicky, esp. as now I have to detect the start of the patched EELOAD startup. I'll get around to testing more it after my home dev env. is setup.

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.