Popslide: a generic video memory updater

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

Post Reply
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Popslide: a generic video memory updater

Post by tepples »

Popslide is a video memory update buffer framework for the Nintendo Entertainment System.

NES games need to update video memory in numerous ways during gameplay. But the frame rendering circuitry in the PPU has exclusive access to video memory while it sends the picture to the TV. So games usually buffer updates in RAM. An unused part of the stack is a convenient place to stash such a buffer, big enough to hold the largest practical VRAM update on NTSC.

Some games have only one update routine because all the updates they do are so similar. Others have multiple update routines, one for each kind of update, such as nametable columns, nametable rows, rectangular areas, tile uploads, attribute uploads, and the like. Still others embed information about the shape of an update in the buffer. This is the approach used by Super Mario Bros. and other games using NES Stripe Image format.

Popslide interprets an NES Stripe Image buffer in the stack page, using PLA as an autoincrementing read instruction. It comes in three forms: a looping version, a partially unrolled (16x) version, and a fully unrolled (64x) version.
Attachments
popslide-0.01.zip
(26.68 KiB) Downloaded 928 times
JRoatch
Formerly 43110
Posts: 422
Joined: Wed Feb 05, 2014 7:01 am
Contact:

Re: Popslide: a generic video memory updater

Post by JRoatch »

Since this "needs feedback badly".

I have been working on a PPU update buffer system very much like this since you started talking about NES Stripe Image format a few months back. Comparing with what I have the one similarity is using pla like in popslide. Other than that, these are the differences:
  • The "increment 32" is put into bit 7 of the address high byte.
  • The maximum length of the strings are then 128, with only bit 7 signifying the run or literal mode.
  • The terminator can then go into the bit 6 of the address high byte, but I don't use this.
  • Instead I use a counter for the number of strings to write, this way the buffer as a whole is always valid for the vblank routine even in the middle of writing a string.
frantik
Posts: 377
Joined: Tue Mar 03, 2009 3:56 pm

Re: Popslide: a generic video memory updater

Post by frantik »

In the code below, POPSLIDE_SLACK is 8.. I don't get why you set the stack pointer to $107.. wouldn't that not leave any room for the buffer? SHouldn't you point to $13F or something?

Code: Select all

popslide_blit:
  tsx
  stx sp_save
  ldx #POPSLIDE_SLACK - 1
  txs
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Popslide: a generic video memory updater

Post by tepples »

In theory, the buffer starts at $0108 and continues to $019F or thereabouts. The slack is in case it gets interrupted, as I leave NMI on even during blank screen loading.
frantik
Posts: 377
Joined: Tue Mar 03, 2009 3:56 pm

Re: Popslide: a generic video memory updater

Post by frantik »

I think i get it now, I was confused why you didnt set the pointer to the greatest value of the range you expect to use (019F ), but thats because youre about to pop all the values so you need to start at the other end.. but how do you know where the bytes to pop start.. or are you assuming you filled the buffer and that's why you start at slack-1?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Popslide: a generic video memory updater

Post by tepples »

The buffer is filled in increasing order starting at $0108 using sta $0100,x instructions and read in increasing order starting at $0108 using pla instructions.
frantik
Posts: 377
Joined: Tue Mar 03, 2009 3:56 pm

Re: Popslide: a generic video memory updater

Post by frantik »

ah thanks, I was thinking you were pushing them onto the stack in reverse order
Post Reply