FPGA VGA Controller for 8-bit computer

[asmi]

I wonder how long it'll be before we (hobbyists) have access to that level of power?  I mean, the (low-end) FPGA's we're talking about and using provide us with power and versatility unheard of back in the 80's, even on dedicated hardware.

5 GHz will probably be out of reach for a long time - considering that even the very best FPGAs out there can barely cross 1 GHz line, but 300-500 MHz for a general logic is very achievable with Xilinx Ultrascale+ devices. These new Artix US+ devices which are supposed to come out soon will also be built on the same fabric, but can be somewhat accessible to hobbyists, even if on a pricey side ($200 per chip). So while certainly not Arduino-level cheap, they are still a lot cheaper than existing devices from that family, which I think starts at like 1500$ per device.

And I thought what BrianHG was doing with the DDR3 was complicated. 

It's not very complicated, because all shader units are usually grouped into "warps", and all shader units within a warp execute in lock-step, meaning each and every shader unit executes the same operation. You can think of SU as a specialized ALU capable of performing all typical math operations. Then you can have two FIFOs, which are filled by the scheduling unit - one for "ready" commands - which have all data ready for their execution, and another one for waiting for memory (since memory operations are pipelined, they complete in the same order they were issued). So if you encounter a memory access operation, you just send a request into the memory subsystem and place command into the "waiting" FIFO, and once it completes, you put it back into the "ready" FIFO. This is of course very simplified, but I hope you get an idea.

My question is, is the access latency literally "very large", or does it just appear that way because the GPU is running at such high clock speeds that it's hitting the physical limits of DDR memory cell capacitor charge/discharge times?  Would be cool if they could come up with a quicker memory technology.  Isn't SRAM faster, but a lot more expensive, or did I imagine that?

DRAM speed in not a problem - interface speed is. This is why NVidia had to partner with Micron to engineer PAM4 interface for GDDR6X memory, which essentially transmits two bit per edge instead of one (by having 4 different signal levels as opposed to just two for typical NRZ-type digital interface), effectively doubling available bandwidth. The downside is that this interface is much more susceptible to the noise (because receiver now need to distinguish between 4 signal levels as opposed to just two), which is why they integrated error correction right at the interconnect level.

As for SRAM - it's faster (BRAM blocks inside FPGA are essentially SRAM, and so are all caches inside a CPU and GPU), but it takes a lot of die space, and it consumes a lot of power - compared to DRAM. You can just look up how much a 32 MB SRAM module costs, and compare it to DDR3 for example - you will see like close to two orders of magnitude difference. SRAM (in form of QDR-X) is still used in some specialized applications where DDRx latency is just unbearable - like network switching equipment, and even there it's mostly used as an extension of on-chip RAM - like additional cache level. Incidentally, I had a single design where I connected a small 1MByte SRAM chip to FPGA and used it as a cache for much larger DDR3 memory, because while it can't match DDR3 bandwidth, it's capable of completing an access in just single cycle, and since it doesn't need a refresh, this access time was guaranteed all the time. It was just a simple 10 ns SDR chip, but there are chip out there which can work at significantly higher frequencies, the problem is they cost a lot of money - we're talking 100's of dollars per chip.

[BrianHG]

And I thought what BrianHG was doing with the DDR3 was complicated. 

It's not very complicated, because all shader units are usually grouped into "warps", and each warp performs in lock-step, meaning each and every shader unit executes the same operation. You can think of SU as a specialized ALU capable of performing all typical math operations. Then you can have two FIFOs, which are filled by the scheduling unit - one for "ready" commands -  ....

Yes even my little multiplayer DDR3 window reader and multiple parallel window outputs I'm making now already has the beginnings of such built in parallel-ism, both using parallel modules for pure speed and serial sequential channels in each module where as much speed isn't needed, allowing me to use each of the same rendering pipes for multiple layers cutting logic resources by a number of fold.  (Now when I say rendering, this is nothing more than a schedule ahead line cache read, with a playback system which manages color mixing overlays of said channels which tells the read scheduler the status of the playback display buffers.)

