Hello There, Guest! Register
Enjoy our site and services? You may donate to help fund server and domain costs. Donate Here for special benefits. You have donated $

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
LeapPad2 now is working quite well as a retro emulator console
Thanks to tremendous work by Forrest Martin it is possible now to turn LeapPad2 (and LeapsterGS) into a retro console. This is not a proof of concept, but quite useable console that could be used for everyday gaming (well, not every day - my kids have homework to do and I am supposed to work as well). Thanks to Forrest's efforts Retroarch works with the default interface, so it is quite functional. So far we have tested games for NES, SNES, Genesis, 8-bit Atari, GameBoy, GameBoy Color and GameBoy Advanced. Most games for older platforms work quite well, some games for more resource-intensive (SNES and GBA) devices are somewhat slow, but often still playable.

Of course, due to very limited number of buttons on LeapPad2 not all platforms and games are equally playable. Leapster GS is a better choice in this respect.

Here is the link:
Figures.... after a couple years of having hundreds of leappad2's around, I decided to toss them out a few weeks ago then this shows up ha ha. I may have saved a few so I will have to give this a shot and see if I can make use of what I have left.

Thanks for posting.
Unfortunately, retroleap only works on certain Leappad2 models.
I bought one on eBay just to try out retroleap and it does not work. The problem is board revision 0x310 GPIOs are not the same as the other models. The retroleap patch to the kernel knows nothing about this board.

I hoped it might be the same as Valenica 0x205, 0x206, or 0x207, but it is not. However, it is close: if you change one of these lines below to end in 0x310 in leapstergs_2.6.37.patch and recompile the kernel, the screen works properly and the volume (A,B) buttons work but the d-pad buttons and home are still dead.

#define LF2000_BOARD_VALENCIA 0x206
#define LF2000_BOARD_VALENCIA_EP 0x207
#define LF2000_BOARD_VALENCIA_FEP 0x208

I posted an issue to the retroleap github, but I think the project has died. That's kind of sad, because all that is needed to get the d-pad working is to correctly define these variables in the patch:

gpio_map[DPAD_LEFT] = ????????????
gpio_map[DPAD_RIGHT] = ????????????
gpio_map[DPAD_DOWN] = ????????????
gpio_map [DPAD_UP]= ????????????
gpio_map [BUTTON_HOME]= ????????????

The values for the volume buttons must be right, since they are working:

gpio_map[BUTTON_VOLUMEDOWN] = LF2000_GPIO_PORT_A | 13;
gpio_map[BUTTON_VOLUMEUP] = LF2000_GPIO_PORT_A | 14;

I tried a few guesses based on the current values (see lines 23167 - 23324 of leapstergs_2.6.37.patch), but no new buttons were enabled. Unfortunately, it looks like there are 128 possibile values:

cat /sys/devices/virtual/gpio/gpiochip2048/ngpio

Okay, maybe only 125 since the screen is using one:

spi_lcd_init: spi_channel: 1, gpio_port:2, gpio_pin:3, lcd: GiantPlus-1, type: 2

and the 2 buttons work. Still, too many to guess. (Recompiling takes a while on my system)

Maybe someone who knows about this hardware can help?
Unfortunately, the creator of retroleap has not been active for a long time, as I understand, his free time is rather limited.

Last time I heard from him, he suggested trying out the scancodes in Linux with some kind of a diagnostic program.
(12-27-2019, 04:01 AM)Jabberwock Wrote: Unfortunately, the creator of retroleap has not been active for a long time, as I understand, his free time is rather limited.

Last time I heard from him, he suggested trying out the scancodes in Linux with some kind of a diagnostic program.

The D-pad and Home do not generate any keyboard events. If you cat /dev/input/event0 and press Home and D-pad buttons, nothing happens at all. I think this means they're not mapped to the right GPIOs.

With the original firmware, pressing any of these buttons causes junk to appear on the screen.

What "diagnostic program?" I'm pretty sure the problem is at a lower level: the kernel needs to know the board revision so it knows where the GPIOs map to and 0x310 is not on the list.

Below is optional reading if you want more detail on why I think the problem is at a lower level than just reassigning keys.

Curiously, OpenLFConnect still works on the latest Manjaro Linux and can be used to enable developer mode (having first restored the leappad back to stock).

You don't have to solder anything to a cartridge; you can get telnet access to your stock leappad by following the simple steps here:

(Basically, just mkdir developer in /flags.)

Anyway, when you boot the stock kernel, there is this in the sys filesystem:

>cat /sys/devices/platform/gpio-keys/keys

These numbers represent the keys up, down, left, right, etc. listed in input.h in the kernel source code.

>cat /dev/input/event0
After you press each button on the Leappad, a little jibberish will appear on the screen. This is good.

If I boot the retroleap kernel and do:

>cat /sys/devices/platform/gpio-keys/keys

Looks fine: u, d and the direction keys are all there.

Monitoring (as done above) /dev/input/event0 shows nothing at all when I press any key other than volume up (22) and volume down (23).

EDIT: The "diagnostic program" is probably evtest?

You can build it in retroleap. It's in the config menu under hardware.

The results are prettier than just cat, but still noting happens except with KEY_U and KEY_D (vol+, vol-):

Here's what happens when you run it having booted the retrolep kernel:

>evtest /dev/input/event0

Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "gpio-keys"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 1 (KEY_ESC)
Event code 22 (KEY_U)
Event code 32 (KEY_D)
Event code 103 (KEY_UP)
Event code 105 (KEY_LEFT)
Event code 106 (KEY_RIGHT)
Event code 108 (KEY_DOWN)
Testing ... (interrupt to exit)
Event: time -909804547.321421, type 1 (EV_KEY), code 32 (KEY_D), value 1
Event: time -909804547.321432, -------------- SYN_REPORT ------------
Event: time -909804547.481428, type 1 (EV_KEY), code 32 (KEY_D), value 0
Event: time -909804547.481437, -------------- SYN_REPORT ------------
Event: time -909804541.691979, type 1 (EV_KEY), code 22 (KEY_U), value 1
Event: time -909804541.691990, -------------- SYN_REPORT ------------
Event: time -909804541.831978, type 1 (EV_KEY), code 22 (KEY_U), value 0
Event: time -909804541.831987, -------------- SYN_REPORT ------------
In the source I was sent it seems the last model was codenamed VTK; the relevant portion of the code is:

static void init_vtk(void)
#define LF2000_GPIO_EXTENDER_BASE 0xC00
    printk(KERN_WARNING "%s: VTK GPIO mapping\n", __func__);

    gpio_map[BUTTON_RED]        = LF2000_GPIO_EXTENDER_BASE + 7;
    gpio_map[BUTTON_B]        = LF2000_GPIO_EXTENDER_BASE + 8;
    gpio_map[BUTTON_A]        = LF2000_GPIO_EXTENDER_BASE + 9;
    gpio_map[BUTTON_VOLUMEDOWN]    = LF2000_GPIO_EXTENDER_BASE + 10;
    gpio_map[BUTTON_VOLUMEUP]    = LF2000_GPIO_EXTENDER_BASE + 11;
    gpio_map[DPAD_RIGHT]        = LF2000_GPIO_EXTENDER_BASE + 12;
    gpio_map[DPAD_LEFT]        = LF2000_GPIO_EXTENDER_BASE + 13;
    gpio_map[DPAD_DOWN]        = LF2000_GPIO_EXTENDER_BASE + 14;
    gpio_map[DPAD_UP]        = LF2000_GPIO_EXTENDER_BASE + 15;
I got it working!! Fullscreen and buttons.

I used debugfs on the stock rom to figure out where the GPIOs are mapped. There was a little more to it than just finding them, but anyway here's my uImage:


You can flash it the same way as mac2612's original version; all I changed was the uImage so only retroarch is installed in rootfs.

I'm not sure about the code you quoted; after mounting debugfs, this is what I found running the stock kernel :

>mount -t debugfs none /sys/kernel/debug
>cat /sys/kernel/debug/gpio

GPIOs 0-87, lf2000_virtual_gpio:

GPIOs 2048-2175, lf2000_physical_gpio:
gpio-2057 (hi253-front clock en) out hi
 gpio-2058 (hi253-front enable  ) out hi
 gpio-2059 (hi253-front reset   ) out hi
 gpio-2060 (hi253-rear reset    ) out hi
 gpio-2061 (Volume Down         ) in  hi irq-93 edge-both
 gpio-2062 (Volume Up           ) in  hi irq-94 edge-both
 gpio-2079 (hi253-rear clock ena) out hi
 gpio-2114 (hi253-rear enable   ) out hi
 gpio-2127 (TS_Y2               ) out lo
 gpio-2128 (TS_X2               ) in  hi
 gpio-2129 (TS_Y1               ) out lo
 gpio-2130 (TS_X1               ) in  hi
 gpio-2133 (Headphone Jack      ) in  lo irq-165 edge-both
 gpio-2136 (Cartridge Detect    ) in  hi
 gpio-2153 (DPAD Left           ) in  hi irq-185 edge-both
 gpio-2154 (DPAD Right          ) in  hi irq-186 edge-both
 gpio-2155 (Escape Button       ) in  hi irq-187 edge-both
 gpio-2157 (DPAD Down           ) in  hi irq-189 edge-both
 gpio-2158 (LFP100 INT          ) in  hi irq-190 edge-falling
 gpio-2159 (DPAD Up             ) in  hi irq-191 edge-both

For example,

DPAD Left 2153 translates to

LF2000_GPIO_PORT_D | 9

2153 -2048 = 105

105 -96 = 9

(A starts at 2048 +0, B at 2048+32, C at 2048+64, D at 2048 +96 )

Yay! Now I can play retroarch at the crazy resolution of 480x272 without enough buttons.  Hmm GBA might not look too bad....
That is great news, thank you for your efforts!
(12-28-2019, 03:57 AM)Jabberwock Wrote: That is great news, thank you for your efforts!

That retroarch UI hurts, so I ported gmenu2x.
Everything in the picture works: a handful of brighness levels selectable by pressing HOME, storage usage monitor, and a battery meter that seems reasonably accurate...I guess. The battery meter assumes your 4 batteries are NiMH. So full is 5.3V and empty is ~4V. (Whenever voltage exceeds 5.3V, like if you put in fresh Alkaline AA,  it thinks its connected to AC. I'm not bothered by this.)

btw, the battery pack just has AA NiMH in it, so you can easily recell a failed pack with any NiMH rechargables.
The hard part is getting the glued-in old batteries out of the pack.

There aren't enough buttons for tab switching, but I think I can fit almost every RA core I can conceivably use on one screen of icons. The menu provides a nice file selector to choose game roms.

Is there a way to reverse what remote_flash.sh does? It would be handy to be able to copy your leappad's filesystem back into a file (rootfs.ubifs)?

It would also make it simpler for me to give this stuff to anyone else who might want to try it out.

Attached Files Thumbnail(s)
Looks nice, but I am pretty used to rgui... If I needed high-end graphics, I would not run retro cores... Smile

You can restore LeapPad to factory condition with the LeapConnect package, but you need a Windows machine.

Forum Jump: