Electronics > FPGA

FPGA VGA Controller for 8-bit computer

<< < (541/734) > >>

nockieboy:
Am I right in thinking that the geometry unit won't draw objects outside the bounds of the visible screen?  This poses a slight issue for clearing the screen.  It appears that the best method for clearing the screen (a CLS subroutine, basically) is to draw a rectangle on it in the background colour, as this handles all the nuances of the screen mode and its specific bpp setting, instead of just writing zero bytes (for 1 bpp) to GPU RAM for a calculated screen size.

The issue I've got is that the rectangle will not fill the screen - there's a vertical line on the far right edge where it won't draw.  This looks like something I've missed when I tested the geometry unit whilst we developed it - I'm off to go and dive into the HDL and add 1 to wherever the bounds check is for drawing pixels, but thought I'd raise it here as it's a bug in the existing GPU code.

Also, I need to clear a horizontal line of pixels past the bottom edge of the visible area (used for vertical scrolling) - I'll need to tweak the HDL to allow for drawing past ALL edges by a pixel or two to cater for scrolling, I guess?  Let me know if I'm walking into a bear trap or something.  :-+

BrianHG:

--- Quote from: nockieboy on September 14, 2021, 10:29:53 am ---Am I right in thinking that the geometry unit won't draw objects outside the bounds of the visible screen?  This poses a slight issue for clearing the screen.  It appears that the best method for clearing the screen (a CLS subroutine, basically) is to draw a rectangle on it in the background colour, as this handles all the nuances of the screen mode and its specific bpp setting, instead of just writing zero bytes (for 1 bpp) to GPU RAM for a calculated screen size.

The issue I've got is that the rectangle will not fill the screen - there's a vertical line on the far right edge where it won't draw.  This looks like something I've missed when I tested the geometry unit whilst we developed it - I'm off to go and dive into the HDL and add 1 to wherever the bounds check is for drawing pixels, but thought I'd raise it here as it's a bug in the existing GPU code.

Also, I need to clear a horizontal line of pixels past the bottom edge of the visible area (used for vertical scrolling) - I'll need to tweak the HDL to allow for drawing past ALL edges by a pixel or two to cater for scrolling, I guess?  Let me know if I'm walking into a bear trap or something.  :-+

--- End quote ---
You may blank the a bottom line after a vertical scroll, or,
just expand the max X&Y limits beyond the bottom of the display area.
However, so be warned, you will allow pixels to be written into ram off the screen, so make sure you have spare memory there.

IE, have 8 spare lines of blank data in the Y direction so that you may use a single blit including the blank ram so you do not have to do the actual rectangle clr at the bottom of the screen.

You may also have a full line of text text, 8 y pixels, below the display area pre-printed if you want a TV type vertical smooth scroll where the text begins off the bottom of the screen.  You may also have 1 spare line above the top of the screen if you want an up-down web-page like smooth scroll for a text reader/word processor or spreadsheet.

You may also do this horizontally as well and it need not be only 1 line and 1 row of text, you may buffer 2 or 4 characters off the borders if you like or even an entire page.

nockieboy:
Of course, there's loads of ways I could have implemented the scrolling.  Why I went with the extra line/s off the screen I don't know, probably the first idea that sprang to mind at the time - other than that I can clear those lines once, then not worry about having to clear every bottom line when I blit the screen upwards one line.  You're right though, if memory is tight then it's not the best solution, but with megabytes to play with in the DDR3, that shouldn't be a concern.

Have sorted the CLS not clearing the rightmost column without resorting to changing HDL in the end.  I'd gotten mixed up with which registers are 0-based and which aren't, and had set the max_x value to 639 instead of 640 in the setup. :palm:  It's the MAGGIE HW registers that are 0-based, not the GPU registers. Sorted now. :-+

nockieboy:
Okay, nearly there with the CP/M graphics driver after a little time to work on it again today.  I can now change modes (between 640x480x1 and 640x480x2 anyway) and 4-colour mode is working.  I could do a 640x480x4 mode but the MAX10 doesn't have enough block RAM for a power-of-2 to allow for it and would involve some HDL hacks that aren't necessary if I'm going to move up to DDR3 shortly.

An issue has arisen which I'd like to address before I move on to connecting the DDR3 up - and it links directly to the previous question I had last week (or recently, anyway) about the XOR-ing of colours when blitting text characters.

I'd like to be able to blit a 1-bit text character to any number of bitplanes in the target, and change the values of 0s and 1s in the source to arbitrary values in the target.  i.e. I'd like to be able to blit the source 1bpp image so that the text could be white on black, or black on white, or green on a different shade of green, depending on which pen/paper values the user has set (and not solely by editing the palette).  The current setup doesn't appear to allow this, at least as far as my understanding of it goes?  It just seems to be able to alternate between colours immediately adjacent to each other in the palette thanks to the XOR-ing? (i.e. palette entries 0 and 1, 2 and 3, 4 and 5 etc)

Is there a setting that I haven't worked out yet that will allow me to (for example) blit blue text with black background (palette entries 2 and 0)?  At the moment all I can do is black on black, or its inverse, or blue on green, or its inverse.  I can obviously edit the palette so that 0 is black, 1 is white, or 2 is light green, 3 is dark green etc, but that's not very flexible if bitmaps are also in play).  :-//

BrianHG:
For the paste, maybe we can change XOR to ADD in the HDL.

Though, if you want to have different background colors, you would need to do 2 blits, one with a 0 transparency, and the next with a 1 transparency, while pasting both with a different ADD value.

This will work fine for 1 bit source data.
For more bits, you would need to think things through to ensure you can get the color functionality you want if you make the 'ADD' change.

Navigation

[0] Message Index

[#] Next page

[*] Previous page