Emulator - Evolving PSP homebrew

[biermana]

As someone who writes software for a living, I would submit that PSP homebrew development will struggle to evolve much past "hacking around" until a real PC-based emulator exists that allows for step debugging.

Writing PSP code on the PC and "seeing if it works" on a physical PSP without the ability to step into code is not a viable long-term scenario. We'll never "catch up" to the community of "official, Sony SDK and Codewarrior" developers until something more evolved than pspe exists.

What do you think? What can we do?

Unfortunately, I've no experience whatsoever creating an emulator. I see that a linux-based MIPS emul called gxemule exists. Would gxemule serve as a good starting point?

[ooPo]

As someone who also writes software for a living, I counter-submit that you should ponder for a moment as to how development has been done for decades now on consoles.

Here's a hint: They rarely, if ever, use emulators/simulators.

Its usually done by running the software on the actual hardware itself, either a devkit with hardware specifically made for debugging/etc, or just a special version of firmware with a network connection to a host pc.

So what should we do? Write a piece of software that sits on the psp and lets us upload/execute programs and receive debugging information from a remote host, say a pc connected via wifi or usb.

[biermana]

Thanks ooPo - good point. Obviously, the sofware I write for a living is not of the game console variety, or I wouldn't have asked such a silly question.

Why is the devkit method preferable? Because of the time required to create the emulator?



So you feel we need a remote debugging scenario?

Let's seen then, we'd need the ability to send files to the hardware, switch the hardware out of USB mode (unless we had an FTP server or something running on the PSP), and have a host process run our subject code while being aware of debug symbols and breakpoints.

Seems like the remote debugging scenario is still pretty far off.

Does the group working on the PSPSDK have a roadmap and guidance for what's needed going forward? Is the PSPSDK development effort being managed/guided in a common direction?

[ooPo]

Using the actual hardware is always preferable for many reasons. The two major ones being that the hardware is usually cutting-edge enough that an emulator isn't really workable with today's pc hardware, and hardware has enough quirks and gotchas that if you do the development on an emulator you may find it doesn't work quite right on the real thing. Not a good situation when you're trying to meet a deadline.

Remote access isn't as hard as you think. If you read up on ps2link and remote-gdb you'll find that the tools are already in use on other platforms. A program is uploaded to memory on the console, executed and has console output and some fileio redirected to the host pc.

[Kristof]

You can write lot of thing on your PC and test them (let's say the core of your demo or game). Then it is "only" porting. Not easy, but the lack of emulator will not stops the developpement of howbrew games/tools/demos.

But PSP is not a complexe machine. I'm sure there will be a powerful emulator one day.

[rinco]

Until recently I was toying around with gxemul. I setup a bunch of TLB entries, created a couple of dummy psp opcodes, loaded kmem.bin and inserted a bunch of known symbols. With this I am able to step through various kernel routines.

I've been trying to get sceKernelExecPlainBuffer to work... and it does seem to be loading modules... but it gets stuck in an infinite loop trying to eret (epc is set to a few instructions before the eret).

I don't plan on working on this anymore unless I can get past this brick wall. PM me and I will send you a diff.

[sherpya]

I've updated the patch to apply to the latest version:
http://oss.netfarm.it/psp/gxemul/gxemul ... 3.6.1.diff
but I could not manage to run nothing (same problem using 0.3.4 as original patch)
it does a cpu exception while executing sceKernelLoadExecBufferPlain

Code: Select all

GXemul-0.3.4   Copyright (C) 2003-2005  Anders Gavare
Read the source code and/or documentation for other Copyright messages.

Simple setup...
    net: 10.0.0.0/8 (max outgoing: TCP=60, UDP=60)
        gateway: 10.0.0.254 (60:50:40:30:20:10)
            nameserver 127.0.0.1
    machine "default":
        memory: 32 MB
        cpu0: Allegrex (I+D = 16+16 KB)
        device  0 at 0x0004000000: fb [Playstation Portable] (bintrans R/W)
        kmem.bin: 0x88000000
        boot.bin: 0xbfc00000
        machine: Playstation Portable
        loading test.elf:
            ELF32 LSB (LE), entry point 0x089000f4
            chunk 0 (load) @ 0x1018, vaddr 0x08900018 len=0x119d00
            416 bytes of symbol strings at 0x7b11f
            696 symbol entries at 0x7b8d8
            10648 bytes of symbol strings at 0x7e458
            found _gp address: 0x0891e610
        starting cpu0 at 0x88064ab4 (gp=0x0891e610)
-------------------------------------------------------------------------------

GXemul> unassemble
<sceKernelLoadExecBufferPlain>
88064ab4&#58; 78453a73      lq_mdmx a1,14963&#40;v0&#41;
...

-> step

Code: Select all

GXemul> step
<sceKernelLoadExecBufferPlain>
88064ab4&#58; 78453a73      lq_mdmx a1,14963&#40;v0&#41;    &#91;0x00003a73, data=&#91; exception ADEL vaddr=0x0000000000003a73 pc=ffffffff88064ab4 <sceKernelLoadExecBufferPlain> &#93;

I'm using boot.bin and kmem.bin dumped from a 1.50 psp with kdumper,
but I'm not sure that this is the right way to obtain a working stuff.

Also note that

Code: Select all

                mips_coproc_tlb_set_entry(cpu, 5, MEG16,
                    0xffffffffffffffff - MEG16 /*vaddr*/, 0, 0 + MEG16, 1,1,1,1,1, 0, 2, 2);

doesn't seams a legal way to assign a 32bit integer? what exatly it does? it 's needed for a dummy MMU definition?

[ChaosKnight]

Remote access isn't as hard as you think. If you read up on ps2link and remote-gdb you'll find that the tools are already in use on other platforms. A program is uploaded to memory on the console, executed and has console output and some fileio redirected to the host pc.

I remember there was a real slick solution like this for Game Cube development. Because it was a hassle to always reboot PSO and go through that a guy came up with a way to send a program and execute it, then break it and upload another, etc... very slick.