Program compatibility: Difference between revisions
From NESdev Wiki
Jump to navigationJump to search
Rainwarrior (talk | contribs) (removing homebrew "shame" list, feel that it is disrespectful to single out specific instances like this, and the useful cautionary examples should be expressed in some other way instead (see talk)) |
Rainwarrior (talk | contribs) m (removal of list orphaned some text in the lead, trimming) |
||
| Line 1: | Line 1: | ||
:''This page describes defects in homebrew games. For defects in games prior to 1996, see [[Game bugs]].'' | :''This page describes defects in homebrew games. For defects in games prior to 1996, see [[Game bugs]].'' | ||
Homebrew development is as subject to bugs as old software was, but many suffer from additional [[Accuracy|compatibility problems]] with the NES hardware due to being tested on emulators exclusively. | Homebrew development is as subject to bugs as old software was, but many suffer from additional [[Accuracy|compatibility problems]] with the NES hardware due to being tested on emulators exclusively. It is often the case that very old homebrew ROMs will not run correctly on hardware. | ||
For a partial list of homebrew projects, see: [[Projects]] | For a partial list of homebrew projects, see: [[Projects]] | ||
Revision as of 00:53, 22 October 2017
- This page describes defects in homebrew games. For defects in games prior to 1996, see Game bugs.
Homebrew development is as subject to bugs as old software was, but many suffer from additional compatibility problems with the NES hardware due to being tested on emulators exclusively. It is often the case that very old homebrew ROMs will not run correctly on hardware.
For a partial list of homebrew projects, see: Projects
Common compatibility problems
This is a list of issues that commonly appear due to lack of popular support in emulators, or sometimes even hardware limitations of flash-carts like the PowerPak. Many emulators are merely trying to be compatible with existing games, rather than accurately reflecting the hardware, making them inadequate for verifying the correctness of new software.
- Use of DPCM samples causes a conflict with controller and PPU reads during sample playback.
- Writes to PPU registers outside of vblank with rendering enabled conflicts with internal use of the PPU address, causing graphical corruption.
- Failure to initialize registers not guaranteed by the CPU power up state or the PPU power up state.
- Failure to initialize RAM, nametables, or mapper registers. (Few mappers have guaranteed power up states.)
- Failure to delay use of the PPU after power/reset to avoid conflicts with its warm up state.
