Archive for December, 2015

Semester has ended.. and I did some PCE timing tests today

Posted in Uncategorized on December 17, 2015 by pcedev

Some bad news for the TSB/TRB instructions for VDC port $0003; it’s damn slow. It’s not the instruction, but apparently there’s a delay for when the VDC switches from reading to writing vram back to back. I.e. doing a bunch of TRB $0003 to increment the vram point is going to block by 6.5 cycles more than the expected 9 cycles. This is even the case of back to back LDA $0003 STA $0003 instructions – the processor is stalled by the VDC and ends up being ~15.6 cycles instead of 12 for the single pair.  Of course, this was only tested at lowest resolution. If the overhead should be half that for high res. I’ll need to test for that. I still have more vdc read/write setups to test.

PCE bitmap mode

Posted in Uncategorized on December 10, 2015 by pcedev

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.