Jump to content
  • 0

Black area at bottom of emulator


Jestin
 Share

Question

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:

image.thumb.png.e1d8b79e1bdc590357ce93e0d32dcb56.png

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

Link to comment
Share on other sites

Recommended Posts

  • 0

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 by StephenHorn
  • Like 1
Link to comment
Share on other sites

  • 0

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:

320x200.thumb.png.7b229f2aa8ef35be51e897365cb2adcd.png

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

320x200-2.thumb.png.d1e7dbf5342e62d79af9cadff8354fd3.png

Edited by StephenHorn
Link to comment
Share on other sites

  • 0
  • Administrators

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.

  • Like 5
Link to comment
Share on other sites

  • 0
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 by Ender
Link to comment
Share on other sites

  • 0
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 by SerErris
Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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 by Ender
  • Like 1
Link to comment
Share on other sites

  • 0
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. 

  • Like 1
Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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...

Link to comment
Share on other sites

  • 0
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.)

  • Like 2
Link to comment
Share on other sites

  • 0

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 by Elektron72
Link to comment
Share on other sites

  • 0
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   

Link to comment
Share on other sites

  • 0
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."

Link to comment
Share on other sites

  • 0
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.   

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use