Black area at bottom of emulator

[Jestin]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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

[svenvandevelde]

On 8/30/2020 at 4:04 PM, SerErris said:

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.

I have exactly the same question. Why was it designed like this. It seems illogical to me. 

[Elektron72]

1 hour ago, svenvandevelde said:

I have exactly the same question. Why was it designed like this. It seems illogical to me. 

Looking through old VERA documentation, it seems that at one point, there was only 64K of VRAM, so the character set would have been at the top back then. I suspect that the team simply has not moved it to a better position yet.

[svenvandevelde]

5 hours ago, Elektron72 said:

Looking through old VERA documentation, it seems that at one point, there was only 64K of VRAM, so the character set would have been at the top back then. I suspect that the team simply has not moved it to a better position yet.

Well ... it would be good to move it now ... but maybe it's too late and as such, this feat will live forever in the x16...

[StephenHorn]

6 hours ago, Elektron72 said:

Looking through old VERA documentation, it seems that at one point, there was only 64K of VRAM, so the character set would have been at the top back then. I suspect that the team simply has not moved it to a better position yet.

I'm not sure what documentation you found, but as far as I'm aware the VERA has never been limited to 64KB of VRAM, and I went looking through the emulator code to build my own documentation as early as r27, which was the first publicly released version of the emulator.

The VERA used to think in terms of 24-bit addresses, however, with the most significant byte acting like a bank switch. VRAM was then located in banks 0 and 1, while other memory-mapped registers were located in other banks. It would be easy to mistake this setup as "VERA only has 64KB of VRAM", if the author was forgetting about the entire second bank of VRAM.

(Note that, even as early as then, there was no internal division between "the two banks of VRAM", so tilemaps, image data, etc. could overlap the bank boundary without causing any issues.)

[Elektron72]

I misinterpreted the documentation I found. Thanks for the correction. I now have no idea why the character set is loaded at $0F800. The only reason I can think of is that the team wanted to keep all of the VRAM manipulated by the KERNAL in bank 0.

Edited April 3, 2021 by Elektron72

[Snickers11001001]

On 6/28/2020 at 7:34 PM, StephenHorn said:

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

Here's my vote against that particular solution and here's my reasoning: 

Whether its at the top of the screen or centered, if the 'mode' is going to be 320x200 then the display should be 320x200 pixel-for-pixel.   Scaling without a clean multiple winds up with certain lines of pixels taller than others and especially for a mode accessed from BASIC would tend in my view to diminish the value proposition.   

Advanced coders using assembly and talking directly to the VERA can make their own choices, but I think whatever BASIC presents as "the bitmap" (i.e., "SCREEN$80") really oughtn't have any weird scaling artifacts.   That's my view even if it means the black bar at the bottom (as now) or perhaps a solid color "pseudo-border" for an area top and bottom like your second example, with the 320x200 bitmap centered vertically between them.   

Just my two-pence, of course   

[StephenHorn]

3 minutes ago, Snickers11001001 said:

Whether its at the top of the screen or centered, if the 'mode' is going to be 320x200 then the display should be 320x200 pixel-for-pixel.

Regrettably, this is not technically feasible, and would never have been. The VERA has always been 640x480 and only 640x480, it has never had the option of supporting multiple pixel clock speeds for multiple native resolutions. So our choices are "scaling with artifacts", "moving the display", or "doing nothing."

[Snickers11001001]

1 minute ago, StephenHorn said:

Regrettably, this is not technically feasible, and would never have been. The VERA has always been 640x480 and only 640x480, it has never had the option of supporting multiple pixel clock speeds for multiple native resolutions. So our choices are "scaling with artifacts", "moving the display", or "doing nothing."

I should have been more clear, and my poor phrasing was "pixel for pixel" -- my apologies.  

Let me try a little to rephrase:    With 640x480 native resolution of the VERA, what I'd prefer is displaying the 320x200 "basic" bitmaps as just a straight 2x scale as I see it down in the emulator now.  Each 320x200 pixel is twice as wide, twice as high, which works with the 640x480 screen -- at the cost of leaving that extra 80 pixels worth of space unused in the vertical space.      

I think when you say "doing nothing" you mean nothing from the current simple 2x scale.   And I agree with that, rather than applying a scaling in the vertical that causes distortion.  

Sorry again for my poor articulation earlier;  rereading my post I can see it was something of a mess.   

[StephenHorn]

2 minutes ago, Snickers11001001 said:

I should have been more clear, and my poor phrasing was "pixel for pixel" -- my apologies.  

Let me try a little to rephrase:    With 640x480 native resolution of the VERA, what I'd prefer is displaying the 320x200 "basic" bitmaps as just a straight 2x scale as I see it down in the emulator now.  Each 320x200 pixel is twice as wide, twice as high, which works with the 640x480 screen -- at the cost of leaving that extra 80 pixels worth of space unused in the vertical space.      

I think when you say "doing nothing" you mean nothing from the current simple 2x scale.   And I agree with that, rather than applying a scaling in the vertical that causes distortion.  

Sorry again for my poor articulation earlier;  rereading my post I can see it was something of a mess.   

No worries, could just as easily be my fault, on a re-read I see what you meant.

[Ender]

I decided to try putting in a PR to move the character tile data to $4000, in addition to changing screen 128 mode to actually be 320x240 now that we have more free space.  It now starts at $C800.  There's also a sprite API I hadn't known about that previously utilized $7800-$F7FF, I changed it to $4800-$B7FF.

[SlithyMatt]

8 hours ago, Ender said:

There's also a sprite API I hadn't known about that previously utilized $7800-$F7FF, I changed it to $4800-$B7FF.

The Sprite registers are $1FC00 - $1FFFF. What API are you talking about?

[Ender]

1 hour ago, SlithyMatt said:

The Sprite registers are $1FC00 - $1FFFF. What API are you talking about?

There's a couple functions in kernal/drivers/x16/sprites.s that are used in some places in the kernal.  Now that I look, they're in the Programmer's Reference Guide as well, "sprite_set_image" and "sprite_set_position".

By the way, I was tired last night and didn't do much testing before I submitted the PR and then of course found it was pretty buggy right after.  Turns out there's a lot of places in the graphics routines that assume we're always in bank 1 of VRAM, and the various places addresses are calculated don't take the 17th bit into account or hardcodes it to 1.  I've already started going through and fixing these, but I put the PR on hold for now.  Hopefully I'll be done soon.

[desertfish]

the GRAPH_xxxxx  routines are all hardcoded to 320x200 i think.... that would be a pretty big task to fix all of them?

[SlithyMatt]

9 minutes ago, Ender said:

There's a couple functions in kernal/drivers/x16/sprites.s that are used in some places in the kernal.  Now that I look, they're in the Programmer's Reference Guide as well, "sprite_set_image" and "sprite_set_position".

 

Those are in the ROM at $FEF0 and $FEF3, not in VRAM.