Search results

Since the system is running linux and the emulators it uses are all fairly low on memory usage the majority of the RAM will simply be used for caching disk accesses anyhow so it should make little difference most of the time and when it does make a difference will be a speed increase accessing...

Seems like the more early adopters the better, can't get too much interest, but it'd probably make sense to have some kind of queuing system in case of slow production.

Sounds about long enough for a Jutley recital...

It's got a 32-bit address space, so technically 4GiB.

I don't understand that, for one the hardware is so easy to access and the firmware so easy to reverse that making the required changes to dingux should be trivial, but this is a handheld, the native OS can execute programs just the same as dingux, there's no real reason to worry about linux.

Not exactly true, the A320 mostly just uses the ucos2 build from the ingenic ftp which is open-source, the few things that are specific to the Dingoo version of the OS can very easily be disassembled.

Yeah thanks, recently we figured out that the all code executed from the native OS is already in kernel mode, so I've disassembled the jump table and had a look, should be able to hook interrupts properly with a bit of twiddling when I get some time.

If the machine proves appealing enough to developers then maybe they'll take a look, but I for one am not interested in the JXD V3 enough to buy one and look into it. If you're really that interested then you could always take a look yourself.

Critical bugfix, all users should update.

Lol, now I feel stupid.

If you look at "mxu_user_guide_EN.pdf" it talks about an awk script that patches assembly files to work with MXU instructions, assuming you can find the script among the millions of files on the ingenic ftp then it should be pretty straight forward. All the files off the ingenic ftp (including...

OK, everyone who hasn't updated yet should update to r94, it's a big change as you can see on the google-code (I'm not repeating stuff here). The links at the top are updated.

Not sure if this is just me seeing things but to me the menu seems a higher resolution when plugged into the TV, but films all seem to play at about the native 320x240 (I doubt it could decode a higher res easily). The TV-out is certainly capable of a higher resolution.

The mem clock value is the maximum memory speed, if you leave it as 112 then it will have to downclock to 100 MHz due to the integer division ratios (400 / 4 = 100), if you set your max clockspeed up to 166 then it will downclock to the maximum that is below 166 which is (400 / 3 = 133). I'll...

Press A to set the clock speed, or press B to reset the speed fields to their actual values. For some reason the dingoos clock speed resets to 336 MHz unless you hold down a button for all the time you're in a menu so you have to hold down B, then keep it held till you've loaded the application...

I've made a new (better) open-source overclocker, it supports different core and memory speed combinations. My dingoo reliably clocks to 448MHz core clock with 149MHz memory clock as I suspect most will with this new overclocker since it sets all the internal clocks better than A600's app...

No I didn't do anything with the IPU but I read all those docs just to see what the soc was capable of.

Here is the hardware documentation: http://www.amebasystems.com/downloads/hardware/datasheets/ben-nanonote/Ingenic-SOC-JZ4720/Jz4740-PM/ You want to look at the IPU (Image Processing Unit) for the video scaling. To use the hardware registers you can use this header file...

Just to let people know this project is quite active at the minute, we have 2 new contributors and updates are happening fairly regularly so anybody using this should regularly update their installation from google-code.

As far as I can tell the filtering is only available when converting from YCbCr to RGB565 so you can't filter RGB textures with it at all.