Hacking the PSP Blog

ARComics to release graphic novels (a.k.a. comic books) on the PSP

GTA Vice City Stories out for pre-order

 The next installment in Rockstar Games's Grand Theft Auto series, Vice City Stories is out now for pre-order. Similar to its PSP predecessor, Liberty City Stories, Vice City Stories will most likely be a continuation, or a different viewpoint, of the plot which it is based off of, that of Vice City

Although not much information has been released yet, we do know that the game will be debuted on the PlayStation Portable, and will most likely move onto the PS2 and other consoles, as Liberty City Stories is currently doing.

So, for those interested, the starting price for pre-orders from US retailers is $49.99 and £39.99 from UK retailers. The game will ship on October 17 in the US and 20 October in the UK.

United States retailers

United Kingdom retailers

Related sites

The Complete PSP Homebrew Database Released! (thanks Fanjita!)

Gamers rejoice: Two new handhelds on their way? (another Microsoft, and even APPLE handheld story!)

Supposedly, two more handhelds are on their way to the gaming industry.

They aren't the Gizmondo, Tapwave, or some super-high tech cellphone. Apparently, Microsoft and Apple are making handhelds.

A handheld gaming system is a small unit that plays video games. For example, the old GameBoy that played the classic Tetris game.

Over the years, many companies have attempted to compete with Nintendo's GameBoys, such as Sega Game Gear, Turbo Express, Atari Lynx and so on.

Since then, Nintendo has pretty much dominated the handheld gaming industry with the GameBoy, GameBoy Color, GameBoy Advance, GameBoy Advance SP, and the current Nintendo DS. Sony joined back in 2005 with the unit known as the PlayStation Portable.

Now there's speculation Apple and Microsoft will be joining in.

PORTABLE GAMING ON RISE

The latest known name for Apple's handheld will be the gPod, which looks quite like the PlayStation Portable -- except without the joystick. It'll have all the same media players as the PSP including pictures, music, videos and a probable browser.

The various iPod models have been dominating the media player industry and now there's already an iPod Video out and all it needs is a game player.

Portable gaming is on the rise -- so why not try to join in?

When Microsoft decided to join the gaming industry, everything changed.

At the time, it was only Sony PlayStation and Nintendo GameCube. Then Microsoft joined in with the unit known as the Xbox, which has now advanced to the Xbox 360.

Time passed and the Nintendo DS (Dual Screen) and the PlayStation Portable have been competing. The consoles are set, and Microsoft has yet to attempt to join in with the handheld industry -- until now.

There is no known release information about it yet, but it's obvious they'll be joining in soon. There's talk the Microsoft's handheld may be called the "Xplayer" and there are no known images of it, either.

With one company dominating the media industry and the other one having everything but a handheld in their product line, a venture into handhelds seems obvious.

Ryan Inman
May 30, 2006

Source: Newsvine

Microsoft Likely to Enter Portable Gaming Market in Late 2007-Early 2008, Says The Diffusion Group

Sam Goody web site discount code

offer excludes Electronics Advantage, Used, Digital Downloads, and Gift Cards.

Nyko Releases PSP Car Adapter - FM Audio Transmitter + Charging Dock

Nyko Technologies, a maker of iPod and PSP accessories, today unveiled a new adapter for charging a PSP while at the same time broadcasting its audio over a car stereo. The new Power Tuner for PSP looks to be priced at $19.99 and available now.

The Power Tuner for PSP, said Nyko, operates both as a charger and an audio transmitter for Sony’s handheld gaming device. Drivers plug the Power Tuner into a car’s lighter or power port and then into a PSP to give it power. The unit also uses one of three selectable FM frequencies to transmit the PSP’s audio through a car radio to the vehicle’s speakers. It comes with a four foot cable for easier placement of the PSP within the vehicle.

"The Power Tuner enhances user experience by offering multiple features at a great price," said Susan Corben, vice president of marketing, Nyko Technologies, in a statement. "We've created the perfect travel companion for PSP owners on long road trips."

Griffin Releases a PSP Strap for Car Seats - The Road Dock

Lumines II - Trailer from E3

Metal Gear Solid: Portable Ops Trailer

Tekken PSP packs a new 8-way PSP D-pad in Japan

It's Apparently Real, Folks: "Undiluted Platinum" PSP Modchip Specs and Pic (will it ever see the light of day, or just the cold flourescent lights of a courtrooms and the reflections from Sony's attorney's spectacles?)

PSP owners, rejoice. Max Console has more details on the world's first PlayStation Portable modchip, the Undiluted Platinum. The chip (dubbed "U.P.") is a replacement flash that allows folks to run homebrew code on the latest PSP systems. Here's the technospeak from Max Console:

The U.P. contains 32MB NAND flash which is programmable from the PC via a high speed USB connection, using our user friendly software. You may boot the PSP from either its onboard flash or the flash contained on the U.P; the flash which is used is determined by a button press as the PSP is powered on (U.P. flash is used by default, hold L1 to use the PSP onboard flash). Since U.P. provides a secondary flash which the PSP can boot from, it can even be used to restore a PSP which has been "bricked".

Play homebrews and get the latest firmware updates? Brillant! Brian Ashcraft

More Here [Max Console] Thanks, Brad!

Other details from PSPUpdates:

Source: Kotaku

Sony Announces Adult Goods Brand - "Playstation Signature" Series

• Remote Control/Headphones: Special versions of Sony's MDR-EX90SL headphones and the PSP remote. 13,000 yen, available in white and black.
• PSP Stand: Has holes for the speakers. 2,200 yen, available in white and black.
• PSP Pouch: A leather case. 8,000 yen, available in white and black.
• Wrist Watch: Features a 39mm, simple, round case. Available with leather strap band for 73,000 yen or metal band for 68,000 yen.
• Wallet: Full leather, with PlayStation symbol colors used for stitching. 11,500 yen, available Summer 2006, only in black.
• Crew Neck Knit Shirt: 15,000 yen, available only in white.
• Wine Glass: Imprinted with the triangle, circle, X and square controller logo. 2,100 yen.
• Wine Opener: Has a gold-colored imprint of the controller logo. 4,200 yen, available Summer 2006.
• Photo Frame: Front is a mirror, back is made of wood. The frame attaches as a magnet. 3,500 yen, release in Summer 2006.
• Leather Note Cover: Has pockets and pen holder and is made of leather. 20,000 yen.
• Set of Two Ball-Point Pens: Controller logo is on pen cap. 2,600 yen, includes one each of silver and black.
• EMILIO PUCCI X PLAYSTATION Signature PSP Case: A PSP case designed as a collaboration with Emilio Pucci. Each unit has a unique design. 33,600 yen.

Super sweet deal on 1 GB Memory Sticks at Fry's - $25!!!

PC Demo for Loco Roco Available

Tiny Projector for PSP on the Horizon?

Rumor: PSP Modchip Coming Soon

A hardware solution would be more sturdy than the hacks people have been using so far to get the PSP to run custom code. However, if Sony can detect if the chip is installed, they can brick your PSP until you take it out, or somehow by pass that code. It never ends. – Jason Chen

Read: First PSP Modchip Announced - Undiluted Platinum! [DCemu]

Source: Gizmodo

Lemmings Now On PSP

Midway Announces Myst(TM) For Sony's PSP

Homebrew PSP MMO in the works

A brave programmer has taken up the task of trying to create the very first PSP MMO, actually, the very first MMO for portable consoles I believe.

His work is very green still, but it will be set in outer space and apparently you'll fly around different systems in order to accomplish different objectives, though nothing has yet been set or spoken about, other than technical details.

So if you want to follow his progress, visit his weblog by clicking on the link below, and who knows, perhaps a few months from now we'll have the first beta on our hands.

Off Topic: Game critics narrow down Best of E3

Journalists from 37 North American publications meld minds to vote on best of E3 2006; Gears of War, Nintendo lead pack. Winners announced next week.

See it »
Screenshot Index »

In the wake of the Electronic Entertainment Expo, the only thing almost as abundant as the trinkets and schwag being sold on online auction sites are the Best of E3 lists touted by various publications. However, one set of awards stands out from the rest as it represents a large sample of the gaming press.

The Game Critics Awards, first held in 1998, is decided by a group of dozens of journalists from different media outlets. This year, 37 judges participated in deciding the best games and hardware from E3 2006. Leading gaming editors culled from publications such as Newsweek, CNN/Money, The Los Angeles Times, Rolling Stone, and GameSpot chimed in on what they thought were the highlights of the conference.

Read the entire article here.

iHikes offers PSP-formatted hiking guides

Orb Fuels PSP Photo Fest

Click to enlarge 1 of 2

Click to enlarge

Less photos on your PSP means more space for games... [more images]

Off Topic: Sony May Try To Stop PS3 Game Resales

Do-It-Yourself Motion sensor for the PSP?

Tom Cruise Bans Xbox 360, DS, PSP, Sony PS3, Wii, and PC Games

(I wonder if he ever played the Top Gun video game? -Auri)

Tom Cruise bans his family from playing videogames for the Microsoft Xbox360, Sony PSP, Nintendo DS, PC, and any reading literature that contains Sony PS3 and the Nintendo Wii.

Pacific Design's PSP Gaming Flip Cases

Sorta Off-Topic: E3 Post Show Impressions #2

Gradius Collection Coming to PSP (Classic gaming fans rejoice!)

Tenchu Heading to PSP (with a snazzy level editor to boot!)

Hacking the PSP book reviewed on Geek.com!

1UP's Post E3 Special Show

Everyone is buzzing about the new Lost Planet demo on Xbox Live--it was the second most-downloaded item this week, just behind the mighty Halo 3 trailer; Ryan and Demian discuss why. And while we're talkin' 360, Mass Effect's behind-closed-doors showing almost won it 1UP's Game of the Show award -- we say what only the lucky few got to see.

Speaking of the lucky few, Mark and Bryan managed to avoid the crazy lines to play through the entire demo of Metroid Prime: Corruption on the Wii and left with some early opinions about what worked and what didn't. And let's not forget Nintendo's "other" system -- the DS had a fantastic show, epitomized by Shane and Jeremy's chat about Yoshi's Island 2 and the new Castlevania adventure, Portrait of Ruin. Even Boktai's spiritual successor Lunar Knights is looking good.

Finally, we finish up with two overlooked gems you probably never heard of: Metal Gear Solid 4 and Metal Gear Solid: Portable Ops for the PSP, including an interview with up-and-coming game creator Hideo Kojima. Take it from us, this guy is going places!

Source: 1Up

Update on Daedalus Nintendo 64 PSP Emulator Work-In-Progres

quote:

---

DynaRec Status

Just a quick update on the dynarec status, as I know a lot of people are more interested in this than the grizly details of branch delay instructions :)

Last weekend (13/14 May) I managed to assemble the fragment buffers into native x86 code, and execute this dynamically. I spent some time debating whether to target MIPS or Intel initially, but I decided that it would be a lot easier for me to debug the code generation on the PC than it would be to debug code gen on the PSP.

In the end I'm glad I started with the PC as it allowed me to fix a number of hairy problems without going down the torturous path of debugging self modifying code on the PSP with just a few printf() statements to help track down any problems.

To start with on the x86 code generation, all I did was convert my fragment simulator loop directly into assembly. So the generated code for each instruction in the fragment looked something like this:

set current pc
set branch delay flag
get op code in ECX
call handler for specified op code (from R4300.cpp)
if ( exception set ) exit to exception handler
if ( branch instruction and branch taken ) exit to branch handler


So a fragment with 100 instructions in would have this block repeated 100 times (with different pc, delay flag constants etc).

This generated a lot of assembly (i.e. 200KB or so of N64 instructions would generate over 4MB of x86 assembly, i.e. an expansion of around 2000%). At this point I wasn't interested in performance though - I wanted to make sure that I was preserving the behaviour of the fragment simulator as much as possible. The exception and branch handlers mentioned in the pseudo code above warrant more detailed description, but I'll leave that for another post.

