GP2X Ac97 Codec Registers


slygamer

Active Member
Joined
Sep 19, 2005
Messages
795
Location
Brisbane, Australia
Website
Visit site
I'm trying to work out what this code in rlyeh's Minimal SDK does.

Code:
    gp2x_memregs[0x0F16>>1] = 0x830a;
    usleep(100000);
    gp2x_memregs[0x0F58>>1] = 0x100c;
    usleep(100000);

I've figured out that they are some AC97 codec registers, but the databook does not go into any further detail. What are these writes to the registers doing and why are the usleep() calls necessary?
 
Well, the standard AC97 registers are mapped to F00 - F7E as you have found out. However, AC97 register 0x16 is AC97_AUX_VOL, and 0x58 is reserved as use for a future modem register, so I've no idea what Rlyeh is trying to do.
 
Doing a Google search, finding ac97_codec.h and trying to decipher what he's doing doesn't help either. Maybe this is NK's infamous stereo fix? Is that still required with current firmware?
 
Register 16 on the WL9711 is OUT3, 830A selecting Mute (0x8000), volume at -15dB (0x000A). The 3 selects capless headphone drive (0x0200), but bit 8 isn't defined
Register 58 is the Jack instertion register. Bit 12 is Jack Insert Enable (0x1000), can't see anything for what the lower byte sets.
Docs are from here: AC97
corrected url
 
Fixed URL

That's a good document. I have no idea how you found it. How did GPH expect anyone to be able to develop for the GP2X if they provide zero information on the hardware? We have to hunt elsewhere for information on this thing.

According to that document, writing 0x100c to register 0x58 is enabling jack insert detection (as you said) and writing the device revision number (bits 3:2).

Bit 8 of register 0x16 is the speaker mix. "Selects source of LOUT2 and ROUT2 signals. 0=from speaker mixer, 1=from headphone mixer"
 
Oopps, thanks for correcting it. I was in a rush to catch a bus.
I don't think GPH don't want us developing at hardware level, we might make something better than them :)
I'm still hunting down specs on the LCD - proving to be very elusive. I've been hacking the registers for weeks and still can't get rid of the interlacing without washing-out the screen...
 
paeryn: Yeah, the taiwanese company that makes the LCD doesn't have the fastest or best site in the planet. I have only been able to find documentaion for their analog interface LCDs. We could always send them an e-mail.
 
What I want to do with the LCD is that considering it's supposed to be persistant (compared to technology like CRT) I want to kill the refresh rate and refresh manually. That means instead of automatically refreshing 60 times a second, only refresh when I want to. That would be perfect for emulation, and they wouldn't need to wait for the vsync pulse - they could create it themselves :)

I just hope the controller circuitry is up to it, and doesn't do something silly like blank the display as soon as it stops receiving data like I've seen some controllers do.
 
You can switch vsync off, however it looks as though the LCD automatically inserts its own if it hasn't seen one for ~20 lines. Though that might be to do with the mmsp2 still sending all the other data at it. From playing around, the mmsp2 seems to be sending odd and even lines alternately even though it's in progressive. If you cut the screen short you get the last two lines alternating until vsync cuts in, and then alternating black and a dimmed (inverted?) last line.
<must... get... back... to... finishing... sdl...>
Nope, stopping the display controller totally just saturates the screen - it needs to be refreshed. You might get away with stopping it for one or two frames but it'll probably be washed out
 
From playing around, the mmsp2 seems to be sending odd and even lines alternately even though it's in progressive.
It is still interlaced, even though it is supposed to be progressive. I found this when I had some text being drawn on alternate frames (fully drawn one frame, not drawn at all the next). What I saw on screen was not a very fast flicker of text, but a solid display of only the odd rows of pixels. Now I have the text flashing on screen with a period of about one second, and you can see the interlace effect when the text appears on screen.

I would really like to get this display in true progressive mode.
 
Last edited by a moderator:
That's quite strange, as the CX25874 has a built in flicker fixer, although I'm not sure it works on the LCD, I would assume it would attempt to fix the incoming signal before passing it along to anything, as it seems to have a nice big fifo for that exact job.
 
I thought the MMSP2 was driving the LCD itself. I've ordered myself a TV cable from Craig so I'll start looking into what this CX chip can do this week. Anybody know how to talk to it?
 
The MMSP2 feeds it's V/H sync, DE, VS0..11 etc lines directly into the CX25874, which then plays with the signal and throws it out of one of the DACs. It can be controlled via I2C.
 
That'll explain a few things then... Don't suppose you have any code for using the i2c bus with the CX? I've just had a quick look at how /dev/proc/i2c works but it's not too clear. Maybe after I get some sleep it'll click into place.
 
There's some example code in the source to mplayer. No idea if it actually works however, as that version didn't support tv-out or anything fancy (and to be honest, didn't play videos or mp3's that well either...) but it may give you something to play with.

Code:
#ifndef _CX25874_H_
#define _CX25874_H_

#include "i2c.h"

/* CX25874 & I2C IOCTL Commands */
#define CX25874_I2C_WRITE_BYTE	_IOW('v', 0x00, I2C_WRITE_BYTE_INFO)
#define CX25874_I2C_READ_BYTE	_IOW('v', 0x01, I2C_READ_BYTE_INFO)
#define IOCTL_CX25874_DISPLAY_MODE_SET	_IOW('v', 0x02, unsigned char)

#define CX25874_ID  0x8A

#define DISPLAY_LCD 0x1
#define DISPLAY_MONITOR 0x2
#define DISPLAY_TV 0x3

#endif	// _CX25874_H_

Hmmm, mplayer seems to depends on /dev/cx25874, if this exists you may be lucky, but then again, it may be that it only supports one command. Still, if it does exist, the source code to the driver should be released soon ;)
 
Hmm, looked at the code for /dev/cx25874, just has the one command to switch modes... At least it gives the values that they use to program the video modes.
I've now got the tech docs for the LCD so I'm going to check the timings, though if the CX is processing the signal first it may be the CX's fault.
Dignsys' i2c code is very suspect - it has a software delay loop! That'll make things interesting when people adjust the clockspeed.
 
I wouldn't read too much into those LCD docs as last time we did that on the gp32, GPH went and changed the LCD... I think the least we depend on certain LCD values like timing, the better.
 
Back
Top