3 ms·

The more significant advantage of the NES over the C64 is the way hardware scrolling works. The NES supports a 4-screen screen memory or "nametable", and the P

The more significant advantage of the NES over the C64 is the way hardware scrolling works. The NES supports a 4-screen screen memory or "nametable", and the PPU, or graphics chip, can be programmed with one or two register writes to basically display any position within that 4 screens. Scrolling is just updates to the scroll registers and populating new video data on the incoming edge (which has to happen during VBLANK). Whereas the C64's VIC-II can only select a few fixed places to start reading video memory to render the screen (2k boundaries for text mode). It can finely shift the screen left or right up to 8 pixels, but scrolling past that requires a many, many cycle recopy of RAM to video memory. Throw in the need to recopy color memory as well and that puts the C64 at a serious disadvantage. Looks like this game on the C64 used some really advanced technique called VSP, which tells the VIC to I guess read from arbitrary memory addresses instead of the fixed ones it normally supports. This apparently exposed a VIC-II hardware bug that can corrupt RAM (since VIC-II is responsible for DRAM refresh). Really interesting. Seems some systems are more susceptible to this hardware bug than others, and there's difficult software workarounds for it.

vidarh 8y ago
Scrolling at most requires copying 2K. In practice much less - even without VSP, Mario levels usually have lots of long runs of the same tiles all over the screen that makes it simple to optimize the copying (or rather optimize which parts you don't need to copy). For that matter you could double buffer and spread the copying of the tiles (not the colors) over multiple frames. The normal approach if you for whatever reason could find a way to copy what you needed, though, was simply constraining the amount of the screen you used a bit and e.g. putting extra decoration top/bottom. But really, Mario should not be a challenge to do this for - the C64 had tons of platform games of similar complexity. Especially Giana Sisters - put this video of Giana Sisters side by side with the Mario version above from the start of level 1, and see why Nintendo threatened the publishers: https://www.youtube.com/watch?v=8teXm6723-g https://www.youtube.com/watch?v=8teXm6723-g (EDIT: I've not checked, but e.g. the clouds in Giana Sisters in some of the levels looks like they might be sprites - using sprites for some of the "background" objects, especially if mostly vertically separated from the main game area was certainly a common method of reducing the amount of background that needed to be copied; notice how the levels without clouds mostly have several lines worth of tiles that doesn't require colour updates near the top and bottom, and often hardly ever requires any copying at all - e.g. mostly unbroken runs of floor tiles; many of the levels requires pretty much no colour updates anywhere) The only reason I can see for using VSP here is because it means less need to actually figure out how to do the copying efficiently.
- djmips 8y ago
  you don't need to double buffer to amortize the copy time. That is you don't need to do all of the copying in the vertical sync time. As long as you stay ahead of the raster you can spread the copy over the subsequent frame. So in my scrolling routine I start copying the top portion and work my way down the screen to stay ahead of the raster. Interrupts still fire during this time and handle some game updates / joystick reads.

vidarh 8y ago

Scrolling at most requires copying 2K. In practice much less - even without VSP, Mario levels usually have lots of long runs of the same tiles all over the screen that makes it simple to optimize the copying (or rather optimize which parts you don't need to copy). For that matter you could double buffer and spread the copying of the tiles (not the colors) over multiple frames. The normal approach if you for whatever reason could find a way to copy what you needed, though, was simply constraining the amount of the screen you used a bit and e.g. putting extra decoration top/bottom. But really, Mario should not be a challenge to do this for - the C64 had tons of platform games of similar complexity. Especially Giana Sisters - put this video of Giana Sisters side by side with the Mario version above from the start of level 1, and see why Nintendo threatened the publishers: https://www.youtube.com/watch?v=8teXm6723-g https://www.youtube.com/watch?v=8teXm6723-g (EDIT: I've not checked, but e.g. the clouds in Giana Sisters in some of the levels looks like they might be sprites - using sprites for some of the "background" objects, especially if mostly vertically separated from the main game area was certainly a common method of reducing the amount of background that needed to be copied; notice how the levels without clouds mostly have several lines worth of tiles that doesn't require colour updates near the top and bottom, and often hardly ever requires any copying at all - e.g. mostly unbroken runs of floor tiles; many of the levels requires pretty much no colour updates anywhere) The only reason I can see for using VSP here is because it means less need to actually figure out how to do the copying efficiently.

djmips 8y ago
you don't need to double buffer to amortize the copy time. That is you don't need to do all of the copying in the vertical sync time. As long as you stay ahead of the raster you can spread the copy over the subsequent frame. So in my scrolling routine I start copying the top portion and work my way down the screen to stay ahead of the raster. Interrupts still fire during this time and handle some game updates / joystick reads.