Zanac (NES)/RAM map: Difference between revisions

From Data Crystal
Jump to navigation Jump to search
(Created page with "A preliminary and tentative list of RAM locations and their usage during gameplay. Regions are listed as address, size, then description. F 1 Currently swapped-in bank. T...")
 
(Add PPU and map-scroll control memory locations)
Line 15: Line 15:
         2=TIME; 3=GAME OVER; 4=BONUS; 5=PONYCA; 6-255=blank
         2=TIME; 3=GAME OVER; 4=BONUS; 5=PONYCA; 6-255=blank
   83  1 Frame count, in game time. (Updated by main loop, not VBLANK.)
   83  1 Frame count, in game time. (Updated by main loop, not VBLANK.)
   FF  1 Desired value for PPU_CTRL. Other logic may alter the actual
  90  1 VRAM Blit Control. Bit 7 = VBLANK should copy target values to
        shadow registers.
  98  1 Target Y Scroll value.
  99  1 If nonzero, use the lower nametables as the base.
  9A  1 If nonzero, use the right-hand nametables as the base. Since
        Zanac is horizontally mirrored, this control byte has no visible
        effect.
  9B  1 Target X Scroll Value
  A9  1 Vertical Scroll subpixel count (256 subpixels = 1 pixel)
  AA  2 Current scroll speed, in subpixels/frame
  AC  2 Target scroll speed in normal play, in subpixels/frame
  AE  1 Actual number of full pixels scrolled this frame
  FC  1 Register shadow for Y Scroll value.
  FD  1 Register shadow for X Scroll value.
  FE  1 Register shadow for PPU_MASK.
   FF  1 Register shadow for PPU_CTRL. Other logic may alter the actual
         value of PPU_CTRL as needed by that logic, but it will preserve
         value of PPU_CTRL as needed by that logic, but it will preserve
         all other settings based on this and will restore to this value
         all other settings based on this and will restore to this value
Line 35: Line 50:
  463 4D Data to copy to VRAM.
  463 4D Data to copy to VRAM.


Major open questions:
== Register Shadows ==
 
In order to keep the display consistent at all times, PPU registers are *triple-buffered* in Zanac's engine. Scroll, mask, and control data are directly stored in the PPU's registers, and the values from $FC-$FF hold the values to reload them with each frame. On top of this, additional "target" values are held in $98-$9B which are updated quasi-atomically, assisted by bit 7 in $90.
 
== Major open questions ==


* Where and how are the non-sprite parts of enemy/player objects held?
* Where and how are the non-sprite parts of enemy/player objects held?
* How do weapon selection and upgrades work? Zanac has some unusual corner cases in its mechanics where certain kinds of upgrades "lock" the player's upgrade status unless something dramatic happens.
* How do weapon selection and upgrades work? Zanac has some unusual corner cases in its mechanics where certain kinds of upgrades "lock" the player's upgrade status unless something dramatic happens.
* The VRAM data for transfer during VBLANK seems to have a number of possible formats, given the complexity of the function that does it. The characterization of 460-49F is almost certainly incomplete.
* The VRAM data for transfer during VBLANK seems to have a number of possible formats, given the complexity of the function that does it. The characterization of 460-49F is almost certainly incomplete.

Revision as of 08:38, 10 July 2019

A preliminary and tentative list of RAM locations and their usage during gameplay. Regions are listed as address, size, then description.

  F  1 Currently swapped-in bank. This is set by the bank-swapping
       routines and is consulted by routines that push it onto the
       stack and restore it later.
 26  1 ROM bank holding compressed data.
 2B  1 Decompression control byte.
 2C  2 Pointer to current position in compressed data
 32  1 Lives. 0 = Game Over, any value up to 255 is valid
 5C  1 Current weapon, 0-7
 5E  1 Weapon timer/ammo. Defaults to $14 (20) on free-fire weapons.
 60  1 Current weapon power (number of times the weapon has been picked up?)
 61  1 Current weapon visage (Increases more slowly than 60, seems to be related to what the weapon's power level looks like when fired.)
 66  1 Selector for graphics in tiles $0F8-$0FF: 0=Illegal; 1=AREA;
       2=TIME; 3=GAME OVER; 4=BONUS; 5=PONYCA; 6-255=blank
 83  1 Frame count, in game time. (Updated by main loop, not VBLANK.)
 90  1 VRAM Blit Control. Bit 7 = VBLANK should copy target values to
       shadow registers.
 98  1 Target Y Scroll value.
 99  1 If nonzero, use the lower nametables as the base.
 9A  1 If nonzero, use the right-hand nametables as the base. Since
       Zanac is horizontally mirrored, this control byte has no visible
       effect.
 9B  1 Target X Scroll Value
 A9  1 Vertical Scroll subpixel count (256 subpixels = 1 pixel)
 AA  2 Current scroll speed, in subpixels/frame
 AC  2 Target scroll speed in normal play, in subpixels/frame
 AE  1 Actual number of full pixels scrolled this frame
 FC  1 Register shadow for Y Scroll value.
 FD  1 Register shadow for X Scroll value.
 FE  1 Register shadow for PPU_MASK.
 FF  1 Register shadow for PPU_CTRL. Other logic may alter the actual
       value of PPU_CTRL as needed by that logic, but it will preserve
       all other settings based on this and will restore to this value
       when it is done.
102  2 Magic Number. A fresh power-on is distinguished from a RESET by
       whether or not these two bytes are 35 53. If they are, the high
       score is not reset and the reset count at 19A is incremented.
       If they are not, first-time initialization is done (including
       setting these bytes to the right values).
17A  8 Score. Big-endian, one digit per byte, so a score of 12,300 is
       the bytes 00 00 00 01 02 03 00 00.
185  7 High Score. Works like 17A, but only 7 bytes long and the ones
       digit is assumed to be zero.
19A  1 Number of times you have soft-reset the console since power-on.
       This count is used to unlock Super-Continue and the Sound Test.
200 FF CPU-RAM copy of OAM data
460  1 Number of bytes of data ready to send to PPU.
461  2 PPU address for data, HIGH BYTE FIRST.
463 4D Data to copy to VRAM.

Register Shadows

In order to keep the display consistent at all times, PPU registers are *triple-buffered* in Zanac's engine. Scroll, mask, and control data are directly stored in the PPU's registers, and the values from $FC-$FF hold the values to reload them with each frame. On top of this, additional "target" values are held in $98-$9B which are updated quasi-atomically, assisted by bit 7 in $90.

Major open questions

  • Where and how are the non-sprite parts of enemy/player objects held?
  • How do weapon selection and upgrades work? Zanac has some unusual corner cases in its mechanics where certain kinds of upgrades "lock" the player's upgrade status unless something dramatic happens.
  • The VRAM data for transfer during VBLANK seems to have a number of possible formats, given the complexity of the function that does it. The characterization of 460-49F is almost certainly incomplete.