Leaked photos have emerged purporting to show a new, smaller revision of the Xbox 360 motherboard, provoking speculation that Microsoft is set to relaunch its console later in the year. Xbox 360 Slim any one?

Similar to the PS3 Slim leaks last year, the pictures emanate from an obscure Chinese message board, and the shots of the motherboard certainly look genuine, with enough of the original 360 components in view to suggest authenticity. They also display several new, original features, plus of course a smaller form factor.

By comparing parts common to the current model, it appears that this most fundamental of components is over a third smaller in size than the Jasper revision 360 board.

Two shots have been revealed so far. The first is a top-down view of the board itself, suggesting a smaller, squarer layout topped off with a conspicuously off-the-shelf Coolermaster fan. The second shot sees the leaker removing the cooling assembly to reveal what appears to be an integrated Xenon and Xenos CPU/GPU combination package, which ties in nicely with the so-called Valhalla revision of the 360 first mentioned a couple of years back and also believed to be based on a single combined processor set-up.

The shot to the left shows the full board, while the right pic reveals what appears to be an all-in-one CPU and GPU package underneath the pre-production cooler.

While the single heatspreader underneath the cooling assembly strongly suggests a unified design for the core hardware, the leaker hasn't had the courage to remove it completely and expose the dies below, which would settle the issue completely and would also allow us to ascertain whether Microsoft is using a 45nm or even smaller fabrication process for the unified chip.

Smaller parts mean a cooler, more power-efficient, cheaper-to-manufacture system and even the current, apparently reliable 360 is still running a 65nm process for both chips. The PS3 Slim in contrast runs at 45nm for the CPU and 65nm for the RSX, and a single package within the 360 would allow Microsoft to pursue an even more aggressive price-cutting strategy if it needed to do so.

What is interesting is that the board has doubled the number of SATA connections to two over on the top-left of the first picture. In current 360 hardware, only one is used for connecting up the internal DVD-ROM drive.

This could mean that Microsoft is planning support for internal drives, but bearing in mind the success of its Arcade SKU, it is unlikely that the firm would commit to HDD-integrated machines: laptop drives don't generally get cheaper, they just get bigger in terms of storage, and for Microsoft to surrender one of the factors behind its price advantage is unlikely. It's more probable that the drives will come in new Slim-friendly caddies.

Another curious change appears to be the complete omission of any mounting holes for the DVD drive, which clearly sits to the left of the fan. Either a variant of the existing DVD drive attaches to the case in a different way, or else an entirely different assembly is used. Assuming the costs work out, we could even be getting a thin, slot-loading drive similar to the PlayStation 3.

The location of the optical drive itself is a big improvement over the existing Xbox 360 design, which places the DVD-ROM directly above both CPU and GPU, further complicating the cooling of the hottest parts of the console. The cooling setup doesn't really tell us much. The Coolermaster fan would be way too large for a production console, plus you'll note that the fan itself is only secured in one place to the heatsink below.

There's nothing on the board that suggests any kind of onboard Natal, meaning that the new 360 still requires a decent array of USB ports, though it looks as though the MU readers have been cut down to just a single slot.

In part understandable but at the same time rather disappointing is the omission of any kind of Wi-Fi chipset on the motherboard, so it does seem as though extortionately expensive wireless internet dongles will remain the standard if the pics are valid.

On the bright side, however, the just-as-stupidly expensive audio dongle appears to be a thing of the past, with what looks very much like a Toslink SPDIF optical output directly above the fan to the left, next to what we can assume is the current Xbox 360 AV port, with HDMI output to the left of that.

Other than that, no surprises, though we can assume that the top-right socket is for the power supply, which will almost certainly remain external in contrast to the neat internal PSU in the PS3 Slim.

Comedy cooling fan aside, there's nothing here to suggest that this isn't the real deal. It's just too well-designed to be a fake and in a world where PS3 Slims turn up months in advance on in a Philippines marketplace, leaked pics surfacing on a Chinese forum are eminently plausible.

Even if it's not a 360 Slim, the radical change in form factor and mounting holes means that this revision of motherboard cannot physically fit inside the current shell and certainly not with the current DVD drive.

A 360 relaunch for Natal then? Microsoft has already issued its obligatory "we don't comment on rumour and speculation" line.

(This piece has been updated! Scroll down for additional clarification of our measurements.)

