Black area at bottom of emulator

[Jestin 27]

I've mostly been ignoring this, but I get a black area at the bottom of the emulator whenever I set the screen mode to 320x200@256C.  Everything runs fine, as if the black area is simply not part of the screen.  However, when I look at other people's demos, I never see this black area.  I'm starting to worry it will be there on the actual hardware and not just the emulator.

When I have an application that only runs this code:

    lda #$80
    sec
    jsr screen_set_mode

Here is what I see:

Is this expected for some reason, or am I doing something wrong?

[StephenHorn 258]

No, that seems correct. Same thing happens to me when I do SCREEN $80.

I can't speak for everyone, but my demos do not run in 320x200@256C. My demos leave the VERA at 640x480 scale, and takes advantage of the VERA's multiple layers and sprites at that "resolution".

@SlithyMatt's Chase Vault's title screen scales the screen to 320x240 resolution, and configures VERA layer 0 to be a 320-wide 4bpp bitmap. Gameplay leaves the global scaling and layer 0 configured like this, and configures layer 1 to a 128x128 tilemap using 16x16x4bpp tiles.

Edited June 28, 2020 by StephenHorn

[SlithyMatt 425]

I think this is correct for the emulator, which is fixed at a 640x480 display, and just doubles the pixels when you pick a mode that is 320 pixels wide. @Frank van den Hoef might be able to tell you if 320x200 mode can output to an appropriate monitor in full screen with the actual hardware.

[StephenHorn 258]

I doubt the VERA is capable of swapping to an entirely different VGA resolution. Also, it appears that none of the scaling settings will allow the VERA to cleanly present a 200 pixel height. The closest you can get is a DC_VSCALE of 54, which shows 202.5 pixels, or 53, which shows 198.75 pixels. In the end, it might be worth suggesting that the kernal use DC_VSTART and DC_VSTOP to limit the drawn area and center in on the display. If maintaining something close to the original 4:3 aspect ratio is desired, it might also consider DC_VSCALE of 56, which isn't a clean multiple of 2 but draws 210 pixels height, which could then be trimmed appropriately.

Edit: Here's what DC_SCALE 56,  DC_VSTART 6, DC_VSTOP 234 looks like, blown up 2X:

Versus a 320x240 scale, but seeing VSTART and VSTOP to 20 and 220 so there's a 200-high display area:

Edited June 29, 2020 by StephenHorn

[Frank van den Hoef 41]

The hardware really only has one output resolution: 640x480. 320x200 isn't a resolution that is natively supported by VERA. As far as I know the kernal has this 320x200 resolution as part of the GEOS drawing code, which Michael didn't yet update to make use of the full 240 lines height. As Stephon Horn showed, you can use the scaling to make the 200 lines cover (almost) the full 480 output lines, but it will give some scaling artifacts.

[desertfish 183]

is there a way to set the screen to 320x240 mode via SCREEN  or perhaps screen_set_mode?  and then use the FB or GRAPH routines as well?

[Ender 55]

20 hours ago, desertfish said:

is there a way to set the screen to 320x240 mode via SCREEN  or perhaps screen_set_mode?  and then use the FB or GRAPH routines as well?

Not the way it is now.  The framebuffer driver is pretty much hard coded at 320x200.  You'd have to write your own driver for the GRAPH API to use (which Michael intended for people to be able to do).  I think the reason it's set at that resolution currently, however, is that, when starting your layer 0 at $10000, that's all there is room for in video RAM.  In fact, at 320x200, I think it might still be too big?  It looks like it would end at $1FA00, which would overwrite the PSG registers? I'm not sure how he's getting away with that.

Edited August 30, 2020 by Ender

[SerErris 70]

15 hours ago, desertfish said:

is there a way to set the screen to 320x240 mode via SCREEN  or perhaps screen_set_mode?  and then use the FB or GRAPH routines as well?

Yes ... Screen $80 is doing this. But still you need to handle the layers or you see both ... (text in front of the graphics)

Sorry, that was crap .. that was 320x200 mode ... 

Edited August 30, 2020 by SerErris

[SerErris 70]

8 hours ago, Ender said:

Not the way it is now.  The framebuffer driver is pretty much hard coded at that resolution.  You'd have to write your own driver for the GRAPH API to use (which Michael intended for people to be able to do).  I think the reason it's set at that resolution currently, however, is that, when starting your layer 0 at $10000, that's all there is room for in video RAM.  In fact, at 320x200, I think it might still be too big?  It looks like it would end at $1FA00, which would overwrite the PSG registers? I'm not sure how he's getting away with that.

For 320x240 graphics mode (x8) you need to move some stuff around, or work only with one layer. 
The Map for the textmode allways takes $4000 bytes. The Charrom (tile map) takes another $800 byte (if I did not remember wrong). 320x240 takes 76800 bytes ($12C00). So the easiest way is to leave the Textmode where it is ($0000-$3FFF) then start your layer 0 at $4000 and move the char rom to $1F000 (the tilemap). That leaves some empty space above the tile map and the beginning of the other VRAM parts (PSG, Sprite and Pallette). And you still have some space between $16c0 and $1F000 for your sprite data. 

Does anyone know, maybe from an older thread, why the charrom is not loaded to the end of screenram? Sitting at $0F800 is cutting the VRAM in half and sits in the way.

[Starsickle 18]

Having a similar problem with the default configuration (80x60 characters) , where it's hard to tell what's going to happen at 79 and 59.

I'm still experimenting, but a few things that may help would be knowing how to get the current size in characters of the screen, as well as current render size in pixels.

This way I could simply store these values and even provide the functionality to re-get them if the user changes video modes.

[Ender 55]

28 minutes ago, Starsickle said:

Having a similar problem with the default configuration (80x60 characters) , where it's hard to tell what's going to happen at 79 and 59.

I'm still experimenting, but a few things that may help would be knowing how to get the current size in characters of the screen, as well as current render size in pixels.

This way I could simply store these values and even provide the functionality to re-get them if the user changes video modes.

This is subject to change as development of the kernel continues, but there are kernel variables for the screen size in characters:  $386 has the width (llen), and $387 has the height (nlines).  Maybe for pixels, you could just grab the HSCALE and VSCALE from the VERA configuration and calculate it ((PEEK($9F2A)/128)*640, (PEEK($9F2B)/128)*480).

Edited September 3, 2020 by Ender

[Greg King 51]

A (Commodore) Kernal function gives the geometry of the current text screen:

https://www.pagetable.com/c64ref/kernal/#SCREEN