NVIDIA is hiring eDRAM engineers for possible upcoming PSP-sucessor GPU

NVIDIA is currently recruiting senior eDRAM design engineers. The new job is for a full-time position at NVIDIA’s Santa Clara, California offices. There is no mention what projects the senior eDRAM design engineers will work on, however, the job responsibilities include:

• Transistor level circuit design for Graphics processors and other ASICs targeted at desktop, laptop, workstation, set-top box, wireless and home networking markets.
  
• Participating in circuit design of eDRAM macros.
  
• Circuit simulations, layout extractions, timing characterizations and timing file generations.
  
• Layout floor planning and layout supervisions.
  
• Circuit level logical function and transistor level verifications.
  

NVIDIA does not have any products that integrate eDRAM now, however, Beyond3D forum members believe the job posting is for an upcoming GPU for Sony’s PSP successor. This makes sense as the Sony PS2 and PSP GPU feature eDRAM.  Although NVIDIA is a likely candidate as the GPU designer for Sony’s PSP successor, neither companies have made any announcements.

Other gaming consoles that take advantage of eDRAM include Nintendo’s Gamecube, Wii and Microsoft’s Xbox 360; however, all three consoles feature AMD ATI designed graphics processors. On the eDRAM side of things, IBM recently unveiled the fastest eDRAM technology yet.

Source:

eiffel56 has released an custom firmware for you ancient devoted 1.5 users. Its basically a 1.5 with added abilities.

So heres what's extra:

• Recovery Menu
  
• Boot Menu
  
• Integrated uxMB
  
• You can start 1.00 style EBOOTS
  
• You can hide corrupt data icons
  
• You can start ISO/DAX files
  
• You can load your own plugins(PRX)
  
• Autoboot EBOOTs at startup
  
• Never turn off the backlight in XMB
  

SO read the readme.txt to read more into this custom firmware.

Note, I'm assuming you already have basic hex editing knowledge...

This is the file structure, as far as I know, of decrypted (FW2.60 and lower) RCOs.
Many thanks go to Z33 at MaxConsole for providing much information on this.  His thread can be found here.

NOTES:

• I tend to refer to "encrypted" - RCOs aren't really encrypted, but just compressed in an unknown way.  I use this word for convenience purposes :P
  
• Everything is aligned to a 4 byte boundary, so basically all values are DWords.  There are one or two which are just Words however.  Thus, padding is used to achieve this 4 byte boundary at times
  
• Lengths don't include padding (obviously)
  
• For text entries, they are always separated by at least one null character

Anyways, there's 3 basic sections of the RCO.

Contents

• RCO Header
  
• Table section
  
• Data area

RCO Header

Offset	Type/Size	Purpose
0x00	DWord	RCO Signature, always is 0x46525000 (.PRF)
0x04	DWord	Appears to be a switch of some kind: 0x70 or 0x71 means normal table section 0x90 means a deflated table section larger values indicate that it's "encrypted"
0x08	DWord	Unknown - always seems to be 0x00
0x0C	DWord	Seems to change when different compressed headers are used: 0x00 = normal header 0x10 = deflated header 0x20 = "encrypted" header
For the following sections, 0xFFFFFF means the section doesn't exist
0x10	DWord	Offset of the "information"? table - always is 0xA4
0x14	DWord	Unknown.  Always seems to be 0xFFFFFF
0x18	DWord	Offset of the text table
0x1C	DWord	Offset of the sound (VAG) table
0x20	DWord	Offset of the model (OMG) table
0x24	DWord	Offset of the image (MIG) table
0x28	DWord	Unknown.  Always seems to be 0xFFFFFF
0x2C	DWord	Unknown.  Always seems to be 0xFFFFFF
0x30	DWord	Offset of the "page" table
0x34	DWord	Offset of the "anim" table
0x40	DWord	Offset of the label table
0x44	DWord	Length of the label table
0x48	DWord	Offset of the "native:/" table
0x4C	DWord	Length of the "native:/" table
0x50	DWord	Offset of the text pointer table.
0x54	DWord	Length of the text pointer table.
0x58	DWord	Offset of the image (MIG) pointer table.
0x5C	DWord	Length of the image (MIG) pointer table.
0x60	DWord	Offset of the model (OMG) pointer table.
0x64	DWord	Length of the model (OMG) pointer table.
0x68	DWord	Offset of the sound (VAG) pointer table.
0x6C	DWord	Length of the sound (VAG) pointer table.
0x70	DWord	Offset of the "page" pointer table.
0x74	DWord	Length of the "page" pointer table.
0x78	DWord	Offset of the "anim" pointer table.
0x7C	DWord	Length of the "anim" pointer table.
0x38	DWord	(note the offset) Offset and length to some text.  If this text doesn't exist, this value is the same as the value at 0x40, and length is 0x00.
0x80	DWord	Offset of the image (MIG) data section
0x84	DWord	Length of the image (MIG) data section
0x88	DWord	Offset of the sound (VAG) data section
0x8C	DWord	Length of the sound (VAG) data section
0x90	DWord	Offset of the model (OMG) data section
0x94	DWord	Length of the model (OMG) data section
0x98	DWord	End marker???  Always seems to be 0xFFFFFF
0x9C	DWord	End marker???  Always seems to be 0xFFFFFF
0xA0	DWord	End marker???  Always seems to be 0xFFFFFF

Table Section (begins at 0xA4)
If the table area is compressed (FW2.60), there are 3 DWords before the compressed data:

Offset	Type/Size	Purpose
0x00	DWord	Packed size of all the table sections
0x04	DWord	Unpacked size of all the table sections
0x08	DWord	"Something about the unpacked size of the next file after the packed header..." -Z33

For FW2.71+, the table seems to be packed in parts, rather than the whole table section packed together.


Now, back to the uncompressed header.
Each table entry seems to have a 40 byte header, followed by the entry data. (note, the "main entry" refers to the first one - which "contains" all the other entries)

Table entry headers

Offset	Type/Size	Purpose
0x00	Byte	ID of the current entry???  The main entry, seems to have a value of 1.  Some subentries seem to use this as the "depth" of the current entry.
0x01	Byte	Type of the entry.  Here's a few: 0x01 = main entry 0x03 = text 0x04 = image (GIM or PNG) 0x05 = model (GMO) 0x06 = sound (VAG) 0x08 = "page" 0x09 = "anim" The "anim" sections seem to have subentries with higher values
0x02	Word	Unknown - always seem to be 0x0000
0x04	DWord	Offset to the label (relative to the label table).  0xFFFFFFFF means the label doesn't exist for this entry
0x08	DWord	Size of entry header? (always 0x28)
0x0C	DWord	Offset of current entry to first entry (of same depth)?
0x10	DWord	Number of subentries in this one
0x14	DWord	Size of the entry
0x18	DWord	Offset to the next entry?
0x1C	DWord	Current entry offset from the main table (which is always 0xA4)
0x20	DWord	Unknown - always seem to be 0x00000000
0x24	DWord	Unknown - always seem to be 0x00000000
For entry headers longer than this, the rest is unknown

Table entry data
This varies, depending on the type:

Entry Pointer sections
These immediately follow the above tables.  They just contain absolute offsets to the various subentries above.  These sections are described by the values from 0x50 to 0x80, and follow the same order.
However, these seem to be out of order, and have "null" entries.  Don't understand why, lol


Text/"native:/" Tables
The "text tables" (offset is given at 0x40 and 0x48) are just ASCII text separated by null characters.  Each string is aligned to a 4 byte boundary (thus extra padding may be used).


Data Area
Basically, where all the data is stored...
Resources are aligned to 4 byte boundaries (thus padding may be used to achieve this).
Deflated resources have the 2 byte signature, 0xDA78.  "Encrypted" resources have the 2 byte signature, 0xD905.



