Next is the address generator/graphics instruction engine.
Here are the targeted controls/capable features: (We want to make 1 identical algorithm which will be used 4 times.)
1) Enable/disable. Requires 1 bit.
2) The base/beginning of a memory address which contains either the screen text data, font data, graphics data and sprite data. (This eats 20 bits since we can address 1 megabyte for this address)
3) Vertical memory increment size. When beginning a new line, this is the amount added every time to the base address. (16 bits is fair, maximum 64kb wide picture.)
4) Pixel type. 1bit=8 pixels wide per byte 2 colors per pixel,
2bit=4 pixels per byte 4 colors per pixel,
4bit=2 pixels per byte 16 colors,
8bit=1 pixel per byte, 256 colors,
16bit=2 bytes per pixel, 65k true-color
= 5 settings possible meaning requires 3 bits for this setting.
5) X scale. Counts the number of pixels wide each bitmap image pixel will occupy. 1 through 16 (4 bits)
6) Y scale. Counts the number of lines each bitmap image line will occupy. 1 through 16 (4 bits)
7) Sub-pixel starting X&Y coordinates. This setting vertically & horizontally shifts the image up and to the left by single pixels in text mode and 4/2/1 bit color modes. IE, smooth scrolling of text horizontally by up to 7/8th of 1 character, then you can change the base memory address by 1 character and reset this setting back to 0 allowing you to move the text pixel by pixel horizontally and vertically. The shift 16 pixels x by 16 pixels y , or 8 bits total.
8 ) Special control for font size. 8x8 pixel bitmap to 16x16 bitmap. 4 bit control.
9) Total number of video lines to render before loading a new set of the above controls. This will allow you to switch video modes mid screen, EG: have a window of 40 column text for half the screen, then switch to 80 column text for the bottom half.
Have I missed anything. The total here is around 14 control bytes, or, we will reserve 16 bytes per address generator and call it safe.
Extra Note: The horizontal and vertical windows and enables for the 16 sprites will be stored separately. 10bit X 10 bit Y.
Palettes also have a dedicated separate set of registers. A programmable interrupt generator based on a selected line of video will also be added for smooth animation apps.
Ok, here we go:
We will have a master H & V trigger for the horizontal reset and vertical reset. This will be parameter assigned inside the address_generator-s, bitplane_to_raster-s, and palette_mixer-s.
All register controls should be latched on the parameter selected ' H && V ' triggers so that the Z80 can make changes during the entire display time, however, the entire bulk of graphics / coordinate settings will be updated/refreshed once every V-sync. The down side (except for the H&V trigger which we will fix later on) is that you cannot take 1 sprite and manipulate it's settings in real time during the middle of the screen refresh to trick construct multiple additional sprites. However, the pros are a ton of CPU cycles may be used to construct an animated display during the entire display time while the next V-sync, all screen geometries will be refreshed all at once. Also, with 12 sprites, and a jump to 24 sprites with the Lattice FPGA part, each one of the 24 being able to be larger than 640x480, like 65536x65536 viewport window, if you complain about this real-time limitation, I'll be on a flight over seas to murder you...
Each line generator will also have a parameter to identify which 1 set of H&V trigger will be used to position their top-left X&Y coordinate location and a second H&V trigger to define the bottom right screen coordinates of the image.
Next, #1 & #4. We will squeeze these 2 together with a few other options. This HW_REG will hold the control for the bitplane_to_raster module. All 8 bits will be sent into that module and define the video mode. Off, 1 bit color, 2 bit color, 4 bit color, 8 bit color, 16 bit color, special 2 byte text color font. Color Palette type (either ARGB 4444, RGB 565, or 16 bit 565 thru, or mixed 16bit 656 thru with last 256 colors assigned through the palette). (5 or 6 bits consumed, 2 spare bits for future features)
Next, bg_color and fg_color. These are 2 HW_REG byte values used for the 1 bit color mode and for where within the palette the remaining missing upper bits of the 16 and 4 color modes will be placed.
Next, #2 The base/beginning of a memory address which contains either the screen text data, font data, graphics data and sprite data. 3 HW_REG bytes.
Next, #3 The X size/width in bytes of the image in memory being displayed. 2 HW_REG bytes.
next, X&Y scale, and sub_pixel X&Y start. 1 byte each for a total of 4 bytes.
We are at 16 bytes to control every feature of the window line generator. 15 address generators, + 16 bytes for a few global controls means 256 bytes for the HE_REGS. You will need to double this setting on the Lattice FPGA as it will have 30 address generators. More if you want to add an audio system.
When a line generator is in the special ascii text mode, it will have the same controls, but with 1 or 2 changes to define the font's X&Y size attributes plus 1 input in the module will be used to receive an incoming ASCII character from the multiport_ram output from a previous line generator to realtime point to a font's position to construct a bitmap. This means you need 2 address generators with 2 ram ports to construct a text/character tile based display on the screen, though the second line generator is mostly dead and just passes through a bunch of wired signals.
For our development path, we will start with a simple line generator which will open a 256 color display window on the screen, with adjustable X&Y coordinates and X&Y size. We will use port 3 on our multiport ram and add bitplane to raster module to receive the output, then feed the palette mixer module 565 input.
We wont touch the text yet. Need to first get the basics working.
More to come after some sleep...
Home
Help
Search
Login
Register