At this point I spent a few hours debugging, but generally everything was working pretty well. The emulator was currently running around the same speed with 'dynarec' enabled as with it disabled (I use quotes because there isn't really much 'dynamic' about this code yet).

I spent the rest of the weekend and the early part of last week trying to optimise the generated assembly and see what I could get away with removing. One of the first things to go was setting the program counter before executing each instruction. The only instructions that need to know this tend to be branching instructions (which are relative and need to know the current PC to work out their target address) and other instructions that can potentially fire exceptions. The vast majority of instructions don't need to know the current PC though (e.g. arithmetic ops, logical ops etc).

Next I had a look at reworking things so I only needed to explicitly set the branch delay flag if a branch delay slot was actually active. I made the precondition that the branch delay slot was always clear, and explicitly set/cleared it when I knew the state needed to change.

Finally I removed exception handling from all the instructions I knew to be safe. For instance, I know ANDI (and immediate) can never throw an exception. As I only perform counter updates at the end of the block, an exception can never be fired when executing this instruction.

After all these changes I had an instruction execution block which looked something like this:

if ( pc needed ) set current pc
if ( branch delay instruction )set branch delay flag
get op code in ECX
call handler for specified op code (from R4300.cpp)
if ( can throw exception and exception set ) exit to exception handler
if ( branch instruction and branch taken ) exit to branch handler

This meant that the vast majority of instructions looked as follows:

get op code in ECX
call handler for specified op code (from R4300.cpp)


So I had nice big fragments like this:

...
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
...

Essentially I removed the vast majority of the instruction fetch/decoding overhead from the emulation.

With this version of the dynarec, 200KB of N64 code was now generating just 2MB of x86 assembly (i.e. an expansion ratio of around 1000%). The PC version was running around 60% faster with dynarec enabled than with it disabled, which is a pretty significant speedup (although this is still very early in the process).

What's also important is that this is before I've done any real optimisation of the generated code. For each instruction I'm still calling the generic instruction handler which has the overhead of figuring out which source registers to use, which register is the destination etc. The *real* speedup comes from generating code to handle op codes explicitly, as you remove all this decoding overhead along with the overhead of jumping to another function. Once you've removed most of the generic instruction handling you can start looking at caching register values to minimise the amount of memory that's being moved around.

With the PC version up and running fairly successfully, I've spent this weekend getting the PSP code generation working. I don't want to go into too many details (as I want to go into more depth in future posts), but I know people are keen to hear some news about how this is going.

I got the basic code generation working on Saturday morning (thankfully I'd already resolved most of the tricky issues in developing the x86 version the previous weekend). I spent most of Saturday afternoon fixing some really horrible instruction cache related bugs. I'm still not 100% sure I've fixed them, but it seems very stable at the moment. At the moment I'm at the same stage with the PSP version of the dynarec that I was with the PC version last weekend - the code generation is running fine (and executing on the PSP without crashing more importantly :) but I've only just started looking at optimising things. It's still too early to speculate on numbers for the performance improvement it will give. Currently it's running around 10% faster with dynarec enabled, but it's still very early days.

More soon.

Branch delay instructions

Well it's been a little longer than I intended since my last post. I've been busy with work, and when I've had free time I've found it hard to drag myself away from the compiler for long enough to post an update :)

In my last post on the subject, I left saying that I was trying to iron out bugs in the fragment 'simulator' and was about to start work on native code generation. I want to pick up from that point, but first I wanted to talk about about branch delay instructions and how they effect the implementation of emulators and the new DynaRec work I've been doing.

The couple of bugs in the fragment simulator were indeed to do with exceptions and interrupts triggering in unexpected places. The problem occurred if an exception was triggered in the branch delay slot following a jump instruction.

In case you're not familiar with the MIPS architecture, after branch instruction has been executed (but before control arrives at the target instruction), the CPU executes the instruction immediately following the branch. So to give an example, this is a block of mips code that calls the function foo( 6, 3 ):


li a0, 6 # load the first argumentjal foo # call fooli a1, 3 # load the second argument# the result is returned in v0 here...foo:jr ra # returnadd v0, a0, a1 # add the arguments, store result in v0



If you've never read MIPS assembly before this will probably look a little strange.
When we call foo with 'jal foo' (Jump and Link), we don't set the second argument until after the jump to 'foo'! Notice also that we calculate the return value for foo after we return with the Jump Register (JR) instruction.

The reason this code works is because of the branch delay slots. When the call to foo is executed ('jal foo') the CPU keeps going for one more instruction and executes 'li a1, 3'. Control then jumps to the start of 'foo', where the CPU immediately executes 'jr ra', jumping back to where it just came from. Again, the CPU executes the following instruction, calculating the sum of the arguments and returning the result in v0.

Although this seems rather pointless and unnecessarily complicated, it serves a very good purpose. With most modern CPUs the instruction execution is pipelined, which means that the processor breaks down the work into discrete chunks (fetch instruction, decode instruction, execute, commit etc), and executes multiple instructions in parallel. Wikipedia (as always) explains this in a lot more detail.

With many architectures the CPU has to throw away the contents of the pipeline when a branch is executed, as the subsequent instructions may refer to data (register or memory contents) that is invalid until after the call has completed. With certain architectures (including MIPS), the engineers decided that it was wasteful to throw away all this work on every branch, and designed the processor to continue processing the pipeline until the subsequent instruction had completed.

What this means is that when writing code for MIPS processors, you have to be careful that your branch delay slot doesn't have any unintended side effects. For maximum efficiency you also have to be careful to try and do useful work in the branch delay slot (rather than just filling it with a NOP for instance). Normally this isn't an issue as the compiler generates all the code for you, but it's certainly an issue if you're writing assembly. It's also been a very important consideration when I've been writing the code generation for the new DynaRec (I'll cover this in a later post).

So, how do branch delay instructions effect emulators? Although they help pipelined CPUs to improve performance, they require emulators to do bit of extra bookeeping and this slows things down slightly and adds complexity. Every time daedalus interprets an instruction it has to check if a branch was taken, and if so set a flag to indicate that a branch delay instruction is due to be executed. When the branch delay instruction is executed, the flag is cleared and the emulator sets the program counter to the original target of the branch.

This is all fairly straight forward, but complications arise when exceptions fire as a branch delay slot is due to be executed. In the example above, what would happen if an interrupt fired immediately before the branch delay instruction 'li a1, 3' was executed? Normally once the interrupt has been handled, the operating system restores control by jumping to the instruction that was due to be executed, allowing the program to run from that point. If this happened in our example above, a1 would be loaded with the value of 3, but the jump to 'foo' that was originally delayed will never take place. The code would continue running without ever calling 'foo'!

In order to handle this situation, when an exception (or interrupt) is triggered, the CPU sets a flag in the 'cause' register. The operating system keeps track of this flag, along with the program counter where the exception fired and various other bits of information. When it's done handling the exception, the operating system uses this information to allow the CPU to correctly restore control to the code that was originally executing. In our example above, the CPU would see that the branch delay flag is set in the cause register, and restore control to the jal instruction immediately preceeding the instruction where the interrupt occured.

It should be fairly clear that there's quite a lot that must be taken care of by the emulator to make sure that the program executes as intended. This is all fairly simple to keep track of when processing instructions individually, but it becomes more complicated when you start to dynamically recompile the code.

The bugs that I mentioned at the start of this post were caused because I wasn't correctly setting the branch delay flag for instructions causing exceptions in branch delay slots. When I build fragments for the dynamic recompiler I avoid triggering certain types of interrupts (e.g. vertical blank and timer interrupts) in the middle of the fragment to reduce the overhead of having to add the code to handle these situations. Unfortunately there are many other types of exceptions that can occur in the middle of a fragment, such as page faults, I/O completion interrupts etc. It turns out these are very rare, but unfortunately not rare enough to save me from a full day of debugging :(

This was a little more detailed than I was originally planning. Branch delay instructions are quite a simple concept on the surface, but they can cause all sorts of complexities when it comes to dynamic recompilation. Fortunately I feel very confident that I've now fixed all the branch delay related bugs in the dynamic recompiler, so hopefully I shouldn't have to think too much about them again in the near future.

I'll follow up this post with a quick update on the state of the new dynarec engine.

---

Herald Review: Handheld Releases a Mixed Bag

Datel Announce Max Media Dock for PSP & DS - Compact Flash Adapters

PSP Gets Some Hot Titles This Week - 21.5.06

• Jaws, May 23
• Puzzle Challenge: Crosswords & More, May 23
• Rogue Trooper, May 23
• Steambot Chronicles, May 23
• Teen Titans, May 24

• FIFA World Cup 2006, May 22
• Field Commander, May 23
• Lemmings, May 23
• Monster Hunter Freedom, May 23
• Puzzle Challenge:Crosswords & More, May 23

• Rockstar Games Table Tennis, May 22
• Call of Duty 2: Game of the Year Edition, May 25

• Jaws, May 23
• Rogue Trooper, May 23

• Zoo Tycoon 2: African Adventure, May 22
• Devil May Cry 3: Dante’s Awakening Special Edition, May 23
• Heroes of Might and Magic V, May 23
• Rogue Trooper, May 23

• Teen Titans, May 24

• Backyard Baseball 2007, May 22

Maxim Sizzles onto your PSP this summer!

Video: The DS Sucks, Folks. Look It Up.

This video editorial from Jon of Talking With Jon fame clearly outlines why the Nintendo DS is inferior to the Sony PSP. For instance, can you use the DS as a PlayStation 3 controller? No. Is the DS widescreen, the future of gaming? No. Does it have the gigabytes? No. Can you play it without plugging it into the wall? Apparently not. Pretty damning evidence.

Before you go out willy-nilly buying game portables, watch this video. You will say "Huh.". You will say "Wow!". You will say "I can't believe I just watched that for 12 minutes...". — Michael McWhertor

Source: Kotaku

Metal Gear Solid Portable Ops on Sony PSP

PSPRadio 0.38.10 Released!

Reverzi Coming To PSP!