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, were 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.

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.

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 of direct addressable graphics in ROM used. 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 of ROMs. 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, were 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.

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, were 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.