Commander X16

In the documentation there is a general overview of how the VRAM address space layout is set up.

But I cannot find anything about Layer 0 and Layer 1, respectiveley where each of these layers start and have their dedicated regions for e.g. charsets and so on. Is there a more in detail explanation where I can read about how the VRAM is currently organized?

Many thanks

Slevin wrote: ↑Thu Mar 21, 2024 10:46 pm In the documentation there is a general overview of how the VRAM address space layout is set up.

But I cannot find anything about Layer 0 and Layer 1, respectiveley where each of these layers start and have their dedicated regions for e.g. charsets and so on. Is there a more in detail explanation where I can read about how the VRAM is currently organized?

Many thanks

When in Screen 128 ($80). The graphics layer starts at 0,0. and continues on to 1, $2BFF . I find myself at a loss as to the Text Layer address. BRB.....

Those are the addresses when strictly using ROM routines. When directly programming the VERA I believe you can set the layer to start at any address that you want it to.

Thanks for your reply. I'm still a little bit confused:

Does that mean, that both layer 0 and 1 share the same addresses? Aren't they layed out side by side in the address space? If that isn't the case it would mean, that the VERA system deals with a kind of virtual mapping. I haven't read about that in particular, but it would work. Please don't be offended by my stupid questions, I just wanna get a grasp of how things with VERA work.

Many thanks for your patience

_almost_ any address.. .there's limited number of bits..

https://github.com/X16Community/x16-doc ... ference.md

$9F2D L0_CONFIG Map Height Map Width T256C Bitmap Mode Color Depth
$9F2E L0_MAPBASE Map Base Address (16:9)
$9F2F L0_TILEBASE Tile Base Address (16:11) Tile Height Tile Width

$9F30 L0_HSCROLL_L H-Scroll (7:0)
$9F31 L0_HSCROLL_H - H-Scroll (11:8)
$9F32 L0_VSCROLL_L V-Scroll (7:0)
$9F33 L0_VSCROLL_H - V-Scroll (11:8)

$9F34 L1_CONFIG Map Height Map Width T256C Bitmap Mode Color Depth
$9F35 L1_MAPBASE Map Base Address (16:9)
$9F36 L1_TILEBASE Tile Base Address (16:11) Tile Height Tile Width
$9F37 L1_HSCROLL_L H-Scroll (7:0)
$9F38 L1_HSCROLL_H - H-Scroll (11:8)
$9F39 L1_VSCROLL_L V-Scroll (7:0)
$9F3A L1_VSCROLL_H - V-Scroll (11:8)



if Lx_CONFIG & 2 is 0, the layer is a tile layer, using tiles with the configured color depth based on Lx_TILEBASE and with tile map data of the configured height/width based on Lx_MAPBASE

If Lx_CONFIG & 2 is 1, its a bitmap layer, map settings are ignored, tile width sets if it is 320 or 640 pixels wide.. height is not set... and scroll registers don't do anything..

because MAPBASE is set using 8bits, the start address must be divisible by 512.
TILEBASE uses only 6 bits, so must be divisible by 2048 ...

so you could configure the VRAM as you please... one possibility might be 320x200 256 color bitmap screen with double buffering.. (doing it this way you swap buffer just writing 1 byte to Lx_TILEBASE

320x200 = 64,000 bytes .. 62.5 K

So potentially no sprites or text mode layers or charsets .. or squeeze these somewhere between the buffers..
$0:0000 => buffer A
$0:FA00 - available for other stuff
$1:0000 => buffer B
$1:FA00 - palette data (fixed)
$1:FC00 - sprite attribute table (fixed )


or maybe you fancy 160x120 .. can't set the bitmap layer any thinner... ends up kinda funny..
$0:0000 => buffer A, but its 160B used then 160B unused per line... could use that 160B for sprites, tiles, etc..
$0:9600 -> 37.5K in... available for other stuff
$1:0000 => buffer b, but its 160B used then 160B unused per line... could use that 160B for sprites, tiles, etc..
$1:9600 -> ~24.5K available for other stuff
$1:FA00 - palette data (fixed)
$1:FC00 - sprite attribute table (fixed )

then considering all the juice bits the FX update provided - like the affine helper to do "mode7" stuff, would have to take up space somewhere for its tiles / map...

or considering you could use the 16-color or 256-color tiled modes to create non-linear frame buffers of arbitray tilextile size...??

you gotta figure out how you want to utilize the space..

Thanks hstubbs3, I think I slowly get the idea of how the VERA works.

So initially there is a Character Set mapped from the x16 Memory ROM bank to the VRAM, but I could restructure the whole VRAM to my pleasure and mark any region as layer0 or layer1. And through the VERA IO registers I then can quickly access the dedicated VRAM, is that correct? So in principal kind of how the Data Port selection works.

Slevin wrote: ↑Thu Mar 21, 2024 11:05 pm Thanks for your reply. I'm still a little bit confused:

Does that mean, that both layer 0 and 1 share the same addresses? Aren't they layed out side by side in the address space? If that isn't the case it would mean, that the VERA system deals with a kind of virtual mapping. I haven't read about that in particular, but it would work. Please don't be offended by my stupid questions, I just wanna get a grasp of how things with VERA work.

Many thanks for your patience

Graphics Layer starts at 0:0 Text starts at 1:B000. There's only one "Ram Area" 128 kb big from 0:0000 to 1:FFFF. Everything is in there.. .

hstubbs3 wrote: ↑Thu Mar 21, 2024 11:13 pm
_almost_ any address.. .there's limited number of bits..

I thought that was pretty obvious, but your correct I probably should have mentioned that.

Graphics Layer starts at 0:0 Text starts at 1:B000

So consequently this would mean that in a symmetric layout I would set the graphics layer for L0 to start at 0:0, while the graphics layer for L1 should start at 0:D800.

And all this will be done through the VERA control register $9F2E for L0 and $9F35 for L1.

Please tell me that I'm correct, so I can go to bed relieved, being able dreaming of unicorns and cotton candy...