forums.ps2dev.org

RadShell
A command line client for the PS2.
Standard stuff:
- loading irx
- running elf
- execute scripts
- basic file management - delete, copy, etc

Cool man!

Thanks

(i must get some free time to do some real homebrewing ... I need vacations urgently!)

(after reading the radshell.txt)

great! usb keyboard support!

New version:
- Updates to display drawn immediately
- Draw cursor
- Improved line input editing
- Command line arguments passed to launched elfs
- Copy progress meter

Very nice !

I finally tried it.
But when I run it from a USB pendrive and type "cd mco:" or "dir mc0:" it freezes ...

What can I say - it works for me.
Although 'mc0:' gives 'Not a directory' for me.
I have to use 'mc0:/'.

Regarding the USB pen, it might be due to that. The SMS media player also doesn't like my pen :)

But it boots ok off the usb doesnt it?
At the point where you are trying to do those commands it has nothing to do with the USB.

radad wrote:But it boots ok off the usb doesnt it?
At the point where you are trying to do those commands it has nothing to do with the USB.

Yes no problems booting it from USB (I copied all the files to the pen and then used uLaunchElf to start it from the USB)

The problems are confined to the "cd mco:" or "dir mc0:" at least... I also can run .elfs stored in the usb pen from the radshell itself using the run(?) command.

ptek wrote:The problems are confined to the "cd mco:" or "dir mc0:" at least...

But didn't radad already say that those path strings you use are wrong ?!?

As I understood that post, you are supposed to use "cd mc0:/" instead of your "cd mc0:" and similarily use "dir mc0:/" instead of "dir mc0:". It may seem like 'nitpicking', but command line interpreters are like that sometimes. If even a single character deviates from the expected input they may refuse that line entirely. Although when I try either of your commands I do get a definite error message stating: "Not a directory: 'mc0:'"

Using the strings radad specified I have no problem at all with either command. (Using radshell v0.2 launched from MC by uLE v4.12g Beta)

For me the immediate problem is the need for screen positioning and sizing, as my TV set shows the leftmost characters partly hidden by the left screen edge, and even more so for the top and bottom rows (no flatscreen this...)

Best regards: dlanor

You are correct dlanor. Although it still shouldnt hang.

dlanor wrote:For me the immediate problem is the need for screen positioning and sizing, as my TV set shows the leftmost characters partly hidden by the left screen edge, and even more so for the top and bottom rows (no flatscreen this...)

I will get onto that for next version. I dont have a flat screen either but mine apparently shows a little more than yours.

dlanor wrote:

ptek wrote:The problems are confined to the "cd mco:" or "dir mc0:" at least...

But didn't radad already say that those path strings you use are wrong ?!?

I'm going to try the right sintaxe although I strongly suspect from my usb pen. Under SMS its contents are not fetched...

(edited : well, I forgot I don't have a usb keyboard. I tried radshell with a borrowed one, so I'm not sure when can I try it again... Sorry all)

radad wrote:You are correct dlanor. Although it still shouldnt hang.

And there was no 'freezing' in my tests. For me those commands never had a worse result than an error message, even when I used incorrect path strings. So I could just continue testing without restart.

----- snip ----- re: need for screen position/size controls

I will get onto that for next version. I dont have a flat screen either but mine apparently shows a little more than yours.

Most TV sets do. Mine is a rather cheap Korean unit ("Kendo" brand). It has some nice features for its low price, including dual compatibility for PAL/NTSC and remote control menu for all settings, but the bad side is that those settings do NOT include any screen positioning, and there is a design flaw causing a slight offset towards the left edge.

I have two of these sets from different production batches and yet with identical screen offsets, so it's definitely a design flaw rather than a normal production variation. I didn't notice it much until I started using these sets for my consoles, but then it became all the more obvious.

Best regards: dlanor

Well, I've able to test again sooner than I expected. Got again the usb keyboard and the "cd mc0:/" still makes the same effect as "cd mc0:".

To be more precise, I type "cd mc0:/" and when I press the Return key the cursor drops down one line being positioned just belog the typed c from cd and no more responses to any key.

Does anyone have any similar problems ? BTW, my memory card is not the standard 8MB from $ony, but a 16MB from Max Memory... Anyway, this shouldn't be relevant, since the memory card seems pretty compatible (no problems at all saving games into yet).

Then today I tried the following : booted from launchElf 4.07 and copied the contents of radshell binaries from the USB pen to the mc0:/ card.
Then, on lauchelf navigated into the radshell folder at mc0 and executed the radshell.elf.

So, the first thing I did was "dir". Same freezing. Rebooted again and the "cd mc0:/" also gives me the same freeze.

In fact (since I don't have an HD) the only time the "dir" command worked was when I started the radshell from the USB pen and did a dir on it... When I tried to go to the mc0, the freeze happened.

Maybe my PS2 is cursed :)

Seems like there is some incompatibility with the memory card modules and your memory card. These modules are loaded off of rom0. I do use the 'x' modules, maybe that is the issue.

In the file radshell.rsh there are these lines: Try uncommenting that last one. I am not entirely sure what it is needed for.
If that doesnt work comment out the lines above and uncomment these lines:

radad wrote:

Code: Select all

load rom0:XSIO2MAN
load rom0:XMCMAN
#load rom0:XMCSERV

Try uncommenting that last one. I am not entirely sure what it is needed for.
If that doesnt work comment out the lines above and uncomment these lines:

Code: Select all

#load rom0:SIO2MAN
#load rom0:MCMAN
#load rom0:MCSERV

I will just briefly explain what all the modules are for. the SIO2MAN is SIO2 manager. SIO2 is the hardware interface for joypads, multitaps and memory cards, it's named "2" since it's the second version, as the PSOne also had SIO (same thing with SPU2). In the ps2sdk there is a XSIO2MAN compatible module called sio2log made by Marcus R. Brown, this module logs the activity in the module to a file on the host. The SIO2MAN module must be loaded before MCMAN, MCSERV, PADMAN and MTAPMAN (there is no such module, but there is a XMTAPMAN, see below)

The MCMAN is the memorycard mananger. But in order to be able to use it from the EE you need to have a RPC interface setup. For some reason this interface is in a seperate module called MCSERV - memory card server. This is simply a design choice. Other modules such as PADMAN have RPC code included in the IOP module, there really isn't much consistency in how the IOP modules in the BIOS are made :-)

When the first PS2 models came out in Japan, the BIOS only included SIO2MAN, MCMAN, etc. and none of the X-modules. It didn't include have LIBSD either, which is why there is a free replacement (freesd.irx) in the ps2sdk. When the PS2 was launched in Europe and the US, some of the original modules were updated and they renamed with an X in front of them, eg. XSIO2MAN. But the BIOS still includes the old modules, to be compatible.

The reason people use the X modules is mainly because of the added XMTAPMAN, which is a module for supporting multitaps, which wasn't included in the original BIOS. There might also be a few new features added in the X modules, but one of the main reasons to use them would be to include multitap suppport.

The X and regular modules are not compatible if there is a dependency, for instance XMCMAN depends XSIO2MAN and would not work with SIO2MAN. IOP modules export functions in a export table with a version number and other IOP modules import these function with an import table, which also includes a version number. If these numbers do not match, the modules are incompatible. However you may use the regular CDVDMAN (which is already loaded if you boot from a CD/DVD) and the X modules for memory card, joypad and multitap together, since they do not depend on each other.

radad wrote:Seems like there is some incompatibility with the memory card modules and your memory card. These modules are loaded off of rom0. I do use the 'x' modules, maybe that is the issue.

That is indeed the issue.

Your code seems dependent on no conflicting modules being present in the IOP at launch time. When I successfully tested radshell I was using either PS2Link which leaves no MC/Pad related modules loaded in launching an ELF, or one of the recent uLE betas, which itself uses X-modules. Thus none of those tests could cause any module conflict.

But when I repeated the same test with an older uLE version I did get the same freezing error that ptek reported, and for such tests that error repeats consistently. This problem has nothing to do with the MC type as I get the same symptom both for 32MB Datel cards and 8MB Sony originals.

