PSX play on PS2 USB

I have tested does not work with USB on PS2 5004 PAL ???? Folder USB FAT32/POPS/MYDUMP.BIN EXECUTE.ELF/disc/disc0 [EXECUTE.ELF ppf patched]
tested 10 games that work with HDD on USB returns to the PS2 Browser.
What I'm doing badly ??????

 

^ Please post the debug output by running it using ps2client.

It may be running out of memory for FAT32 formatted sticks. My own USB stick is FAT16 formatted.

 

The problem is FAT16 file system you cannot use a bigger than 2GB
I have Flash Drive 4GB
FAT or FAT32 not works..

 

Awesome patch! Works on my Ps2 Slim, model 79006! Tested Syphon Filter and Umihara Kawase Shun, (both Jap versions)!
The save funcion dont work in my tests... In game, you can save, but after reseting or turn off the ps2, the save don't exists.

Is possible in future, a Popstarter for USB?

Note:I never have a Ps2 FAT =(

 

Please what is the route of archives?.

 

I was under the impression we don't know enough about how the PS2 runs PS1 games to be able to switch modes. It certainly wouldn't surprise me if there was a way you could do it, even if it ends up a bit like nintendont/devolution where it searches for problematic code and patches it.

 

This is hardware emulation. There is nothing to modify in software, so it is not possible to intercept I/O to the CD/DVD hardware and to emulate the CD/DVD hardware and DMA channel interrupts.

The IOP is reset into 33MHz mode, and its bootstrap code takes a different branch to boot the PS1 boot monitor during its reboot.

The GPU emulation, on the other hand, is done in software with the EE. The GPU DMA channel is actually SIF2, so Sony had already designed this console with the idea of software GPU emulation in mind. This could mean that it might be possible to patch PS1DRV to use another video mode, like 480P. But that is about it.

 

So you run the IOP in normal and not PS1 backward compatibility mode, so you get access to all the hardware. Then patch the libraries where register access differs (like CD loading) & grab the GPU emulation from PS1DRV. That assumes that the DMA from the IOP to the EE works the same when not in emulation mode, I can't see why that would change though. The extra CPU speed might cause a problem to some games, I don't know if GTE works when running fast & you might struggle for RAM having the game and a USB stack running at the same time. So it's not a guaranteed solution, but it might possibly work.

That is the equivalent of nintendont/devolution, where it runs gamecube games in Wii mode but patches the disk loading, controller handling and some graphics differences.

 

Obviously, nobody has done this because it isn't easy.There is a reason why GSM was designed to hook onto writes going to the hardware registers: any program could write to them in any way they want. Therefore, scanning and patching the CD/DVD library is not going to work in all cases. The PlayStation BIOS will be unpatchable too (since it is in ROM), making anything that interfaces with the CD/DVD hardware that way dysfunctional.

You have already listed down the potential limitations here with this method, which is why writing up a full software emulator will be better on the long run.

I think that there is actually one more part to the problem with the higher clock rate of the IOP mode: the SPU will have a sampling frequency of 48KHz instead of 44.1KHz, making all your games sound really high-pitched.

 

All official games will be going through the official libraries and detecting those should be easy. The BIOS is easily patchable as it goes through a call in ram.
PSIO is doing their loader for the PS1 in the same way.

I might be wrong, but I thought the frequency could be switched independently from the mode. But as all games will go through the official libraries anyway, the periods can be adjusted to get the sound correct. Red book audio is a problem too, but you can probably get EE to convert it and then stream it through one of the extra SPU channels.

It'll be harder to write a decent emulator that runs on the EE. You don't have enough cpu power to get the timing right, speed problems that would affect running the IOP faster are going to happen just as much on a software emulator running on the EE.

 

wow, I had no idea that the PS1 gpu was emulated by the EE engine... I always thought they just had the silicon embedded in the EE and it got activated in PS1 mode.

 

You're probably talking about intercepting syscalls, before the CPU jumps from RAM to the BIOS's syscall handler. I'm talking about correcting the BIOS's behaviour, before it hands control over to the game. This is because a game is loaded by the BIOS. If the BIOS cannot load the game from the disc (whether this is emulated or not), there won't ever be a game running on the IOP.

Unless, I'm wrong about the entire BIOS running from ROM (meaning, its browser is like the PS2's OSDSYS, which is loaded into RAM before it gets executed). But even so, how is the system going to patch the game that the PlayStation browser loads? How would it know when it loads the game?

I don't know about how PSIO works internally, but it appears to be a device that is attached to the expansion connector of the PlayStation unit. Apparently, a LOT of things can be done with that port, even with replacing the boot ROM, accessing RAM, and accessing everything on the peripheral bus. This is something that cannot be done as conveniently in software.

The PlayStation 2 seems to have a similar connector, but it isn't accessible without disassembling the unit. This is the connector that modchips abuse too, but has seen official use in the SCPH-18000 GH-003.

Please feel free to prove me wrong. I never disassembled PS1DRV to the point where I can safely say that I know every step of the process that reboots the IOP into PS1 mode.

I believe that I am right because I remember seeing a post by mrbrown at ps2dev.org regarding the SPU2 and the clock rate. It's also because my Kisarazu SCPH-10000 unit was suffering from a problem with the EE clock generator going haywire, causing sounds to be played at low sample rates.

