Questions regarding VERA

[russell-s-harper]

I have a program I'd like to port to CX16, but I have some questions about the video capabilities.

I reviewed the guides for TGI and VERA but I'm still not sure if about the capabilities.

For example, the VERA guide says the output is fixed 640x480 at 256 colors, which would imply 300K, i.e. exceeding 128K, whereas the TGI opens a 320x240 screen, or 75K.

This is what I'm looking for:

- display a screen at one memory address, while updating a screen at another address
- to accommodate the above within the existing memory footprint, reduce to 4-bit color, but still at 320x240
- switch which screen is displayed, say using a vertical blank interrupt or equivalent

I remember reading a document that might have mentioned screen switching, including internal routines to call, but I can't seem to find it again, if it even applied to CX16.

[SolarSurfer]

This video by Matt Heffernan gives a concrete example of how to shuffle data in and out of VRAM
https://www.youtube.com/watch?v=Wn8-unoaWSc

Note it's an old video based on the CX16 memory layout at the time. Everything is still relevant but some memory offsets might be different now. For example his example writes to VRAM address $00000 but the correct offset per the current ROM is $1B000.

This video shows concrete examples of using bitmaps and tradeoffs between resolution and bits per pixel.
https://www.youtube.com/watch?v=3TeSP9wXYJ0

[ahenry3068]

VERA does have a 320x240 x 8 bit color mode, Yes it uses 76800 bytes of VRAM. Its pixel doubled internally so the Hardware resolution is still 640x480 but your only programming a 320x240 screen.

[BruceRMcF]

I have a program I'd like to port to CX16, but I have some questions about the video capabilities.

I reviewed the guides for TGI and VERA but I'm still not sure if about the capabilities.

For example, the VERA guide says the output is fixed 640x480 at 256 colors, which would imply 300K, i.e. exceeding 128K, whereas the TGI opens a 320x240 screen, or 75K.

This is what I'm looking for:

- display a screen at one memory address, while updating a screen at another address
- to accommodate the above within the existing memory footprint, reduce to 4-bit color, but still at 320x240
- switch which screen is displayed, say using a vertical blank interrupt or equivalent

I remember reading a document that might have mentioned screen switching, including internal routines to call, but I can't seem to find it again, if it even applied to CX16.

See the Programmer's Reference Guide ... chapter 8 for the memory allocation used by the Kernel and chapter 9 for the registers and capabilities.

640x480, 256 colors is the hardware output. There is a color palette that contains 12bit color values. In 8bpp color modes all 256 entries in the palette are used, in 4bpp a 16-entry range of the palette is used.

There are registers that allow you to set the scaling of generated pixels into video output pixels, and registers that allow you to set which area of the native 640x480 display space is active, so if the registers are set up to doubled pixels and a 320x240 active display space, you have a 320x240 display mode. If the color depth is set to 4bpp, that would be 38,400 bytes for a bitmap, which would support a double buffered bitmap.

Also note that you are not required to fill the full visible display with a bitmap, since you can set a bitmap with an active area smaller than the video display area, sitting in layer0 behind a tilemap layer1 which can have surrounding decoration and/or gizmos around the bitmap display.

[russell-s-harper]

Thank you. So I think this will work, converted to BASIC:

POKE 40749, 6 : REM SET BITMAP TO 16 COLOR MODE POKE 40751, 0 : REM SHOW BITMAP 1 STARTING AT 0K OFFSET POKE 40751, 76 : REM SHOW BITMAP 2 STARTING AT 38K OFFSET

The existing TGI routines will likely not work, so will have to set up clear screen and plotting routines.

[BruceRMcF]

I haven't done any work on bitmap modes, but there may be a benefit for your double buffering to setting the two bitmaps in parallel ranges of the bottom 64K of video RAM and the upper 64K. Then the high bit of the buffer address is set based on which buffer you are presently writing, and the balance of the display buffer addressing is identical before and after toggling display and write buffers.