Some other website posted news as having discovered that the iLink ID still exists on newer consoles that do not have an iLink port, and how this creates hope that somehow iLink really does still exist and there is only the matter of finding the right signal lines to tap into.
It matters not which site is making this claim, nor should one bothering finding it, as the entire substance of the claim is described above. All that matters is that should anyone seriously believe the above, there are a number of factors to consider that make the probability of iLink still existing extremely unlikely.
For starters, lets discuss the continued existance of the iLinkID, which is separate from, but somewhat related to consoleID. Both IDs are stored in the CDVD/mechacon NVRAM. They are accessed via the CDVD driver. They exist essentially as digits stored in non-volatile memory. Aside from storing these digits for access by an iLink driver, there is no relationship between CDVD/mechacon and any iLink hardware on the PS2.
In other words, assuming Sony did in fact remove iLink support, an iLinkID may still be present in an otherwise unrelated area of the system. It could be that it was overlooked, or removing it caused more trouble than leaving it. Or finally, the concept of a GUID (which is what the iLinkID really is) was worth keeping in the console, even if iLink itself no longer existed. Other things could conceivably make use of it in the future.
Regardless, the GIUD/iLinkID is not a concept intrinsically tied to a 1394/ilink hardware implementation - it is a software concept abstracted on top of 1394, and its requesting, retrieval, and transmission, is governed at the software driver level. At the hardware level, a 1394 bus node is identifed by a combination of a busid/nodeid number pair. These numbers change dynamically as 1394 devices/hosts are added, removed, or reset on a 1394 bus.
As part of the OHCI protocol driver, associations of busid/nodeid pairs with GUIDS are made each time a bus reset occurs. In fact, the software driver responsible for retrieving its own hosts GUID on request by another 1394 could be written to supply an arbitrary number rather than the one stored in NVRAM or PROM. Such would be a violation of OHCI spec, but all serves to demonstrate just how loosely related the presence of a GUID (iLinkID) is to the actual existance of a 1394/iLink hardware implementation on that host.
Thus, the presence of the iLinkID, in an of itself, is completely inconclusive with respect to any existance of iLink hardware capability in the PS2. In fact, if one wanted a test for the presence of iLink, despite the absence of any external clock drivers and port lines, one should be testing for access to iLink node/link controller registers. The memory locations of those registers are well known, and its not difficult to invoke ilink port hardware initialization and reading result. So it is curious why this more certain method is not used to ascertain the presence or not of iLink.
But there is nothing wrong with hoping that iLink somehow still exists. When I acquired a new SCPH-50000 system, which naturally did not have an iLink port, I wondered if iLink actually still existed. It should just be a matter of finding the proper signal lines and attaching a connector, right ? After all, for those who did not know, the iLink/1394 hardware node, link, and phy controllers were a physical part of the IOP processor, attached directly to an internal bus on the IOP MIPS core.
In order to truly remove iLink support, Sony and their partner LSI Logic would have to redesign the IOP generate new masks for manufacturing the chip. This type of process is not lightly done. Clear cost savings have to exist, based on selling large quantities of units, before this is ever done. So, in the absence of any obvious and compelling reason for Sony to have the IOP redesigned, iLink should still be there.
On inspecting the mainboard of the SCPH-50000 (v11 btw), two things were apparent: the 25Mhz clock circuit needed for 1394 was missing (it would attached and present right next to the IOP), and there was no SPU chip present.
The former made hooking up an iLink port a much harder proposition, because without it, iLink just cannot work. A properly functioning 1394 link/phy controller needs a 25Mhz clock. This is missing on the V11 unit, and certainly isn't apparent in mainboard photos for other iLink-less PS2 systems, including the new SCPH-70000 series.
The latter provided more insight on what Sony most likely did with ilink.
There are many ways to reduce manufacturing costs of devices with lots of chips. One way is to reduce actual chip size, thus allowing more chips to be manufactured per wafer of silicon. This has the effect of reducing per chip costs. Another way is to integrate more functions onto a single chip, reducing the number of chips needing manufacture, but also greatly simplifying PCB layout, which cuts costs in multiple ways. The EE+GS is another obvious example of this.
Clearly, the SPU wasn't truly missing, but was integrated elsewhere. This elsewhere turns out to be the IOP itself. Thus, Sony did have a reason to make a redesign of the IOP, and this occurs about the same time the decision was made by Sony to stop offering the iLink feature. After all, to keep iLink would have been more costly, increasing the size of the chip, and not allowing as much simplification of the mainboard, but by removing it, there was plenty of room to insert the SPU. In any event, Sony had a redesign opportunity here, and the most lift would be from redesigning the IOP, even if it meant deleting a prominent, if underutilized feature. I have no doubt the cost savings from such a move more than madeup for any shortcomings, there were too few shortcomings. Please note that I do not know with certainty the SPU ended up on the IOP, it could have gone to the SSBUS controller as another likely place, but on the IOP it is far more likely to save costs as a replacement to iLink than an addition to SSBUS.
Given all of this, it is highly unlikely iLink exists at all on any recent PS2 without an iLink port. Even if it did, there are still steeper barriers to tapping it than attaching a port, because a clock circuit is also needed. Considering Sony's obvious business model of selling PS2 units at a loss in the beginning of its life, recouping over time by making manufacturing more efficient and cutting costs through higher integration and strategic economizing, it makes all too much business sense that iLink was a cost liability that needed removing; and it was removed.
Presence of iLink ID in newer consoles, overhyped
Speaking of what, how goes your firewire driver implementation? :)
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
On the topic of saving money, my buddy mentioned that 1394 has to be licensed from Apple, so that would definately be a good way to save money if they just cut it right out of there, I'm not familiar with too much PS2 hardware that used it either (heck any), although yes it beats USB... the whole Apple thing seems to be holding it back from what I hear.
http://www.applelinks.com/editorials/firewire.shtmlmrbrown wrote:IEEE1394 is a standard defined by IEEE. You don't have to license it from anyone. The only thing you have to pay for is the standard, which is a couple hundred bucks from IEEE's website.
In paragraph 3, it is stated that all licensing boards (IEEE, ITU, ANSI, etc.) clearly state that if a standard includes proprietary, patented technologies then the owners of those patents have complete freedom over licensing fees and royalties.
Apple did attempt to charge $1 for each port, it was scrapped (changed to royalty free for 1394ta members) when the other members objected to it.