Commander X16

Thank you very much, hstubbs3. All these insights are very helpful. I really appreciate your help to help us helpless getting a better understanding of how the VERA works and what one can do with it.

I stumbled across a YT video which I'm half through and which also helped to make things a bit more clear. I hope it's ok to share it: Spriteworx: Commander X16 Tilemap, Tiles, Color Palette - Part One.

As Sgt. Pepper already knew: with a little help from my fiends I'll even get VERA to obey

Slevin wrote: ↑Fri Mar 22, 2024 8:15 pm Thank you very much, hstubbs3. All these insights are very helpful. I really appreciate your help to help us helpless getting a better understanding of how the VERA works and what one can do with it.

I stumbled across a YT video which I'm half through and which also helped to make things a bit more clear. I hope it's ok to share it: Spriteworx: Commander X16 Tilemap, Tiles, Color Palette - Part One.

As Sgt. Pepper already knew: with a little help from my fiends I'll even get VERA to obey

You're very welcome... After all the time I'd spent watching YT videos about the NES PPU and getting into trying to write a game for the Sega Mega Drive and dealing with its nutty little VDP quirks and memory limitations...

Honestly, I feel spoiled... the 6502 doesn't have all them nice 32-bit registers that the Mega Drive's 68K had... but base hardware has 512K of RAM and this VERA thing has all this .... and we haven't even discussed any of the FX stuff - the 32bit cache writes, the affine and line helpers... not even the multiplier....

I do wish the VERA had more VRAM or at least some fast DMA or even line-by-line horizontal or vertical scroll... but I suppose we'll all somehow make due with the gifts given...

Le Sigh.

hstubbs3 wrote: ↑Fri Mar 22, 2024 8:36 pm

Slevin wrote: ↑Fri Mar 22, 2024 8:15 pm Thank you very much, hstubbs3. All these insights are very helpful. I really appreciate your help to help us helpless getting a better understanding of how the VERA works and what one can do with it.

I stumbled across a YT video which I'm half through and which also helped to make things a bit more clear. I hope it's ok to share it: Spriteworx: Commander X16 Tilemap, Tiles, Color Palette - Part One.

As Sgt. Pepper already knew: with a little help from my fiends I'll even get VERA to obey

I do wish the VERA had more VRAM or at least some fast DMA or even line-by-line horizontal or vertical scroll... but I suppose we'll all somehow make due with the gifts given...

Le Sigh.

I 2nd your wish for more VRAM. If I had my one single wish for the X16 it would be 256kb or 512kb of VRAM. But I did HANGMAN just using the provided Bitmap & Text Layer. I didn't even use one single Sprite. The VERA is quite a capable beast for this platform.

Thanks for the nice reports, I think it's great what you can do with the bitmaps.
I just didn't understand how to turn on bitmap 1 at $10000.

Thanks.
greeting

funkheld wrote: ↑Fri Mar 22, 2024 7:13 pm Hi good afternoon.

what is bitmap level 0 and bitmap level 1 please?

How can you make bitmap level 1 transparent to bitmap level 0 in the graphic, no tiles?

As hstubbs3 notes, Color 0 is transparent, so using color 0 in level 1 makes a "window" down into level 0. It's transparent in Layer 0 too, but there's nothing "below" layer 0, so Color0 in Layer 0 is effectively the color set as the default background color.

So you can have the starfield or planet outside the spaceship on Layer0, and the spaceship deck Layer1, and the viewscreen and portals are all Layer 1 color 0 so that is where you can "see outside".

funkheld wrote: ↑Fri Mar 22, 2024 9:53 pm Thanks for the nice reports, I think it's great what you can do with the bitmaps.
I just didn't understand how to turn on bitmap 1 at $10000.

Thanks.
greeting

set L1_TILEBASE ( $9F36 ) to $80 (for 320pixels wide at $10000 )
SET L1_CONFIG to ( $9F34 ) to -
$04 for 1 bit per pixel
$05 for 2 bit per pixel
$06 for 4 bit per pixel
$07 for 8bit per pixel

