Recently i've been exploring the possibility of generating video output on PIC microprocessors for simple games like pong, which are, though simple, entirely possible, such as this breakout game here : http://www.acm.uiuc.edu/sigarch/projects/breakout/
It resulted in me wondering if a similar sort of project would be possible for the PSP, bearing in mind my knowledge of the psp hardware isn't all that great, and neither is my knowledge of writing software for the device, however a few friends of mine weho have written applications for the device before suggested i ask here.
Basically i would like to know the answer to a few questions regarding the psp's hardware, these are as such.
1) What is the comprative voltage range of the audio jack alone, for audio L/R? would it be able to provide a maximum of 1v?
2) I'm aware that the remote connector is capable of providing a constant 2.5v after reading through this thread : http://forums.ps2dev.org/viewtopic.php?p=18903 , but i'd like to know if the voltage to this connector can be modified via software, and if so, what sort of timing for voltage change would we be talking about?
Now bare with me here, i'm aware my lack of knowledge may have already set alarm bells ringing in the 'noob stamp' department, but i'd basically like to ask the blunt question of, just how feasable would it be to generate a video signal in software, either specifically for displaying a specific application or image, or converting data from the framebuffer to a composite video format, and outputting that video signal to a display via either the remote connector or over L or R audio line (leaving the second for mono audio).
Question regarding alternate use of audio +remote jack
Interesting... from a quick skim over dvemgr.prx reversed by Dark_AleX, it looks like it may be possible to write any kind of data (such as video) to one of the headphone channels, using the sceI2cMasterTransmit function.
In the case of dvemgr.prx it seems to be reading from/writing to device 0x42 which I assume is the Slim's remote socket, so I wonder what the equivalent IDs are for the headphone channels. Has anyone reversed audio.prx?
Of course, that PRX is from the Slim which has extra hardware to produce the video output, but maybe it could be done in hardware (i.e. capture framebuffer and convert it). :/
In the case of dvemgr.prx it seems to be reading from/writing to device 0x42 which I assume is the Slim's remote socket, so I wonder what the equivalent IDs are for the headphone channels. Has anyone reversed audio.prx?
Of course, that PRX is from the Slim which has extra hardware to produce the video output, but maybe it could be done in hardware (i.e. capture framebuffer and convert it). :/
I think it would be possible using the same method used in the tutorial written
by the author of pic pong and pic tetris.. I assume that is where you're getting
the idea from.
Surely with a few capacitors for buffering, you could produce an audio signal
to achieve a composite video signal without any resistor ladder.
by the author of pic pong and pic tetris.. I assume that is where you're getting
the idea from.
Surely with a few capacitors for buffering, you could produce an audio signal
to achieve a composite video signal without any resistor ladder.
If not actually, then potentially.
The slim video output is a curious thing... The video signal is digitally transmitted to two chips: Hibari and DVE, each of them having a distinct purpose. Hibari is the LCD *driver*, i-e it converts a digital signal into properly synced RGB for the LCD. DVE is the video output module, which converts the digital input into composite, RGB or component output.jas0nuk wrote:Interesting... from a quick skim over dvemgr.prx reversed by Dark_AleX, it looks like it may be possible to write any kind of data (such as video) to one of the headphone channels, using the sceI2cMasterTransmit function.
In the case of dvemgr.prx it seems to be reading from/writing to device 0x42 which I assume is the Slim's remote socket, so I wonder what the equivalent IDs are for the headphone channels. Has anyone reversed audio.prx?
Of course, that PRX is from the Slim which has extra hardware to produce the video output, but maybe it could be done in hardware (i.e. capture framebuffer and convert it). :/
To come back to the topic, the 0x42 I2C device is the DVE control and configuration channel. You cannot send it raw data, or anything of sort, through I2C; for that you have to use the *proper* channels, which are displaying and setting the display mode with display.prx functions and EDRAM.
The same holds for the audio controller, which is a chip the configuration of which can be controlled through I2C (That's how we can choose where we want the sound to come out from...)
Hmm... the DVE is just a chip taking raw pixel data and converting to an appropriate output format.1) emulate what DVE is doing in the slim without making everything run slowly
But why would you want to do that?2) put this data out through one of the audio channels
The main issue with the two propositions is the bandwidth. Why is there a special IC to do the video output? Simply because the audio chip is probably too slow to output video at a decent framerate. I personally think it's a dead end project, but I'd love to be contradicted...
EDIT:
I looked at the page cited in the first post and they say the output has to be clocked at 12Mhz for a decent framerate. Although I don't know the exact bitrate and frequency limit of the PSP's chip, I highly doubt it's possible to do such a thing.