PSP version ?

Apr 29, 2012 at 6:55 PM
Edited Apr 29, 2012 at 7:34 PM

Hi, I'm a programmer on the psp, I do C and C++ and a bit of assembly (MIPS).

So I'm wondering if it would be a good idea to port it on psp, for that, I need a few questions to be answered:

-Is the code of Wabbitemu portable without any change ? (I mean the code, I'll myself do the HUD/GUI)

-Will it work with about 25mb of memory ? (yes, the psp is limited)

-The psp has his speed set to 222mhz but I can switch it to 333mhz with no problem, is 333mhz enough to make the emulator work without lags ?

-If you want to, I will add a banner on the start of the emulator, it must be sized to 480*272. (It can be whatever like "Buckeye, The Great" or "Wabbitstudio, 'cause we program as fast as rabbits eat")


See you ;)

Apr 29, 2012 at 11:39 PM

Hello again,

We had a PSP programmer on our team a few years back, but he never found the time to get it ported. It should work fine, it runs on the DS, the biggest issue, I believe, was the skin. Because the PSP is landscape, a new skin was required similar to the Voyage 200. The core code is buildable on any system that supports C. I think the only issue might be the clock speed, and only really for the Silver Editions. 15 MHz requires a decent amount of horsepower to emulate, so you might see some slow down issues there. Don't worry about a banner, if you absolutely have to have one, just the text Wabbitemu with the wabbit icon would be fine.

Here's the link to the source It includes a simple makefile that builds the core files but doesn't link them.

If you have any questions or issues, you can ask me more questions on here, or hit me up on IRC on EFNet in #ti.


Apr 30, 2012 at 1:07 PM

By the way, its there a main file or si it only functions that allow me to emulate this ?

Apr 30, 2012 at 1:42 PM

In this case no. I can give you a brief description of the functions that you will need. I also recommend taking a look at some of the windows or wxwabbitemu GUI code to see how certain things are handled. These are just off the top of my head so there may be more.

The core folder is simple. Don't touch it. The only file you might need to look in is core.c, which contains the CPU_step function. This is called to make the CPU step a single instruction.

Same with hardware, you shouldn't really need to touch it. The one exception is the LCD. You want to be able to get a screen image, so you call LCD_image. This will return an 8 bit buffer 128 * 64, representing the pixels of the array. All the grayscale and stuff is handled by the logic of calling this function.

The interface folder is much more interesting. This is where all the functions intended to be needed by the GUI for access to the core are. Functions of interest are:

calc_run_all: run all active calcs for a frame. 

rom_load: open a file and attempt to load it as a new ROM.

calc_run_tstates and calc_run_timed: run the calculator for a certain time period.

calc_reset: reset the calculator to the uninitial untouched state.

calc_turn_on: attempt to turn the calculator on by simulating pressing the ON key.

calc_slot_new: create a new calculator.

calc_slot_free: free a calculator you created. Should be called if you are done using a calculator

For utilities not all the files in there will build on all systems I believe. I may have taken out the extra files, but either ways, they are things that aren't related specifically to emulating the calc, but are just useful for the emulator. Of note are:

gif.c: I don't remember the exact functions in here, but this handles all the GIF writing. You can call something like gif_start_screenshot and then gif_stop_screenshot to have wabbit handle writing out a GIF file.

var.c: This handles the importing of files in the TI variable file format. You should just need to call newimportvar in here.

sendfile.c: Once you've imported the file, you'll want to send it to the emulator. I believe the function is called SendFile.


I believe that's most of it. Wabbitemu runs at a constant frame rate set in core.h. Basically it expects you to call calc_run_all every frame. This means that it expects to be run every 1000/FPS milliseconds. The default is 50 FPS, but you can change this depending on how well it runs on hardware. The way I normally do this is by setting a timer to fire every TPF which is defined to be CLOCKS_PER_SEC/FPS. In here you call calc_run_all and after that finishes, update the LCD. Windows also has some fancy logic to handle if the timer fires early or late, but that's not too important to start.

That should help you get started. Let me know if you have any questions, or get stuck anywhere.

May 1, 2012 at 2:03 PM
Edited May 1, 2012 at 3:13 PM


Thanks for these explanations.

-does wabbitemu runs in his own thread when I call a function or does it run in the thread of the parent one ?
-for sendfile.c, I believe I'll have too change the way files are read since it's not the same on the psp.
-how does wabbitemu return the current frame of the screen and how can I know if the frame is new and so, I've to update the screen for ?
-is the full code in C or parts in C++ ? (I myself prefer C but no matter)
-there will only be one calculator running at one time (otherwise would be impossible to handle)
-what do you think is the best: display the screen of calculator as large as possible and interact it with a virtual danzeff's keyboard | or | make a custom skin and a virtual mouse | or | switch the psp in landscape mode (means the user have to trun his psp of 90°) ?

-I first want to get only the emulator to run without skin, no sendfile etc (but send rom); So what I need for that, core folder, hardware ? interface ? (btw, what I objs are needed to basic run, means what objs should I add in the makefile ?)

I don't know your mind about but I think it would be really nice to see this emulator on psp.

I'm not familiar with that but it would be great to port it on wii after (with the virtual mouse controlled by the hand's position, it could be really pratical to use the skin), then why not port it on ps3 (there will maybe no need of any code change since the ps3 does hold a psp emulator). Another thing that would be great is to port it on iPhone but that, you already know !

btw: better we speak on Gtalk, please consider to add me on Gmail: devnoname120[-@-]gmail(D.0t)com

May 2, 2012 at 12:54 PM

