forums.ps2dev.org

As time goes on and changes are made we sometimes forget that people are using old software, even using ps2lib, because they're afraid of change and cvs in general.

So, we should think about tagging and releasing what we have in the near future.

Any comments? What is left outstanding on ps2sdk at the moment that we should wait for? Any major bugs?

Wait, what? You're talking about releasing ps2sdk, correct? Because the final version of ps2lib was already tagged and bagged.

Duh, yes. I'm talking about ps2sdk. :)

Will ps2lib be removed, or has it allready been removed from ps2sdk?

I ran across two bugs but was waiting to invistigate before reporting.

I'm running my dev on cygwin CYGWIN_NT-5.0 1.5.16(0.128/4/2) 2005-04-25 installed on a windows 2000 server. I installed from cvs last week. I have ps2linux and use XLink-beta and reload1 with ps2link embedded to transfer and run programs on the ps2.

1) I added some printf to one of the demo programs. The printf's without parameters didn't print on the XLink log window, (i.e., printf("Starting program\n");). I had to add a dummy parameter for it to print (printf("Starting program %d\n",0);).

2) I compiled and built reload1 with ps2link embedded. Running from memory card fails to find IPCONFIG.DAT . It ends up looking in host:. The code in ps2link to resolve where it was booted from looks funky. It assumes if argc == 0, boot is from host:. If argc > 6000, boot is from [reload1] on memory card, etc.. I am booting from memory card with reload1 and argc is equal to 0 triggering the 'boot from host:' setting. I hardwired that section of code for my install.

Related to 2) I tried to rewrite the 'boot from' code to look at argv[0] but every way of referencing argv[0] caused EE exception error screen. I got as far as believing that a program executed by reload1 is not passed argv[0] or the address points to protected memory (except I couldn't even print the address of argv[0] without causing the exception.

that old pfs bug? partition > 4gb woking strangely: with a just created partition: 5gb = 1gb free; 6gb = 2gb free; 8gb = 4gb free; 10gb = 2gb and so on...

Steve F wrote:I ran across two bugs but was waiting to invistigate before reporting.
<snip>

2) I compiled and built reload1 with ps2link embedded. Running from memory card fails to find IPCONFIG.DAT . It ends up looking in host:. The code in ps2link to resolve where it was booted from looks funky. It assumes if argc == 0, boot is from host:. If argc > 6000, boot is from [reload1] on memory card, etc..

This does indeed pose a problem on later revisions of the ps2 - I had the same issue and rebuilt ps2link without the 'funky' argc. Essentialy removing all the other possible boot options.

I passed to the code sometime ago to ooPo ;)

If you want an embedded working ps2link for reload, take the one I built and used: www.psxdev.com/reload1.elf

I remember something long ago about reload1 for v12 units... I'll have to dig around to see where I put that. :)

ooPo wrote:I remember something long ago about reload1 for v12 units... I'll have to dig around to see where I put that. :)

That would've been the patch for the actual reload code - Marcus has that and it's been updated on homebrew haven on ps2l. The code modification this time was for ps2link, but is no biggie :)

Should really get cvs access... ;)

Thanks boomint, I used your reload1 this last week to get started. Once I was able to get elf's loaded and running, things started to come together. I really want to work on my game idea but fixing up the sdk kind of sidetracked me. I want to show my appriciation for everybody else's work by adding to the quality of the sdk. Plus I'm a tool maker by trade. I can't offer a better way to show my thanks.

I have an old Amiga video monitor and a Dell SOG. I want to run on the Dell only (I got tired of switching cables). My elf's are configured for VGA output (and really look nice). I dug into ps2link to change it's output to VGA. Since it is using the debug library, I patched that to accept video mode parameter to init_scr(). I still have to add code to set up the frame buffers for the different modes. If you think having debug library support the different video modes, I'll be glad to doc the usage and submit it for CVS.

My test PS2 is a SCPH-30001 and I think it is kinda old. At least V4 or earlier. Still it would be nice to have a working ps2link instead of a hacked one. On the problem of argv[0] causing EE exceptions I looked at the EE syscall for spawning an elf. argv[0] should be passed in. I looked at the reload1 code but couldn't match up where the call is. I wonder if reload1 is correctly handling arguments. I just thought of something. I remember reading that one of the crt0.o shouldn't be used and ps2link has a crt0.S although it looks like the make file doesn't include it. I'll look in about 5 hours and see it I can figure out anything.

p.s. what is 'that old pfs bug?' referring to? Something in my post or is it totally not related to anything here?

tux wrote:Will ps2lib be removed, or has it allready been removed from ps2sdk?

PS2SDK was from PS2LIB and PS2DRV. Think of PS2SDK as the new incarnation of PS2LIB.

Okay, a few words from a (very crappy) Internet Access in Glasgow. First, I won't be back at home until next week or so.

Now, would you mind waiting for me to release anything ?

About the "printf" issue, I'd like to know what happens exactly. Note that when compiling in optimized mode, gcc will translate into(note, no \n: puts does add one by itself).

So, the main issue might come from that translation, and I've faced it several times now. But I thought it was fixed meanwhile... Could you so give more infos?