The tricky 2 sided mess is making code which bottom end fabric FPGAs will still achieve a good FMAX even as you add channels, and, generate code where the compiler may automatically trim/prune logic effectively based on which features the user enables as well as whether a number of functions as hard-wired or under real-time software control without needing to go to the top-end dedicated HDL compilers separate of the FPGA vendor's development studios.

The other issue is the tiny 1.7megabit core FPGA ram.  1.7megabyte for this project would have been a luxury and I could code things much simpler, but, being a project designed to fit even on a smaller 6$ lattice 25kgate, 900kbit core ram FPGA, I went through the effort of making something which can still function on a few 10k of blockram instead of requiring a few 100k of blockram.

[voltsandjolts]

LVGL is a nice open source graphics library for adding a GUI to your embedded system.
It doesn't currently support 8-bitters, but then they didn't expect an 8-bitter to have a GPU
It might be worth considering LVGL requirements when designing new GPU functionality to ease creation of an LVGL backend for your custom GPU.
Just a thought.

[SiliconWizard]

LVGL is a nice open source graphics library for adding a GUI to your embedded system.
It doesn't currently support 8-bitters, but then they didn't expect an 8-bitter to have a GPU
It might be worth considering LVGL requirements when designing new GPU functionality to ease creation of an LVGL backend for your custom GPU.
Just a thought.

Not a bad idea indeed, although here, as you yourself said, this is a bit beyond what was meant for an 8-bit system.

[nockieboy]

I've managed to put together some simple test images for the 1-8 bpp images you requested.  I have no idea where to start or how to do the 512x512 images you're requesting.  There's a 512x512 image with transparency in the zip, but I have no idea if it's ABGR or anything else.

I'll make a start on the fonts as soon as I have some more time.

[BrianHG]

Cute, the Mandalorian, 32bit instead of 24bit, with an Alpha translucency layer, in .png.
Ok, for the palette, Why isn't color 0 black?
I figure they are in order.
Also, not a single transparent color, usually #0.

[BrianHG]

  Ohhh, Adobe Photoshop Elements, Ohhh Paint Shop Pro 5, you both screw up, but in different ways and one is more use full than the other.

Ok Nockieboy, your 512x512.png Mandiloarian has a proper true Alpha blend channel recognized by both Adobe Photoshop and Paint-Shop-Pro 5, though PSP5 doesn't show it as nice unless you have an additional layer or stencil enabled below it.

If I save the image in non-compressed Truvision TARGA .tga in Photoshop, I had a choice of 16/24/32.
Saving it as 24 bit gave me a file just above 786432 bytes as expected.
Saving it as 32 bit gave me a file just above 1048576 bytes as expected.

If I save the image in non-compressed Truvision TARGA .tga in PaintShopPro5, I had a choice of 8/16/24.
Saving it as 24 bit gave me a file just above 1048576 bytes, not as expected.

Ok, I took the 2 just above 1048576 bytes files from both paint tools and hex-edited them both to remove the header and footer making both files exactly 1048576 bytes.  From what I can tell, the image in the file is vertically flipped, I don't like that, but, it seems to be a trend with a number of picture formats on the PC.

Look at the 2 files in the attached .zip in once of your hex editor of choice and remembering the image is upside-down, you tell me what is the difference.  (Hint, make sure you hex editor rows are viewed in rows which fit a multiple of 4 bytes...)

Files:
512x512x32.Adobe.tga.bin
512x512x32.paintshoppro5.tga.bin
(I removed the useless file as the next post has a good one.)

[BrianHG]

Ok, same photo, saved by photoshop in .tif uncompressed, including transparency layer.

This time the photo is right side up.
However, the header was a doozy, fairly large filled with tons of garbage text.

On the plus side, this is the only format which did not loose anything at all or interpret the transparent pixels to another background color in the process of saving.

The order appears to be RGBA.

So, in my window system, place this .bin on a layer above another with the alpha enabled, you will get that smooth shaded transition embedded in the outline of the Mandalorian so he will appear floating above the below image without any visible harsh cut-out edge.

Keep this .bin as it is a good test reference image for playing with an image with a true smooth transitioned alpha-blend edge.

Know that PSP5 seems to loose the transparency when loading the .png and saving to .tif, or corrupt the transparent area with color values it deems to be it's set default background color.

I've attached the save method to make the .tif in Adobe Photoshop Elements 9 which I trimmed in a hex-editor to make the attached raw 512x512x32 .bin file.  With these settings, though there is a cram of header BS, it should be easier to decode in software as uncompressed .tif is not too complicated and you get the RGBA as a 32bit integer for each pixel.

[BrianHG]

Ok, progress so far on my new BrianHG_DDR3 video generator system:

Module 1: BrianHG_GFX_Sync_Gen.sv and testbench.
Done.
Provide a pixel clock with CLK_DIVIDE_IN, H&V total, display res, front porch width & sync width and it generates all the synchronization signals to generate a video output.
CLK_DIVIDE_IN can be 0,1,2,3,4,5,6,7 to both divide the source clock by 1,2,3,4,5,6,7,8 and also used by the output video line generator to support from 1 through 8 layers sequentially interleaved / multiplexed.

Module 2: BrianHG_GFX_Video_Line_Buffer.sv and testbench.
Beta functional.
Takes input from a single BrianHG_DDR3 read port with multiplex addressing to allow multiple parallel modules running from one single DDR3 read port, and a set write address range for tile memory and palette memory compatible with my BrianHG_DDR3 TAP_xxxx port, and generates a line of video output with the capability of up to 8 sequential layers according to the sync generator's CLK_DIVIDE_IN setting.  All inputs run on the system CMD_CLK while the video output stream runs on the video output clock synchronized to the BrianHG_Sync_Gen.sv.

Module 3: BrianHG_GFX_Window_DDR3_Reader.sv and testbench:
Just beginning to work on.
Takes in the user graphics settings and sends commands to a DDR3 read port to fill the BrianHG_Video_Line_Buffer's memory in sync with that module's feedback outputs: horizontal reset, vertical enable and line buffer FIFO position status.
It will be configurable to support both up to 16 parallel BrianHG_Video_Line_Buffer.sv modules with up to 8 Sequential layers within each module allowing addressing up to 128 layers total.  (I don't think the DECA has enough blockram/gates to do all 128 layers, but, the 35$ 85kgate 4megabit Lattice LFE5U-85 can do it with ease.)

Module 4: BrianHG_GFX_Window_Layer_Mixer.sv
Will work on after module 3.
Coalesces and superimpose/mix all the video layers streamed out of the BrianHG_Video_Line_Buffer modules, using the 'Alpha' channel to set the layer-to-layer translucency when generating the single video output.  Also contains the individual layer-layer hardware accelerated pixel collision detector status.


Once #4 is done, it is just a wiring into the GPU and assigning the video window setting controls to your chosen HW_REGS settings.  Then program away.  Though, I will have a GPU setup ready when module #3 is done, except it will only support 1 layer, but every video mode and feature should function for testing.

[BrianHG]

Module 3: BrianHG_GFX_Window_DDR3_Reader.sv update:

Finished all the IO, definitions and testbench setup.  Next onto the formulai and testing in my DDR3 1080p example.

Here are your new window controls with description exposed to the Z80:

Code: [Select]

input        [2:0]                  CMD_win_bpp            [0:LAYERS-1], // Bits per pixel.  For 1,2,4,8,16a,32,16b bpp, use 0,1,2,3,4,5,6.  *16a bpp = 4444 RGBA, 16b bpp = 565 RGB.
input        [31:0]                 CMD_win_base_addr      [0:LAYERS-1], // The beginning memory address for the window.
input        [HC_BITS-1:0]          CMD_win_bitmap_width   [0:LAYERS-1], // The full width of the bitmap stored in memory.  If tile mode is enabled, then the number of tiles wide.
input        [HC_BITS-1:0]          CMD_win_bitmap_x_pos   [0:LAYERS-1], // The beginning X pixel position inside the bitmap in memory.
input        [VC_BITS-1:0]          CMD_win_bitmap_y_pos   [0:LAYERS-1], // The beginning Y line position inside the bitmap in memory.

input        [HC_BITS-1:0]          CMD_win_x_offset       [0:LAYERS-1], // The onscreen X position of the window.
input        [VC_BITS-1:0]          CMD_win_y_offset       [0:LAYERS-1], // The onscreen Y position of the window.
input        [HC_BITS-1:0]          CMD_win_x_size         [0:LAYERS-1], // The onscreen display width of the window.      *** Using 0 will disable the window.
input        [VC_BITS-1:0]          CMD_win_y_size         [0:LAYERS-1], // The onscreen display height of the window.     *** Using 0 will disable the window.

input        [3:0]                  CMD_win_scale_width    [0:LAYERS-1], // Pixel horizontal zoom width.  For 1x,2x,3x thru 16x, use 0,1,2 thru 15.
input        [3:0]                  CMD_win_scale_height   [0:LAYERS-1], // Pixel vertical zoom height.   For 1x,2x,3x thru 16x, use 0,1,2 thru 15.
input        [3:0]                  CMD_win_scale_h_begin  [0:LAYERS-1], // Begin display part-way into a zoomed pixel for sub-pixel accurate scrolling.
input        [3:0]                  CMD_win_scale_v_begin  [0:LAYERS-1], // Begin display part-way into a zoomed pixel for sub-pixel accurate scrolling.

input        [7:0]                  CMD_win_alpha_override [0:LAYERS-1], // When 0, the layer translucency will be determined by the graphic data.
                                                                         // Any figure from +1 to +127 will progressive force all the graphics opaque.
                                                                         // Any figure from -1 to -128 will progressive force all the graphics transparent.

input                               CMD_win_tile_enable    [0:LAYERS-1], // Enable Tile mode enable.  *** Display will be corrupt if the BrianHG_GFX_Video_Line_Buffer
                                                                         //                               module's ENABLE_TILE_MODE parameter isn't turned on.

input        [2:0]                  CMD_win_tile_bpp       [0:LAYERS-1], // Defines the tile bits per pixel.  For 1,2,4,8,16a,32,16b bpp, use 0,1,2,3,4,5,6.  *16a bpp = 4444 RGBA, 16b bpp = 565 RGB.
input        [15:0]                 CMD_win_tile_base      [0:LAYERS-1], // Defines the beginning tile 16 bit base address (multiplied by) X 16 bytes for a maximum of 1 megabytes addressable tile set.
input        [1:0]                  CMD_win_tile_width     [0:LAYERS-1], // Defines the width of the tile.  0,1,2,3 = 4,8,16,32
input        [1:0]                  CMD_win_tile_height    [0:LAYERS-1], // Defines the height of the tile. 0,1,2,3 = 4,8,16,32

HC_BITS and VC_BITS are set to 16 meaning a maximum horizontal and vertical resolution of 65536 pixels or tiles.
LAYERS is a parameter which allows you to set the maximum available window layers.
All the above inputs are wired to incrementing addresses from the new HW_REGS module.
The tile/font and palette memory are also addressed as regular DDR3 memory as they are wired through the new TAP_xxx port.

It looks like you will need 32 bytes worth of controls per window.
We should double it just for spare future expansion.

So, once we configure a base offset for the HW_REGS, each progressive window layer will has the same controls, but beginning at +64 bytes above the previous window's beginning address.

Except for CMD_win_scale_h_begin & CMD_win_scale_v_begin inputs (which you probably not want to use unless it is something special), this new window module does all the cruddy math work internally when addressing sub-pixel positions with regards to tile/font and the input CMD_win_bitmap_x/y_pos settings so you just enter the coordinate you want and my window HDL will automatically work out the sub-pixel addressing within each tile or bitmap below 32bit for you.

When choosing a base address and bitmap width, it is still recommended that you pad the address and size to every 32 bytes to make the most of the new BrianHG_DDR3_Memory_Copy_Manager.sv coming in the new year which will copy memory from A->B with functions which can be used for general memory copying with advanced functions for graphics, sound mixing/blending/processing where 128/256bit mode is the fastest, but to use the 128/256 bit mode, your source and destination memory pointers will need to be located on 128/256bit boundaries.  Otherwise, 64bit mode is half speed, 32bit mode is half that, 16 bit mode is half that, and 8 bit mode is half that.

[BrianHG]

Merry X-Mas everyone, Happy Holidays!

Module 3: BrianHG_GFX_Window_DDR3_Reader.sv update:

All the window metrics/coordinates and addressing appear simulate properly.

Next:
A) Stream out the DDR3 read requests from the generated addresses.
B) Wire into my existing show_1080p demo project and test.
C) Wire into Nockieboy's GPU.

