A ps2link suggestion.
A ps2link suggestion.
With all this fancy dump command stuff it occurs to me that a dumpvram command would be useful for screenshots of stuff. Sure, you'd have to know the resolution and depth of the framebuffer and fiddle with a bit to reconstruct a full frame from interlaced sources but the client could handle most of that given a raw dumpvram command.
How about a small library that the app links to instead? Just one or two calls that allow them to specify the height, width, format, etc. and they make the call to ps2link to dump it? I've been thinking it's about time to allow user apps to get a bit of control of ps2link. Anyway, you'd be able to get much more precise screenshots if you did it that way.
Let me expand on that idea a bit. I think it'd be useful to provide a syscall interface into ps2link, to provide a way for the running app to interact with the host directly through ps2link. There are some advantages to using syscalls as opposed to going straight through the IOP, using ps2ip or SIF file I/O:
- Provide a level of abstraction for host comms. If we have a syscalls for all of file I/O that doesn't explicitly require SIF RPC, we can do things like loading files over EE SIO, or use the unused SIF 2 DMA channel to communicate with the IOP.
- Provide debugging hooks. A big wish of mine would be to have a GDB stub integrated into ps2link.
- Exert control of ps2link itself. Anything from setting the comms "port", to telling ps2link to dump vram, or even having ps2link shutdown itself or reboot the PS2.
By syscalls I don't mean the ones we normally use in libkernel in ps2lib, but perhaps syscalls that use a different index (the MIPS syscall instruction relies on the syscall exception handler to decode an immediate value from the instruction word itself, the EE kernel uses syscall 0), or the break instruction, etc.
Ideally, whatever library that the app links with would provide stubs if it detected that ps2link wasn't loaded. This library could conceivably go into ps2lib. What do folks think?
- Provide a level of abstraction for host comms. If we have a syscalls for all of file I/O that doesn't explicitly require SIF RPC, we can do things like loading files over EE SIO, or use the unused SIF 2 DMA channel to communicate with the IOP.
- Provide debugging hooks. A big wish of mine would be to have a GDB stub integrated into ps2link.
- Exert control of ps2link itself. Anything from setting the comms "port", to telling ps2link to dump vram, or even having ps2link shutdown itself or reboot the PS2.
By syscalls I don't mean the ones we normally use in libkernel in ps2lib, but perhaps syscalls that use a different index (the MIPS syscall instruction relies on the syscall exception handler to decode an immediate value from the instruction word itself, the EE kernel uses syscall 0), or the break instruction, etc.
Ideally, whatever library that the app links with would provide stubs if it detected that ps2link wasn't loaded. This library could conceivably go into ps2lib. What do folks think?
I was actually hoping to have the ability to dump screenshots from any program we can run through ps2link without having to change any code in the user's app. Nice and stealthy like...
Now, getting ps2link to run over SIF2 would be nice and completely clear up the SIF for the user and that is a good thing. :)
Host comms already have a level of abstraction with SIF RPC. Sure, you can send fileio and stuff over SIO, but wouldn't that be at the expense of what we already have for abstraction?Provide a level of abstraction for host comms. If we have a syscalls for all of file I/O that doesn't explicitly require SIF RPC, we can do things like loading files over EE SIO, or use the unused SIF 2 DMA channel to communicate with the IOP.
I have no idea how this works or what this would require, so I'll skip it...Provide debugging hooks. A big wish of mine would be to have a GDB stub integrated into ps2link.
Letting the app control ps2link may seem like a good idea, but I'd rather work towards having apps never need to know that ps2link is running. The less intrusive the loader is, the better. There's already methods to do reset/poweroff (ps2link uses these methods, right?) and dumping vram would be a simple fileio open/write/close affair. There's no reason for control over ps2link that I can see. I imagine even the GDB stub stuff could probably be done acceptably over SIF RPC.Exert control of ps2link itself. Anything from setting the comms "port", to telling ps2link to dump vram, or even having ps2link shutdown itself or reboot the PS2.
Now, getting ps2link to run over SIF2 would be nice and completely clear up the SIF for the user and that is a good thing. :)