GS Mode Selector: Development & Feedback

[E P]

In fact I now have two separate Cygwin setups, each with two different PS2Dev lib setups, with each of the two Cygwin setups stored as separate snapshot branches of a VMware virtual machine. The dual lib setups are because I need one for uLE, and another for projects that require later lib versions, like "Open PS2 Loader" and GSM both do. And the dual Cygwin setups are due to my searching for the optimum version. (The best updated one before compatibility to ps2dev stuff was lost.)

That's great to hear. Oh and speaking of "Open PS2 Loader" which ps2sdk version is used with that project? I've been thinking of doing a simple symbolic link so I can change ps2sdk versions to build my own test versions in order to better follow its progress. Also while on the topic of ps2sdk, I did try to build GSM a few weeks back with the latest ps2sdk and it just wouldn't build the loader.elf. So I switched to the one we use with uLE and at least I got it to compile. Maybe it's time to go back a recompile the "r" version because I'm pretty sure I built a working version of it last time I tried.

The Cygwins I currently have are from December 2004 and July 2005, and they are both working fine. It is interesting to note that I re-compiled uLE v4.40b, originally compiled and released by you, and the result with the latter Cygwin version was byte for byte identical with your "uncompressed BOOT.ELF", so this setup must be very close to yours.

That's definitely good news. So we should be on the same page. Hopefully that will make things much easier in the future.

The ones I used are much larger (around 500MB each), as I've been downloading complete Cygwin packages from the 'fruitbat' site. The odd thing is that not all of those are complete or even working for an install. I've tried over half a dozen of them, and so far only these two worked acceptably.

I just tried to pick and choose the minimal setup to keep the clutter down way back when. That's why I only have 50MB of cygwin packages. In your case though, it surely makes things easier having the bulk of packages to sift through.

I may try a linux setup sometime later too, but for now I decided to go with the stuff I was more familiar with.

I probably wouldn't bother now in your case as you now seem to be able to produce the similar binaries to mime. My Linux setup is a stripped down install that runs entirely off a USB 4GB flash drive with no swap file. I have to go though what the Linux gurus call "dependency hell" from time to time, but I like to run a nice slim setup. All of this really makes maintenance a breeze.

But on the slim consoles it only works if I first run an old version, and then exit from that to run the new version. I suspect some lib update of PS2SDK or gsKit to be responsible.

Yeah, this is what I did before. Ran an older version and then loaded a newer one over the top of the existing state. However, with changes to the CNF file and other adjustments I wasn't sure it would work too well this time.

I certainly hope to fix it shortly, as it relates to the integrity of my ps2dev setups.

And mine as well.

[doctorxyz]

Man... How time-consuming is make the toolchain from the scratch!!! :-(....

[Bootlegninja]

depending on your system resources, average is a couple hours for a basic one without gsKit or anything else.

[doctorxyz]

Hi all,

Well, the setup has just finished. It took me about two and half hours. But there is another thing that it took more time than this: I had to make a lot of adjustments to conclude it: There are several issues (libs that weren't available anymore on their original urls and related mirrors broken, wget command line tricks, proxy settings, many compile warnings, and so on). Despite of all this obstacles, I could compile GSM successfully. But... NB... I had no chance to test it yet (I will try this later, or another night or day).

So it's just a little progress, therefore I know that it is too soon to celebrate anything.

I've just finished the backup. After that I will repeat all the process in "silent mode" to see if I really learned the "recipe" (I wrote down some notes in order to remember the steps when needed). Then I will compile GSM and test it again.

If I got success on it, I will publish my toolchain "recipe" and the related REV numbers as well. And a a copy of my current home beta to dlanor (or to other coders interested. Just let me know).

BR,

[dlanor]

That's great to hear. Oh and speaking of "Open PS2 Loader" which ps2sdk version is used with that project?

For this I just use the latest versions of everything, as downloaded by a script as mentioned before. This script is related to the one we use for uLE, though I do it slightly differently for the 'all new' lib collection (no SVN revision numbers, and no CSD folder).

Here is the script I use with the new Cygwin setups (for the non-uLE libs):

#!/bin/bash

# This script is intended to rebuild a ps2dev environment and compile as needed

###########################################################################

##############
## SETTINGS ##
##############
export BUP_DIR=$PS2DEV/SVN_BUP
export PS2SDKSRC="$PS2DEV/ps2sdksrc"

# The -s command line option skips downloading
if [ "$1" = "-s" ]; then
	DOWNLOAD=0
else #otherwise just what they want done
	DOWNLOAD=1
fi

if [ -e $PS2DEV ]; then
  echo PS2DEV folder exists.
  TRUE=1
else
  echo PS2DEV folder is missing, so we must abort
  exit
fi

if [ -e $BUP_DIR ]; then
  echo SVN_BUP folder exists.
  SVN_BUP_NEW=0
else
  echo SVN_BUP folder is missing, so we create it
  mkdir "$BUP_DIR"
  SVN_BUP_NEW=1
  DOWNLOAD=1
fi

####################
## DOWNLOAD FILES ##
####################
if [ $DOWNLOAD -eq 1 ]; then
  cd $BUP_DIR
	svn co svn://svn.ps2dev.org/ps2/trunk/ps2sdk ps2sdksrc
	svn co svn://svn.ps2dev.org/ps2/trunk/gsKit gsKit
	svn co svn://svn.ps2dev.org/ps2/trunk/usbhdfsd usbhdfsd
	svn co svn://svn.ps2dev.org/ps2ware/trunk/ps2ftpd ps2ftpd
	svn co svn://svn.ps2dev.org/ps2ware/trunk/myPS2/lib/libjpg libjpg
	svn co svn://svn.ps2dev.org/ps2ware/trunk/SMS/drv/SMSUTILS SMS/drv/SMSUTILS
	svn co svn://svn.ps2dev.org/ps2ware/trunk/SMS/drv/SMSMAP SMS/drv/SMSMAP
	svn co svn://svn.ps2dev.org/ps2ware/trunk/SMS/drv/SMSTCPIP SMS/drv/SMSTCPIP
fi

# Since old work libs may have been patched, and the user wants to recompile,
# we need to erase the old work libs and renew their sources from $BUP_DIR

echo erasing old lib work copies

cd $PS2DEV
rm -fr ps2sdk/*
rmdir ps2sdk
rm -fr ps2sdksrc/*
rm -fr ps2sdksrc/.svn
rmdir ps2sdksrc
rm -fr gsKit/*
rm -fr gsKit/.svn
rm -fr gsKit/.cdtproject
rm -fr gsKit/.project
rmdir gsKit
rm -fr usbhdfsd/*
rm -fr usbhdfsd/.svn
rmdir usbhdfsd
rm -fr ps2ftpd/*
rm -fr ps2ftpd/.svn
rmdir ps2ftpd
rm -fr libjpg/*
rm -fr libjpg/.svn
rmdir libjpg
rm -fr SMS/*
rmdir SMS

echo all content of old lib work copies has been erased

echo starting to copy lib work copies from $BUP_DIR

cd $PS2DEV
cp -r SVN_BUP/ps2sdksrc ps2sdksrc
cp -r SVN_BUP/gsKit gsKit
cp -r SVN_BUP/usbhdfsd usbhdfsd
cp -r SVN_BUP/ps2ftpd ps2ftpd
cp -r SVN_BUP/libjpg libjpg
cp -r SVN_BUP/SMS SMS

echo lib work copies are now ready

echo This is the point to apply custom patches to the work copies...
echo At present no such patches are being applied

echo it is now time to compile all the libs

cd $PS2DEV/ps2sdksrc && make clean && make && make install
cd $PS2DEV/libjpg && make clean && make
echo now we fix header compatibility to all progs that use libjpg
cd $PS2DEV/libjpg && mkdir include && cp *.h include
cd $PS2DEV/gsKit && make clean && make all && make install
cd $PS2DEV/usbhdfsd && make clean && make
cd $PS2DEV/ps2ftpd && make clean && make
cd $PS2DEV/SMS/drv/SMSUTILS && make clean && make
cd $PS2DEV/SMS/drv/SMSMAP && make clean && make
cd $PS2DEV/SMS/drv/SMSTCPIP && make clean && make

echo all libs have now been compiled

echo script work is now complete

I've been thinking of doing a simple symbolic link so I can change ps2sdk versions to build my own test versions in order to better follow its progress. Also while on the topic of ps2sdk, I did try to build GSM a few weeks back with the latest ps2sdk and it just wouldn't build the loader.elf.

I vaguely recall some such trouble too, but with the current version I have no such troubles.

So I switched to the one we use with uLE and at least I got it to compile. Maybe it's time to go back a recompile the "r" version because I'm pretty sure I built a working version of it last time I tried.

Even so, you should realize that the new GSM is dependent on a newer gsKit than we use for uLE, so compiling GSM with the same lib setup as for uLE is not valid.

----- re: My new lib setup for uLE compiling identical binaries like yours do

That's definitely good news. So we should be on the same page. Hopefully that will make things much easier in the future.

Yes, and this ability makes me sure that the Cygwin setup must be spot-on. (Any major faults there would affect the toolchain compilation, which would snowball into huge changes of compiled binaries. First for the libs compiled and then for applications.)

I just tried to pick and choose the minimal setup to keep the clutter down way back when.

I've considered doing that too, but doing it the right way, by editing the Cygwin setup.ini to match the pruned installer package, while also keeping track of all dependencies... Well, that's just too much work for the savings to be worth it. I'd rather waste a few hundred megabytes on including some sub-packages that I'll never use, than spend all that time and also risk losing some package (due to a misedited dependency) which could make a difference to some future project.

With my new internal HDDs (2 of 1.5 TB each) I don't have to be a storage miser anymore, which was much of the point in getting them.

That's why I only have 50MB of cygwin packages. In your case though, it surely makes things easier having the bulk of packages to sift through.

Otherwise I would not have been able to get these setups working this fast.

----- re: Possible Linux setup for me in future

I probably wouldn't bother now in your case as you now seem to be able to produce the similar binaries to mime. My Linux setup is a stripped down install that runs entirely off a USB 4GB flash drive with no swap file. I have to go though what the Linux gurus call "dependency hell" from time to time, but I like to run a nice slim setup. All of this really makes maintenance a breeze.

I clearly don't need a linux setup now, but what I'd like to do is to put together a VMware virtual machine with a basic PS2Dev toolchain and lib setup preinstalled. Future co-developers could then just download that virtual machine, and instantly use it (though they may have to get and install VMware first of course).

This is something we can never do with a ready-to-run Cygwin setup, since that demands a commercial component for the OS.

As an alternative though, I could prepare a set of files to be used with one of my downloaded Cygwin install packages, so that peoplle can use this by following a step-by-step procedure for installing a setup similar to mine.

It's something I've been thinking about in the repetitive Cygwin install attempts I've made lately (far more than the two which resulted in working PS2Dev setups). Two things are definitely needed to make this accessible to a wider group of user-programmers, and those are:

1: Some standardized installer packages guaranteed to work as expected
2: A clear step-by-step instruction for how to do this from scratch (like having newly installed XP) to having a working PS2Dev setup

I'm not quite ready to put that together yet, but it is something I'd like to do, and should gain the tools for doing if I complete my current investigations like I plan to.

----- re: GSM init problems, partly solved by using an old version for the init

Yeah, this is what I did before. Ran an older version and then loaded a newer one over the top of the existing state. However, with changes to the CNF file and other adjustments I wasn't sure it would work too well this time.

I don't think that stuff matters. It is the opcode trap initialization that is all-important, and that has been fixed for a long while now. I tested it earlier today by letting v0.23e initialize before using my current v0.23u, which worked fine.

And mine as well.

But I really don't think this issue is related to the libs you and I use for uLE, as those are entirely separate from the ones I use for GSM. I'm sure you remember the various troubles uLE would get whenever we tried some of the newer libs for it, which is why we never could use those except for brief testing. But with GSM I use the latest libs for everything which makes its lib problems completely unrelated to uLE.

Best regards: dlanor

[dlanor]

Man... How time-consuming is make the toolchain from the scratch!!! :-(....

That is where I love the snapshot system of VMware, because immediately after making any such lengthy operation I can take a snapshot, and if anything then goes wrong with the next thing to be installed I can just revert to that snapshot. This is a little like XP restore points (which I never use and always disable), except that it is superfast, and also allows several parallel snapshot branches. (Unlike XP which forgets any state you revert from.)

With VMware you can jump both back and forth between snapshot points, and branch out from any one of them. This allows you to explore several different possibilities in parallel, before deciding which branches to keep and which to prune away.

I've recompiled toolchain several times over in the last couple of days, due to bad Cygwin packages, but at least I know that I won't have to repeat the successful attempts due to any later mistakes in installation, as the snapshots always allow me to recover from such problems. So for each good Cygwin package only one toolchain install is needed, no matter how many independent lib setups I use it for.

Well, the setup has just finished. It took me about two and half hours. But there is another thing that it took more time than this: I had to make a lot of adjustments to conclude it: There are several issues (libs that weren't available anymore on their original urls and related mirrors broken,

Ouch! Like I said before, I did not use the toolchain script but instead used an existing source collection, so I never had this problem with missing stuff.

wget command line tricks, proxy settings, many compile warnings, and so on).

Compile warnings are quite normal for toolchain work, and there really is no point in even watching them during the compilation, as there is no way to keep track of the many thousands of messages displayed.

----- snip -----

If I got success on it, I will publish my toolchain "recipe" and the related REV numbers as well. And a a copy of my current home beta to dlanor (or to other coders interested. Just let me know).

I just hope we can clarify the init problem by those REV numbers, because otherwise I have no clue as to what is causing it. And if you now get the same result I did, it's hard to know what to look for. But I suspect it is the opcode trap vector handling that is affected.

Best regards: dlanor

[E P]

Here is the script I use with the new Cygwin setups (for the non-uLE libs):

Alright, thanks for the info and the script. It's time for me to make another attempt at building GSM with the current ps2sdk as opposed to using the one we use with uLE.

Even so, you should realize that the new GSM is dependent on a newer gsKit than we use for uLE, so compiling GSM with the same lib setup as for uLE is not valid.

Yeah, I caught that early on when I saw ragnarok2040 giving pointers. I did initially try to use the older gsKit version that we use with uLE and obviously got nowhere.

Two things are definitely needed to make this accessible to a wider group of user-programmers, and those are:

1: Some standardized installer packages guaranteed to work as expected
2: A clear step-by-step instruction for how to do this from scratch (like having newly installed XP) to having a working PS2Dev setup

I'm not quite ready to put that together yet, but it is something I'd like to do, and should gain the tools for doing if I complete my current investigations like I plan to.

Not a bad idea if done correctly. Still this could take a huge amount of time if you get right down to the specific library combinations.

----- re: GSM init problems, partly solved by using an old version for the init
I don't think that stuff matters. It is the opcode trap initialization that is all-important, and that has been fixed for a long while now. I tested it earlier today by letting v0.23e initialize before using my current v0.23u, which worked fine.

Okay, then I'll use that as a way of loading things to do some tests again.

I'm sure you remember the various troubles uLE would get whenever we tried some of the newer libs for it, which is why we never could use those except for brief testing. But with GSM I use the latest libs for everything which makes its lib problems completely unrelated to uLE.

Sure, I just meant that since we can produce the same ELF's using more similar PS2 toolchains you're not alone in experiencing this.

@doctorxyz:
Building the ps2 toolchain can be time consuming. They used to joke around on the ps2dev forums that some machines could overheat during the operation causing errors. They obviously weren't kidding. If you want to do it fast, fire up a Linux distro like a live CD of sorts and build the toolchain within the computers main memory. It sure showed me just how much time is wasted reading and writing all that stuff to the hard drive.

Edit:
Hum now that's a little odd. I tested my own build of v0.23t, which was built with the current ps2sdk and gsKit versions. The program was ran through ps2link but it caused the dreaded exception screen. So I did the usual reset call to ps2link using ps2client. Then I ran your binary, dlanor, and now the program is up and running. So it looks like as we agreed an initialization issue. I'll see if I can further track it down or at least try to understand why my build is going haywire.

[lee4]

Quite wrong. This DX=700 setting is what gives ideal display of NTSC vmodes on my old CRT TV sets (I have two identical), both of which have 24" screens with 4:3 aspect ratio and which lack any trace of widescreen compatibility.

Their only semi-advanced features are that they come with SCART interface and full compatibility to both PAL and NTSC. I use these sets to establish screen positioning precisely because I want to AVOID the mistake you accuse me of, of making it depend on an HDTV set.

Also, for an HDTV set the precise DX value shouldn't matter anyway, since it should be able to display the entire screen of any 4:3 picture regardless of DX, as there is plenty of room to spare on either side of the used screen area.

On the other hand, the DX=632 value that you seem to love can only be useful with a composite or S-Video signal, as it is bound to place the left edge of the display off-screen when used with either RGB or component signals.

Best regards: dlanor

oh crap what I posted on #892 is sightly inaccurated, I fixed my post to make abit more sense.

no, you are wrong, you are just adding the 700 value is NTSC2PAL X fix value for PAL TV, your tests are on your PAL TV.
(you live in Europe not in USA or Japan)

on 100% "USA/Japan NTSC TV only" 632 is 100% correct value.

This error has nothing do with cables or HDTV types, its about correctness for vmodes.

I will be keep conplaining, until I can proof I'm correct because nobody else will for 100% USA NTSC TV.


@doctorxyz
NTSC 480i & NTSC 480ni (excecpt q to s2) inaccurated because dlanor is using NTSC X fix value PAL TV.

all NTSC 480ni vmodes are still wrong. (on s2 and t built my NTSC ni settings dont work)

last useable build was 23s for me.

[doctorxyz]

@all
I sincerely hope we all - psx-sceners from the four corners of the globe - can put our cultural / technical differences aside in order to work together on our common goal. :-D

@lee4
Don't be offended okay ;-)
I'm having a lot of issues to solve here, but decided to I sepparate some time to share some info with you.
Maybe you haven't realised yet that dlanor and me are not using always the same source code (If you've already realised this, please ignore the following explaination lines).
I wish I could keep updated the "Developer To Do List" and "User Wish List" sinchronized, but it is not possible due a lot of factors.
Currently there is no a SVN repository for GSM. This is not even necessary (currently we have only two developers actively working on GSM).
What really occurs is that dlanor/me just pick up the latest beta source code attached here by other, or sometimes send/receive the home beta source code by email to/from other.
I haven't enough time to test or code anything from the latest dlanor's release published on his latest v0.023t release. Despite I dunno if the vmodes selected by you were kept on that release or not, the important and good thing is that me and dlanor are delivering, at our pace, more and more functionality to GSM. And this means more power to the final user. Since Detailed Fine-Tuning can be a good benefit to support different needs from different users with different consoles/titles/regions/TV/Monitor sets.

@dlanor
Thanks for the latest source code you attached here.
BTW, I believe I made some relevant progress during the latest two days ;-)
I intend to finish my post about the 'ps2 toolchain saga' and their REVs today or tomorrow.

BR,

[dlanor]

----- re: Preparing Cygwin installer packages with step-by-step instructions for ps2dev

Not a bad idea if done correctly. Still this could take a huge amount of time if you get right down to the specific library combinations.

True, which is why I don't even intend to try size optimizing this stuff. That would force me to waste tons of time checking out cross-dependencies to calculate what can be removed from a package without ill effects, and any mistakes in this could lead to equally time-consuming efforts to repair them.

So I don't intend to edit the release packages at all. I just want to add explicit instructions for how to install them and then follow up the basic installation with the steps needed to install a fully working ps2dev setup similar to my own.

But even the basic installation needs of Cygwin varies from package to package, and for most of them a single-session install is not enough, as it has to be done in two or three sessions in order to finalize correctly (running all relevant postinstall scripts). In fact I don't think that any of my previous ps2dev setups (and I've had several) were ever based on a fully correctly installed Cygwin.

They worked, as far as the ps2dev stuff was concerned, but the Cygwin system itself was never at full health, like I think my latest installs are.

Btw. I just made another successful ps2dev install today, based on a Cygwin release from January 2006. But I haven't yet compared any application binaries produced by it. Still, it is always a good sign when it compiles PS2SDK without problems. The toolchain compile is also important of course, but that is mostly concerned with compiling code to run on the PC, whereas the PS2SDK compile is the first one to produce significant amounts of PS2 code.

----- re: old-version GSM trick of initializing before running new version

Okay, then I'll use that as a way of loading things to do some tests again.

Yes, at present that seems the only way of testing new changes in the main code of GSM.

Sure, I just meant that since we can produce the same ELF's using more similar PS2 toolchains you're not alone in experiencing this.

Sure, I just wasn't certain you had alternate lib setups yet, and I wouldn't want you to replace your uLE setup otherwise.

@doctorxyz:
Building the ps2 toolchain can be time consuming. They used to joke around on the ps2dev forums that some machines could overheat during the operation causing errors. They obviously weren't kidding. If you want to do it fast, fire up a Linux distro like a live CD of sorts and build the toolchain within the computers main memory. It sure showed me just how much time is wasted reading and writing all that stuff to the hard drive.

This is true, but never-the-less I have spent a lot of time recently doing just that repeatedly, and in VMware virtual machines at that... But fortunately my new computer is fast enough to let me work on other things in parallel, as the virtual machine normally uses only one of the two CPU cores. So I was actually surfing PS2 forums at full speed while simultaneously doing the latest toolchain install on the same physical computer. (Something I could never even have imagined trying with my old system using an Athlon CPU)

Edit:
Hum now that's a little odd. I tested my own build of v0.23t, which was built with the current ps2sdk and gsKit versions. The program was ran through ps2link but it caused the dreaded exception screen. So I did the usual reset call to ps2link using ps2client. Then I ran your binary, dlanor, and now the program is up and running. So it looks like as we agreed an initialization issue. I'll see if I can further track it down or at least try to understand why my build is going haywire.

I think you need to run both my elf and yours the same way, in order to make a fair comparison of their conduct. I seldom use PS2Link in my testing, so I'm not really sure how that would affect things.

Best regards: dlanor