forums.ps2dev.org

Hello all,
I am new here and wanted to say Hello, and ask for some guidance.

I am trying to get started with PS2 programming under Cygwin. I've checked a lot of the tutorials and a lot of postings at other sites, but there appear to be many different (and sometimes conflicting) methods of getting there.

The first thing I notice is that there is a post (here:"http://forums.ps2dev.org/viewtopic.php?t=9310") that references
another location (" hxxp://www.lukasz.dk/ ") that basically says that the PS2 toolchain does not work under Cygwin. This post is dated July of this year. Is this still the case, or has Cygwin (or the Toolchain) been updated and is now functional?

I have seen other posts which say you must downgrade to a certain version of Cygwin, or a certain version of various packages in Cygwin, etc. As I said, very confusing!

I have Cygwin installed to my C: drive; it shows version 1.5.19-4 using the CygCheck command. Does anyone know if this version is too new? To old? Just right?

Then there is a post (here: "http://ps2dev.org/ps2/Tools/Toolchain/") that tells me to install some softwares. It is interesting to note that these items all appear in a Cygwin install! Futher, there is another entry on this page that references "PS2DevWin32.zip ", which I have downloaded. It contains an executable file, and it appears that running this executable will handle much of the work I would normally have to do to install the
PS2 development environment. Yay! However, it does not tell me specifically where (at least, as I understand it) to install this software. I have taken the dubious step of creating a directory,
C:/cygwin/usr/local/ps2dev, and directing the installer to place the files there. Although everything seem to have installed properly, is this the right thing to do, or should I install them elsewhere?

Finally, I go into the samples directory that was created by the installer, with the intent of running the good ol' HelloWorld example make file. Aggh! Cygwin can't find that file! Willing to try an educated guess that there are PATH issues, I moved the source files into a directory that is within the PATH environmental variable. Yay, Cygwin finds the makefile and executes it...and promptly gives me a slew of errors that again seem to point to PATH problems. So, rather that move a lot of stuff around
willie-nillie, or change a lot of source code to use my possibly incorrect install, I though I should ask the experts first. Namely, what directory should I use to install the development environment under Cygwin?
Can I make my own directory, maybe called "Projects", that I can, well,...keep my projects in? How do I tell Cygwin and it's various packages to use that directory?

That's probably more that enough for now, so I any kind soul wants to lend a hand, I'll sure appreciate it. I have no problem doing the work/investigation/learning, it just seems I need to be pointed in the right direction.

Thanks
Charlie

PS: It appears that there is another route to an installation like this, related to SVN, which appears to be a source-control function. I can't seem to access those files indicated by the SVN URL. Am I doing something wrong?

Whenever cygwin gets around to actually being stable and standards compliant it may be easier to use for development. Until then, if you can get it working you're a luckier person than most. There's a reason why there aren't any good tutorials for setting it up - cygwin frequently breaks things with each update and a whole new set of workarounds need to be figured out.

I'd really recommend using something else, like linux. Or maybe a precompiled toolchain of some sort.

Aha! That simple paragraph may explain a lot.

I'm guessing then, that PS2 under Cygwin is a lot different than PSP under Cygwin? The PSP development environment installation was rather clean and simple; so much so that I was able to capture that installation as a single integrated entity that I save to CD, whereas I am able to install it on other machines in about 20 minutes. I was/am hoping to get a PS2 install into the same state. (This was a few years back, and I don't fully remember how I did it, which is why I am struggling again now; complicated by the now-understood-by-me instability of Cygwin)

So, if you don't mind (and I'm guessing you don't - you didn't flame my lack of knowledge), I like to continue to try; maybe I will get lucky. Towards that end, then, I like to ask one additional question. If I do an install of Cygwin via the standard download off the network, and then want to ATTEMPT(?) to install the toolchain, into what directory do I "un-tar" the toolchain? Someplace under Cygwin, or someplace entirely separate, in which case how do I tell Cygwin to access it?

Thanks for your patience, this looks to be the best PS2 development site.

Charlie

The main difference is age. Development on the PS2 is dying off and there's very few people bothering to keep up with cygwin changes.

