1 bpp bitmap mode missing

[Serentty]

The official specifications list mentions a 1 bpp bitmap mode, which is a feature that I've been trying to use to draw monochrome graphics without having to waste half of the VRAM on zero bits. However, this currently seems to be missing from both the emulator and the Vera documentation.

[mist64]

@fvdhoef ?

[fvdhoef]

There is no 1 bpp bitmap mode. The spec on facebook is incorrect, I have updated it.

[Serentty]

This seems like a pretty strange omission to me. Monochrome graphics are a pretty common use case, and the 2 bpp mode takes up twice the necessary amount of VRAM. Plus it increases the processing power needed to load and display 1 bpp bitmap data.

[mist64]

Actually, I would have to agree...

[Serentty]

Just today I came across a project using the 2 bpp bitmap mode when really it's rendering monochrome image data. It's using it to display Unicode text on the screen. A 1 bpp mode would drastically increase performance by cutting the amount of data that has to be copied to VRAM in half.

https://github.com/kreativekorp/u8m

[c64skate]

I also prefer adding 1bpp support instead of removing it from supported modes list. There will be many convertions from other 8 bit systems. There are a lot games using hires mode (all ZX Spectrum games i believe). So, a native graphic mode would make things a lot easier.

For demo coders, we always try to fill a huge area as fast as we can (while drawing polygons for instance). Even if it's not very useful in all cases, i already have some special cases where i can speed things up using 1bpp mode. Wanna see some crazy 3d stuff on x16? Add this mode please. :)

[Serentty]

@fvdhoef Is there any chance of coming back and considering adding this? It seems to be a very popular feature, and I've seen quite a few projects that have to simulate it using the 2 bpp mode, significantly increasing VRAM usage and causing a performance hit.

[c64skate]

At the beginning i thought 1bpp bitmap mode is sacrificed to fit graphic modes in 3 bits but there are 4 unused bits at CTRL0. If they are not reserved for some already planned feature, using one more bit gives us 8 more gfx mode possibilities.

0 | Tile mode 1bpp (per-tile 16 color foreground and background color) 1 | Tile mode 1bpp (per-tile 256 color foreground color and fixed background color 0) 2 | Tile mode 2bpp 3 | Tile mode 4bpp 4 | Tile mode 8bpp 5 | Bitmap mode 2bpp 6 | Bitmap mode 4bpp 7 | Bitmap mode 8bpp

These are the existing ones.

8 | Bitmap mode 1bpp 9 | Bitmap mode 1bpp (vertically mapped bitmap memory) 10 | Bitmap mode 1bpp (c64 like char by char bitmap memory addressing with video/color memories) 11 | Bitmap mode 2bpp (vertically mapped bitmap memory) 12 | Bitmap mode 2bpp (c64 like char by char bitmap memory addressing with video/color memories) 13 | Bitmap mode 1bpp wide pixels (c64 multicolor mode simulation with video/color memories) 14 | Reserved for other platform compatibility options 15 | Reserved for other platform compatibility options

These are my suggestions. We can live without these modes but they would be awesome to have. We can easily port our c64 codes having these modes without much modification.

Important one is only mode 8 here. But reserving one more bit for the modes, why should we waste remaining mode slots right? :)

[codewar65]

You need 1200 16x16 mode 0/1 tiles to fill a 640x480.

If a tile mode were added like 0/1 that allowed for tiles like modes 2/3/4, but sacrificed v/h-flip, you could get upto 4096 tiles, more than enough to fillscreen. A screen could be built in tile map space.

Mode X 0 : bits 7-0 tile index (7:0) 1 : bits 7-4 = palette offset, bits 3-0 = tile index (11:8)

[codewar65]

Or a bitmap mode that assumes that the palette is entry 0 and 1. and do 1 bpp.

[c64skate]

I have one more suggestion on alternative modes. This is just what i need on my project i'm working on. I can live without it but it would be a huge speed boost for me.

• 2x scaled modes.

I know VERA is still under development and things might change and i remember you were discussing appling some display composer options to the layers independently (like HSCALE, VSCALE etc.). So, if you go that way, this wouldn't be necessery. But if you choose not to change current design, 2x scale modes could help us to have something like.

layer0: 320x240 layer1: 160x120

Display composer would affect both layers just like how it already is now. For instance if we change HSCALE and VSCALE to their default values same layers would be shown as;

layer0: 640x480 layer1: 320x240

I know it requires some extra work and only 640 and 320 widths are supported at the moment but using 2x scaled mode we can fill whole screen 4x faster. Yes, it will be low res. But think about it, layer0 will contain the high res graphics and layer1 will contain some overlay stuff which is quite acceptable in low res.

[ElfEars]

I support this motion. x16 is intended to be able to utilise many old graphics styles and I agree that monochrome needs some love.

I would also support adding 1bpp and 2bpp sprite modes (Considering there's a free bit after the mode bit to support this sort of behaviour) but maybe that deserves it's own issue.

Ps. Considering this is the emulator's issues page and not a discussion page for the hardware design, where would the best place to put these sort of suggestions in future? (Yes, I know it's currently facebook but having an account there is a pain)

[greg-king5]

PS, Considering this is the emulator's issues page and not a discussion page for the hardware design, where would the best place to put these sorts of suggestions in future? (Yes, I know it's currently Facebook, but having an account there is a pain.)

https://murray2.com/forums/commander-x16.9/