ps2 linux on usb memory

[deba5er]

@ Mega Man

Thanks for the auto-patch in kernelloader, that will make a big difference for regular users with the RTE with the next release of kloader.elf. My SMB version is mostly stable at this point (hangs during dselect installs), and I am in the process of uploading a fixed SMB version to ps2.nuclearfall.com now (slow, will be done in an hour) along with a new smb_init.

[ragnarok2040]

I wonder why all these modules didn't use dmacman? But maybe it's bugged in newer ps2's as well...

You can try importing dmacman's dmac_get_dpcr2() and see if it returns 0 as well.

[noiseand]

O papel do sbios é gerenciar o hardware do ps2, assim como nos computadores?

Então, na verdade, os módulos estão correto, mas precisamos que a Sony lance um sbios novo, se é que já não existe.

Engraçado, estive testando o "Netfront Browser" e o som funcionou normamlmente, mesmo com mouse e teclados usb conectados ao slim.

O que quero fazer na verdade é usar o ps2 como central multimédia, para poder assistir ao Youtube e afins e vídéos já baixados.

Alguma experiência em como reproduzir MPEG4 (H264) no linux do ps2?

[dlanor]

I wonder why all these modules didn't use dmacman? But maybe it's bugged in newer ps2's as well...

You can try importing dmacman's dmac_get_dpcr2() and see if it returns 0 as well.

Hmmm. Actually the fact that this function is NOT bugged might be the reason why no games have been reported to have any problems of this kind. All games do use sound, and a whole lot of them also allow USB devices (Eye-Toy and special controllers etc), so if the problem applied to all software I would have expected many games and normal homebrews to be likewise affected, and this is just not the case.

I'm not well familiar with 'dmacman' myself (and currently the computer holding my PS2Dev setup is crashed...), but if that "dpcr2" acronym stands for the same register Mega Man was speaking of, then a generic solution like I suggested already exists. And commercial games developed in accordance with Sony recommendations would use that solution automatically. And if we also have it properly implemented in the homebrew libs (which I can't check myself right now) this also explains why we never saw this problem in normal homebrews, where we also have lots of programs that combine the use of sound with the use of USB, all of which work fine on newer PSTwo consoles (SMS, other media players, most emulators).

The only problem then seems to be that the current implementations of PS2Linux stuff and some other things (like CodeBreaker) apparently ignore the existence of that dmac_get_dpcr2() function. This then is what has led to these bugs, as those programs instead access the register directly, which inevitably fails for read access on the newer consoles.

Best regards: dlanor

[deba5er]

@noiseand

The role of sbios is to manage the hardware of the PS2, as well as in computers?

So, in fact, the modules are correct, but we need Sony launches a new
sbios, if it no longer exists.

Funny, I was testing the Netfront Browser "and the sound worked normamlmente, even with usb mouse and keyboard connected to the slim.

What I do is actually use the ps2 as a multimedia powerhouse, to be able to watch Youtube and related videos already downloaded.

Some experience in how to play MPEG4 (H264) in linux ps2?

I don't know the exact technical answer to your sbios question. Sony created the PS2-Linux Kit only for FAT PS2 consoles. As hardware changed, the PS2-Kernel modules were NOT updated, unlike (I believe) Netfront Browser, which I assume was made to work on the Slim PSTwo also?

As for MPEG4 (H264), it plays too slowly using my current compiled version of mplayer (-vo x11 or -vo sdl) to be useable. Sorry, it takes up too much CPU. None of the video outputs seem to be able to take advantage of the PS2's great graphics capabilities. It plays regular .flv youtube videos ok though.
-----------
Eu não sei a resposta exata técnicas para a sua pergunta sbios. A Sony criou o PS2-Linux Kit apenas para consoles PS2 FAT. Como o hardware alterado, o PS2-módulos do Kernel não foram atualizados, ao contrário de (creio) NetFront Browser, que eu assumo foi feito para trabalhar no PSTwo Slim também?

