forums.ps2dev.org

I'm working on writing a memory resident program for the PS2, to run behind a game. I've gotten it to work in PCSX2 and print out the syscalls that other demos. It does this by overwriting parts of the syscall interrupt handler. I've only been able to test in an emulator so far, still waiting for my equipment to arrive so I can test it on the hardware, but does anyone know a reason why it shouldn't work on the hardware?

What does the memory resident program do?

Which brings up another topic...and discussion.

Has anyone investigated the utility of PCSX2 for ps2dev development ?
Too many times I would prefer to do some development completely
on my laptop.

Of course, there are the always present legal concerns. However, since
at this point its ability to play actual games seems to be near impossible,
but I have seen reports of homebrew demos working fine, one might not
need to be concerned about indirectly contributing to warez efforts merely
by being a "consumer" of this tool.

If PCSX2 could actually play commercial games, I think the line might be
more clear, that this would have the same status of modchips, that is to
say, completely muddled and a major grey area, as opposed to a minor
grey area ?

What do people think ?

Gorim

I think this would be more or less the same that the first battles between SONY and Bleem!. Having a full emulator for a platform like the PSX has prooved to be not that much illegal, if it is not coded using the official documentations.

Bleem! was the only PSX emulator to be threatened by SONY, and many other free emulators were out a bit after, without beeing problematic. Now, PCSX2 seems to be not even considered by SONY at all.

Apart of that, I quite do not care :)

Right now it prints something each time a syscall is made (except for... whichever one is called in the printf itself so it doesn't recurse). I only need to find if the principle of memory-residence will work, not the specific program.

Doing something like a syscall logger wouldn't be difficult on it's own, but the printf might be problematic. Simply adding your own syscall exception handler to the exception table would work for the actual syscall logging, but you'll need a way to keep your printf() stuff working. That's not a problem if you use EE SIO as it doesn't require any drivers/etc on the IOP, but using Naplink/ps2link means that you need to make sure those modules get loaded every time the IOP is rebooted. Certainly not impossible but problematic when you consider things such as USBD/DEV9/etc conflicts with some games. EE SIO is the way to go. :)

pixel wrote:Bleem! was the only PSX emulator to be threatened by SONY, and many other free emulators were out a bit after, without beeing problematic.

Not quite - VGS from Connectix was sued by Sony in court. The case lasted quite some time. Other PSX emulators haven't been targetted for two reasons - they aren't commercial like Bleem! and VGS were, and they are developed in countries which don't care about enforcing copyright or patent laws.

Ah yeah, I always mess up between Bleem! and VGS.

they aren't commercial like Bleem! and VGS were, and they are developed in countries which don't care about enforcing copyright or patent laws.

Which countries are these now ?

I know linuzapp is bresilian, but I don't know if bresil is such a country.

Otherwise, I know that .cx (Christmas Island) is.

linuz is argentinian but still ;)

And Christmas Island is a den of piracy, been like that since the the 1720s :P

Herben wrote:EE SIO is the way to go. :)

Is there any way to get access to the EE SIO without building mrbrown's serial cable?
What I'm trying to do now is get scr_printf in the exception handler and see if I can just take over the screen when I need to write something. Is there a character set in ROM or RAM that I could use instead of including font.c?

Another question:
can I be reasonably sure that the exception table will be in the same place between BIOS revisions?

check out adresd bios font unpacker, its on ps2dev.org somewhere.

hcs wrote: Another question:
can I be reasonably sure that the exception table will be in the same place between BIOS revisions?

The V_COMMON exception handler is always at the same address. If you're referring to the kernel's syscall handler table, the easiest way to find it's origin is to add a dummy syscall, scan kernel memory for it's address, and subtract the number of the syscall * 4 (since the address is 4 bytes). That's the only reliable way to get the start of the syscall table as it is different in almost every kernel revision.

Alright, that's what I was hoping to avoid doing with the syscall table, but if I must I must.

Tolerate another question if you will:
I mentioned using scr_printf, is there a reason why I couldn't write this so that it overlays whatever graphics are already on the screen? Of course I'd have to do it every frame . . .

well unless you know the framebuffer locations for each frame, turn of zdepth test, write text to some "safe" area in vmem, and draw a sprite primitive with the uploaded text texture.

I'm not sure I understand what you're saying, will it be necessary to do all of this or is this how I could get around drawing each frame? What I thought I could do was replicate the debug printf and somehow have that called once per frame. There I only need space for a single character. I've got this working, though not behind any real program yet.
On the subject of the framebuffer, this wasn't something I noticed anywhere in the scr_printf sources. Is this assumed or set by default?

scr_printf just writes to the beginning of vram.
if you double buffer like any sane person you will have 2 different vram locations,
using scr_printf only every second frame will show the scr_printf output.

Does scr_printf just write to the beginning of vram because of how it initializes the GS, or is there something specific in the command to draw each character that forces it there?

[edit]
Never mind, I see it now.
Couldn't I read the current framebuffer address and write my characters directly there?

sure aslong as you know where the frame buffer is you can write data to it and expect it to be shown.

Should I be able to read from GS_DISPFB1 and GS_DISPFB2? Although changing the framebuffer pointer produces the expected effect in PCSX2 I only ever read zero from those registers. Is this a hardware artifact or an emulator bug?

Those registers are write-only.

That will make it more difficult... drat you for crushing my dreams!
Is there any other way I could get the framebuffer address out of the hardware?

no. back to drawing sprites with ztest off.

The only zany idea I could think of, which I have no idea if it would work, is adding entries to or modifying the MMU TLB entries to "trap" accesses to GS priveledged registers. There really is no reliable way to get access to those registers once they've been written to.

no. back to drawing sprites with ztest off.

So as I currently understand it I should be able to blit the text to vmem and then draw sprites, which will go to the framebuffer currently being drawn. I presume disabling z test was to prevent it from being under something already on screen. Could setting the z value very high be another solution, with the added benefit that things drawn after the text wouldn't overlap it?

Is there any way I could get text on screen without having to find a safe place in vmem to render a texture to? Something that just popped to mind is using the line primities to draw text (or as a last resort drawing one pixel at a time with points), but is there any other way to get a texture to the currently drawing buffer? If not the other two possibilities should be fine.

Thanks for answering all these newbie questions . . .