You can find information and downloads here:
http://ps2dev.org/ps2/Tools/Toolchain

A typical toolchain install goes into /usr/local/ps2dev, with your path set to run programs from there. If you're building the toolchain yourself with the autobuilding script then it doesn't matter where the build takes place - it will install automatically to the correct place once built.

Thanks, especially since it appears that my failing memory had correctly guessed where the PS2Dev should reside.

Well, I'm off to playing........!

Thanks again
Charlie

-----------------------------------------------------------
Edit: I have also learned that, when I create a post, the red underline means "I dun't spel goot"

Working with a precompiled toolchain is not the optimal solution since it's a matter of time for it to be outdated ...

The best is building it from the latest source from the SVN. So you have 3 options :

- do it under linux (I tried xubuntu with success)
- use MinGW under Winblows (some report that it's not very mature as cygwin, although the compiling performence is better)
- use cygwin.

I'm using cygwin but not the latest version. The latest features a updated GCC and this is the cause for the toolchain building problem (it introduced some changes although i'm not really aware of them).

I'm using a old version I got from a p2p network : see the link from iderlei
at
http://forums.ps2dev.org/viewtopic.php? ... highlight=

Anyway, I think the linux solution it the optimal. Currently I have some compiling issues with some sources (they compile fine, but the ELF does strange things) and I *suspect* cygwin is the cause, until I compile them under linux. I already heard problems like this from the cygwin solution, maybe it's the case.

BTW: I'm don't truly agree with ooPo regarding the PS2 homebrewing being dying. As long there are people interested and doing (even minor) stuff for the PS2 we cannot talk about death of the platform. However I see his point, since recently there weren't announced "big" releases like uLE, SMS player and others, but even those are being updated. Hey, even Sony didn't dropped completly the PS2 :) Just my opinion.

Hello ptek.
I, too, and working under Cygwin, as you have determined from my previous posts. I have gotten the latest Cygwin installed, with the previously mentioned four downgrades installed. (anyone notice the typo in the version listing?). Is this a viable starting point? Don't know, but I'm going to find out soon!

I'm in the process of exploring the toolchain, and it brings up a lot of "why" questions. I can tackle the "how" questions, as I'm not afraid to dig into all the headaches that the incompatibilities cause, but without a knowledge of the history of the ps2's original toolchain creation, I am hampered by having to put some effort into reverse engineering rather than simply fixing things.

A few examples of "why":
1. Why does the toolchain download source code to be compiled locally? Why not just have the usual source/library files that are made specifically to work with the PS2 hardware and provide callable functions, and leave it at that?
2. Why does the toolchain actually edit that source code, via Patch, before compiling it? Why aren't those files fully upgraded and thus become fully complete within themselves?
[Sidebar: I remember seeing something like "PS2DevLib" that said it was precompiled. Does that mean a better route would be to simply download and install it, or are there other problems associated with that, also? And, is the person/people/group who created the original toolchain available? Or has his/her/their interest in PS2 development waned?]

And a question related to my lack of knowledge:
1. If the toolchain compiles without crashing (fatal error), can I consider the job done? That is, how do I know that there may or may not have been a non-fatal error that DIDN'T crash it, but that still needs attention? And how about warnings? Do I need to absolutely fix those also? And how the heck can I see any of them, if they go scrolling up my screen at ninety miles an hour for 6 hours straight?!?!?!

As for the homebrew, I don't expect to make my own DVD-based "latest-and-greatest" video game, and I actually expect that the PS3 will spawn some interest in it's own homebrew. But I believe that the basic hardware that Sony has, will be the hardware it sticks with. That MAY imply that a PS3 toolchain, if developed to work smoothly with the latest Cygwin, might be a good starting point for a brand-new PS2 toolchain. (I've not looked into this, so I may be quite wrong). Like many beginners, I will be happy to see a HelloWorld on my personal PS2. I don't mind working a couple of years to do that.

Besides, isn't the challenge really the fun part?

charliee1151 wrote: 1. Why does the toolchain download source code to be compiled locally? Why not just have the usual source/library files that are made specifically to work with the PS2 hardware and provide callable functions, and leave it at that?

There are several reasons for this. One is that we dont have a system running which can compile the toolchains for every OS available, each time there is an update to the source code. Another reason is that you can be "cutting edge" by recompiling the toolchain shortly after fixes have been comitted, instead of relying on others suppling them.

charliee1151 wrote: 2. Why does the toolchain actually edit that source code, via Patch, before compiling it? Why aren't those files fully upgraded and thus become fully complete within themselves?

The PS2 toolchains patches for VU, MIPS5900 and IOP/IRX are not part of GCC. So with the toolchain scripts you download the official GCC and patch it, instead of having to checkout the entire GCC source from svn. The patches are much smaller in file size compared to the GCC source :-)