Como para MPEG4 (H264), ele joga muito lentamente usando a minha atual versão compilada do mplayer (-vo-vo x11 ou SDL), a ser utilizável. Desculpe, ele ocupa CPU demais. Nenhuma das saídas de vídeo parece ser capaz de tirar partido das excelentes capacidades de gráficos do PS2. Ela desempenha regular. Flv videos youtube ok though.

[ragnarok2040]

I took some time and went through all the modules in ps2sdk. The usbd, ahx, and freesd modules seem to be the only modules that use the pcr2 register directly. The ps2dev9 module uses dmacman, though.

Here's the list of the bit settings for pcr2 that are in ps2sdk:
1 << 27, 0x08000000 is usb ohci channel used in usbd
1 << 3, 0x00000008 is spu(spu2?) channel
1 << 7, 0x00000080 is dev9 channel used in ps2dev9

[noiseand]

@noiseand

The role of sbios is to manage the hardware of the PS2, as well as in computers?

So, in fact, the modules are correct, but we need Sony launches a new
sbios, if it no longer exists.

Funny, I was testing the Netfront Browser "and the sound worked normamlmente, even with usb mouse and keyboard connected to the slim.

What I do is actually use the ps2 as a multimedia powerhouse, to be able to watch Youtube and related videos already downloaded.

Some experience in how to play MPEG4 (H264) in linux ps2?

I don't know the exact technical answer to your sbios question. Sony created the PS2-Linux Kit only for FAT PS2 consoles. As hardware changed, the PS2-Kernel modules were NOT updated, unlike (I believe) Netfront Browser, which I assume was made to work on the Slim PSTwo also?

As for MPEG4 (H264), it plays too slowly using my current compiled version of mplayer (-vo x11 or -vo sdl) to be useable. Sorry, it takes up too much CPU. None of the video outputs seem to be able to take advantage of the PS2's great graphics capabilities. It plays regular .flv youtube videos ok though.
-----------
Eu não sei a resposta exata técnicas para a sua pergunta sbios. A Sony criou o PS2-Linux Kit apenas para consoles PS2 FAT. Como o hardware alterado, o PS2-módulos do Kernel não foram atualizados, ao contrário de (creio) NetFront Browser, que eu assumo foi feito para trabalhar no PSTwo Slim também?

Como para MPEG4 (H264), ele joga muito lentamente usando a minha atual versão compilada do mplayer (-vo-vo x11 ou SDL), a ser utilizável. Desculpe, ele ocupa CPU demais. Nenhuma das saídas de vídeo parece ser capaz de tirar partido das excelentes capacidades de gráficos do PS2. Ela desempenha regular. Flv videos youtube ok though.

Mesmo com o sbios feito para o fat, sem ele não consigo subir o linux no slim.

Não sei se o Netfront foi feito para slim, ele foi desenvolvido em 2001 e esta em japonês. Reconhece normalmente rede, som e usb.

Estou vasculhando alguns sources de homebrews e o segredo esta em usar uma versão do audsrv de 2005, a "0.75" ao invés do sjpcm.

[dlanor]

I took some time and went through all the modules in ps2sdk. The usbd, ahx, and freesd modules seem to be the only modules that use the pcr2 register directly. The ps2dev9 module uses dmacman, though.

Here's the list of the bit settings for pcr2 that are in ps2sdk:
1 << 27, 0x08000000 is usb ohci channel used in usbd
1 << 3, 0x00000008 is spu(spu2?) channel
1 << 7, 0x00000080 is dev9 channel used in ps2dev9

All of those modules really should have used the dmacman call, and if only one of them does then I am quite perplexed as to why we don't see any conflicts at all in normal homebrew using these features.

There are plenty of emulators around using both HDD, USB, and sound, but none of these suffer any loss of functionality of any of those parts when one of the other parts initializes. This only happens with the PS2Linux stuff.

But if that register truly is write-only on the new consoles, under all conditions, then all software that relies on its readability should suffer the same problems. So why then do all normal homebrews seem completely immune to these problems ?

Is it possible that the write-only state is somehow conditional ?
Could it be a side-effect of some address-space mapping unique to the PS2Linux kernel ?

I'm just guessing wildly here, but we really need to understand why these problems do NOT occur in normal homebrews, even though they too seem to use direct register access (given those PS2SDK modules).

Best regards: dlanor

[ragnarok2040]

I think it's more or less just coincidence.

In order to activate the bug for homebrew:

• You need a newer pstwo.
  
  dev9 enabled prior to enabling usb/spu2 will cause only the last dma channel enabled to work.
  
  usb or spu2 enabled prior to dev9, should cause only the last two enabled channels to work.*

For uLe, which loads modules on an as-needed basis, the bug would rarely show up. You'd have to load the ps2dev9 module prior to the usb module and then use 'host:' again, after enabling the usb channel. I think that's probably the only way to enable the bug on uLe on a newer pstwo.*

For SMS, I think it uses libsd from the bios, same for FCEUltra. I'm not sure if libsd in the bios has the same problem as libsd.irx, but problems with FCEUltra were reported about freezing/crashing when saving/loading files. I tried to debug it as best I could, even going through a couple of rewrites of the file loading code, thinking I had a pointer problem somewhere.

• *I'm not sure, because dmacman hasn't been tested yet to see if the bug is present in it, or if it works around it.

[noiseand]

I took some time and went through all the modules in ps2sdk. The usbd, ahx, and freesd modules seem to be the only modules that use the pcr2 register directly. The ps2dev9 module uses dmacman, though.

Here's the list of the bit settings for pcr2 that are in ps2sdk:
1 << 27, 0x08000000 is usb ohci channel used in usbd
1 << 3, 0x00000008 is spu(spu2?) channel
1 << 7, 0x00000080 is dev9 channel used in ps2dev9

All of those modules really should have used the dmacman call, and if only one of them does then I am quite perplexed as to why we don't see any conflicts at all in normal homebrew using these features.

There are plenty of emulators around using both HDD, USB, and sound, but none of these suffer any loss of functionality of any of those parts when one of the other parts initializes. This only happens with the PS2Linux stuff.

But if that register truly is write-only on the new consoles, under all conditions, then all software that relies on its readability should suffer the same problems. So why then do all normal homebrews seem completely immune to these problems ?

Is it possible that the write-only state is somehow conditional ?
Could it be a side-effect of some address-space mapping unique to the PS2Linux kernel ?

I'm just guessing wildly here, but we really need to understand why these problems do NOT occur in normal homebrews, even though they too seem to use direct register access (given those PS2SDK modules).

Best regards: dlanor

É muito estranho mesmo a facilidade em que os homebrews usam os módulos sem degradação de performance, mesmo que seja um emulador de atari e nes.

Se não me engano, até o luaplayer permite acesso ao som, usb, memcard, cdrom, menos hd.

Você ja chegaram a avaliar algum source do sms, etc?

[dlanor]

I took some time and went through all the modules in ps2sdk. The usbd, ahx, and freesd modules seem to be the only modules that use the pcr2 register directly. The ps2dev9 module uses dmacman, though.

Here's the list of the bit settings for pcr2 that are in ps2sdk:
1 << 27, 0x08000000 is usb ohci channel used in usbd
1 << 3, 0x00000008 is spu(spu2?) channel
1 << 7, 0x00000080 is dev9 channel used in ps2dev9

All of those modules really should have used the dmacman call, and if only one of them does then I am quite perplexed as to why we don't see any conflicts at all in normal homebrew using these features.

There are plenty of emulators around using both HDD, USB, and sound, but none of these suffer any loss of functionality of any of those parts when one of the other parts initializes. This only happens with the PS2Linux stuff.

But if that register truly is write-only on the new consoles, under all conditions, then all software that relies on its readability should suffer the same problems. So why then do all normal homebrews seem completely immune to these problems ?

