Bally's Blitter Lance Squire This was originally posted on the Astrocade message group as postings (1071, 1073, 1074, and 1075). (November 17, 2002) In talking to the guy at Wikipedia [and online free encyclopedia], I realized that the 'Magic' functions of the Bally Video system are a primitive blitter. Well.... Minus the actual blit part. Definition: Blitter: Bit Block transfer device. A standard Blitter, as seen on the Amiga and Atari ST computers, also incorporated into many of todays videocards, is a chip that does block memory moves and various functions on that block. For instance the amiga&st could tell their blitters to take memory block X-Y and move it to screen as a H x W block at location Z using functions a, b, on it. Magic: The Bally's 'Magic' functions are what allow it to do the many flyers & MANY missiles in 'Galactic Invasion' without coming to a complete crawl. Magic functions are performed by setting the Magic registers then writing data into ROM in the same offset you'd want it to show up on the screen. For example write to 0x0000h to get 0x4000h (first byte of screen) The first important function to look at in the Magic register is Expand. Expand: ------- This function takes a monochrome single bit image and converts it into a 2 bit 2 colour image. With your selection of 2 colours from the 4 palette registers. What this allows us to do is have an image in memory like this: Pac Man Ghost Bits ------ 00011000 01111110 11101011 11111111 11111111 01010101 Expand can render this to the screen as three different coloured ghosts, Presuming we want to keep one colour for the background. Presuming a palette of: black (B) Yellow (y) Red (r) Blue(b) Expanded bits Colour Image ------------- -------------- 00 00 00 01 01 00 00 00 BBByyBBB 00 01 01 01 01 01 01 00 ByyyyyyB 01 01 01 00 01 00 01 01 yyyByByy 01 01 01 01 01 01 01 01 yyyyyyyy 01 01 01 01 01 01 01 01 yyyyyyyy 00 01 00 01 00 01 00 01 ByByByBy Expanded bits Colour Image ------------- -------------- 00 00 00 10 10 00 00 00 BBBrrBBB 00 10 10 10 10 10 10 00 BrrrrrrB 10 10 10 00 10 00 10 10 rrrBrBrr 10 10 10 10 10 10 10 10 rrrrrrrr 10 10 10 10 10 10 10 10 rrrrrrrr 00 10 00 10 00 10 00 10 BrBrBrBr Expanded bits Colour Image ------------- -------------- 00 00 00 11 11 00 00 00 BBBbbBBB 00 00 11 11 11 11 11 00 BbbbbbbB 11 11 11 00 11 00 11 11 bbbBbBbb 11 11 11 11 11 11 11 11 bbbbbbbb 11 11 11 11 11 11 11 11 bbbbbbbb 00 11 00 11 00 11 00 11 BbBbBbBb This allows us to save memory by not having the expanded versions in memory, and save processor cycles by not having the CPU do the conversions. So right now, we can draw 3 colours of ghost on byte boundaries (every 4 pixels) What if we want the ghost to move sideways by less than 4 pixels? Shift: ------ This function unlike the CPU version is pixel oriented. That is it only shifts by pixels, 2 bits at a time, rather that just 1 bit at a time. To place our ghost 2 pixels off the left edge, we would set the magic shift bits to 10 (2) The shifter only takes values of 0, 1, 2 and 3. If we want the ghost on the 4th pixel from the edge we set shift to 0 and write the ghost data 1 memory location over. Ok, now we can draw different coloured ghosts all over the screen! Now, how do we get rid of them? XOR: ---- You will notice that in 'Galactic Invasion', the ships and shots never disturb the star-field behind them. In fact if you watch you will notice that you can see the stars through the ships. This is because they are using XOR mode to both write and erase the ships and shots. This works because writing XORed data onto an existing image causes a sort of inversion of the data. So if you re-write to the same place the inversion returns to normal leaving no trace of your original write. Now, the reason this mode is so important to the Magic functions is because for the CPU to XOR data it takes 3 cycles (Read target, Modify target, write target). Using the Magic version the CPU does a simple write (1 cycle) and the video system Expands, Shifts and XORs the data for it. This should be enough. I plan to create a page for the HTML FAQ using this information...Programming section? ---------------------------------------------------------------------- Re: Bally's Blitter Tony Miller Good set of observations, Lance. To put this all into Windoze graphics accelerator perspective, a blitter is a chunk of hardware that takes the contents of a chunk of memory and replicates it elsewhere. The origin can be from a memory somewhere or someplace on the screen. The destination can be memory somewhere or another location on screen. This is generally done by hardware (DMA) under the control of software (register writes for origin, destination, size, etc. Sometimes a logical operation is performed on the way. This is usually referred to as a 'Raster Op'. The BPA Magic certainly did the 'Raster Op' portion of the blit. The rest of it is done by the Z80 code, with no hardware acceleration. ----------------------------------------------------------------------- Re: Bally's Blitter Lance Squire Thanks, Now I've been testing this, starting with expand. I now know what it means when it says ..."either the upper half or the lower half of the data bus is expanded" This explains why I only get 1/2 of my image on the screen. However I can't figure how to get the other half to show up! Ok... Now I can. I guess the Magic isn't as powerful as I hoped. To get the other half of my image to show up, I have to write the same data into the next byte over. The first screen byte(4 pixels) gets the expansion of the top 4 bits, the second screen byte gets the expansion of the bottom 4 bits. For shifting I find I have to pad the right side with 0 bytes, to keep data from wrapping around to the left of my image. Flopping so far, just makes a mess for me. ---------------------------------------------------------------- Re: Bally's Blitter Tony Miller >For shifting I find I have to pad the right side with 0 bytes, to keep >data from wrapping around to the left of my image. Shifting needs to have the pixels to the left of the object set to the background color (usually 0). Think of this as 'priming the pump'. Then each successive write will be shifted the selected # of pixels. >Flopping so far, just makes a mess for me. Flop makes a mirror image of the contents of the byte. Thus bits in position 7:6 will be exchanged with 1:0, and 5:4 will be swapped with 3:2. If you think this is bad, try rotating. However, it only works in commercial mode. END OF ARTICLE