DC_VIDEO ( $9F29 ) should be set to enable/disable sprites and the 2 layers as desired... one should be careful with this register as you need to maintain the low nibble or you will switch your display settings...

from BASIC, one would like use VPOKE to set these and VPEEK on DC_VIDEO first to get the current low nibble, and then ORA whichever layers on/off

When your program should be just about ready to exit, you may want to do NEW in BASIC or call into Kernal $FEDB: console_init - initialize console mode - to reset the screen to BASIC prompt before returning... otherwise, your program will exit without bringing the system back to that state.

Once you've started mucking about with the VERA registers, you should expect that the various BASIC and KERNAL routines for the graphics should not work unless you call into screen mode or other routines to bring the VERA back into some configuration they should expect...

below is excerpts from the doc regarding these registers, in case anyone else hates scrolling up and down the doc trying to make sense of it...

. . . . . . .

Bitmap mode 1/2/4/8 bpp
MAP_BASE isn’t used in these modes. TILE_BASE points to the bitmap data.

TILEW specifies the bitmap width. TILEW=0 results in 320 pixels width and TILEW=1 results in 640 pixels width.

The palette offset (in 'H-Scroll (11:8)'), as well as T256C in non-1bpp mode modifies the color indexes of the bitmap in the same way as in the tile modes.

$9F29 DC_VIDEO (DCSEL=0)
bit 7- Current Field
bit 6 Sprites Enable
bit 5 Layer1 Enable
bit 4 Layer0 Enable
bit 3 NTSC/RGB: 240P
bit 2 NTSC: Chroma Disable / RGB: HV Sync
bits 1/0 - Output Mode

OUT_MODE Description
0 Video disabled
1 VGA output
2 NTSC (composite/S-Video)
3 RGB 15KHz, composite or separate H/V sync, via VGA connector


$9F34 L1_CONFIG Map Height Map Width T256C Bitmap Mode Color Depth
$9F36 L1_TILEBASE Tile Base Address (16:11)

Hello thanks for the information.

I think it works.
I saved an image in screen $80 that consists of circles.
I now have bitmap0 below which is transparent to the graphic image


next I have bitmap1 ?

Thanks.
greeting

about the graphic bitmap0???
-------------------------
POKE $9F36,$80
POKE $9F34,64

A=PEEK ($9F29)
POKE $9F29,A OR 96

SCREEN $80
BVLOAD "FUNKPAL.PAL",8,1,$fa00
BVLOAD "TEST1.RAW",8,0,0

------------------------

bitmap1 ???
-------------------------
POKE $9F36,$80
POKE $9F34,64

A=PEEK ($9F29)
POKE $9F29,A OR 96
-----------------------

Funkheld,

I am not sure I follow..

SCREEN $80 ...
from the doc -
$80 320x240@256c
40x30 text

this makes layer 0 over 64K ! - per the VERA doc, the KERNAL VRAM map has this -
$0:0000-$1:2BFF 320x240@256c Bitmap

and indeed.. 320*240*8bits per pixel = 75 KB ...

Then you set L1_Config to $64 - only the 4 matters here though, since it sets bitmap mode ... for 1 BPP ... which means every 8 pixels in a row is within 1 byte ... 320x240*1bpp = 320*240 / 8 = 9.375K

Because layer0 is "oversized" here, you have this in VRAM now -
$0:0000 Layer0 - start of layer0 line 0
$0:FF00 Layer 0 - start of layer0 line 204
$1:0000 Layer 0 - 256,204 of layer 0.... Layer 1 starts ...
$1:2580 Layer0 - 256,234 ..... Layer1 end
$1:2C00 Layer0 has ended..

The layers overlap in memory... my example with the multiple layers and setting layer1 at $1:0000 had layer0 set to 4bit, which would occupy only 37.5KB !

If you want to have layer0 be 8bit graphics starting at $0:0000, then you can't put anything else before $1:2C00 and still have 320x240..

You could set the vscale to stretch the pixels and use less in height - 320x200 would be 62.5K ... or you would have to set layer1 higher up in VRAM .. at 1bpp it _is_ only ~9.5K ... so isn't really problem setting L1_tilebase to $1:2C00 >> 9 .... $96 ...

Then in VRAM the 2 layers wouldn't overlap and interfere with each other..
this works even for layer1 up to 4bit - 4bit 320x240 would be 37.5KB ... so first 75K is 8bit layer0, then + 37.5KB = 112.5K of VRAM used out of the ~126.5K that is up for grabs..

OR, another way to think of this overlapping issue... is that layer0 should be covered from line ~204 down... Like if one used sprites or layer0 to cover the bottom ~40 lines with some sort of status display or something, then you effectively have a 320x240 video mode but layer0 is only really using 320x200 ...


but for now, just be aware of where everything _ends_ in VRAM, because the VERA does not care if you tell it everything is using the same VRAM somehow...

As small example, a few of my assembler programs have a little debug font set loaded at $0:0000, and then I stuck layer0 as a 256 color layer starting at $0:0000 .... but I used a tile layer1 that purposely obscured the first 7 or 8 lines at the top of the screen, so it didn't matter that was where my tileset was...

https://github.com/hstubbs3/CommanderX1 ... ls-001.asm
https://github.com/hstubbs3/CommanderX1 ... g_font.inc


and this is why somewhere near the top of my own code I have taken to doing this - just commenting the heck out of what is where in VRAM and how large it all is... What my plan is, since the VRAM "memory map" is basically up to the programmer...

; VRAM Addresses
; Address range Description
; $00000 - $1F9BF Video RAM - 129,424 bytes -> 126K is 129,024 (1F800)
; $1F9C0 - $1F9FF PSG registers
; $1FA00 - $1FBFF Palette
; $1FC00 - $1FFFF Sprite attributes
VRAM_SPRITES = $00000 ; putting sprite data at start of VRAM for now.. may move later?
VRAM_BITMAP_LAYERA =$11800 ; starts at 70K ... so up to ~70K for sprites.. not too shabby..
VRAM_BITMAP_LAYERB =$18000 ; ~25K needs to start at 2K boundary... 121.5-25= 96k
VRAM_TEXT_SCREEN = $1E400 ; 121.5K 256 x 21 => 32 x 24 would take 1.5K tiles is min.. 64*32 = 2K 8 config..
VRAM_SPRITE_BUF = $1EC00 ; 123K - sprite attribute buffer for swapping data in ..
VRAM_CHARSET = $1F000 ; $1:F000-$1:F7FF Charset loaded by kernal here .. is at 124K ..
; only can go to 126K ...
VRAM_palette = $1FA00 ;
VRAM_sprite_attributes = $1FC00

Hello, thanks for the help.

I didn't know that you could play with VRAM and other memory like that. it's wonderful.

a nice introduction from you.

Thanks.
greeting

hstubbs3 wrote: ↑Sat Mar 23, 2024 10:04 am ... The layers overlap in memory... my example with the multiple layers and setting layer1 at $1:0000 had layer0 set to 4bit, which would occupy only 37.5KB !

If you want to have layer0 be 8bit graphics starting at $0:0000, then you can't put anything else before $1:2C00 and still have 320x240.. ...

... unless you make sure that the overlapping area has no transparency in Layer1 ... the Display Composer pipelines will put garbage into the row for Layer0, but then when it gets to composing that row from Layer1, all of the garbage gets overwritten, so it doesn't matter what is in that garbage data that is physically part of the display but you aren't using it.

So that's how you do the trick where you have a 320x240x8bpp display but only work with the top 200 rows of pixels, and make sure that there is no transparency in the 320x240x4bpp Layer1 display in last 40 rows of pixels in the display. 320x200x8bpp is 64,000, so it fits in the bottom 64KB of VRAM. There are 1,536 bytes left in the lower 64KB of VRAM in that approach, which can be used for some appropriate data.

That uses the top 200 rows of the default Kernal bitmap, so the bitmap kernal operations still work, though you have to be careful to avoid directing them at the last 40 rows of pixel.