The proper way to cure this problem is to perform an IOP reset early in the program initialization, so as to 'throw out' incompatible modules and load the ones you want, but the drawback of doing that unconditionally is that it makes PS2Link feedback impossible. So a better way to do it is to make routines that can test what modules are active at launch and check for incompatibility to the ones needed, and then perform IOP reset only if a conflict is detected. (Which also implies that PS2Link is not being used.)

If you want some working examples of such code you can check out the current uLE beta v4.12g over at PS2-scene, but it's a litlle messy, so perhaps you're better off writing your own.

For uLE we're currently considering going back to normal modules again, as the X-modules brought more problems than solutions. The only really nice thing about them was the ability to rename files on MC, but getting that at cost of MC file timestamp control, as well as tons of compatibility problems, was definitely not worth it IMO.

Best regards: dlanor

radshell executes the script radshell.rsh found in the same directory as the elf. In that script it performs an 'iopreset' and then reloads all needed modules. When I run it under PS2Link I comment out the 'iopreset' line. So I dont understand how an older uLE would have different results unless you didnt copy the startup script aswell.

One of the reasons I created radshell was to get feedback on what works and what doesnt by allowing non-programmers to test things like this.

I was under the impression that the x modules had more bugs fixed. What was the issue with "MC file timestamp control"?

radad wrote:radshell executes the script radshell.rsh found in the same directory as the elf. In that script it performs an 'iopreset' and then reloads all needed modules. When I run it under PS2Link I comment out the 'iopreset' line. So I dont understand how an older uLE would have different results unless you didnt copy the startup script aswell.

I originally unpacked the entire ZIP into a folder of its own, transferred that to my main MC, and used uLE to add a valid PS2 icon.sys setup to the folder. Then I copied that entire folder to a secondary MC which I used for the test with the older uLE version. So all tests used a complete file set.

But it's still not very hard to understand why the problem occurred, becuse the radshell.rsh that you put in the release ZIP is the one which has the "iopreset" commented out, so that line says "#iopreset". After using the uLE text editor to remove that '#' character the program does work fine with the old versions of uLE as well.

I was under the impression that the x modules had more bugs fixed.

If their purpose was just to fix bugs, then they should have replaced the standard modules entirely, which is not the case.

What was the issue with "MC file timestamp control"?

Each directory entry for a file or folder on a PS2 MC has a struct named mcTable, which contains the file's creation and modification timestamps, file size, PS2-specific attributes, file name, and some other stuff (partly undocumented). You'll find the declaration of this struct in libmc.h of PS2SDK, and most likely you have already had some contact with mcTable structs in your work on radshell too.

The mcTable struct of a directory entry can be modified by the function mcSetFileInfo (also declared in libmc.h), which despite its name is equally valid to use for a folder as for a file. One of its parameters is a pointer to an mcTable struct which will be used to replace the one that file/folder used previously. (Except that it doesn't affect ALL entries in the struct, which is the reason we can't rename files this way with standard modules, though we can do it with X-modules.)

uLE uses mcSetFileInfo after copying stuff from one MC to another, or after restoring PSU backups to MC, so as to ensure that each copied or restored object gets an identical mcTable as the original.

But with X-modules that does not work right, as they ignore the timestamp fields, and create new timestamps every time. This makes it impossible to restore a backup to exactly the same state the original had.

Best regards: dlanor

I meant to uncomment the iopreset for the release. Must have missed that. That explains your results dlanor.

ptek: For the tests I mentioned above about using the x versus non-x modules make sure the iopreset is uncommented as well.

New Version: RadShell 0.3
Changed the copy functionality:
- 'copyfile' to copy files to a different name
- 'copydir' to copy dirs to a different name
- 'copy' to copy files and dirs (also can use patterns) to a directory
Added ability to change the 'border' ie text offset
Updated to latest ps2sdk.

About the testing i'll try as soon as possible, although I cannot say when... I already asked to borrow an usb keyboard from the office two times :S
Eventually I'll buy one but I wasn't thinking of it now - radshell will be more use to me when i'll have a HD installed. First I need a network adapter to the PS2 (i'm homebrewingto into an USB pen drive ;) )

But i'll not forget this and maybe next week i'll get the usb keyboard again.

BTW : If someone knows a trustable online shop in Europe that sells a network adapter for the PS2 (i have the fat model SCPH-39004) please PM me - i'll google for some but it's also good to have any recommended also. thanks)

