PCE bitmap mode

I’ve talked about the PCE bitmap mode, albeit vaguely, in the past. It’s a 128x128x16 color mode. It’s a linear bitmap mode, which makes it fast for certain types of effects or operations. The SGX extends this to 128x128x241 colors. But I was thinking this morning, is it possible to push this limit. I approach with with a dithering angle; if 256 tiles is all that is needed to show 16 colors, but surely 1024 tiles could be used as extended dither patterns of those same colors. The limit is near 240 colors, but PCE doesn’t have enough room in vram for that (technically it does, but it would need column scrolling which it doesn’t have – so it’s the long way round by wasting memory).

Then I decided to flip the problem on it’s head. In the SGX approach, each VDC pixel is 16colors of that tile along with one of 16 color subpalette. In the PCE method, each tile (or BAT entry) is two pixels. Normally, each pixel has a max value of 16 colors. Together they don’t exceed the limit of 16 colors – in any combination. And in 16 colors, I can’t just apply different subpalettes to the whole tile or bat entry, because both pixels would be affected. Technically I could, but I would need a lot of subpalettes to achieve this goal. More than what the PCE has.

So, I thought about what if I reduced the color count per pixel in the tile/bat to 8 colors each. I still can only show two different pixels, but now I have an easier set of differences to work with. The upper 4bit of the tile, the pixel to the left of the pair, would be colors 8-15. And the lower 4bits of the tile number, the pixel to the right of the pair, would be colors 0-7. I can now setup the subpalettes in groups of 4. Four for the right pixel, and four for the left pixel. This combination gives a total of 32 independent colors per pixel (technically 29 because of color #0).

What it gains in colors, it loses in speed. The 16 color method is fast because each pixel is a nybble. In this higher color method, you now have 5bit pixels; 3bit for the index and 2bits for palette. It’s still faster than using planar graphics AND having to deal with tile segment boundaries. And to top it off, you can still add dithering back into it. The indexes go back to 4bit, with the high bit selecting a dither pattern of C and C-1.. within that 8 color subpalette. It’s more convoluted in that colors need to be setup appropriately in the subpalette. Or, and this is more specific to certain applications, the dithering could be not from the subpixel group itself, but across the two paired pixels. If you visualize this, the 128 pixels going across the screen, each pixel is actually 4 highres pixels from 512px graphics mode. So blending two pixel colors across 8 highres pixels should provide a nice gradient effect – although strictly horizontal in application. The blending would happen by setting the 8 bit (of 0-7 for the tile index) of the BAT entry (giving both C/C-1 option and Blend mode switchable option by high bit selection). I guess you could call it blend mode, as one color blends into the next for that pair. And the second set of tiles would be this fixed pattern.

Advertisements

2 Responses to “PCE bitmap mode”

  1. Yeah, the C64 was much more simple when it came to colors, but this makes me want to play with a PCE and see if I can grasp what you’re talking about… the Sega Genesis had a similar system, from what I remember. Not sure if more or less complicated. I’m pretending the SNES didn’t exist for now, esp. when you consider the optional co-processors like the SuperFX and such.

    • The Genesis has 4bit linear pixels for the tiles, so it can be setup for a pseudo bitmap. But the draw back is that the buffer needs to be in ram, and that it needs to be cleared before usage, and it has to be transferred to vram. But random pixel writes are faster. And you can do a single byte as a color (it’s have res, but gives you the option of dither on that double nybble pixel write). Vdma from local ram to vram isn’t fast enough for a 128x128xbyte data to be transferred in a single frame. So it has to be split over two frames or the display clipped to 176 pixels tall for a single frame transfer.

      On the PCE, this is all done with the tilemap itself to simulate a linear bitmap, not tiles.The bitmap buffer is kept in vram, so no need to transfer to vram. And clearing the buffer is free on the cpu (the VDC vdma does this). Row and column sequential writes are fast, but random (x,y) single pixel access is slow. One could keep the bitmap buffer in local cpu ram, and transfer it to vram, but that would be pretty slow as the PCE can’t clear it as fast as the Genesis (68k has a move group of registers to ram function), and transferring to vram is slow (5 cycles a byte) – 2.5 times slower than Genesis vdma (ram-vram). It would take 1.37 frames to both clear and transfer to vram. Or 163k cpu cycles. In vram, it still takes 2 frames for the option; 1 vblank for the vdma clear, and another vblank for vdma transfer. Leaving the cpu free to do other stuff during that time.

      C64 is nice in that it has video memory mapped into logical cpu address space. On the PCE, this could have been possible in the design because there are more open read/write access slots to vram during active display than what the cpu can even saturate. So they could have dual mapped it, as cpu banks, and both the VDC and cpu access it without issue.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: