5 ms·
How does your blitter compare to the Amiga blitter? http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0119.html http://amigadev.elowar.com/read
by nerpderp82 7y ago
How does your blitter compare to the Amiga blitter? http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0119.html http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui...
- Lerc 7y agoIt's quite different for a number of reasons. The read area and the write area are separate spaces. It is strictly main RAM to frame buffer. It is pixel based instead of bit-planes, so a lot of the features of the Amiga blitter aren't required. The minterms , multiple sources and the shifter were great for masking and sliding the bits to the right place, but once you go to chunky pixels they aren't so useful. It does pixel format conversions to convert various compact data forms to colour graphics. 8 pixels per byte in 2 colours, 4 pixels per byte in 4 colours, 3 pixels per byte (where each 3 pixel block can have 4 colours from one of 4 micropalettes), 2 pixels per byte in 16 colours. It supports Cell modes were it can decode cells of pixels from data, mode 0 has 3x3 blocks described in two bytes each. Cells may have any two of 16 colours. mode 1 is quite similar to the NES tiled graphics mode with 8x8 cells chosen by index to a table and individually coloured and flipped. I don't have a line drawing option but I was wondering about having some registers to accumulate with each pixel written and if the accumulators overflow the X or Y pixel position increments. It would add some rudimentary skewing for little cost. A lot of it comes down to the fact that the blitter is doing much of the job of the display hardware in other systems. The frame buffer is the output device with no smarts at all.