Repository navigation
Game Issues
Some games allocate dynamic memory (AllocSysMemory) on the IOP, but write past the end of the requested buffer.
When using the official method to boot such games, the memory layout will always be the same, and the buffer overrun will always overwrite the same memory area. Resulting in defined behaviour. When this memory area does not contain data crucial to the game, there is no issue. The game developers who tested these games will not have noticed these buffer overrun issue.
When using a different boot method however the memory layout is different. Depending on many factors, the overrun can cause issues that seem random. Each seamingly unrelated commit can cause these bugs to cause issues, or not.
Try to replicate the memory layout of the official boot method. After an IOP reboot the memory layout should not contain 'gaps'. Becouse small memory allocations by the game can be allocated into those gaps. The offset at which modules are loaded will still be different, but all allocation will be placed in the same order. This will not fix the issue completely, but it will cause the issue to behave the same as on the original boot method. No compatibility mode is needed.
Games fixed:
- Splashdown
For some games the above fix is not enough. A new module is created (patch_membo.irx) that makes all dynamic memory allocation larger (256b or more). Obviously this will cost extra IOP RAM on games using it. A new compatibility mode has been added that loads the new module: -gc=7 "7: IOP: Fix game buffer overrun".
Games fixed:
- Donkey Xote - 256b
- Disney's Treasure Planet - 256b
- .HACK - 2kb
- Inuyasha - Feudal Combat - 256b
Games are not allowed to use the first 1MB of the 32MB EE RAM. As defined in the EE_CORE linkfile:
bios_rom : ORIGIN = 0x00000000, LENGTH = 512K /* The ROM overlaps with 512K of RAM. This RAM is used by the BIOS. */
bios_ram : ORIGIN = 0x00080000, LENGTH = 512K /* Used for BIOS updates, but mostly not used */
The EE_CORE runs in this region and also stores all IOP modules here to be used when rebooting. However, some games DO use this region causing neutrino to crash.
After the first IOP reboot by the game, the EE_CORE can be deactivated. This means further reboots will not be possible, but at least neutrino will not crash. This is also called "mode 3". Use -gc=3 to activate this mode.
Games fixed:
- Many, search for OPL or HDLoader compatibility lists
If a game writes only a few bytes to this region then this can easily go undetected, but causing random issues on random releases. Neutrino adds a checksum to all loaded modules and checks this at each IOP reboot. If corruption is detected a color error code (1x purple + 2x red) will be displayed on screen and neutrino will freeze. Enable compatibility mode 3 if this happens.