Kermit: Interface pour l'émulateur PSP de la PS Vita

Turns out he’s not just a green frog! So, I’ve been throwing this word around recently and it’s probably about time I explain. Kermit, either a protocol or perhaps a funny name (see KIRK/SPOCK) is a communication interface for the PSP emu. Specifically it allows the PSP to talk to the host.

Now, I can tell there aren’t as many developers here, so I’ll try to simplify for the curious minds but this stuff is pretty complicated. I’ll only explain the API in detail as the lower level still need a little bit of clearing up, but here goes.

Ok, Kermit is here so that the emu can communicate to the host to share resources and other vitality. Perhaps the primary reason is that of hardware; the PSP emu is excluded from many hardware devices. So kermit sets in and allows the system to talk to the vita in order to use the hardware. Blabbering aside, this is the hardware that kermit seems to be responsible for:

Memory stick
Flash filesystem
DMA
LCD
GE
IDStorage
Audio
Camera
Power Control
USB
OSK
WLAN
RTC
… more

Interestingly, the kermit communication isn’t used for headphone remote or controller inputs.

In order to understand how kermit functions, it’s important to explore the usage of the API. Starting with the power house tool:

int sceKermit_driver_4F75AA05(KermitPacket *packet, u32 cmd_mode, u32 cmd, u32 argc, u32 allow_callback, u64 *resp)

This function is the send command function. It accepts a kermit packet initialised to minimum 64 bytes (no args need to be filled) a command mode which describes the set of commands, cmd: the actual command; the number of args following the 16 byte packet header. It also allows you to pass a boolean value to allow callbacks when waiting for completion and a 64 bit response.

What is important to note is that the packet arguements are 64-bit wide (not 32) and little endian encoded. There is a maximum of 13 arguements that can be passed to the host.

Sometimes, it is needed to send more than the 13 arguements worth of data. This is where kermit provides an API for memory. Shown below:

void sceKermitMemory_driver_AAF047AC(KermitPacket *packet, u32 argc, u8 *buffer, u32 buffer_size, u32 io_mode);
void sceKermitMemory_driver_80E1240A(u8 *data, u32 len);
void sceKermitMemory_driver_90B662D0(u8 *data, u32 data_size);

These function provide the fundamentals for data transmission to the host. sceKermitMemory_driver_AAF047AC is the staple command. It accepts a packet BEFORE transmission to host with the amount of args, a pointer to the input/output buffer and an indicator for the mode. This allows kermit to recieve the buffer of data when it processes the command, or have a place to output the data.

sceKermitMemory_driver_80E1240A and sceKermitMemory_driver_90B662D0 are the opposites of each other, providing input and output respectfully. This API is incredibly simple and is used to send multiple buffers to kermit prior and following a command.

These are pretty crap descriptions, but as you can see it’s a very command and transfer sort of interface. You tell it you have data you want to give it, you signal it and then it tells you where it’s put it.

https://github.com/DaveeFTW/vita_kermit

There is some source code describing in more codey ways. Also there are small reverses of functions used in the kermit. As you can see it works on a sort of circular queue of semaphores in the core. Have a “peek”.

Thanks to Proxima + some1