D) Work on module 4: BrianHG_GFX_Window_Layer_Mixer.sv so we may see more than 1 window layer.

I have passed 2K lines of code for this Video Windows Generator and expect ~1k mode before I finish.
It is already as complicated as my DDR3 controller from over a decade ago.

[BrianHG]

Got the first picture with HW_REGS controls.
Got a bunch of debugging to do.

I need those font files...

[BrianHG]

@Nockieboy, the font tool you need: http://www.codehead.co.uk/cbfg/

Though you only get 128/64kb using the HW accelerated tile/font system, with a max of 32x32 pixels, (maybe I should extend that to 64x64 as 1bpp/2bpp fonts still are just within 128k, using the blitter for text give you access to all DDR3 memory to draw text.

[BrianHG]

I've managed to put together some simple test images for the 1-8 bpp images you requested.  I have no idea where to start or how to do the 512x512 images you're requesting.  There's a 512x512 image with transparency in the zip, but I have no idea if it's ABGR or anything else.

I'll make a start on the fonts as soon as I have some more time.

Test Image report:
1024x768x2.bin   - I seem to be getting a line of garbage at the top of the display and a width of 1028 pixels, not 1024 pixels.

1024x768x4.bin   - This one seems fine, 16 shades of grey.  However, with 16 shades, did you really need to dither is so hard?  Or, is there some sort of color palette I need to see it right?

1024x768x8.bin   - Best looking one yet.  Still heavily dithered.  I'm guessing I need a special palette to see it in color.

2048x1536x1.bin  - Looks good.

Only the '1024x768x2.bin' is out of spec.

[BrianHG]

Ok, the my BrianHG_GFX_VGA_Window_System is 90% functional.  Only the final layer alpha channel mixer is missing as I am now just averaging windows for testing, but they are all there with all their features.

I paused here because the ravage DDR3 memory access done by the BrianHG_GFX_VGA_Window_System with multiple windows simultaneously open, each deliberately configured with an odd number of row pixels and to eat up over 90% of the available bandwidth causes that one DDR3 read port in use by the graphics system to randomly freeze.  It's time to look at debugging my multiport section of my controller before I finish my last alpha-blend window layer mixing module of my window system.

[nockieboy]

Okay, I'm back - sorry for the radio silence over the holiday, it's been a bit hectic and for some reason I wasn't getting notifications of posts to the forum.  I've got a very busy couple of days coming up, but I'll try to get up to speed with developments as quickly as I can and get those fonts sorted ASAP.

Happy New Year! 

[nockieboy]

Tiles/Fonts: (Supports separate 4/8/16/32 widths and heights, 1/2/4/8/16a/16b/32 bpp, up to 16k characters with mirror and flip per character.)

1bpp 8x16, 256 character VGA Font  (I already have this one.)
1bpp 8x8, 256 character VGA Font.
1bpp 16x32, up to 256 character Font.
1bpp 32x32, up to 256 character Font.
2bpp 16x32, up to 256 character Font.  (4 color.)
4bpp 8x16, up to 256 character Font.  (16 color.)
4bpp 16x32, up to 256 character Font.  (16 color.)
8bpp 8x16, up to 256 character Font.  (256 color.)

See attached fonts.zip for the above font requests.  I've produced several bitmap (.BMP) source files for each tile size (filenames are Font_XxX.bmp) and from those source files I've produced font bitmaps with the requested number of bit planes.  Hopefully they're in the correct format you want and all is okay with them.  They're all greyscale, so despite the differing bpp, they should all be only 2 colours.

16bpp 8x16, up to 256, 16 is enough, character Font.  (4x4x4x4 ABGR 4096 true color font with with 16 translucency levels.)
16bpp 8x16, up to 256, 16 is enough, character Font.  (5x6x5 BGR 65536 true color font.)
32bpp 8x16, 16 is enough, character Font.  (8x8x8x8 ABGR 16.7M true color font with with 256 translucency levels.)

I have no idea where to start or how to produce a colour bitmap font mapped to a particular palette type.

[BrianHG]

Big update coming tonight.
Be ready for tomorrow morning your time.

The documentation alone will be hell as my VGA system is has controls up the wazoo.  (Yes, spellcheck says 'wazoo' is a real word to my surprise.)

[BrianHG]

  Ok, here we go, the first beta of the GPU project with my new:

     BrianHG_GFX_VGA_Window_System.sv

  Another maddening 4596 lines of code so far.... WTF was I thinking...

Anyways, right now, the number of window PDI_LAYERS can only be set to 1 while the number of SDI_LAYERS windows is 4.  The layer swapping / priority sorting logic isn't functional and there is no pixel collision detect function.

You will need to read the attached documentation to do anything.

To avoid a bug with my DDR3 Controller, for now, the ram is clocked at 300MHz half-rate mode instead of 400MHz quarter rate mode.  It's shouldn't affect anything on your side as with a 4 window layer limit, you arent getting close to the DDR3 limits no matter what you do.

I've also attached a 4layer.bin file which you may use the RS232 debugger to send to your GPU with a test setup having all 4 layers turned on.

These are your current project setup parameters:
(The attached .txt file tells you what they do and how to use the graphics system.)

Code: [Select]

parameter string     ENDIAN                  = "Little",            // Endian for 8bit addressing access.
parameter bit [3:0]  PDI_LAYERS              = 1,                   // Number of parallel window layers.
parameter bit [3:0]  SDI_LAYERS              = 4,                   // Number of sequential window layers.
parameter bit        ENABLE_TILE_MODE  [0:7] = '{1,0,0,0,0,0,0,0},  // Enable tile mode for each PDI_LAYER from 0 to 7.
                                                                    // TILES are available to all SDI_LAYERS of an enabled PDI_LAYER.
                                                                    // Each tile enabled PDI_LAYER will use it's own dedicated FPGA blockram.
parameter bit        SKIP_TILE_DELAY         = 0,                   // Skip horizontal compensation delay due to disabled tile mode features.  Only necessary for multiple PDI_LAYERS with mixed tile enable options.

parameter bit        ENABLE_PALETTE    [0:7] = '{1,1,1,1,1,1,1,1},  // Enable a palette blockram for each PDI_LAYER from 0 to 7.
                                                                    // Each palette enabled PDI_LAYER will use it's own dedicated FPGA blockram.
parameter bit        SKIP_PALETTE_DELAY      = 0,                   // Skip horizontal compensation delay due to disabled palette.  Only necessary for multiple PDI_LAYERS with mixed palette enable options.


parameter int        HWREG_BASE_ADDRESS      = 32'h00000100,     // The first address where the HW REG controls are located for window layer 0.  The first 256 bytes are reserved for general purpose use.
                                                                 // Each window uses 32 bytes for their controls, IE assuming 32 windows, we need 1024 bytes worth of address space.
parameter int        HWREG_BASE_ADDR_LSWAP   = 32'h000000F0,     // The first address where the 16 byte control to swap the SDI & PDI layer order.

parameter int        PAL_BASE_ADDR           = 32'h00001000,     // Assuming 32 layers where each palette is 1024 bytes, we will use 32768 bytes for the palette.
parameter int        TILE_BYTES              = 65536,            // Number of bytes reserved for the TILE/FONT memory.  We will use 64k, IE it is possible to make a 16x16x8bpp 256 character font.
parameter int        TILE_BASE_ADDR          = 32'h00004000,     //

Good luck and make sure you can get everything to work.
I will be adding PDI_LAYERS support in the next few days multiplying you available windows up to 8 fold.
Then I'll fix my DDR3 controller.
The add a hardware window-to-window pixel collision detector.

[BrianHG]

Well?
Do I finish what I started?

[nockieboy]

Well?
Do I finish what I started?

Unfortunately I've had next to no time to spend on anything other than work this week.   Hopefully this weekend. 

[nockieboy]

Before I hit the sack for the night, I've built the project and uploaded it to the DECA.  Getting a rock-solid 1080p@60Hz output with random memory contents on the screen, but signs of life as a band at the top is cleared and pixels are being written to the screen when I type, albeit not making any sense.  Looks like I will need to re-write the graphics driver for the new system, or at the very least study the instructions you've provided and see how to set up the screen as before.

[BrianHG]

Yes, read the instructions.

I believe you should first switch to 720x480 mode.
Also, read the new storage positions for the multiple palettes and font memory as well as every control register which is now different.

Remember, even drawing to the screen using the geometry unit, if that unit writes to an address containing the palette, font, or screen controls, they will all be affected as if your Z80 did the writing of the data.

[nockieboy]

Okay, I'm making progress with getting the display set up for the uCOM and understanding the notes you've provided.

I have a 480p 60Hz screen mode working using the 'special 480p' mode 7.  The graphics driver is currently unchanged, which is the next thing I need to tweak as it still thinks that the start of the video buffer is at 1200H and the tile data starts at 0200H, which overwrites the palette data at 1000H, making some text black, but I've got this on screen so far:



As you can see, GEOFF is working too.  I'll run some more tests once I've tweaked the graphics drivers (especially the CP/M one).

Here's my current settings:

Code: [Select]

     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C100 00 00 12 00 83 7F 02 D0 00 00 00 00 00 00 00 00
C110 02 D0 01 E0 00 00 00 40 00 00 00 00 00 00 00 74
This translates to:

HWREG_BASE_ADDRESS+00 = 0x00001200 (32-bit) Window[0] base address
HWREG_BASE_ADDRESS+04 = 0x83 (8-bit value) Screen bpp (3 bpp and enabled) <- arrived at this value by trial and error
HWREG_BASE_ADDRESS+05 = 0x7F (8-bit signed value) 100% opacity
HWREG_BASE_ADDRESS+06 = 0x02D0 (16-bit) Bitmap width (720)
HWREG_BASE_ADDRESS+10 = 0x02D0 (16-bit) Window width (720)
HWREG_BASE_ADDRESS+12 = 0x01E0 (16-bit) Window height (480)
HWREG_BASE_ADDRESS+16 = 0x4000 (16-bit) Tile/font base address <- this doesn't appear to be important?
HWREG_BASE_ADDRESS+1F = 0x74 (8-bit) Video mode (480p, CLOCK_DIVIDER 5)

Going to get the drivers updated before I do too much more so that the palette isn't getting corrupted.

One question I have on your HDL notes - the Altera string bug.  This isn't preventing us from loading tile data into the FPGA's setup, is it?

Also, the font base address of 4000H doesn't seem to do anything - if I set it to 0x0000H, nothing changes.  I think this is because my GPU driver ignores this setting as it loads a font in at 200H and sets the blit parameters itself at startup.

[BrianHG]

Okay, I'm making progress with getting the display set up for the uCOM and understanding the notes you've provided.

I have a 480p 60Hz screen mode working using the 'special 480p' mode 7.  The graphics driver is currently unchanged, which is the next thing I need to tweak as it still thinks that the start of the video buffer is at 1200H and the tile data starts at 0200H, which overwrites the palette data at 1000H, making some text black, but I've got this on screen so far:



As you can see, GEOFF is working too.  I'll run some more tests once I've tweaked the graphics drivers (especially the CP/M one).

Here's my current settings:

Code: [Select]

     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C100 00 00 12 00 83 7F 02 D0 00 00 00 00 00 00 00 00
C110 02 D0 01 E0 00 00 00 40 00 12 00 00 00 00 00 74
This translates to:

HWREG_BASE_ADDRESS+00 = 0x00001200 (32-bit) Window[0] base address
HWREG_BASE_ADDRESS+04 = 0x83 (8-bit value) Screen bpp (3 bpp and enabled) <- arrived at this value by trial and error

Ok, yes the high bit enables the window layer.  As for the 3, as seen in my notes:

// Bits per pixel.  For 1,2,4,8,16a,32,16b bpp, use 0,1,2,3,4,5,6.  *16a bpp = 4444 RGBA, 16b bpp = 565 RGB.

IE:
0 = 1 bpp 2 color mode.
1 = 2 bpp 4 color mode.
2 = 4 bpp 16 color mode.
3 = 8 bpp 256 color mode.  Also the lowest mode required for tile text mode.
4 = 16a bpp 4096 color mode with 16 translucency levels, IE: 4444 RGBA mode.
5 = 32 bpp 16.7m color mode with 256 translucency levels, IE: 8888 RGBA mode.
6 = 16b bpp 65536 color mode, where color 0 is 100% translucent and all other color values are 100% opaque, IE: 565 RGB mode.

HWREG_BASE_ADDRESS+05 = 0x7F (8-bit signed value) 100% opacity
HWREG_BASE_ADDRESS+06 = 0x02D0 (16-bit) Bitmap width (720)
HWREG_BASE_ADDRESS+10 = 0x02D0 (16-bit) Window width (720)
HWREG_BASE_ADDRESS+12 = 0x01E0 (16-bit) Window height (480)
HWREG_BASE_ADDRESS+16 = 0x4000 (16-bit) Tile/font base address <- this doesn't appear to be important?

Step 1, first you need the 'CMD_win_bpp', HWREG_BASE_ADDRESS+0x04 video mode enabled to at least 8bpp or higher as we need at least 8 bit data to access a character.  The 16a&b bpp and 32bpp gives you access to colored characters, 1024 of them and H&V mirror/flip per character.

Step 2, 'CMD_win_tile_enable', HWREG_BASE_ADDRESS+0x18 needs to be at least 0x80 to turn the tile mode, '0' meaning the tile set is 1 bpp 2 color mode just like the IBM VGA font.

HWREG_BASE_ADDRESS+1F = 0x74 (8-bit) Video mode (480p, CLOCK_DIVIDER 5)

Going to get the drivers updated before I do too much more so that the palette isn't getting corrupted.

One question I have on your HDL notes - the Altera string bug.  This isn't preventing us from loading tile data into the FPGA's setup, is it?

Also, the font base address of 4000H doesn't seem to do anything - if I set it to 0x0000H, nothing changes.  I think this is because my GPU driver ignores this setting as it loads a font in at 200H and sets the blit parameters itself at startup.

The tile font base address will not do anything for a few reasons.

1. The 'CMD_win_tile_enable', HWREG_BASE_ADDRESS+0x18 needs to be at least set to 0x80 to turn on the tiles for that window layer as well as setting the CMD_win_tile_width & CMD_win_tile_height.

2. Note that even if the 'TILE_BASE_ADDR' parameter is set to 0x00004000, this is just the address you use the Z80 to write and read the tile's bitmap pattern data.  This address points to 0x0000 when setting the 'CMD_win_tile_base' @ HWREG_BASE_ADDRESS+0x16.  Placing a 0x0001 in this address tells the tile processor that the first character 0x00 will be moved from 0x000000, IE 0x00004000 accessed by the Z80, to 0x000010, IE addressed by the Z80 at 0x00004010.  This is a 16 byte step per 1 16 bit 'CMD_win_tile_base' value allowing you to address a 1mb offset.  Basically, since the VGA font is 16 bytes per character, adding a 0x00001 into the 'CMD_win_tile_base' would shift all the characters you see on the screen by 1.  (IE printing a 'B' would show a 'C'.)

As for the 'TILE_MIF_FILE' and 'PAL_MIF_FILE', it is just that Altera will no accept the parameter string.  I have hard wired the 2 parameters to 'VGA_FONT_8x16_mono32.mif' and 'VGA_PALETTE_RGBA32.mif' inside the source code and you will find the source .mif files inside the 'BrianHG_DDR3_GFX_source_v16' source code folder.  If you will be editing these, be sure to keep backups as receiving new updates from me may overwrite your changes.