It took a short while to figure out exactly how it was modifying the code. I was worried that it was modifying the code via the cpu (i.e. manually updating instructions) but it turned out to be a DMA transfer. I'll post again with a bit more details about how I'm handling this.
Glad you found the post useful
I did consider the lockstep method (I believe Zilmar was using this on pj64) but I think the aproach I use in Daedalus is much simpler to get working. The lockstep approach would cause a few issues for the psp as you'd need to have enough RAM for two copies of the emulated RAM etc.
It probably would be quicker than going via disk though, and less hassle to get everything set up.
Hiya. Most n64 games seem to be pretty well behaved (they generally invalidate caches where required) which is why I've not spotted too many problems in the past.
They don't generally seem to modify code very frequently either - usually just on specific events (e.g. transfer from menus to game etc) rather than on a frame-by-frame basis.
Separate caches is a good idea though, I'll investigate that this weekend.
In the past I've gone to the length of scanning the rom for recognisable library functions and patching them (mostly just to help debug what's going on with the rom, but also for optimising a few things like memcpy() etc). There's no reason why I couldn't use the same technique to patch game-specific code which is known to cause problems, but I think this would be pretty labour intensive.
In the end my solution was just to check each DMA transfer directly for an overlap with the fragment cache. This solution should work with all roms that modify code though ROM->RAM DMA, but still won't solve the problem of roms modifying individual instructions directly
The N64's textures tend to be pretty tiny anyway - it only had 4KiB of texture memory so 16x16 and 32x32 are pretty typical texture sizes. The ones that I have the most problems with are textures used for backgrounds in menus. Quite often these are really wide and thin - MarioKart's menus use lots of 320x3 textures for instance, which I have to round up to 512x4 for the psp. Down-sampling the textures might help a bit here - I'd have to experiment to see how it looked.
Amusingly I used to have code to support this in the PC build - I can't remember the details, but it was a compatibility fix for certain PowerVR cards which were limited to 256x256 textures IIRC
Welcome to the DCEmu Homebrew and Gaming Network. This Network of sites is owned and ran by fans of all games consoles, we post news on all the consoles we cover about hardware aspects, gaming and Homebrew. Homebrew and Emulation are software thats made using free and legal tools to play on games consoles. This Network is the only worldwide network of sites where coders can upload and post comments they deserve for all their hardwork. We have a Network that currently supports PSVita, WiiU, Nintendo Wii, Xbox360, PS3, PS2,PS1, Snes, N64, Gameboy, Nes, Xbox, Gamecube, Nintendo DS, PSP, GBA, Dreamcast, Sega Saturn,3DS, DSi, Switch, PS4, Pandora, xboxone, GP2X, iPhone, Windows Phone, iPad, Android and also Mobile Phone Emulation. When new consoles appear we will expand to cover those consoles. We also cover Theme Park News and news and reviews of Beer, cider, lager, wines and spirits.
news of their own releases and get the credit and
Please help DCEmu become stronger by posting on the forums every day and make our community larger.