pixel:

Heh, don't worry... we'll wait. :)

As for the puts, isn't that fixed by using -fno-builtin-printf?

(beeing inside the duty free zone at Amsterdam, stuck for the day due to crappy connection handling)

No, puts SHOULD work. I'd want any bug report concerning any issue about it not working.

I have class tonight and tomorrow night so I only have a little time for testing until Friday.

Last night I found a section of code in debug/scr_printf/ Dma02Wait that gave the following warning during compile,

ccHQtJcd.s:441: Warning: Loop length is too short for r5900.

static inline void Dma02Wait()
{
unsigned dma_addr;
unsigned status;

asm volatile (" .set push \n"
" .set noreorder \n"
" lui %0, 0x1001 \n"
" lw %1, -0x6000(%0) \n"
"1: andi %1, %1, 0x100 \n"
" bnel %1, $0, 1b \n"
" lw %1, -0x6000(%0) \n"
" .set pop \n"
: "=&r" (dma_addr), "=&r" (status) );
}

When I added a nop after bnel the warning went away during compile but the program stopped working correctly. I think it has something to do with 'delay slot' processing. I only have a few days MIPS asm experience so far.

Tonight I will try this code,

static inline void Dma02Wait()
{
unsigned dma_addr;
unsigned status;

asm volatile (" .set push \n"
" .set noreorder \n"
" lui %0, 0x1001 \n"
" lw %1, -0x6000(%0) \n"
"1: andi %1, %1, 0x100 \n"
" nop \n"
" nop \n"
" nop \n"
" nop \n"
" bnel %1, $0, 1b \n"
" lw %1, -0x6000(%0) \n"
" .set pop \n"
: "=&r" (dma_addr), "=&r" (status) );
}

It compiles without errors or warnings. I will be able to test it in about 12 hours from now. The minumum loop length might explain the random loss of characters and bad formating from scr_printf output.

I will have better information about puts and scr_printf behavior on my dev/test environment by Saturday morning at the latest. One of the things I will differentiate first is capturing the network packets from the PS2 back to the XLink program to make sure XLink isn't causing the formatting problems.

The warning isn't so problematic. However, your fix isn't right: the nop should be BEFORE the branch, not right after; since the code is in noreorder mode, each instruction after a branch is executed. So, there, you're squashing the lw which is after the branch. So, well, just don't change that code: the warning shouldn't affect the good processing of it.

And, err, you're now talking about scr_printf, which is not the same as printf. scr_printf doesn't get squashed into puts by optimisation code.

opps! You're right, I'm looking at too many things at once and got confused. The printf with no args not showing up in XLink log window and puts are one thing. I'll make sure to isolate this from my other stuff.

Later that day ...

I compiled the hello.c in the sdk samples directory. As coded in the cvs (no changes by me), I get 14 cr's on XLink instead of the "Hello, World!\n". I tried the same elf with ps2client and it looks like everything works correctly. I am a little stumped how the same output to the two client apps behaves differently, then when I add an argument to the printf statement it works the same on both. In any case, it looks like the problem is with the XLink app.

Even later that same day ...

I tried another test by removing all optimizations and compiling the version with a printf("Hello, world!\n"). In XLink the output is correct. I changed to optimization -O1 and the output goes back to 14 cr's. Same with -O2 (as configured in CVS). Now that I am noticing the long string of cr's, the ps2link app on connecting to XLink also dumps long strings of cr's. I'm betting if I compiled ps2link without optimization I would get correct output.

[deleted preamble]

I recorded the network packets and found that with no optimizations, the printf's output is contained in one UDP packet and displays correctly. When I exec an -O1 or -O2 version, each character is transmitted in it's own UDP packet. XLink isn't handling this transmission well but ps2client has no problem with it [?]. So, it seems that optimizations are effecting the flushing of the buffer in a way that is not exactly optimum. pixel, would you like me to look further into this? By the way, should I move this sub-thread to the bug-report forum?

p.s. I'm starting to realize that what you guys have accomplished here is totally awsome. Sorry I showed up late; it must have been so cool to be a part of creating these tools a few years ago.

Ah, I see. Well, this is obviously a bug in X-Link, and that should be up to raizor to fix it. However, the output stream should be buffered in some ways... Anyway, the difference of behavior between puts and printf is obvious:
Maybe I should add something like a fioWrite(1, s, strlen(s)); to avoid multiplication of packets.

If I was a betting person, I would say that the vsprintf() call between va_start() and va_end() (both are macros) is getting loop-unrolled during -O2 because passing only some string "this example\n" to printf() without any additional arguments results in a constant expression that can be optimized by the compiler by iterating over each character in the string.

This is probably why the compiler normally likes to replace such expressions with a puts("") since a normally good optimization becomes inefficient.

But having said that, proper buffering on the system i/o lib end may solve this problem. Although a switch to turn buffering off might be nice for those situations where the program crashes and you must absolutely positively see everything and not have it lost while waiting...

I don't know how old this post is, but, does anybody have that elf that boomint posted? Or anyway I can make it myself?

This file isnt on archives or anything.