Bold claims have been made for PlayStation Move in terms of its latency, or so-called controller lag. At both the GDC press and developer events, Sony itself pegged the lag of the new motion controller at "under one frame".

Previous information from the guys who created the PC drivers for the PlayStation Eye camera also indicated that the mechanism is extremely low latency. In that case, a lag of one frame was measured, and the chances are that in this case it was probably impossible to measure if it was actually any faster.

At the nuts and bolts level, then, it's difficult to argue with the case being put forward when both official and independent sources corroborate each other so closely. In use, however, on actual PlayStation Move software, it's clear that there is some level of latency.

Regular readers of Digital Foundry will know that lag is basically inevitable. The creation and flipping of a framebuffer within the console causes lag, and in measurements (not just ours), the very fastest response has come from the PS3 XMB, which has been pegged at three frames, or 50ms.

On top of that, of course, the proliferation of flatscreen panels means that we have display equipment where latency can change radically even between screens made by the same manufacturer. Anything from two to five frames' additional delay (33ms to 84ms) is fairly common.

Muddying the waters still further is that the PlayStation Move is such a precise implement that game-makers may feel the need to smooth the input, reducing natural player jitter, but again introducing further latency.

So, with all that in mind, I set out to get some idea of the lag in Sony's motion controller while at GDC. The chance to get hands-on with Sony's augmented reality demo (used by the firm itself in demonstrating the controller's tech credentials) was probably the best possible test, and presumably the screens Sony used would be the very fastest consumer-level panels it has bearing in mind just how much "precision" was mentioned at both of the company's GDC events.

A cheap and cheerful Kodak Zi6 handycam was used to film the proceedings. It's an unremarkable camera, but it can film at 60 frames per second, making it very useful for measurements like this where temporal resolution is far more important than the number of pixels.

Hanging out with the Move waggle homies, testing motion controller response.View this video in HD

The augmented reality demo is a worthwhile test for a number of reasons. Firstly, actual game-level processing is at a minimum. The demo is simply displaying the camera feed (in itself used for some of the motion control calculations), and overlaying a couple of fairly simply 3D shapes. Make no mistake, this isn't some Killzone 2 level workout of the PS3 hardware.

While exact latency measurements aren't possible in these conditions, a ballpark idea of the level of response isn't a problem at all. The methodology is remarkably straightforward. Keep your hand as steady as possible, then make fast motions with the controller. Count the frames between your hand moving, and the motion being carried out on-screen.

Equally illuminating is to stop your movement suddenly, then count the frames necessary for your on-screen counterpart to catch up. While not 100 per cent accurate, repeat the process enough times and the frame difference becomes fairly evident.

Bearing all of that in mind, and recognising that we don't know how much latency the display itself is adding, I'd say that a ballpark figure of around 133ms of controller lag (give or take a frame) seems reasonable, certainly not the ultra-fast crispness of response we see from games like Burnout Paradise or Modern Warfare, but fine for most of the applications you would want from such a controller.

Also worth remembering is that the motion control itself is only a part of the mechanics within the Move. Much of the internal mechanics, along with the button presses, will all be sent to the PS3 via the Bluetooth connection: lightning-fast and perfectly equivalent to the response levels of the DualShock 3. In terms of a more definitive test, a 60FPS game with comprehensive support for both Move and the traditional controller could be interesting...

Update: Some interesting feedback to this piece, so I thought an update with clarification on the measurements would be in order.

First up, I chose to use this demo as a best-possible example of Move operating in ideal conditions - no game logic running and basically in "tech demo mode", so as close as conditions allowed to what we would hope to be gameplay at optimum conditions. This is what the video itself is showing - the time taken between input by the player and it being recognised, processed and displayed by Move.

This is the generally accepted definition of controller lag (certainly what's been used in our previous pieces on the subject, and that includes the 200ms pre-production Natal measurement), although we do like to filter out the display lag in the measurement where possible - and in this case, we can't. So hopefully this element of the piece is now clear.

So, to put it plainly, based on frame-counting of the motions shown in the video, and others, the measure of 133ms overall is an indication of the gameplay experience as the camera captured it. So, this includes controller and camera input, processing, display of the completed frame plus the additional latency from the LCD (probably in the region of one to two frames on a set like this).

Interestingly, this measurement puts us in the ballpark area of the PlayStation Eye test I did a couple of weeks ago. As mentioned at the beginning of the piece, there is independent corroboration for Sony's sub-frame latency claim at the mechanical level, but the key measurement comes from gameplay.

So, this is indeed a tentative analysis with one big unknown remaining (the lag of the display itself), and others still undefined, for example whether the demo itself is smoothing the data and introducing further latency as a result.

However, as an indication of the response level of the games played at the GDC reveal (and I played them all), this overall measurement seems sound in the meantime. Once the controller is here in the office, we can get it running on properly calibrated equipment to see how close we are.

Epic Games' senior console programmer Josh Adams officially introduced game developers to the new iPhone edition of Unreal Engine 3 at the Game Developers Conference this week.

While much of the presentation concerned how Epic's Windows-based tools interfaced with the Mac-based "XCode" workflow of the iPhone development kit, Adams also showed a working model of an Unreal Tournament level running on the Apple device, with the developer confirming that the demo refreshed at a rate of 25 to 30 frames per second.

Adams described the process of bringing UE3 to iPhone as a fun "can we do it?" project, based on Open GL ES 2.0, meaning it will only work on the newer Apple devices such as the iPhone 3GS, the iPad, and the third-generation iPod Touch. UE3 won't work on older iPod Touches and iPhones as they do not support the programmable pixel shaders that the engine requires, but, as newer, faster devices in the mobile Apple family appear, Epic's engine will obviously scale with them.

Interestingly, during the presentation Adams also revealed a range of unsupported platforms that Epic currently has Unreal Engine 3 working on: Linux, Mac,and NVIDIA Tegra 2 (potentially very interesting if the Nintendo DS 2 rumours turn out to be true).

Converting Epic's middleware to the iPhone was no mean feat. The engine itself consists of two million lines of code in a 16MB executable, with 90 per cent of that code being platform-independent, with the other 10 per cent tuned to the hardware it is running on.

Almost all of the core functionality of the engine remains in the iPhone iteration of the tech. The same gameplay, collision, math routines and even file formats are used. Game-makers used to the Unreal Engine editor use the exact same Windows-based toolset when developing for iPhone. Where Epic had to make changes was primarily in the Render Hardware Interface (RHI) - the "thin layer" between the engine's render thread and the host platform's API.

Josh Adams also described how Unreal Engine lights environments. The code gathers up static and dynamic lights decided upon by the artists and turns them into just one or two lights instead, with directional, ambient or spherical harmonic lights all supported. This is great for iPhone in that many lights set up by the artists or generated dynamically during gameplay have a very low rendering cost.

New code was created to cope with the iPhone's unique controls. Buffers are set up that store up the touch-screen inputs, which are then all processed as each new frame is rendered. Tilt functions are polled in a similar time period but without the buffering. Adams also talked about how the iPhone 3GS's magnetometer was considered as a means for enhancing turning information, but was dismissed owing to the fact that the input it generated turned out to be unusable while the CPU cost for accessing the function was prohibitively high.

Changes made to the core Unreal Engine renderer were twofold. First of all, the shift to Open GL ES 2.0 had to be accommodated (by expanding upon the existing Open GL driver) and secondly, the fact that the mobile chipsets are considerably less powerful than UE3's usual target platforms had to be taken into account.

Unreal's shader support was completely overhauled. The engine works with thousands of shaders, with between five and 20 of them being used for just one material. Epic's solution was to "auto-flatten" these shaders into a single texture while adding preview support to the PC editor so artists could see how the final art would look on-screen.

While precision is lost (as is support for specular and normal maps), the effect looks similar and as the final work is displayed on a very small screen, the diminished quality is not so apparent. Epic's normal art pipeline can still be used, there are fewer textures to load and it obviously runs faster on the mobile platform.

Another weakness Josh Adams identified was within Open GL ES 2.0 itself. Games optimise their rendering through occlusion culling - killing polygons that are invisible to the user. Occlusion queries aren't supported in ES at the moment, meaning that levels created with Unreal Engine have to be smaller as a result.

Going forward, Epic expects the iPhone, iPad and iPod Touch devices to get progressively more powerful as new hardware revisions hit the market. Newer hardware obviously means more power and the engine-maker expects support for specular and normal mapping to be included at some point, and for prominent "hero" artwork (for example, your main character) to get full material support.

Epic also expects the occlusion query issue to be solved in a later rendition of the Open GL ES 2.0 driver, which should allow for larger, more complex environments. UE3's integration with other middleware - for example, GameSpy and PhysX - will also be added to the iPhone engine as when they are ported across to the mobile format.

When the iPhone version of UE3 was first announced, Epic revealed that it would also support "another platform", which is obviously the recently announced iPad. Josh Adams told GDC delegates that Epic doesn't have access to iPad technology right now and that the firm was no real idea of just how much power the new hardware will bring to the table.

The iPad itself is widely believed to be running a 1GHz ARM A8 Cortex CPU, combined with a more highly clocked version of the same PowerVR SGX535 chip found within the iPhone 3GS. According to Epic, bottlenecks in performance with UE3 on the mobile platform are mostly down to the CPU and as a consequence, the graphics chip isn't really being stressed at all.

So while the short Unreal Tournament demo we had on the iPhone 3GS looked impressive, potentially the iPad architecture could see some fairly radical performance increases - even after factoring in the enormous resolution boost of the iPad's screen.

It took Epic four man-months of work with a two-man team to bring Unreal Engine 3 to the iPhone, and based on the surprise reveal of Tegra 2 work, it's clear that the company is very interested in bringing its middleware to a wide range of mobile platforms. Asked whether UE3 would be heading to Android, Josh Adams pointedly declined to comment...

We've not heard much from Bizarre Creations since the release of The Club and the subsequent Activision buy-out, so the chance to check out the Xbox 360 multiplayer beta of the forthcoming Blur proved to be irresistible.

The firm's last 360 title - Project Gotham Racing 4 - was a handsome-looking game with native 720p, a rock-solid 30FPS and 2x multisampling anti-aliasing, boosted by excellent post-processing effects that helped to significantly enhance the sense of speed and the realism of the simulation.

With Blur, the approach shifts to a more arcade-like experience, with shades of Mario Kart and WipEout in its use of power-up weaponry and intense vehicle-to-vehicle combat. However, Bizarre's focus on solid-looking visuals and impressive effects work hasn't changed.

So how does the performance look based on the beta code?

Bizarre Creations has handed in a game boasting absolutely rock-solid performance.View this video in HD

The answer is "remarkably well". From start to finish, no matter how much is happening on-screen, Blur maintains its 30 frames per second output without a single dropped frame, and thus not a single fluctuation in the graph, which is as even and consistent as previous record-holder Dante's Inferno.

Tech-wise we see a slight upgrade in the framebuffer format compared with PGR4. The game retains the native 720p resolution, but anti-aliasing is upped to the Xbox 360's maximum 4x MSAA. While background geometry levels are a little on the low side in the beta, the eye is kept occupied owing to the sheer amount of vehicles on-screen at any given moment.

In short, Blur is looking as solid as we would expect from a Bizarre Creations title and we're looking forward to checking out final code on all formats. Blur is due out for PC, PS3 and Xbox 360 on 28th May.

Back in 2005, Sony Santa Monica redefined the technical limitations of an entire console generation with the epic God of War. Five years later, the team has done it again with its debut PS3 outing. God of War III is magnificent.

But you've played the game already, right? Last year's E3 demo received a limited release in Europe before the code was circulated widely with the US release of the God of War Collection, and the sampler was recently made available as a general release on PlayStation Network.

Checking out the final God of War III review code, it is obvious that while impressive, the demo is simply not fully representative of the finished game. Understandably, extensive amounts of content didn't make it into the sampler, but more than that a range of visual effects have been added and performance has been improved considerably.

For the sake of not spoiling the game, we won't cover the additional content (cool though it is!), but a comparison of effects and performance offers an intriguing window into just how much the Sony Santa Monica tech team squeezed out of the hardware in the final months of God of War III's development.

Perhaps the most obvious change to the game is an extensive retooling of the lighting scheme, which for the most part is now much richer and more realistic. Dark areas of the demo level now seem to more accurately represent the effect of the ambient light on the environment.

The most obvious change is in the lighting of the entire level - far more of the art detail is now more readily apparent.

A realistic, per-object motion blur has also been added to the game. This has the effect of giving the game more realism in motion, but does have the unintended side effect of not looking so clean in screenshots.

The final God of War III has a much more 'film-like' quality about it owing to the excellent motion blur implementation.

It's interesting to note that the Sony Santa Monica team has made a number of graphical improvements across the board, some very noticeable, others subtle. The changes on the Titan are immediately apparent, with an obvious level of increased detail in the skin texture.

Close-ups of the Titan in the demo show a lack of detail compared to the version in the final code.

Smaller tweaks to the level are also apparent. In this brace of shots, we can see that the team has added additional shadow effects that were not present in the demo.

Note how shadows have been added to the boxes on the left of the screen in the review code, compared to their omission in the demo.

The fire effect on Helios's circling chariot now looks much more detailed, and you can also see how the main light source that influences the environment has been changed between the demo and retail versions of the game.

Many of the effects optimisations appear to give God of War III a less CG-like feel.

It's also interesting to note that Helios himself now looks subtly different compared to his debut in the demo. There's dither on his hair in the demo that is much reduced in the final version. Could it be an effect of God of War III's new anti-aliasing technique? According to posts on the internet by Sony Santa Monica itself, God of War III is using an implementation of morphological anti-aliasing, carried out by the SPUs. This achieves superior edge-smoothing, and is another example of how offloading tasks typically done on the graphics chip can result in both performance and quality increases.

Again, the more 'game-like' elements of the scene have been refined.

Bearing in mind just how much of a visual upgrade the game has had, it's impressive that the improvements do not restrict themselves simply to visual quality. Sony Santa Monica has achieved all of this while creating a faster, smoother game. In this video we have several different clips taken from a playthrough of the God of War III demo. These have then been matched with action taken from the same areas in the review copy of the game.

Not only has there been a huge improvement in visual quality, performance has also been boosted significantly. Blue line indicates review copy performance, while cyan follows the demo's frame-rate.View this video in HD

The conclusions from the video are enlightening: the video above shows a significant improvement in frame-rate in like-for-like scenes. In our analysis of the E3 demo, we were curious about why the game ran with an unlocked frame-rate when in the thick of the action, frame-rates were around the 30FPS area anyway. Looking at the final game, the performance increase speaks for itself, and while there is still noticeable judder incurred by the variable frame-rate, the effect is mitigated somewhat by the quality of the motion blur.

We'll have more on God of War III soon.

Just Cause 2 is a game that pushes all the right buttons for us here at Digital Foundry. Proprietary engine? Check. Scandinavian developer? Check. Colossal open world? Ingenius physics-based gameplay? Epoch-making pyrotechnics? Check, check, check!

The arrival last Thursday of demo code for PlayStation 3 and Xbox 360 gives us our first chance to properly evaluate the technology and performance of the respective console versions within the DF lair, away from the compromises of compressed internet video.

Not that Avalanche's various gameplay vids aren't worth checking out, mind you: they effectively showcase the range of gameplay possibilities made possible by the tech.

It's exciting stuff - not just gamers, but for other game-makers too. On a recent DF visit to a developer currently working on a triple-A title, Avalanche's videos were being showcased at a team meeting on a 50" plasma. Interestingly this presentation wasn't about polygon counts, LOD biases or framebuffers. They were checking out the footage because Just Cause 2 looked like fun to play.

Central to the game's appeal is the inclusion of an extremely long grappling hook. You use it to winch yourself onto just about anywhere within the huge environments, or else to effortlessly hijack speeding vehicles.

Its offensive capabilities are impressive too. Sure, you can use it to pull opponents towards you, but the ingenuity of the grapple-gun comes down to its ability to link enemies and objects together. Attaching your opponent to a barrel that's about to explode has its appeal, as does connecting them to a passing vehicle.

Beyond the grappling, the key appeal of this game is its environments, and this is where the technology Avalanche has been working on comes to the fore. The rendering distance of the gameworld is absolutely colossal, with an impressive level of detail retention even in the most faraway areas. Jump into a chopper to reach stratospheric heights and check out the view: this sort of stunt was impressive in the first Just Cause, but it's been taken to a new level in the sequel.

The overall feel of the game is bolstered by an impressive lighting model, with smooth atmospheric effects. Transparency elements such as particles, clouds and explosions look very smooth indeed. Despite the 34 square kilometres of gameplay world available in the demo, water sources within the playable area are hard to locate (the available play area is so vast, we're still looking). How Avalanche has handled this effect in both of the console builds will be interesting to see.

Early impressions are that PlayStation 3 and Xbox 360 owners have been well-served by Avalanche's code-smiths. However, it is curious to note that while overall the similarities between the console games outweigh the differences by quite a margin, Avalanche has chosen two different approaches to the performance aspect of Just Cause 2. The headline news here is that the Xbox 360 version can drop v-sync while the PS3 game does not.

Let's kick off with a performance analysis of the Xbox 360 version.

Just Cause 2 on Xbox 360 caps frame-rate at 30FPS, but does tear when the engine is put under stress.View this video in HD

Few surprises here. Avalanche has capped frame-rate at 30FPS. In order to maintain fluidity and consistency in response, when the game engine struggles, v-sync is lost and torn frames enter the equation. In the course of this video a mere eight per cent of the 60Hz output of the Xbox 360 consists of torn frames. Cut-scenes apart (which both consoles struggle with in their own way), the game only really seems to suffer when big explosions kick-off.

There's no problem at identifying the core attributes of the framebuffer here. Just Cause 2 on Xbox 360 has the full, requisite 1280x720 and implements 2x multisampling anti-aliasing.

Now let's turn the focus to the PlayStation 3 rendition of the demo.

PlayStation 3 Just Cause is a tear-free zone with a uncapped, variable frame-rate. View this video in HD

Here we see a very different FPS graph owing to a change in the rendering attributes of the Avalanche engine running on PlayStation 3. The game maintains v-sync throughout, making for a higher consistency in image quality as you play. Also note that the PS3 game runs without a frame-rate cap while overall maintaining an average just a notch below 30FPS - just like Xbox 360.

It's not the first time we've seen v-sync/tearing differences like this before, of course. Resident Evil 5 had a similar setup, albeit without the unlocked frame-rate. Why Avalanche has gone with two separate approaches like this is curious: it may well have been the case that performance of both platforms was analysed and the best was chosen for each according to how the engine performed on each architecture.

In terms of image quality, Just Cause 2 appears to use 2x quincunx anti-aliasing, though this is not conclusive owing to the fact it appears to be used relatively sparingly - some edges get smoothed, some do not. Getting a good reading is also made more difficult owing to the way bloom is deployed, and there's plenty of it in Just Cause 2.

Another interesting difference concerns the shadow-rendering. Low-resolution shadows with obvious serrated edges close-up can be seen on both versions of the game, though these serrations are a touch smoother and more refined on PlayStation 3. More obvious is that the inclusion of a camera-based motion blur only appears to have been implemented on the Xbox 360 game

Other elements of the engine appear to be pretty much like-for-like on both console platforms. There's fairly well handled geometry LOD popping on trees and shadows - it usually happens so far away that the eye doesn't really pick up on it. Depth-of-field seems to mask foliage as it transitions into a lower resolution alpha texture.

Bearing in mind how colossal this gameworld is, and how much of it you see, perhaps the biggest question mark remaining concerns just how Just Cause 2 plans to stream its data. Mandatory install on PS3? Lower performance running from DVD on Xbox 360? What about load times?

These are the sorts of thing we'll be looking at in the forthcoming Face-Off. We'll also be factoring in the PC version of the game too. Avalanche is looking to offer plenty of goodies for PC owners with NVIDIA graphics cards: there's 3D Vision compatibility, plus promised support for the GPU-specific programming language, CUDA. And Avalanche is promising an impressive battery of visual effects for CUDA-capable GPUs, which we're looking forward to checking out in the final game.

Just Cause 2 is due out for PC, PS3 and Xbox 360 on 26th March.

The panic is over. Just as quickly as they were crippled, "fat" PlayStation 3 consoles worldwide started working again as their faulty internal clocks moved away from the fateful date of 1st March 2010. Sony can breathe a deep sigh of release: no firmware update patch will be needed (for a while at least), no hyper-expensive recalls will be required. Everything is as it was. Balance has been restored.

So, what actually happened? And will it happen again? Throughout the debacle, Sony referred to the issue erroneously as a "network connectivity" problem, with the blame pinned squarely on poor old PSN.

However, as gamers rallied and experiences were shared, it quickly became obvious that the issue was far more serious: consoles that were disconnected from the internet displayed the same problems as those that accessed PSN. This wasn't anything to do with the online service, but everything to do with a specific piece of hardware within the PlayStation 3.

The PS3's internal clock is completely invisible to the end user and is used to sync with PSN, as well as time-stamping trophies and downloadable content activation certificates. Yesterday, with this invisible master clock now set to a date that simply didn't exist due to a misunderstanding of leap years, most trophy-supported games wouldn't launch either online or offline, PSN couldn't be accessed, and the activation certificates for downloaded content became invalid. Those affected were left with a games console that wouldn't play games.

Early yesterday afternoon, PS3 users on the #Efnet IRC network claimed to have pinpointed the problem. A small ARM Syscon CPU dedicated to menial tasks within the PlayStation 3 was known to have an issue dealing with leap years. The same piece of silicon had a history of causing similar aggravation for mobile devices with the likes of Zune and some Blackberry devices afflicted. In those cases, MSFT and RIMM were on top of the issue. Sony, unfortunately, was not.

As it happened, the fix for this issue was remarkably straightforward. Similar to a PC motherboard exhibiting CMOS memory issues, the ApocalyPS3 could be resolved by opening up the PlayStation 3, removing the button-shaped battery and letting the power dissipate internally. If you re-inserted the battery and reconstructed your PS3 10 minutes later you were good to go. Great if you're confident dealing with electronics and happen to have a set of the special Torx security screwdrivers needed to disassemble the PS3. Not so great if you're just a regular gamer, nor if you fancied retaining your warranty (if you still have one for a "fat" PS3 anyway).

In the here and now, the problem has righted itself and a patch for the ARM controller can be incorporated at Sony's own pace into a future firmware update. Internally the company must surely be relieved about the bullet it has dodged. Unofficial community-compiled lists of "fat" PS3 hardware affected by the problem suggest that of 11 different SKUs, eight of them use the bugged controller chip, resulting in a colossal amount of affected users.

This isn't just thousands or tens of thousands of units, it's surely millions of them worldwide. While an internet-delivered mandatory firmware update could have solved the problem, it's difficult to imagine how Sony would have handled the multitudes of these units in homes with limited or non-existent internet connectivity.

Thankfully such desperate measures not required. Power up your PS3 and you're back in action. The raging, NSFW fat bloke on YouTube can return to "owning noobs" and that comment-writer on the EU PlayStation blog can probably revise down his estimate that ApocalyPS3 is equivalent to "9/11 x 1,000". However, one of the most disturbing things about the whole episode was the lack of accurate or worthwhile information from Sony itself.

While pointing out the slim owners were safe in its initial blog posting, there was never any acknowledgement that offline consoles didn't work either. Promised updates on Sony's Twitter page never happened in a timely manner, nor offered much in the way of useful information.

As the real cause of the issue became common knowledge within the community by mid-morning, Sony urged gamers not to "trust info regarding this issue unless from an official Sony source" but failed to produce any meaningful information until the late afternoon when the internal clock issue was finally confirmed to be the culprit. The lack of clear, unambiguous information on the root cause and how it would be fixed was disappointing to say the least.

Clearly there are lessons to be learned here and it will be interesting to see how Sony chooses to handle the aftermath.

Yesterday, PS3 owners worldwide suddenly found themselves locked out of the PlayStation Network, with trophy and game functionality severely compromised. No-one knows why, but it appears that a calendar bug within older PlayStation3s has wreaked havoc with the PS3's DRM and authentication systems with a far-reaching impact on the system.

The phenomenon does not appear to have affected the new PS3 Slim, but owners of the larger console are at risk, with the PS3 logging an 8001050F error as soon as the system attempts to connect to the PlayStation Network. The bug causes the date on the system to be reset to 1st January 2000, and reseting the clock manually makes no difference.

Other gamers have reported that the same error kicks in even on offline systems, meaning that titles that synchronise trophies when first booted fail to start. Even test PS3 units used by press and developers are said to be affected. The impact of the bug is so far-reaching that all the paid-for PSN content residing on your PS3 hard drive suddenly loses its activation privileges, meaning that in addition to some retail Blu-ray games that sync trophies on launch, bought-and-paid-for PSN titles are no longer playable in anything other than their trial versions - if they have one.

Quite why the bug kicks in remains unknown at this time. Checking in with SCEE this morning, the official line is, "We have found out that some users are experiencing a network connection failure when signing on to PlayStation Network. We are currently looking into the issue to identify the cause of this network connection failure and will update further information as necessary (on the Blog or official website). We appreciate for your understanding and continued support."

Sony initially acknowledged the issue early this morning, but thus far has offered no advice so far on what the problem is, how it can be avoided, and crucially when it will be fixed. The company has confirmed that Slim units are unaffected.

In the meantime, if you have a non-Slim PS3, and you've not used it since Saturday or beforehand, our advice is to keep it powered down until Sony issues some sort of guidance, or provides a fix. Confirmed on our 60GB launch unit this morning, the bug still impacts PS3s powered up today, even if they were not active on 28th February.

Website Ve3tro.com has reported the NXE hard disk install sizes for each of the three game discs that make up the Xbox 360 version of Final Fantasy XIII.

According to the site - which has posted screenshots as proof - disc one weighs in at 5.9GB, while the second and third discs install at 5.8GB and 6.6GB respectively. This combined 18.3GB compares with a total of 39.4GB for the Japanese PS3 version, making the 360 game less than half the size of the PlayStation 3 release.

There are a few interesting facts to derive from this news. Owing to copy protection measures, the maximum potential size of an Xbox 360 game is 6.8GB, meaning that across the whole three discs Square-Enix actually had 2.1GB of potential space that remains unused, so we would hope that any omissions from the Xbox 360 version of the game would be minimal, if not non-existent.

The reduced size of FFXIII can easily be explained by more aggressive compression in the game's large array of CGI cut-scenes. Of the total 39.4GB that makes up the Japanese FFXIII on PS3, a quick look at the file structure on the Blu-ray disc suggests that a whopping 32.6GB of it is dedicated entirely to the video sequences, leaving just 6.8GB for the actual gameplay.

While the convenience of having the game on a single disc is obviously beneficial, disc-swapping in the Xbox 360 version is kept to a minimum owing to the linear nature of FFXIII itself. Very few locations can be revisited, so there is little actual need to have all three discs installed to the hard drive in the first place, over and above the obvious noise issues related to the Xbox 360 DVD drive.

In terms of other elements of comparison, the western versions of the game remain under embargo. The definitive Digital Foundry Face-Off will be published when this lifts next week.

iPhone hacker George Hotz claims to have expanded the scope of his PS3 exploit, and reckons he now has complete access to the system's GameOS, the area of the console than runs the XMB and operates beneath game code.

"I believe that defeats the last technical argument against the PS3 being hacked," Hotz wrote on his blog.

Geohot's original PS3 hack concentrated on the attack and analysis of the Cell chip's so-called Hypervisor, the "guardian" code designed to oversee general system operation and prevent the types of assault that continue to compromise Sony's PSP.

However, despite the mass media coverage of Hotz's achievements, doubts remained over the usefulness of the exploit since the core encryption techniques used within the PS3 remained secure.

Typically PlayStation 3 dedicates an entire SPU for the purpose of decrypting code and the actual decryption keys never enter main RAM, making the process of retrieving them impossible using the typical hacking technique of dumping the system memory. But in OtherOS, with Linux installed and his exploit active, Hotz has a much more vulnerable system at his disposal.

"In OtherOS, all 7 SPUs are idle," Hotz explained. "You can command an SPU (which I'll leave as an exercise to the reader) to load metldr, from that load the loader of your choice, and from that decrypt what you choose, everything from PKGs to SELFs. Including those from future versions."

SELFs are best described as the PS3 equivalents to PC .EXE files - they contain game code, while PKGs are the containers in which game installs, PSN games and DLC are delivered. Think of them as encrypted ZIP files. We can assume that "metldr" is the code PS3 uses to set up the dedicated, security-focused SPU that descripts them.

Although he has not publicly confirmed it, it is widely believed that Geohot has not only established his own Linux-based decrypter, but that he has also decrypted GameOS, raising the possibility that the PS3 firmware could be patched to run homebrew code straight from the XMB.

Hotz himself maintains that he will never write code to directly enable piracy, and while attempts have been made to improve the somewhat unreliable nature of the original hack, actually getting the exploit to activate remains something of a haphazard process.

In short, if anything ever comes of this, chances are that Sony will have made a good attempt at updating its firmware to circumvent the hack in the meanwhile.

Just how Sony will choose to respond to this remains unknown. In a topic posted on the YellowDog Linux community board, an employee of Fixstar - the firm responsible for the Cell-accelerated CodecSys h264 encoder - reckons he has heard from a "reputable source" that OtherOS may be removed in the next PS3 system update.

However, this post has now been deleted, and the whole notion of OtherOS being removed sounds rather heavy-handed and extremely unfriendly to the consumer.

The chances are that Sony will move to close Geohot's loophole in a more elegant manner, leaving the potential pool of exploitable consoles to diminish as more and more people upgrade their firmware.