Alright, that's all I really know about the RCO format - Z33 has some more info in his documentation (can be found here).

Hope this guide helped someone

double you tee eff!!!1

Quote:Does anybody remember PspIrDA? For the guys who don't, the homebrew application allowed you to transfer files between your PSP and your cell phone, PDA, PC, and pretty much any device compatible with the application's protocol (nope - no DS here). With that said, author Mat17 has just released version 0.0.2.

Major changes include improved device compatibility and transfer speed, although the application's GUI has been kept sparse. Mat notes that version 0.0.3 will carry improved transfer speed, and (it is hoped) an improved GUI.

Included in the bundle is a debug version of the app, along with this note from the author:

Quote:I've included in the archive a debug version which outputs a debug.log and dump.log files in the pspirda directory. So if this release does not work for you, try a transfer (send or receive) with this debug version and send me the corresponding debug.log and dump.log.

As always, wee recommend a thorough viewing of the app's README, along with a trip to the release thread for any further details. Wee thank Mat17 for the effort, and hope you guys enjoy trying this application out.

Source: http://pspupdates.qj.net/PspIrDA-v0-0-2/pg/49/aid/83443

Hmm, sounds quite an interesting program - hopefully it gets better ;)

Quote:Homebrew coder Gunner dropped by our forums today and posted that he is currently working on a new application called Frapsp that will allow users to capture and record game video footage. In case you've noticed, that is what exactly AdePSP's ScreenVideo Capture Module does.

However, Gunner added that he's gunning for a proper capture as well as a better and faster application than SVC. Frapsp is still in its early stages but the owner assures that it doesn't freeze the game. The games may run slower at times but he's working on it, Gunner added.

Frapsp currently uses usbhostfs.prx and psplink.prx butt he plans on including usb host into the plugin. Good luck to Gunner on his Frapsp! Wee are sure that the community will be there the moment you release this application.

Proof of Concept videos
Source: YouTube

Source: YouTube

Source: YouTube

Source: http://pspupdates.qj.net/Frapsp-new-vide.../aid/83453

Hmm, sounds interesting I guess, though I'm not sure how all that would actually work

nVidia, by far the best GPU maker of course :cheesygrin: has released CUDA, a C compiler package which allows programmers to run calculations on the Geforce 8800 and up series GPUs. CUDA uses the GPU as a coprocessors, so now software can be made that uses the GPU to do stuff so the CPU can do other stuff. Just to show how cool this is, the Geforce 8800 GTX has 128 cores (shaders) running at 1.1Ghz each. And with 2 of these cards in SLi setup, you have a 1+ teraflops system (which is really fast).

Link

Dark_AleX Wrote:Well something i did for myself because i will be a month outside with my chipped psp(and there are annoying things with it), but that i guess it will be welcomed by other up users.


3.03/3.10 OE mix for UP.

This is an OE update to let UP users have the vsh of 3.03 (which is more customizable) and the kernel of 3.10 to launch psp and psx games.

I have also done this thing to fix some annoying things for up users (pressing L at boot, and at recoveryng from sleep).

Instructions.

- On the PSP original nand, install 3.10 OE-A (or A', doesn't mattter because the patches of A' will be applied)
- On the UP nand, install 3.03 OE-C
- Copy 303_10 mix to GAME150, and run it from the UP nand.
- Done.

Now you will have the following benefits:

- 3.03 vsh, which you can customize.
- When you execute a psp or psx game, or a homebrew, OE will switch the nand to the psp one (containing 3.10 OE) automatically, so you will be able to play psx and psp games in the higher firmware, and since it will run on the psp nand, you won't have problems with psx games or with 333 Mhz.
- When you recover from sleep mode, OE will also be back to the nand you were, so you don't need to press L  (in fact, you must not press it :p)
- You can access both flashes via usb in the recovery.