USF on real hardware would require re-dumping them to eliminate the use of Project 64 save states, and re-generate the coverage and unused code/data removal with a more accurate emulation setup, like with LazyUSF2's coverage generating mode.
All current sets use Project64 save states to initialize the player code, which includes loading most of the player code into RAM for execution. Many current sets also trim off code that would be required for execution under more accurate emulation, which rules out real hardware as well.
If it plays badly under LazyUSF2, which is already being terribly generous when it comes to shortcuts for old rips, it will never work on actual hardware without a re-rip.
(Terribly generous is an understatement. Most of these sets were trimmed of any code paths dealing with any hardware action having a natural delay. Everything is expected to complete instantly. Interrupts are also expected to fire the instant they are programmed. Audio DMA is expected to complete instantly as well.)
Can confirm. Most of the ones I ripped were done as makeshift and horrible as possible :) As soon as a routine takes slightly longer than expected, it'll die horribly
Though I have wondered how well one would work on my Everdrive, with regards to the timing issues most suffer
I noticed with usfs like Perfect Dark if you play them with foobar and your usf player, when using RSP not HLE for the audio almost all tracks crash around the middle mark of a sing ir strangely during their 2nd loop. Is this a player issue or the actual usf rip?
Using the RSP the audio is better so would be cool to use it. It crashes on my mobile and.computer at the exact mark. The crashes happen the exact time for a given song every time..