ptek wrote:About the testing i'll try as soon as possible, although I cannot say when... I already asked to borrow an usb keyboard from the office two times :S
Eventually I'll buy one but I wasn't thinking of it now - radshell will be more use to me when i'll have a HD installed. First I need a network adapter to the PS2 (i'm homebrewingto into an USB pen drive ;) )

Perhaps it will raise your motivation to buy one if I tell you that radshell is not the only program where you can make good use of a USB keyboard.

uLE also accepts USB keyboard input for all cases where you are supposed to enter text strings, which includes all file/folder naming needs in the FileBrowser and of course all text entry in the TextEditor of uLE. In fact you can also use the keyboard instead of a gamepad for all menu navigation in uLE (or use both in parallel even).

One of the few commercial programs which accepts input from a USB keyboard is CodeBreaker (at least in v9.2 and v9.3).

PS2 Linux is another obvious case, but for most users that's not an option since it demands a Sony HDD (or modchip 'fakery').

There are a few other programs around too which can use a USB keyboard, though the ones above are the only ones where I've found it really useful myself (in addition to radshell of course).

Best regards: dlanor

uLE also accepts USB keyboard input for all cases where you are supposed to enter text strings, which includes all file/folder naming needs in the FileBrowser and of course all text entry in the TextEditor of uLE. In fact you can also use the keyboard instead of a gamepad for all menu navigation in uLE (or use both in parallel even).

Thanks. In fact I didn't knew it about the uLE... And it would be great if the Linux mentioned on the thread "Linux 2.6 on PS2" become a reality!

dlanor wrote: PS2 Linux is another obvious case, but for most users that's not an option since it demands a Sony HDD (or modchip 'fakery').

PS2 Linux only requires a compatible HDD, not a Sony one. I've run PS2 Linux on a Western Digital Caviar and a Maxtor Diamond without a problem. If you meant it requires the ethernet/harddrive adapter that only works with the fat PS2, then you're correct in that respect. Beyond that, any drive that fits the connectors will do. I also don't use the Sony VGA cable (I've got the Blaze VGA cable instead).

J.F. wrote:

dlanor wrote: PS2 Linux is another obvious case, but for most users that's not an option since it demands a Sony HDD (or modchip 'fakery').

PS2 Linux only requires a compatible HDD, not a Sony one. I've run PS2 Linux on a Western Digital Caviar and a Maxtor Diamond without a problem.

Ooops! Sorry about that piece of misinformation. I believed it to be dependent on the Sony HDD, and so I only tried it with ATAD-patching active, thus never finding out that it would have worked even without that.

If you meant it requires the ethernet/harddrive adapter that only works with the fat PS2, then you're correct in that respect.

No. I really thought PS2 Linux was dependent on the HDD either being the one intended for PS2, or being made to appear so (by ATAD-patching). But I'm glad to find out that it isn't quite so limited.

Beyond that, any drive that fits the connectors will do. I also don't use the Sony VGA cable (I've got the Blaze VGA cable instead).

Well, it stands to reason that any cable which connects the proper signals should work. As far as I know Sony never devised any special method to identify an original cable, like they did to identify the HDD.

Btw: I feel we've gone a bit off-topic here, so let's try to get back to the subject of radshell now...

Best regards: dlanor

Just noticed in my investigations that MCMAN doesnt fail when trying to open a directory that doesnt exist where XMCMAN does.

Some functions in RadShell currently depend on this behaviour.

(I'm just writing to say I didn't forget the mc0 thing test ... I just didn't had the opportunity to grab the usb keyboard again)

New Version: RadShell 0.4
Added 'devlist'
Added 'sync'
Added 'stat'
Added 'x' versions of some functions
Sort directory output
Fixed up 'copy' semantics

New Version: RadShell 0.5
Added 'poweroff' - just make sure the poweroff.irx is loaded before hand.

Also included in this release is romdir.irx. It is completely independent of RadShell but complementary.

romdir.irx provides directory browsing and subdirectory file access for the 'rom' filesytem. ie try 'dir rom0:' in RadShell. A more powerful example would be to try 'copy rom0:/* pfs0:/rom0'.