7

According to https://en.wikipedia.org/wiki/Donkey_Kong_(video_game)

The Donkey Kong hardware has the memory capacity for displaying 128 foreground sprites at 16x16 pixels each and 256 background tiles at 8x8 pixels each. Mario and all moving objects use single sprites, the taller Pauline uses two sprites, and the larger Donkey Kong uses six sprites.

This was a game released in 1981. By contrast, the Commodore 64, released a year later, spent most of the area of a fairly large complex video chip, providing just 8 sprites.

Admittedly that might not be 128 sprites per scan line, but judging by the size of the vertical comparator block on the VIC-II, there are significant costs associated with total number of sprites, even if not on the same scan line.

Admittedly an arcade machine can afford a larger hardware budget than a home computer, but sheer memory bandwidth is an important limiting factor on number of sprites.

So how did this machine do it?

Improve this question
0

1 Answer 1

Reset to default
9

To start with, the citation is a bit misleading. The logic didn't handle 128 sprites and 256 tiles at a time, but its ROM could hold as many different ones.

The arcade board does not feature a free programmable sprite engine. There is a fixed sets (128) of direct addressable graphics in 8 KiB of ROM used (128 x 32 x 16). A set of shift registers, feed by the object ROM provides the object (sprite) data to be superimposed on (non shifted) tiles from another set (256) of ROMs (256 x 8 x 16 = 4 KiB). Either is indexed via a 1 KiB RAM.

The whole design is quite simple. Since it's a fixed logic with all data embedded, no loading is needed. Further no priority logic for overlapping is present (Overlapping, where neccessary, is handled by software thru page flipping) and no collision detection either (as well done in software).

It's a complete different technology than what is used in any sprite units like from a VIC or 9918 or alike. All sprite data is 'on board' (as ROM), and likewise the display RAM, thus zero memory bandwidth (*1) is needed to display them.

*1 - At least not in the sense a CPU RAM based system with shared access would need to be calculated. Of course do all parts of the controller have certain bandwidths and use them.

Improve this answer
7
  • Okay, so let me try to paraphrase to make sure I understand. Of the various resources that usually limit the number of sprites you can have...
    – rwallace
    Commented Jan 25, 2020 at 18:03
  • Bandwidth is not a limiting factor because there are separate data paths from the different classes of ROM.
    – rwallace
    Commented Jan 25, 2020 at 18:04
  • 1
    Are those accurate paraphrases?
    – rwallace
    Commented Jan 25, 2020 at 18:06
  • 2
    @rwallace Basically yes. If you look at the schematics, you'll see that both data ROM groups together with their data buffers and shifters (LS299) form king of a pipeline (details are a bit more complex). Sorting has to be done by software ahead of time - much like with a 9918 sprite order. If you remember my answer about the two opposite ways of handling sprites, this is much like the all-aboard variation - with computing left to the CPU. IIRC there is an interview with Miyamoto were he complains how inflexible the hardware was and that he had to change the game several times to go along.
    – Raffzahn
    Commented Jan 25, 2020 at 18:15
  • 2
    Sorry, I'm unclear how sprite overlaps are handled in software if sprite contents always come from ROM. I notice from live video — e.g. youtu.be/tJagEKVJ8x4?t=19 — that there's no obvious flickering. Would it be possible to get some more detail on that?
    – Tommy
    Commented Jan 25, 2020 at 19:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .