Sunday, July 18, 2010

snes-sdk update

After about a year I finally got around to do something with snes-sdk again. I fixed it to build (ahem), and added some of the optimizations from a tool called optimore to the peephole optimizer. (I do not recommend to use optimore, BTW. I have found at least some of the optimizations to cause test suite failures...)

Saturday, July 3, 2010

Linux and the built-in flash

I don't know if this is generally known, but I've been digging into the original firmware, and it appears that the flash translation layer used for the internal memory is NFTL. At least some left-over debug strings strongly point in that direction. NFTL is readily supported by the Linux kernel, but there's a problem: When I enable the jz4740 NAND flash support in the opendingux kernel, it freezes at some point during bootup, so I cannot test my assumption.

(Also tried the legacy kernel, but it wouldn't even compile with NFTL enabled.)

Friday, June 25, 2010


Hacking on my "Dingux emulator", I recently came across some applications that behaved rather erratically. So I looked into the source code of one of them, and I found that while the application itself uses SDL throughout, the Dingoo-specific GUI tacked on mmap()s the JZ4740 I/O registers to get user input. This, of course, spectacularly and needlessly fails on everything that is not a Dingoo A-320.

Here's some advice: Once you have chosen one level of abstraction, you stay there. And when you're porting somebody else's code who chose to develop on top of SDL, you also stay there, whether you like it or not!

And, generally, using /dev/mem to sidestep the operating system is wrong. Always.

Unless you're me, of course. But even then it's a hack. Thanks for listening.

Sunday, June 20, 2010

gmenu2x hogs my CPU no more

Not sure if anyone ever noticed that, but gmenu2x wastes enormous amounts of CPU time (20-30%) by constantly redrawing the screen when there's absolutely nothing going on. So I made a quick fix that makes it redraw the screen on user input only.


Saturday, June 19, 2010

something to play with for the weekend

Here are binaries of an opendingux kernel with TV-out ioctl and CPUFreq, a matching "tvout" tool, and a fixed gmenu2x that doesn't mess up the display:

Have fun. This appears to be much more stable than the previous userspace-based hack.

Source code repos are here:

Have fun.

opendingux-kernel work

I created an opendingux-kernel fork on GitHub yesterday, and added some of my stuff:

  • FBIOA320TVOUT ioctl, which is the LCD controller part of dingoo-tvout done properly in the kernel where it belongs. There is a corresponding dingoo-tvout branch that makes use of it.
  • CPUFreq driver based on the ubiquitous jz_cpuspeed() function. This driver is not perfect yet (TV image loses sync for a brief moment when changing frequencies, and too rapid rescaling breaks USB networking), and definitely needs some adjustments for coding style, but it is already way better than the currently preferred method of messing with the PLL and dividers in userspace.
  • Port of the /proc/jz interface from the Ingenic kernel. I like it, it's good for debugging clock stuff.