We've just updated MediaWiki and its underlying software. If anything doesn't look or work quite right, please mention it to us. --RanAS

SA-1 Pack

From SnesLab
Jump to: navigation, search

SA-1 Pack is a package of patches for activating and optimizing the SA-1 system for Super Mario World, with emphasis on eliminating slowdown, game limitations and accelerating the engine to the maximum possible. Unlike SA-1 Root, SA-1 Pack is focused for ROM hacking and it includes several features for implementing new features for the game using the chip.

Being the most complex patch made for Super Mario World, SA-1 Pack requires to all other ASM patches apply a RAM remap for warranting compatibility with the patch. However, without the RAM remap, it would have been impossible to accelerate the game because the SA-1 chip cannot access the S-CPU work memory (WRAM).

For implementation details, see SA-1 Root.

Features

  • Makes the game run up to four times faster.
  • Increase the maximum amount of sprites at once on screen to 22.
  • Increase the maximum amount of sprites on a single sub-level to 255.
  • Reduces loading time of all levels and maps.
  • Increase the maximum ROM size to 8 MB.
  • Offers enhanced bitmap and arithmetic capabilities for better graphics performance.


MaxTile System

MaxTile System or just MaxTile is a new feature introduced on SA-1 Pack v1.40 that fixes all known OAM issues involving the game, allowing custom sprites using both $0200 & $0300 area and implements a basic sprite priority system for custom resources interested in using the MaxTile API directly, while still keeping compatibility with regular and custom sprites that weren't designed for MaxTile.

How it works:

  • at the beginning of the frame, $7F:8000 is called and invalidates all OAM data.
  • $0200 - $049F can be used normally on the game.
  • when a sprite is executed, its OAM index is set to $0340.
  • when the next sprite is executed, the previous OAM tiles are copied into a new buffer and the $0340+ is freed so the next sprite can use it.
  • at the end of the frame, the entire OAM is scanned for other tiles and unused tiles are removed.
  • during the process, any tile outside screen is automatically dropped as well, maximizing free OAM slots.
  • the sprite buffer then is copied back to the OAM and all sprites are rendered to the screen.