Is it possible that the write-only state is somehow conditional ?
Could it be a side-effect of some address-space mapping unique to the PS2Linux kernel ?

I'm just guessing wildly here, but we really need to understand why these problems do NOT occur in normal homebrews, even though they too seem to use direct register access (given those PS2SDK modules).

Best regards: dlanor

É muito estranho mesmo a facilidade em que os homebrews usam os módulos sem degradação de performance, mesmo que seja um emulador de atari e nes.

Se não me engano, até o luaplayer permite acesso ao som, usb, memcard, cdrom, menos hd.

Você ja chegaram a avaliar algum source do sms, etc?

I have no idea what you are saying here.

If you want to discuss anything with me then you will have to use some language I can understand (English, Deutsch, Svenska, Norsk, Dansk).

Best regards: dlanor

[dlanor]

I think it's more or less just coincidence.

In order to activate the bug for homebrew:

• You need a newer pstwo.
  
  dev9 enabled prior to enabling usb/spu2 will cause only the last dma channel enabled to work.
  
  usb or spu2 enabled prior to dev9, should cause only the last two enabled channels to work.

I can't fully agree with this order reasoning. Even if the modules using dmacman are thereby able to read a 'shadow' copy of the register, that does not make them immune to the problem. Such immunity only works if all writes to the real register are also copied to the shadow variable, which will not be the case when other modules access the register directly, as that will not be reflected in the shadow variable.

But naturally the Dev9 driver will normally be loaded prior to any other modules that depend on it, like HDD and networking stuff. So when either HDD or networking is mandatorily used then Dev9 is likely to be loaded early on.

*[/list]For uLe, which loads modules on an as-needed basis, the bug would rarely show up. You'd have to load the ps2dev9 module prior to the usb module and then use 'host:' again, after enabling the usb channel. I think that's probably the only way to enable the bug on uLe on a newer pstwo.*

I agree with part of the principle behind your reasoning, but it doesn't hold water in practical testing. I just now made another test of this, as follows:

1: Started PSClientLoader on my current PC
2: Booted my slim v15 PSTwo into FMCB, auto-launching uLE (with IOP reset active in uLE)
3: Opened uLE FileBrowser and browsed to host: twice (once to open server, then again to see content), which worked perfectly, showing me the contents of the PC, where I inspected one of the drives available.
4: Backed FileBrowser to root and browsed to mass: instead, inspecting some folders on the USB drive
5: Backed FileBrowser to root again and browsed into host: yet again, this time inspecting some other PC drives than before

I repeated this test twice with new PS2 power-on for each test, to rule out any 'fluke' results, and it worked perfectly each time. So the fact remains like I've said earlier:

This bug simply does not exist for homebrews like uLE !!!

I have also done similar operations many times before, outside of formal testing, and it always works fine, so it was not just specific to the particular operations made in these two tests.

For SMS, I think it uses libsd from the bios, same for FCEUltra. I'm not sure if libsd in the bios has the same problem as libsd.irx,

If that bios module is used, then we have to leave that out of our discussion, since we have no disassembly info available on it. But SMS also uses both USB and networking, and I often use both myself, without any problems. But since SMS is a closed-source project we can't say anything for sure about why it works. EEUG might even have some code of his own which writes a value to that register after all the normal module initialization has been done. We have no way of telling what it does in that regard.

but problems with FCEUltra were reported about freezing/crashing when saving/loading files.

Really ? I don't have such problems with it.

Your v0.92r2 works fine for me, and it is only the notorious v0.93 that is thoroughly bugged. I guess we all have a bad day now and then, and that v0.93 was clearly made on one of yours... :(

I tried to debug it as best I could, even going through a couple of rewrites of the file loading code, thinking I had a pointer problem somewhere.

If you are still talking about FCEU v0.93 here, let us please deal with that elsewhere, as its definite bugs have little to do with the current discussion. Your FCEU v0.92r2 works fine with USB and has no problems with simultaneous use of sound and USB access. I have used it so quite a lot on my v15 PSTwo, where I have no problem playing a ROM from USB with sound, and then exiting from that game to choose another ROM from USB and play that as well with perfect results.

• *I'm not sure, because dmacman hasn't been tested yet to see if the bug is present in it, or if it works around it.

We definitely need to inspect that code to see how it works, and if other modules can have their 'direct register reads' replaced by using that module function instead (if that really is needed/helpful).

But most of all we need a thorough investigation into why this problem seems non-existent for normal homebrew use. Personally I am leaning more and more towards suspecting some erroneous system remapping unique to the PS2Linux usage.

Who knows ? It might even be some Sony design change in how the address space remapping for the EE-processor is supposed to work for the EE chips used in newer consoles, such that some remapping done by the PS2Linux kernel now accidentally makes some register address range write_only. This would explain why normal games and homebrews seem completely unaffected since they never do any system remapping of their own.

Something to consider/test:
Did Mega Man (or anyone else) really test if that register truly is write_only when accessed from normal homebrew software using normal PS2SDK only (no PS2Linux stuff at all). If not, then this should be tested ASAP. I would do it myself if it were not for my PS2Dev PC still being crashed... :(

Best regards: dlanor

[noiseand]

All of those modules really should have used the dmacman call, and if only one of them does then I am quite perplexed as to why we don't see any conflicts at all in normal homebrew using these features.

There are plenty of emulators around using both HDD, USB, and sound, but none of these suffer any loss of functionality of any of those parts when one of the other parts initializes. This only happens with the PS2Linux stuff.

But if that register truly is write-only on the new consoles, under all conditions, then all software that relies on its readability should suffer the same problems. So why then do all normal homebrews seem completely immune to these problems ?

Is it possible that the write-only state is somehow conditional ?
Could it be a side-effect of some address-space mapping unique to the PS2Linux kernel ?

I'm just guessing wildly here, but we really need to understand why these problems do NOT occur in normal homebrews, even though they too seem to use direct register access (given those PS2SDK modules).

Best regards: dlanor

É muito estranho mesmo a facilidade em que os homebrews usam os módulos sem degradação de performance, mesmo que seja um emulador de atari e nes.

Se não me engano, até o luaplayer permite acesso ao som, usb, memcard, cdrom, menos hd.

Você ja chegaram a avaliar algum source do sms, etc?

I have no idea what you are saying here.

If you want to discuss anything with me then you will have to use some language I can understand (English, Deutsch, Svenska, Norsk, Dansk).

Best regards: dlanor

ok, sorry.

[ragnarok2040]

I see. Then it seems that this bug is being inconsistent, heh. The reason 0.93 is so buggy was because I was trying to workaround a bug that I never experienced, but trying to work around it just kind of broke it, heh, and that's the last I'll mention it, since that version was discontinued. I'm making a fresh port after I've finished my changes to ps2sdk.

Mega Man:
I checked kernelloader's code, and it doesn't look all that different from what other homebrew does, when loading modules. I noticed that you set 0xBF801570 from the EE side, rather than the IOP side for enabling the usb host controller's dma channel. This seems to be the only difference that I can see between normal homebrew and kernelloader. Perhaps using 0x1F801570 from the EE side would work better, if the uncached version isn't working for some reason.

[ialongiya]

Why do I find Linux so appealing and so difficult to migrate to? I've had a partition with a linux distro on about every computer I've owned. I will install the OS, do the updates, run into some compatibility issues and not bother any longer. How can I solve this?
_________________
market samurai ~ marketsamurai ~ marketsamurai.com

[dlanor]

Why do I find Linux so appealing and so difficult to migrate to? I've had a partition with a linux distro on about every computer I've owned. I will install the OS, do the updates, run into some compatibility issues and not bother any longer. How can I solve this?

That question is something you will have to pursue elsewhere, as it has nothing to do with PS2 development, which is the only purpose of this forum. Thus all topics valid on this site should be related to PS2 development of some kind. All other topics (except for some on site maintenance) are better dealt with in other forums.

Best regards: dlanor

[KadettGTE]

Hi all, i managed to port openwrt.org's distro to the ps2 , booting from usb with a custom kernel and custom initrd, if any of you wants to give it a try, let me know :D

[deba5er]

I'm interested in this port. Any links?

[KadettGTE]

working on them at the moment, and i'm recompiling the kernel to remove debug messages since it's already stable

[KadettGTE]

ok here's a small tutorial

:) okay, i'm going to try and simplify the procedure as well as i can:

requirement : Ps2 FAT (only tested on this one) or a slim (might work with a modchip) with a modchip (tested with matrix infinity) or swap magic/cogswap (might work, since my ps2's modded and i have no swap cd)
At least a 128MB USB Pen Drive and if it's a FAT ps2, also the network controller (that big black thing that fits behind the console)
uLaunchELF (i use 4.40)
and of course some knowledge about running homebrew on the ps2

1st: if you already have ulaunchelf you can ignore this part:

download ulaunchelf iso http://www.4shared.com/file/182092830/5 ... D_ISO.html and burn it to a DVD
download ulaunchelf boot.elf http://www.4shared.com/file/182092888/e ... /BOOT.html and copy it to a usb drive (don't use the same pen drive since the wrt one is going to be repartitioned and stuff)

2nd: download the rest of the files
download kernelloader http://www.4shared.com/file/182086923/3 ... der20.html
download kernelloader config file http://www.4shared.com/file/182107912/2 ... onfig.html

download initrd.gz http://www.4shared.com/file/182093949/8 ... nitrd.html
download kernel modules http://www.4shared.com/file/182108030/a ... dules.html
download ROOTFS http://www.4shared.com/file/182108031/d ... OOTFS.html
download the kernel http://www.4shared.com/file/182107489/6 ... linuz.html

copy ulaunchelf boot.elf , kloader20.elf, config.txt (kernelloader config) to a pen drive

3rd: bootup ulaunchelf either using the dvd or your previously installed ulaunchelf, i won't make an explanation on how to use it because it would take too long, but it's quite intuitive (you can use a usb keyboard)
insert the pen you previously created , go to filebrowser, mc0:/, create a folder named BOOT (CASE SENSITIVE), and copy BOOT.ELF and kloader20.elf there
create a folder named kloader and copy config.txt there (the if you can't find the files on launchelf they're probably on mass0:/ or mass1:/)

you can now turn off the ps2, the memory card should be ready.

4th: now get another pen drive (or just repartion that one), erase ALL partitions on it and set it like this:
1st partition primary with only 15MB , with FAT Filesystem
2nd partition primary with AT LEAST 50MB, ext2 filesystem (be sure to format it using 128 inodes e.g: mke2fs -I 128 /dev/sdX2)
3rd partition primary with AT LEAST 64MB (i'd recommend 300MB for php and stuff) for Swapping

5th: black magic :D
copy vmlinuz and initrd.gz to the first partition
untar ROOTFS.tar to the second partition

unmount pen drive

6th: Try it
plug in a usb keyboard to the PS2
plugin the newly created Pen to the PS2
Boot up launchelf
go to filebrowser mc0:/BOOT/ select kloader20.elf and boot it
inside the kloader i've set it up to autoboot, but feel free to look around, when u're ready go to boot using this configuration and cross your fingers

7th: Post results :)

as for the buildroot i'm going to try and make a patch file to add that platform to 8.09

my buildroot configs for building are here :

openwrt config: http://www.4shared.com/file/182115072/e ... onfig.html
uclibc config: http://www.4shared.com/file/182115813/c ... onfig.html
busybox config: http://www.4shared.com/file/182115784/8 ... sybox.html
base-files package: http://www.4shared.com/file/182115952/d ... files.html

P.S: DO NOT OPKG INStaLL FROM THE OFFICIAL REPOSITORYS, packages WON'T RUN, and don't istall kernel modules

i'll try to set up a repository with all the packages that build later

[KadettGTE]

here's are all the built binaries

http://www.4shared.com/file/182474519/4 ... kages.html

(sources are the same as openwrt so i don't need to post them , just go to openwrt.org and do a svn co on 8.09)

[GENERiC]

It's possible to run BBNAV on slim PS2 from USB? The BBNAV is build on Linux so it maybe run with Kloader. Thanks in advance & sorry for my bad english.

[KadettGTE]

i don't have a slim to test... but , try it

[noiseand]

O BBNAV, embora praticamente um linux, não funciona no slim.

Não há como subir o linux no slim a não seja com estes arquivos: "http://sourceforge.net/projects/kernelloader/files/".

-------------------

The BBNAV, even so practically one linux, does not function in slim.

It does not have as to go up linux in slim it is not with these archives: " http://sourceforge.net/projects/kernelloader/files/".

[noiseand]

Estou com o ps2sdk instalado em meu computador, como posso compilar o kloader1.9 para tentar reconhecer a placa de som em meu slim?

--------------------------

I am with ps2sdk installed in my computer, as I can compile kloader1.9 to try to recognize the plate of sound in mine slim?

[KadettGTE]

you don't need to compile kernelloader 1.9 or 2.0, what you may need is to build the kernel 2.4.17 with that support, but try my tutorial and see if it works, thought it has no sound support nor X

nao precisas de compilar o kernelloader, isso é só um bootloader nada mais, talvez tenhas é de alterar algumas configuraçoes la dentro para a slim que axo que estao no readme, se calhar o que precisas mesmo é de recompilar o kernel 2.4.17 e configuralo para tal, axo que no meu post esta la a minha configuraçao de kernel, mas de qualquer maneira olha, tens de instalar o redhat Shrike (numa maquina virtual ou algo do genero) e compilar a partir daí, eu segui este link
http://playstation2-linux.com/download/ ... howto.html

[deba5er]

@noiseand

If you look at Mega Man's post in this thread from Nov. 21, you will see sound working on the Slim PSTwo with a patched RTE LIBSD.IRX. I have this working on my version 15 Slim PSTwo now. Sorry if you know this already and your post was that you are trying to make it work without the patched RTE module. That would be excellent for all people who don't have the RTE.

@KadettGTE

Sorry I haven't checked out your distro yet - it is downloaded and I should get a chance by this weekend...

[noiseand]

Tenho os dvd´s do RTE, mas creio que não servem para o slim.

Aonde consigo esta nova versão do LIBSD.IRX?

Não encontrei o post do Mega Man de 21 de novembro.

--------------------

I have dvd´s of the RTE, but I believe that they do not serve for slim.

Where I obtain this new version of the LIBSD.IRX?

I did not find post of the Mega Man of 21 of November.

[noiseand]

Encontrei o patch do LIBSD.IRX e o post do Mega Man, agora é aplicar e testar.

Obrigado a todos

------------

I found patch of the LIBSD.IRX and post of the Mega Man, now is to apply and to test.

Thanks for all

[noiseand]

Sim, penso em quem não tem os dvds do RTE e o módulo LIBSD.IRX para aplicar o patch, mas em compensação tenha este módulo de algum outro jogo e possa usar.

Preciso testar se isto funcionaria, se poderíamos aplicar no módulo alternativos.

Preciso confirmar, mas acredito que sem os módulos do RTE, ninguem conseguirá usar o linux no slim.

--------------------

Yes, I think about who does not have dvds of the RTE and module LIBSD.IRX to apply patch, but in compensation another game has this module of some and can use.

Necessary to test if this it would function, if we could apply in the module alternative.

Necessary to confirm, but I believe that without the modules of the RTE, nobody it will obtain to use linux in slim.