Do you know whether it's actually self-modifying (as in, selectivelyish), reading a new routine from ROM (as in a loop from $b0000000), or a PI DMA?
How are you handling PI DMA at the moment when it comes to code fragments?

I have been looking at ways to verify dynarec execution against an emulator, for similar reasons (but I'm just starting out in mine), so this is very helpful!

Have you considered running both the emulator and dynarec in a semi-lockstep mode? I am going to try this when I get far enough into getting my dynarec working, as I'm not too worried about performance (yet... it's more of a learning experience and for some researchy ideas I have) and this should avoid the need to have a temporary log and the disk access. Of course it will be a lot slower, due to having to run two complete emulations at once, but this may prove quicker than going via disk?

Self-modifying code is perhaps the most annoying thing to deal with in a dynarec (that is, if you do in fact have to worry about it beyond cache invalidation). A good number of GBA games are very unfriendly in this regard. Actually, if it isn't checked for in general then a large number of games will fail outright.

Of course, to detect it for the general case you have to add code to either check for it or change state somewhere after every write to RAM. In your case, since this happens relatively infrequently, you can probably manage to special case it only for certain writes in certain games.

If you look at Project64's INI file you can see that there are several self-modifying code handling models (many of which probably don't really apply to PSP as it doesn't have an MMU). This alone indicates that it's a real problem for a number of N64 games, although perhaps not the most popular ones.

One thing I do recommend, if you're not already doing this, is to have separate translation caches for code that is in RAM and ROM (and not directly linking fragments between the two). That way you don't need to flush all of the generated code upon an icache invalidation or other detected modification, rather just the code in RAM. You can also go a step further and split things into dynamic and static regions to track modifications and try to minimize flushing overhead. This is only a concern if the game modifies code heavily - if any N64 games are like some GBA games then there will be ones that modify code many times a frame.

I talked about this issue in my blog, if you're interested: http://gpsp-dev.blogspot.com/

In a word: whoa!

Great job StrmnNrmn. Here's a question for ya: can the SSB rom be 'patched' to work correctly? Maybe not the file itself, but during the loading you have game-specific patches that Daedalus adds on the fly?

Also, on an unrelated note:

Is it possible to implement some kind of down-sampling of the N64's textures in order to save ram? The PSP's screen is tiny (large by handheld standards sure, but still smaller than a TV) and I am wondering if people would notice or care if the textures were reduced.

Keep up the great work man. I gotta say, you're regular posts are motivating. I have a wierd urge to try an Atari Jaquar PSP emulator with JIT dynarec! (okay... it passed)