Looking for advanced technical information

MRCMRC

Member
Joined
Jun 27, 2007
Messages
103
Reaction score
0
Location
Madrid, Spain, Spain
Hello everyone!

I've been repairing classic arcade PCBs for some years. I have an average knowledge on digital electronics, and microprocessors theory, and medium skills on (de)soldering ICs and troubleshooting from easy to medium PCB issues.

I have also a basic idea of the main parts that make a game play (CPU code, sound circuits, palette, sprite buffers).

But I don't have a complete vision of how do really arcade games work: how sprites are drawn on screen, what interrupt routines do, how background and sprites are mixed together, and so on.

Is there any good tutorial, or any good information over there on the net that could help me to understand how a game works from a slight higher sight than the one I have just now (chips and digital signals)?

Thanks in advance!
 
Is there any good tutorial, or any good information over there on the net that could help me to understand how a game works from a slight higher sight than the one I have just now (chips and digital signals)?
Check out this description of the Bally MCR system: http://arcarc.xmission.com/PDF_Misc/MCR2.pdf

But I don't have a complete vision of how do really arcade games work: how sprites are drawn on screen, what interrupt routines do, how background and sprites are mixed together, and so on.
In really simple games like Space Invaders the video is a simple framebuffer. There's a RAM where each bit represents one pixel on the screen. There's dedicated hardware that outputs the memory bit-by-bit to generate the video signal. But it's a lot of work (reads and writes) for the CPU to move a screen full of invaders, pixel-by-pixel, to the right or left. You can play the game and see how sluggish it is.

Later games had dedicated hardware to generate video. For example on MCR the background is described with an array in RAM; each location controls the graphic that will be displayed on that tile (among a 32 x 30 grid). The foreground is described with another array in RAM but it's more flexible -- each element is a data structure that specifies the graphic plus an XY coordinate of where to draw. When the dedicated hardware scans through RAM, at each pixel it's making the decision "do I draw the background or is there something on top?" automatically.

One example that comes to mind is Qbert. That game has a fixed pyramid in the background. To make him hop, the CPU only needs to rewrite a few bytes (X and Y coordinates) instead of redrawing the character and the background. This game has very smooth, color video with about the same computing power as space invaders!
 
Back
Top Bottom