charliee1151 wrote: 1. If the toolchain compiles without crashing (fatal error), can I consider the job done? That is, how do I know that there may or may not have been a non-fatal error that DIDN'T crash it, but that still needs attention? And how about warnings? Do I need to absolutely fix those also? And how the heck can I see any of them, if they go scrolling up my screen at ninety miles an hour for 6 hours straight?!?!?!

If you get the toolchains built, I think you can be very certain they work correctly. All the warnings come from the fact that you are not building the toolchains with the version of GCC which was used to the develop them, later versions of GCC are more strict about code and therefor give warnings. If you encouter problems with the toolchains, like code generation errors, feel free to post on the forums and maybe this will lead to a patch.

You just have get use to the thought of PS2Dev being open-source driven, created by people in their spare time for free. This is not a commercial product, there is no support.

AHA! And thanks.

(and, message received)

I'll get back to you all if/when I get a lot smarter.

Thanks again.
Charlie

Ok, I'm a tiny bit smarter.

But I think the details are a bit too belabored for a public forum.

Any of you gentlemen available for PM?

Thanks
Charlie

Please, ask publically, so we only have to answer once and can point to the search form for everyone else :)

As you wish (but this is a bit more complicated that I like):


I have DL'ed the latest PS2 toolchain, which is dated 2007. This is obviously relatively recent. Upon examination, I see that it uses [for example], binutils 2.14, and runs a binutils patch specifically for 2.14.

However, the latest binutils is 2.18. So, an obvious question would be "why does the latest toolchain not use the latest binutils"? (I think I know this answer already). But there is a even more basic question, which is "If I use binutils 2.18, can I just change the toolchain to use this new version (which presumably has the updates), and thus totally eliminate the patch operation?" That is, is version 2.18 sufficiently updated that it is worth using it as a starting point when cleaning up the toolchain, or should I continue with 2.14, apply the patches manually, and eventually end up including this new 2.14 as fully functional and in that manner eliminate the patch operations? If so, what do I loose between this updated 2.14 and 2.18? (Or, is maybe this an entirely stupid path altogether!!)

As a sidebar, what kind of, er.....unusual syntax is used in the patches? Is there a primer on "Patch programming"? I think I've determined that those blocks with the double @-symbols are data blocks (maybe), but I need to do a bit more work until I understand it fully.

Thanks
Charlie

Those patches fix up 2.14 so that it works on PS2. 2.18 doesn't have all the PS2 stuff added, so those patches will have to be remade for 2.18, but there might be other good reasons why 2.18 isn't used (dependencies or compatibility with gcc, for instance).

Jim

There's no reason to upgrade binutils just because it's newer. Is there some specific feature in binutils 2.18 that you need? Toolchains are notoriously finicky and easy to break, especially for non-standard architectures.

The patch format is standard diff, nothing at all unusual.
http://en.wikipedia.org/wiki/Diff#Unified_format

Another AHA! Not being a Unix/Cygwin kind of guy, I somehow assumed that these files are/were specifically created for the PS2 operations. Apparently they are real files that are modified (by the Patch) to be USEABLE for PS2 operations. This also would explain the continued use of the current revs, as opposed to updated revs (the subject of my previous post).

It also appears I must take a side trip down "Patch street" to learn how that stuff works. Thanks for that link, I would never have thought to check for the availability of info that way; in fact, I would probably not have ever thought of the concept of active patching. Thanks.

Ok, so, having determined the above, it would seem to follow that the existing revs of those files, along with the existing patchs for those files, will continue to be the norm. So, if these guys haven't changed, but I suddenly find the toolchain breaks (as we all suspect it will), it becomes obvious (finally) that changes in Cygwin are the cause. Nevertheless, since Cygwin is out of our control, it must be the patches that get changed to fix the problem. By the way, any educated guesses as to whether the best approach is to fix 2.14 patches, or create 2.18 patches; given the comment about possible gcc dependencies?

Comments welcome. In the mean time, I'm off and running again.
Thanks all for your patience. "I'll be back."

Charlie

The best approach would be to just run the toolchain.sh and be done with it.
There's no reason to mess with the patches or versions unless you are hitting a specific problem, in which case if you post the error we can probably help.

Yup, I agree. But running the toolchain script is just the HOW. I am trying to learn the WHY of it, also.

As an FYI, I have successfully worked my way through the first two shell scripts. There is a lot of typing there! If all goes well, the remaining scripts will be successful also. At that point, when I compile that first wonderful HelloWorld, I'll be ask more questions, but at that point, they will be about actually getting the compiled program (ELF?) to run on my machine.

And I'm running.....

Thanks
Charlie

FYI update:
Using the latest/greatest Cygwin (Setup.exe version 2.572.2.2; Setup.ini version 2.573.2.2), binutils-2.14 and gcc-3.2.2 (as found in the toolchain ps2toolchain_20070626) both work. (In this case, "work" is defined as the scripts not crashing or exiting with an error). However, both scripts give numerous warnings, such as "...cmp Command not found", "***This
configuration not valid for this directory", etc. I don't know if either or both of these is fatal for eventual operation of the PS2 development, even though, as I said, they don't crash the script.

However, the script DOES fail under newlib-1.10.0. Someplace in/near the command sequence:

<../configure --prefix="$PS2DEV/ee" --target="ee">
<make clean>
<CPFLAGS="G0" make -j 2>

the script is (I think) looking for the command/directory/file "ee-gcc". The script output with the error message is:

=================================
Making all in libc
make[2]: Entering directory `/usr/local/ps2toolchain/build/newlib-1.10.0/build-e
e/ee/newlib/libc'
Making all in stdlib
make[3]: Entering directory `/usr/local/ps2toolchain/build/newlib-1.10.0/build-e
e/ee/newlib/libc/stdlib'
ee-gcc -B/usr/local/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/ -isyste
m /usr/local/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/targ-include -i
system /usr/local/ps2toolchain/build/newlib-1.10.0/newlib/libc/include -DPACKAGE
=\"newlib\" -DVERSION=\"1.10.0\" -I. -I../../../../../newlib/libc/stdlib -O2 -
DMALLOC_ALIGNMENT=16 -DMISSING_SYSCALL_NAMES -I../../targ-include -I../../../../
../newlib/libc/../libc/include -fno-builtin -G0 -g -O2 -c ../../../../../new
lib/libc/stdlib/__adjust.c
make[3]: ee-gcc: Command not found
make[3]: *** [__adjust.o] Error 127
make[3]: Leaving directory `/usr/local/ps2toolchain/build/newlib-1.10.0/build-ee
/ee/newlib/libc/stdlib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/ps2toolchain/build/newlib-1.10.0/build-ee
/ee/newlib/libc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/ps2toolchain/build/newlib-1.10.0/build-ee
/ee/newlib'
make: *** [all-target-newlib] Error 2
======================================

As you can see, ee-gcc has a problem (again, I think).

The config log for this error is:

==========================================
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:592: checking for a BSD compatible install
configure:645: checking whether build environment is sane
configure:702: checking whether make sets ${MAKE}
configure:735: checking for Cygwin environment
configure:751: ee-gcc -B/usr/local/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/ -isystem /usr/local/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/targ-include -isystem /usr/local/ps2toolchain/build/newlib-1.10.0/newlib/libc/include -c -g -O2 -G0 conftest.c 1>&5
/usr/local/ps2toolchain/build/newlib-1.10.0/newlib/configure: line 750: ee-gcc: command not found
configure: failed program was:
#line 740 "configure"
#include "confdefs.h"

int main() {

#ifndef __CYGWIN__
#define __CYGWIN__ __CYGWIN32__
#endif
return __CYGWIN__;
; return 0; }
configure:768: checking for mingw32 environment
configure:780: ee-gcc -B/usr/local/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/ -isystem /usr/local/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/targ-include -isystem /usr/local/ps2toolchain/build/newlib-1.10.0/newlib/libc/include -c -g -O2 -G0 conftest.c 1>&5
/usr/local/ps2toolchain/build/newlib-1.10.0/newlib/configure: line 779: ee-gcc: command not found
configure: failed program was:
#line 773 "configure"
#include "confdefs.h"

int main() {
return __MINGW32__;
; return 0; }
configure:866: checking host system type
configure:907: checking for working aclocal
configure:920: checking for working autoconf
configure:933: checking for working automake
configure:946: checking for working autoheader
configure:959: checking for working makeinfo
configure:984: checking for gcc
configure:1063: checking whether we are using GNU C
configure:1072: ee-gcc -B/usr/local/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/ -isystem /usr/local/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/targ-include -isystem /usr/local/ps2toolchain/build/newlib-1.10.0/newlib/libc/include -E conftest.c
/usr/local/ps2toolchain/build/newlib-1.10.0/newlib/configure: line 1071: ee-gcc: command not found
configure:1120: checking build system type
configure:1141: checking for -as
configure:1173: checking for -ar
configure:1205: checking for -ranlib
configure:1282: checking for a BSD compatible install
configure:1336: checking whether to enable maintainer-specific portions of Makefiles
=========================================================

I don't yet know where ee-gcc comes from (any hints?). I'll be backtracking it this weekend.

And I'm crawling...

Thanks
Charlie

Sounds to me like you didn't set the PATH as described in the README.

I'm on it!!

Charlie

Edit:

PATH environmental variable using Cygwin "ENV":
=================================
PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/c
ygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI Control Panel:/usr/local/ps2dev/bin:/usr/local/ps2dev/ee/bin:
/usr/local/ps2dev/iop/bin:/usr/local/ps2dev/dvp/bin:/usr/local/ps2dev/ps2sdk/bin
===================================

PATH command as edited in "etc/profile":
=========================
#Path modified for PS2Dev
export PS2DEV=/usr/local/ps2dev
export PATH=$PATH:$PS2DEV/bin
export PATH=$PATH:$PS2DEV/ee/bin
export PATH=$PATH:$PS2DEV/iop/bin
export PATH=$PATH:$PS2DEV/dvp/bin
export PS2SDK=$PS2DEV/ps2sdk
export PATH=$PATH:$PS2SDK/bin

PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:$PATH
export PATH
===========================

Is this correct? Is "etc/profile" the place for this?
Charlie

Edit #2:
It seems to work under Win2k, but not on XP. I need to compare the Cygwin setups, etc, between the two machines. I'll get back to you.

Charlie

Found it.
The "good" machine had Cygwin version 1.5.25, the "bad" machine has 1.5.24. So, script 3 is good.

Moving on to script 4, which is gcc #2. (Hey, why do we erase everything and start again?)

I'll be back when it dies again.

And I'm running...

Charlie

Well, here I am again.

This time, I have a true problem in script #4, which is the second GCC script. It seems to occur due to the script line <CFLAGS_FOR_TARGET="-G0" make -j 2>. The error appears to be related to the function "money_get" in the file "locale_facets.tcc". This is the first error I have encountered that has caused a failure in the toolchain operation; all the other events in this and other scripts have been either non-fatal errors or warnings.

Here's the relavent text:

============================
/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-stage2/gcc/xgcc -shared-libgcc
-B/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-stage2/gcc/ -nostdinc++ -L/us
r/local/ps2toolchain/build/gcc-3.2.2/build-ee-stage2/ee/libstdc++-v3/src -L/usr/
local/ps2toolchain/build/gcc-3.2.2/build-ee-stage2/ee/libstdc++-v3/src/.libs -no
stdinc -B/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-stage2/ee/newlib/ -isy
stem /usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-stage2/ee/newlib/targ-incl
ude -isystem /usr/local/ps2toolchain/build/gcc-3.2.2/newlib/libc/include -B/usr/
local/ps2dev/ee/ee/bin/ -B/usr/local/ps2dev/ee/ee/lib/ -isystem /usr/local/ps2de
v/ee/ee/include -nostdinc++ -I/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-s
tage2/ee/libstdc++-v3/include/ee -I/usr/local/ps2toolchain/build/gcc-3.2.2/build
-ee-stage2/ee/libstdc++-v3/include -I../../../../libstdc++-v3/libsupc++ -I../../
../../libstdc++-v3/libmath -g -O2 -fno-implicit-templates -Wall -Wno-format -W -
Wwrite-strings -Winline -fdiagnostics-show-location=once -G0 -g -c ../../../../l
ibstdc++-v3/src/locale-inst.cc -o locale-inst.o
/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-stage2/ee/libstdc++-v3/include/
bits/locale_facets.tcc: In
member function `_InIter std::money_get<_CharT, _InIter>::do_get(_InIter,
_InIter, bool, std::ios_base&, std::_Ios_Iostate&, std::basic_string<_CharT,

std::char_traits<_CharT>, std::allocator<_CharT> >&) const [with _CharT =
char, _InIter = std::istreambuf_iterator<char, std::char_traits<char> >]':
../../../../libstdc++-v3/src/locale-inst.cc:47: instantiated from here
/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-stage2/ee/libstdc++-v3/include/
bits/locale_facets.tcc:1167: Internal
compiler error in schedule_block, at haifa-sched.c:1714
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[3]: *** [locale-inst.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-sta
ge2/ee/libstdc++-v3/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-sta
ge2/ee/libstdc++-v3'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/usr/local/ps2toolchain/build/gcc-3.2.2/build-ee-sta
ge2/ee/libstdc++-v3'
make: *** [all-target-libstdc++-v3] Error 2
=================================

I guess I now need to dig into what Make is doing, as well as search this forum for any related posts. I am hoping that there is no "rollover" from the error/warning events in the previous three scripts (can some guru confirm this, or inform me that I should revisit any of the first three scripts and clean them up?); this would seem to make some sort of sense given that this fourth script completely deletes the previous GCC setup. So I am now on another side trip to look into how Make works. I'm getting just enough knowledge to be dangerous!

And I'm crawling...

Charlie

FYI Update:
Well, it looks like I finally got past the dreaded "haifa-sched.c" Cygwin-with-PS2Toolchain-under-Windows error. (At least, script #4 ran without errors!). I now have to check the log outputs to be sure, maybe see if there is anything that may be a "gottch-ya". Next, it's on to scripts #5 and #6, obviously. Before anybody wants to throw a party, however, I should add this caveat: I used an older version of Cygwin. I started with only the Cygwin package and installed it. Then I ran the scripts, line by line. When I hit a problem, I determined what package was missing, installed it, and ran the scripts again. I now have, I believe, the near absolute-minimum Cygwin installation that will support the PS2 stuff. Learned a lot, but it also leads to a number of questions, which I will no doubt be posting soon!

Also, I've had some success in other PS2 areas:
1. I have a functional ethernet connection; I can ping the PS2 from my PC when using a program that normally accesses the Network Adapter

2. I successfully compiled (using the pre-built toolchain you guys so thoughtfully provided) the simple Helloworld program and ran it on my PS2 ; however, the default (?) font is almost unreadable, so that's probably my next programming exercise.

3. I've purchased the HardDrive; installing it sometime this week.


And I'm running...

Charlie

Good work charliee1151. If all went right, please post later a tutorial on how to build the toolchain using the current cygwin. Or if it's a matter of editing the toolchain script, please post the needed changes so anyone with svn access could commit it. I'm also using a old version of cygwin, but it isn't practical to get it, since old versions aren't available from the official sources.

Wow, that was a quick reply.

Being somewhat anal retent....oops, I mean "a stickler for precise details"..yeh, that's it!...I am in the process of completely tearing down my present Cygwin install to perform a second complete install from scratch; I want to make sure I've got the Cygwin stuff right, then repeat the scripts #1-#4.

As for updating to the current Cygwin, all I'm looking for is to be able to compile a working executable for the PS2; I don't really care how poorly Cygwin is in terms of functionality, as long as it is stable for PS2 development. Having said that, what are the advantages of upgrading to the current Cygwin, other than maybe the packages are easily obtained? Or, to reverse the question, how could I be hurt if I did NOT upgrade to the current Cygwin? (Of course, it sounds like a fun challenge!)

By the way, I am not using any SVN stuff, but I guess that eventually using it is actually inherent in the Cygwin upgrade effort.

But, let's make sure I can repeat the previous success first. And, once I get past script #4, I still need to attack #5 and #6, but those SEEM to be a bit less involved (foot-in-mouth?)

And I'm running....
Charlie

Another update...

I have successfully installed Cygwin on another computer, and successfully executed scripts #1-#4. Looks like the legacy stuff I've been digging up is working. I'm on to scripts #5 and #6 this week. If that works, I should be able to create an executable HelloWorld.

I'll probably need some help when I dig into the legacy-vs-current Cygwin stuff.

And I'm running...

Charlie

Here's a quickie, I think:

Where should I put the tar file for PS2SDK? I done a bit of searching here using the terms "PS2SSDK", "directory", "install"...got a lot of hits...looked at a lot of them, but didn't find the simple answer. Here's my situation:

If I put it in the PS2DEV directory, when I un-tar it, it will populate a PS2SDK directory under PS2DEV; this is where I think PS2SDK belongs, based on script #5. But if I do that, when I run script #5, it fails because it is trying to copy files from my chosen source directory, which in this case is the .../PS2DEV/PS2SDK directory, onto the hardcoded intended destination, which is of course also the .../PS2DEV/PS2SDK directory. This gives an error.

If I put the PS2SDK tar file elsewhere, in tmp, for example, then the copy is successful and there is no error since the source and destination are different. I would then expect to delete all the files in the tmp directory. However, it appears, from the script, that additional processing takes place on the files still in the tmp directory; at least, a WinDiff shows many differences.

So, assuming that I must use some directory OTHER than the hardcoded destination directory, what is the recommended placement? And, once script #5 is finished, can I ignore and erase the source directory and assume that the destination directory is the "bible"?

Please remember that I am doing all of this manually, outside the official toolchain. I'm hoping that doing it in this manner will help when I do the legacy/current Cygwin upgrade.

Thanks
Charlie

PS: A quick look at script #6 shows a parallel operation. So, same question for it also. (I am now guessing that both of these scripts belong together...somewhere)

charliee1151 wrote:Where should I put the tar file for PS2SDK?

I don't recall using a tar file like you do. And I'm not 100% sure about what your script #5 does, but I assume that this is where you get to recompile the entire PS2SDK, so as to produce its binary release tree.

I'm using CygWin on WinXP and use TortoiseSVN to fetch/update most sources, and I didn't use quite the same methods you're using. But I still think I recognize your basic problem, which is that some scripts and docs don't seem to differentiate properly between the source tree and the binary release tree of PS2SDK, and incorrectly refer to both using the same name.

If I put it in the PS2DEV directory, when I un-tar it, it will populate a PS2SDK directory under PS2DEV; this is where I think PS2SDK belongs, based on script #5. But if I do that, when I run script #5, it fails because it is trying to copy files from my chosen source directory, which in this case is the .../PS2DEV/PS2SDK directory, onto the hardcoded intended destination, which is of course also the .../PS2DEV/PS2SDK directory. This gives an error.

This is the inevitable effect of treating the two folder trees as if they were identical.

If I put the PS2SDK tar file elsewhere, in tmp, for example, then the copy is successful and there is no error since the source and destination are different. I would then expect to delete all the files in the tmp directory. However, it appears, from the script, that additional processing takes place on the files still in the tmp directory; at least, a WinDiff shows many differences.

You will need the PS2SDK source tree for future patches too, so you need to keep it intact, but separate from the binary release tree.

So, assuming that I must use some directory OTHER than the hardcoded destination directory, what is the recommended placement?

I'm not really sure what's 'recommended', but my own folder trees are stored directly inside the PS2DEV folder, and are named "ps2sdksrc" and "ps2sdk" respectively.

Well, actually those are not the names of the folders themselves, but the names of two Cygwin-style symbolic links pointing to the real folders. This way I can have serveral versions of PS2SDK installed in parallel, and switch between them simply by redefining those two links. But for a simpler setup I'd just use the names given above for the real folders

And, once script #5 is finished, can I ignore and erase the source directory and assume that the destination directory is the "bible"?

Not if script #5 is the one that compiles and 'installs' the binary release, as you should also preserve your source tree, for future updates/patches.

Please remember that I am doing all of this manually, outside the official toolchain. I'm hoping that doing it in this manner will help when I do the legacy/current Cygwin upgrade.

I had the same ambition too once, but trying to get there wasn't worth the hassle. I'm happy just to have a working setup, but I don't expect that upgrading to all the latest CygWin components will ever work.

PS: A quick look at script #6 shows a parallel operation. So, same question for it also. (I am now guessing that both of these scripts belong together...somewhere)

I'm not exactly sure what your scripts #5 and #6 are for (haven't looked at toolchain stuff for quite some time), but the end result should never the less be that you keep both a source tree and a binary release tree for PS2SDK.

Best regards: dlanor

Thanks for your reply. I can see that my question wasn't detailed enough, but you've given me some additional info that I definitely need.

Let me fill in some blanks...
If you look at script #5, the first line gets the files via SVN:
"svn checkout svn://svn.ps2dev.org/ps2/trunk/ps2sdk"

If you browser to that location (as I mentioned, I can't use SVN..that's just the way it is), you can see the entire file listing, which includes "common", "ee", "iop", etc. If you drill down, eventually you can see the text listing of the code. To obtain this, I would have to cut-and-paste the texts of all the files (I think...is there some other way to get all that data easily, in a manner NOT using SVN?). So, instead, I dl'ed the tar'ed file set (thanks, guys!). I have to stick it someplace to un-tar it, which lead to my original question. Even if I did use the cut-and-paste approach, I still would have to put them someplace.

Let me try a different approach...
When the line in script #5 executes, where does the fetched data go? I assumed it was into the "ps2sdk" directory, since the next line is
"cd ps2sdk". Since this is a change into a child directory, it obviously means that you have to currently be in the parent directory. So, where is that parent directory? Well, the only "ps2sdk" that exists after the first four scripts that run is under "ps2dev". So, "ps2dev" must be the parent; that's where I put it (as you also did, apparently), that's what caused the problem of the identical trees, that's why I moved it, that's when I discovered the file discrepancy, what's why I asked.

I am familiar with the concept of checkout in regards to source control, but not SVN specifically. So, I took the above approach, which is failing, which prompted my post.

Finally, to your response (whew!)...
Using a "ps2sdksrc" folder is no different than using a "tmp" folder; the point is that, after copying the source files to the destination files, the source files themselves are operated on. This kind of goes against the concept of source! Wouldn't you expect that only the destination files to be the ones that are changed? So I need either a quick tut on SVN checkout, or maybe someone who is more familiar with script #5.

As for updating Cygwin and the newer files, you are right, it probably is not worth the hassle; if it ain't broke, don't fix it. But I like a challenge...look at how much work it was to not only re-create the legacy Cygwin, but to go package-by-package vs script-by-script to eliminate the unused packages and allow a manual, commandline build! I was hoping to apply the same strategy to scripts 5 and 6, and I will...if I can get past this latest hurdle.

So, thanks for listening,..er....reading. I'll keep at it, and will gladly accept any help.

Thanks
Charlie

I think I found it!!.

After a lot of Googling for SVN, I found an obscure reference (well, darn it, it's obscure if you don't know what you're looking for!!!) that indicated that the script line in question will, if a destination is not specifically indicated, use the last entry in the URL. Well, that's "ps2sdk", which we all knew, duh, but that meant that the parent directory had to be the "build" directory that the original toolchain created. Tried that, and it seems to have worked.

And I'm running...

Charlie