I have an interesting anecdote about GC development - I know of a game that almost released on GC that would break the drive on every console it was played on - a developer responsible for the loading code used an undocumented method to increase the read speed from the optical drive, so that data would stream in sufficiently fast for the game. Unfortunately, that was more than the drive was designed for, and it would actually die after few hours of use that way. QC reported some of their test consoles dying, but Nintendo ruled they must have been defective, and replaced them - and the game actually went to manufacturing like that. The whole release was halted a week before it was due because someone spoke to the guy and asked how he got the data streaming to work quickly enough.
You could do something similar with PS1, PS2 and PSP - use undocumented methods to overclock the CPU and make them run quicker.
As someone who has used undocumented methods on many consoles and ALWAYS been caught by QA and told to remove them I'd love to know how they got away with this.
Even on the PS1 where I used an undocumented graphics command to get a 'free' screen clear (nothing dodgy and we learned about it by watching Tekken in the PA) I got told to remove it.
Crash did not really do anything weird with the CD drive, it just read from the disc a lot. So much, in fact, that a single playthrough would hit the disk more times than the drive was rated for (the drive was rated for some 70000 reads, but completing the game required something like 120000). [1]
Yeah. It looks like a memory optimisation to squash more code and data into the gamecube's 24mb of memory.
It was one of the earlier gamecube games and it looks like they rolled their own custom solution rather than using one of the standard nintendo libraries for advanced memory management that most other games use.
