ZodTTD: Home Of Homebrew

Quick status report for psx4iphone and gpSPhone coming right at cha!

psx4iphone v1.0.0 currently does not work on any device with firmware greater than 3.0. I have a build that now works with newer firmwares and will be releasing it shortly. Hopefully tomorrow, but don’t hold me to it.

gpSPhone currently works with all 2.x and 3.x firmwares on all devices. But there’s a catch. DevTeam messed up a kernel patch in the latest 3.1.x jailbreaks (confirmed by saurik) that affects only the iPhone 3g. If you have an iPhone 3g and use 3.1.x jailbroken with pwnagetool, there’s a fix for gpSPhone (as well as the upcoming psx4iphone). Simply run blackra1n on your current iPhone 3g firmware. It won’t erase anything or do any harm. It will however fix the issue at hand, and allow gpSPhone and the next psx4iphone to run.

Thanks,

ZodTTD

For those who have been long time followers, you probably saw how much I hoped to be able to write to the iPhone and iPod Touch’s video framebuffer. My reasoning was that I would not need to use the taxing call to “setNeedsDisplay” to render all the UIKit elements down to the framebuffer, increasing the performance of my emulators and ports. This basically would skip the middleman that is Apple, and get me closer to something like /dev/fb of NIX.

Recently I was speaking to crash-x and others in saurik’s IRC about the framebuffer. It seems the devteam, in particular planetbeing, has been able to write to the framebuffer ever since redsn0w. Due to devteam’s strict privacy policy he was unable to make this public. At least that is what I hear was the case. This saddens me as it was Steven Troughton Smith and I’s work figuring out how to read the framebuffer for Veency’s use, that probably led to his discovery.

Either way, moments after crash-x and I dug into redsn0w, I had a working example for writing to the framebuffer. It’s not ideal for most people out there, and can’t be used for AppStore apps, but it’s the holy grail of blitting a fullscreen buffer of pixel data repeatedly. And this is exactly what emulators tend to do. What I found out however, is my emulators are set up to still require setNeedsDisplay to swap video buffers. This is not ideal for performance sake. Until setNeedsDisplay can be removed from the equation, I don’t see the following example of writing to the framebuffer too useful for a series of blits.

Here’s the code:

IOMobileFramebufferRef connect = NULL;
kern_return_t result;
CFMutableDictionaryRef dict;
CoreSurfaceBufferRef screenSurface = NULL;
unsigned char* screenbuffer;
// Probe possible framebuffers
io_service_t framebufferService = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleH1CLCD"));
if (!framebufferService)
{
framebufferService = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleM2CLCD"));;
}
if (!framebufferService)
{
NSLog(@"Nothing found to draw too!");
}
result = IOMobileFramebufferOpen(framebufferService, mach_task_self(), 0, &connect);
result = IOMobileFramebufferGetLayerDefaultSurface(connect, 0, &screenSurface);
CoreSurfaceBufferLock(screenSurface, 3);
// Add to a CALayer here if you want
//
// Get the framebuffer's address to be written to and store it in screenbuffer
screenbuffer = CoreSurfaceBufferGetBaseAddress(screenSurface);
CoreSurfaceBufferUnlock(screenSurface);
// write to screenbuffer like so
// draws a fully white screen
// The screen is 320x480 and seems each pixel is 4 bytes ARGB
memset(screenbuffer, 255, 320*480*4);

I’ll fiddle with this code some more to see if I can remove the need to setNeedsDisplay to swap buffers, and simply check if it will actually improve performance as well. Updates to come!

Thanks,
ZodTTD