Wabbitemu itself doesn't spawn any threads. The reason being that it synchronizes all running calculators 1024 times a second, so the threads would just end up blocking most of the time and cost additional CPU time. This may be changed in the future, but for now don't worry about it.

Does the PSP not implement FILE *, fopen, and the likes? If so you're going to have to rework lots of things, sendfile.c and var.c being the most important ones, if you want to load a ROM.

All the main files I sent you are in C.

If you're sure you don't want to run more than one calculator, in calc.h change the define of MAX_CALCS from 8 to 1. This will let the compiler optimize a lot.

I don't know, you'll have to play with it. I think some users will prefer one way, some the other. Make it an option eventually, but code it whatever way is easiest to start. I personally like the idea of a custom V200 style skin, but that's extra work of course :P

For getting a ROM running you'll need everything in that zip. Your code will look something like this:

void CreateCalc() {
 LPCALC lpCalc = calc_slot_new();
 rom_load(lpCalc, "rom.rom");
 Timer *timer = CreateTimer(TPF, TimerFunc, (LPVOID) lpCalc);

void TimerFunc(LPVOID param) {
 LPCALC lpCalc = (LPCALC) param;

void UpdateDisplay(LPCALC lpCalc) {
 LCD_t *lcd = lpCalc->cpu.pio.lcd;
 if (lcd->active == FALSE) {
  BYTE lcd_data[128*64];
  memset(lcd_data, 0, sizeof(lcd_data));
 } else {
  unsigned char * screen = LCD_image(lcd);

Now there are two important things to note about this code. One is the Draw8BitArray function. You'll have to figure out how to do this. I don't know how drawing on the PSP works, but in all likelihood you'll need to convert it to an RGB array. Easiest way to do this is a for loop duplicating the values. The other note is that the pixels are opposite of what you would expect, ie black is 255, white is 0. Windows uses a palette to make the screen more realistic, which just maps the colors of based on the following functions:

Red = (0x9E*(256-i))/255;
Green = (0xAB*(256-i))/255;
Blue = (0x88*(256-i))/255;

I've added you on Gtalk, feel free to hit me up whenever. I'm glad to help you get this running on the PSP its always cool to see it running on other platforms.


May 2, 2012 at 3:44 PM
Edited May 3, 2012 at 4:29 PM


"Does the PSP not implement FILE *, fopen, and the likes? If so you're going to have to rework lots of things, sendfile.c and var.c being the most important ones, if you want to load a ROM"

Actually no, sony implemented their own functions. but it's necessary since there are different drives on the psp: internal storage (for the pspgo only), flash card, flash0 (holding all modules like the one which handles the wlan), flash1 (mostly user settings as PSN password (not encrypted !!!)), flash2 (blahblahblah...).

I think it won't be that hard to change but I actually didn't look how you handle this, if you dump the whole file to the buffer to process this or if you do much reads to the file.


 "Timer *timer = CreateTimer(TPF, TimerFunc, (LPVOID) lpCalc);

Sony does also have their own functions for that and they don't work in the same way but it shouldn't be hard to handle.


"I don't know, you'll have to play with it. I think some users will prefer one way, some the other. Make it an option eventually, but code it whatever way is easiest to start. I personally like the idea of a custom V200 style skin, but that's extra work of course :P"

Probably :P I'll first try to get the emulator to work (without skin or anything) before doing the GUI ;)


What do you mean by "lcd->active" ?

Do you mean if the calculator is active or ?


By the way, psp has two memorys for image processing: the RAM and the VRAM. The VRAM is the GPU internal's ram and it is faster than the RAM. Counter part is that it's only 4mb size so it should be used only for images that are often used. I've calculated that the the array's image of the calculator is actually 65 536 bytes. That's not much, so I think the best is to put it directly in the GPU's buffer.

Does this return directly the black and white screen or does it return the screen according to the contrast and the font (green) ?

I found the image formats accepted by the library I'll use:

"\param pixelFormat
Defines the screen resolution.
- OSL_PF_8888: 32-bit render, very precise and nice, especially when it comes to gradients. However requires twice the memory required by the 16-bit mode (1088 kilobytes in double buffer
mode, half in single buffer mode). Also uses more bandwidth and thus is slower.
- OSL_PF_5650: 16-bit render, can only display 65 thousand colors instead of 16 millions. Requires 544 kB in double buffer mode, and half in single buffer mode. It's the recommended mode.
 Use oslSetDithering to simulate more colors with dithering."


Since I don't use visual studio, can I delete this with no problem ? (is this really need for the program?)                                 "#include "stdafx.h"



Red = (0x9E*(256-i))/255;
Green = (0xAB*(256-i))/255;
Blue = (0x88*(256-i))/255;

I didn't understand it, but explain me on Gtalk.

I accepted you on Gtalk.


Personnal notes:

-display an img from memory: void oslDrawImage(OSL_IMAGE *img);

-create an img to memory (returns an OSL_IMAGE *): oslCreateImage(int larg, int haut, short location, short pixelFormat); <-- location can be either OSL_IN_VRAM or OSL_IN_RAM, pixelFormat can be either

Aug 10, 2012 at 8:34 PM
Edited Aug 10, 2012 at 8:35 PM

News about the project:

I stopped to maintain it: I'm busy and not very motivated anylonger. That's why I GPL'ed the project and I hosted it on google code with the hope that someone is going to continue the port. In the current state, it's working fine, there is not much to do yet:

  • Create a GUI
  • Optimize the emulator to get a good framerate
  • Etc

On the repository, I create issues for what needs to be changed and what is still needed to do.

Please drop me an email if you're willing to continue the project.