l_Oliveira was the one who told me (as well as writing here: http://www.assemblergames.com/forum...Graphic-Issues&p=711829&viewfull=1#post711829) that the EE's clock output is divided and fed to the IOP's peripherals from the IOP.

Then it has to go from the IOP to EE, and back to the IOP again. It's not easy. I used to come up with crazy ideas like you are doing now, but I've stopped doing that over the years because I learned what the hardware is only capable of, and how difficult it really is to create resident programs that hook onto running code. Since SIF2 is already in use, you need to either use both SIF 0 and 1 for bi-directional communication, or to hack up the SIF2 DMA channel handling code in PS1DRV to add such functionality.

I forgot to mention one more thing about adding more code to the IOP address space: since it's outside of the game's design, you need to ensure that the game will never overwrite it. This part will most likely not be easy because the IOP kernel region is very small and the remainder of the whole 2MB seems to be available for use by the game. For PS2 games, we are fortunate that there is some space within EE RAM that was conveniently designated to be used by the kernel for ELF loading, which all game loaders use. There are also (considerably large) regions that Sony had apparently reserved for storing patches.

Sony had done it. POPS for the PS2 exists and does a decent job. POPS for the PSP has certainly shown that it is doable because they have most likely used software emulation for even the peripherals, and the PSP's Allegrex MIPS (333MHz) is only slightly faster than the EE's R5900 (295MHz).

And unlike the PSP, the PS2 will only need to emulate the GPU, CD/DVD drive and (optionally) the memory card interfaces in software. The rest can be emulated with the hardware, by passing the data that was written by the program directly to the hardware.

 

Loading a playstation exe into memory is trivial. There is a header which includes a load and start address and the rest of the file just gets loaded into ram. Someone was writing an open source bios replacement if you need more.

You'd probably pretty much ditch the IOP kernel.

I'm not convinced anyone really knows what the hardware is capable of, we have no documentation and only disassembly of PS1DRV to go on.

It's actually a very poor emulator, but then even the hardware emulation on the PS2 needs per game patches due to timing issues. The GTE emulation in POPS is very inaccurate though, I don't know if that is due to unintentional bugs or them writing the code so it's fast rather than correct.

 

I was not saying that it is difficult to load a PlayStation executable. I was highlighting that it is difficult to determine when new code is loaded into the system.

Since what you're suggesting requires the CD/DVD library of every executable in the system to have been patched to access the USB interface instead, there must be a way to determine when new code has been loaded into the system, in order to know when and where to patch the newly-loaded code.

You're right to say that we do not know about every register that the IOP has. But we know that the IOP only has 2MB of EDO RAM. Since PlayStation games already know how much space there is for them, where are you going to stick the additional code? The code for USB support alone is not small.

If one was to try to move the sound data from the IOP to EE and back, there must be code that intercepts the sound data and sends it over the SIF. This code has to exist somewhere, and there must be some protocol that governs the transfers between the EE and IOP. Plus DMA must deal with buffers. There has to be a buffer for receiving the upsampled data from the EE, before sending the whole lot to the SPU.

Like I wrote, if you really know what you are talking about, do it and prove me wrong. I'm also here to learn. I'm just telling you what I've seen as a developer, so far.

If what you're suggesting was really better than making a software emulator, Sony should have done it instead. They have the specifications, the engineers and the development tools, all which we lack. They could have written a proper replacement for PS1DRV without even patching it. But something must have told them that a software emulator was the better option.

I know what you mean by "per game patches", but PS1DRV doesn't patch every single game out there. In fact, there are so many PlayStation games out there that the list of games that will be patched by PS1DRV is only a fraction of them.

 

If you're loading another exe using the BIOS then that is easy. If you're loading code yourself then I would imagine you'll be flushing the instruction cache afterwards.

According to this thread: https://code.google.com/p/pcsx2/issues/detail?id=449 you can access IOP ram/hw registers from EE, if that is true then the USB code could run on EE, with just the data read going into the IOP ram (you need to read the FAT and directory before starting the game so the EE would know where to load each sector from).

It might be the better option, but I wouldn't assume that just because of how they wrote POPS. You're giving them a lot more credit than they deserve. They can't even get GTE right on the PS3.

 

PSIO - is hardware emulator, it replaces cd-rom drive. no loaders, no replaced code in ps-exe.
...something like GD-EMU)))

 

I thought it sat on the external bus port using dma channel 5. If that isn't PSIO then someone is doing one like that.

GD-EMU is a lot easier because it's just an ATAPI (IDE) device, while replacing the CD drive on the PS1 without soldering would involve you pretending to be the laser. If you're prepared to replace a chip then it becomes easier again but not everyone can solder like that.

 

But the information on the PSIO website isn't inaccurate, is it? Is the PSIO device connected to only the expansion connector, and nothing else? If yes, then it means that my understanding of what the expansion connector provides is correct, meaning that it does offer access to the peripherals on the bus.

 

The expansion connector is one of the buses from the CPU, shared with the rom. You can configure what area of memory it is at, which can actually disable access to registers. So you could stop the CPU having access to the CD registers. But the expansion connector only has the DMA control lines for it's own channel, not for the CD channel. It has read and write strobes from the CPU, but nothing to suggest you can reverse the direction. It also cannot inject red book audio, but it does have it's own audio channel. So my understanding is you'd need to patch some SPU and DMA code at the very least.

no$ has done a lot of reverse engineering of this and nothing he has said has suggested that the SPU and DMA patching could be performed using the expansion port, once you've put the expansion port over a set of registers they appear to become unavailable. In the schematics, the data from the CD drive to the controller and SPU doesn't go anywhere near the expansion port.

While it's possibly that PSIO uses some previously unknown method, it is a project surrounded in mystery with a terrible reputation. Therefore I treat anything with scepticism.

 

all unknown things is mystery)))

actually we sent v1 of PSIO to RetroJunkie, he made some vids.

for PSIO you need solder 2 wire from cd-dsp to free pins of parallel port, in the case if we attach psio to Par port.