FPGA VGA Controller for 8-bit computer

[BrianHG]

The only way I can get the graphics into the GPU currently is via the RS232_debugger.  I can't access the actual graphics in the GPU's DDR3 RAM from the uCom if I wanted to - the first layer starts at the very end of GPU RAM that the uCOM can access within its 512KB window.

As a minor side project, I'm going to start on an MMU for the uCOM's memory interface to the GPU's DDR3.  I'm just starting to think about it and could do it one of two ways that I can see at the moment:

• I could page 512KB banks of DDR3 into the uCOM's memory window. Maybe the easiest way to do this would be to control which 512KB bank of DDR3 is visible to the uCOM via another IO port, which would give the uCOM access to 256x512KB banks - enough to access 128MB of DDR3 if I use only one additional IO port.
• The other way would be to keep the lowest 16KB of DDR3 (the HW_REGS and palettes) always visible to the uCOM, and instead of IO, use a memory location/s in that first 16KB to control which 496KB chunk is available in the rest of the 512KB window.  That sounds complicated, but would give access to unlimited memory.

Option 1 seems the most sensible way to do it.  This would involve some minor additional code in Bridgette (the Z80 interface) to add some additional address lanes to its DDR3 pathway and control the upper bits with an additional IO port value.  Is there an easier/better way to do this?  Can you see any issues that I am unaware of or haven't thought of yet?

Go for #1.  The lane addition is easy enough as they are already wired there, just that those addresses are assigned to a value of 0 when addressing the DDR3.  As for the patched GEOFF and my Window system, all 32bits are wired, so they already have full 512mb access and can go to up to 4gb.

[nockieboy]

On the subject of palettes, how can I make a particular Layer use a particular palette?  With five layers, each referenced its own palette when I would have preferred to point them all to the same palette.

I'm sorry, but it is hard wired.

Pff, don't apologise - it's not an issue.   I just had it in my head for some reason that we could do that - I'd even checked the HW_REGS table to see if there was a palette memory location for each layer.

[BrianHG]

Ok, it's been a week.  Anything new to see?  Any new bugs found?

[nockieboy]

Hi, no - nothing new to see yet.  As usual, work is getting in the way of 'less important' time sinks, like hobbies.  Hopefully might be able to set aside some time this weekend or next week.

Did you manage to sort that overflow bug with the DDR3 controller?  I haven't noticed any bugs or issues.

[BrianHG]

Hi, no - nothing new to see yet.  As usual, work is getting in the way of 'less important' time sinks, like hobbies.  Hopefully might be able to set aside some time this weekend or next week.

Did you manage to sort that overflow bug with the DDR3 controller?  I haven't noticed any bugs or issues.

I've been waiting on you to do more with the video controller.  I need to know if it is ready to finalize.
I doubt you can overload the DDR3 with your current apps.

[BrianHG]

Ok, it's been a week.  Anything new to see?  Any new bugs found?

[nockieboy]

No, spare time is like gold dust for me currently.

[nockieboy]

Okay, I found a half hour this morning to get something done today and that something was... *drumroll*  An MMU for the GPU RAM.

It's not much, but the Z80 can now access up to 4GB of DDR3 RAM via the 512KB 'window' into the GPU RAM.  Two IO ports control which 512KB block of DDR3 RAM is accessible in the 512KB window.  The host controls bits 18:0, with one IO register adding a full 8 bits to the address; the other adds 5 bits, allowing the host to access the full 32-bit address width of the DDR3.

I was able to streamline the HDL a little in BRIDGETTE as well, removing the mem_in_range wire etc.

I didn't have time to look into the new IO system you've created unfortunately, settling for a quick hit rather than trying to work the changes into a new system and all the bug-hunting complications that may create.  It seems simple enough, but I have to ask the question - why?  How is it better to have a 256-bit strobe bus (and 256*8 data bus) that (presumably) goes off to another module dedicated to handling the IO functions?  As far as I can tell, the only benefit is to keep BRIDGETTE as platform-agnostic as possible, so long as it uses a Z80 all anyone would need to do is edit the IO module?  I realise Quartus will prune the 2,304 wires down to the minimum required, depending on the number of IO ports in use, but still, to me it seems a little obtuse.

Anyhoo, I'm sure there's a compelling argument that I haven't thought of.

The Z80 can now access the entire GPU RAM, so I'm not limited to the first 512KB like previously.  Can focus on writing the tile demo when I get a chance now.

Latest project files attached.

[BrianHG]

Ok, when will we see this?
https://youtu.be/rAd6MlU5yiY?t=387

You have all the layers, color, and memory you need.

[nockieboy]

Ok, when will we see this?
https://youtu.be/rAd6MlU5yiY?t=387

You have all the layers, color, and memory you need.

    I was watching that video for far too long... became engrossed in nostalgia before I remembered what you'd written.  You're expecting what?!

You DO realise I'm not a professional programmer, right?  Everything I've learned about Z80 assembly is self-taught or from z80-Heaven.   Give me some time though, I'll see what I can do.

[BrianHG]

Well, this was done on a Commodore 64 with the only requirement being a 256k ram expansion:
https://youtu.be/_Cg8r-VmeMk?t=0

However, for Rayman, if you were to get a file copy from the assets, almost all of them will be directly compatible with my video buffer.  Just a lot of smart look-up tables for the animation cells and some clever physics engine written in assembly should squeeze out a good 60fps as there are around at most 8 enemies onscreen.  (IE: A Sony PS1 emulator running the game or CD/roms from the other 2 systems it was available on)

A guess improving/adding a programmable smarter memory copy module for my DDR3 controller would mean the Z80 would need be spitting out around 50 sets of coordinates with animation cell ID each frame to replicate the Rayman game.  Something which looks possible for a 8MHz Z80.

[nockieboy]

Well, this was done on a Commodore 64 with the only requirement being a 256k ram expansion:
https://youtu.be/_Cg8r-VmeMk?t=0

That's very impressive.

Quick question - I should probably know the answer, but can't seem to find it.  How do I change the foreground/background colour of a 1bpp font tile in Tile Mode?

[BrianHG]

Read here (beginning at line 362 in the manual):

Code: [Select]

******************************************************************************************************
******************************************************************************************************
******************************************************************************************************
******************************************************************************************************
*** Understanding the TILE/FONT enabled PDI layer.
******************************************************************************************************
******************************************************************************************************
******************************************************************************************************
******************************************************************************************************

The font/tile layer utilized on-chip FPGA blockram to hold it's tiles/fonts.

**********************************************************************************
Tile selection when using different 'CMD_vid_bpp' modes, 8/16a/32/16b bpp modes.
* On a tile layer, bpp will actually mean bpc -> Bits Per Character Tile.
----------------------------------------------------------------------------------
FGC  = Foreground color.  Adds this FGC value to any tile pixels whose color data is != 0.
BGC  = Background color.  Replace tile pixels whose color data = 0 with this BGC value.
MIR  = Mirror the tile.
FLIP = Vertically flip the tile.
----------------------------------------------------------------------------------

CMD_vid_bpp' mode:

8   bpp -> Each byte = 1 character, 0 through 255, no color, mirror or flip functions.

            BGC,  FGC,  Char 0-255.   *** BGC & FGC are multiplied by 16 in this mode.
16a bpp -> {4'hx, 4'hx, 8'hxx}                           = 16 bits / 256 possible tiles.

            FLIP, MIR,  FGC,  Char 0-1023. *** FGC is multiplied by 16 in this mode.
16b bpp -> {1'bx, 1'bx, 4'hx, 10'hxxx}                   = 16 bits / 1024 possible tiles.

             BGC,   FGC,  FLIP, MIR,  N/A,  Char 0-1023.
32  bpp -> {8'hxx, 8'hxx, 1'bx, 1'bx, 4'h0, 10'hxxx}     = 32 bits / 1024 possible tiles.

Instead of 8bit for the CMD_vid_bpp' mode screen data, use 16bit or 32bit where 1 of the bytes is still the letter, the other bytes contain the color and features.

[nockieboy]

I think I'm a little confused about how to address different tile sets.

Here's what I'm trying to do whilst I learn how to use different layers:

1) I've got 3 layers - top Layer 0 is text, middle Layer 1 is anything I want to appear above Layer 2, which is the bottom layer and displays a map.
2) Layers 1 & 2 need to use a different tile set to Layer 0, which displays the standard font.  Layers 1 & 2 will display an 8bpp graphical tileset, which I'm loading (randomly) at 7000h, out of the way of the screen memory for the three layers.

It appears, from tweaking the HWREGs settings for the layers using the RS232_debugger, that the 16-bit Tile/Font Base Address register is actually only a 12-bit register, as the value set doesn't seem to care what the MSN (top 4 bits) are set to, but then reading the HDL notes in BrianHG_GFX_VGA_Window_System.sv, I'm reminded that the tiles are stored in block RAM, not DDR3 RAM, so where should I be loading the additional tile set?

[BrianHG]

Arrrg... Ok....

Code: [Select]

module GPU_DECA_DDR3_top #(

// ****************  GPU controls.
parameter int        GPU_MEM                 = 524288,           // Defines total video RAM, including 1KB palette

parameter string     ENDIAN                  = "Little",            // Endian for 8bit addressing access.
parameter bit [3:0]  PDI_LAYERS              = 4,                   // 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,     //

These lines:

Code: [Select]

parameter bit [3:0]  PDI_LAYERS              = 4,                   // 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.
Means that the tile mode will only function on layers 0,1,2,3.

These lines:

Code: [Select]

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,     //
Means that when the Z80 or any other peripheral writes to memory address 32'h00004000 through 32'h00013FFF, you will be writing into the tile block memory memory address 20'h00000 through 20'h0FFFF.

This is hard wired and cannot be changed once compiled.

So, writing a font beginning at address 32'h00004000 means it's tile blockram address begins at 20'h00000.
Or, writing a font beginning at address 32'h00005000 means it's tile blockram address begins at 20'h01000.

Now, when setting the 16 bit register 'CMD_win_tile_base' address, it sets the first character '0' pointing into the 'tile blockram address', not DDR3 address.  Remember, the value you set will be multiplied by 16 so that you may address more than 65536 bytes for the tile blockram memory.  Now, since in the parameters you have a set limit of 65536 bytes, this means that setting a value above 4095, (65536/16-1), the tile memory blockram read address will loop around back to 0 as the line display buffer has no check for error addresses above the set parameter 'TILE_BYTES' size.

I hope this helps.

[nockieboy]

Means that when the Z80 or any other peripheral writes to memory address 32'h00004000 through 32'h00013FFF, you will be writing into the tile block memory memory address 20'h00000 through 20'h0FFFF.

Probably a stupid question, but does this mean that all of the screen memory I've been using so far has been in block RAM, as I've had the screen memory start at 0x5000...?

Ah, thinking about it, all the work is handled by GEOFF in graphics modes.  The only direct writes to memory by the host are when writing the font/tile set data in the first place, and this will go to block RAM where it should be.  Still, handy to know that I can't write to the screen directly (without using the blitter or GEOFF) below 0x13FFF.

[BrianHG]

Yes, the GEOFF can write into the tile memory.
You can use the blitter to quickly move/edit/animate not just the picture data, but the tile's contents as well.
Yes, you were probably wasting some of the limited available tile memory space.

[nockieboy]

  Okay, I'm struggling with this for some reason.

Here's what I'm trying to do:

1) Set up Tile Mode, with Layer 0 displaying normal text.
2) Set up Layer 1 and Layer 2 to display 16x16 graphics tiles (which I'm loading-in with the rs232_debugger for the moment)

The setup works, displaying normal text on all three layers.  What I can't get to work is making Layers 1 & 2 display a different tile set (i.e. the 16x16 graphics tiles).

Here's the HW_REGs setup code:

Code: [Select]

VMtabl: ; Layer 0 - TEXT
DB 00h,0D0h,00h,00h,83h,00h,TPR,00h,00h,00h,00h,00h,20h,00h,20h,00h
DB 90h,02h,0A0h,01h,00h,00h,00h,00h,80h,12h,00h,00h,00h,00h,00h,74h
; Layer 1 - ACTORS
DB 00h,0D9h,00h,00h,83h,00h,TPR,00h,00h,00h,00h,00h,20h,00h,20h,00h
DB 90h,02h,0A0h,01h,00h,00h,00h,00h,80h,12h,00h,00h,00h,00h,00h,00h
; Layer 2 - BACKGROUND
DB 00h,0E2h,00h,00h,83h,00h,TPR,00h,00h,00h,00h,00h,20h,00h,20h,00h
DB 90h,02h,0A0h,01h,00h,00h,00h,00h,80h,12h,00h,00h,00h,00h,00h,00h
I've updated the setup to move the screen memory location up to 0xD000 onwards, to avoid writing into the tile memory in the GPU's block RAM.  The above setup works, displaying ASCII characters appropriately on all three layers.

So, the next step is to load up and test the graphics.  I tweak the above setup code to make Layer 1 & 2 display 16x16 tiles from a different location in the GPU's block RAM (hopefully!):

Code: [Select]

VMtabl: ; Layer 0 - TEXT
DB 00h,0D0h,00h,00h,83h,00h,TPR,00h,00h,00h,00h,00h,20h,00h,20h,00h
DB 90h,02h,0A0h,01h,00h,00h,00h,00h,80h,12h,00h,00h,00h,00h,00h,74h
; Layer 1 - ACTORS
DB 00h,0D9h,00h,00h,83h,00h,29h,00h,00h,00h,00h,00h,20h,00h,20h,00h
DB 90h,02h,0A0h,01h,00h,00h,00h,01h,80h,22h,00h,00h,00h,00h,00h,00h
; Layer 2 - BACKGROUND
DB 00h,0E2h,00h,00h,83h,00h,29h,00h,00h,00h,00h,00h,20h,00h,20h,00h
DB 90h,02h,0A0h,01h,00h,00h,00h,01h,80h,22h,00h,00h,00h,00h,00h,00h
Then I try to load the tile set into the GPU RAM using the rs232_debugger.  The tile set is a 64x64 image, stripped to raw binary, 4,096 bytes long.  I load this at address 20,480 (0x5000), which should be 0x1000 in the block RAM and above the existing font tile set.  With the above HW_REGs settings, I should see something?  Unfortunately, the screen just goes blank and I have to quit my test program, which resets the HW_REGs, then I get a normal (graphics-based) display back again.  When I load the test program again, I can only see Layer 0 text, messing with the tile_base_addr setting in the debugger I can't seem to find any graphics.

Is there anything obvious I'm doing wrong?

[BrianHG]

Hmmm, ok.

TPR?  I assume that's your raster/character width, IE number of characters across the screen.

Everything looks OK.

Are you sure you actually placed actual tile data into the right address?
The only real change between layers is the tile base address and the 16x16 pixel tile mode.
And, if the text on all 3 layers worked, it's only that the tiles you chose to print may be blank or never filled with any data.  This is all I can think is happening.

You have a tile address of $0100 x 16= 4096, or you need to place this tile data into DDR3 ram at $5000.
Remember, the data at $5000-to-$501F is char(0) if you are using a 1 bit, 16x16 pixel font.  $5020 begins char(1).  The 1 bit font data at 16x16pixels means 2 bytes per line.

Try filling the display mem with char(0) and just poke around $5000.  You should be filling the entire screen with pixels as you modify the font's char(0) bitmap.

[BrianHG]

Did you remember to set the palette for layers 1 & 2?  If you did not, the RS232 debugger may have cleared them.

[nockieboy]

Ah, I'm making progress.  I had an errant piece of code that was clearing the wrong part of memory since I'd moved the layer addresses further up into DDR3 RAM, and I worked out I was putting the tiles together in the wrong format - I'd just created a 4x4 tilesheet, then realised as I was looking at the garbled mess on the screen that they should be a 1x16 layout instead.

Exactly what does the rs232_debugger do when you load in a binary at an address?  It looks like it reloads memory from 0000 all the way up, rather than just loading in the specific area of memory affected by the binary?

[BrianHG]

Exactly what does the rs232_debugger do when you load in a binary at an address?  It looks like it reloads memory from 0000 all the way up, rather than just loading in the specific area of memory affected by the binary?

The debugger tends to always re-read the 1mb buffer.

If you load a binary to a specific address, it will place the file into it's 1mb buffer at the specified location, then re-transmit the entire 1mb buffer.

When starting up the debugger, it will read in the 1mb buffer from the DDR3.

When scrolling through the display, it continuously re-reads that current 256byte block in real time, updating the internal 1mb buffer.

Remember, the debugger has a 1mb limit to the first 1mb.

[nockieboy]

The debugger tends to always re-read the 1mb buffer.

If you load a binary to a specific address, it will place the file into it's 1mb buffer at the specified location, then re-transmit the entire 1mb buffer.

When starting up the debugger, it will read in the 1mb buffer from the DDR3.

When scrolling through the display, it continuously re-reads that current 256byte block in real time, updating the internal 1mb buffer.

Aha!  That's what's been going on.  I've been experiencing some very strange behaviour whilst testing the tile set, with the screen looking perfect when the binary load starts, but half the screen disappearing as the load continues.  The debugger hadn't buffered the changes made by the test program when I loaded it, so when I then loaded the binary image with the tile set in, it reset a load of stuff that the test program had set up (Layer 1 and 2's screen map, essentially) and corrupted the screen.  After reading your last post, I went back and scrolled through the screen memory in the debugger before loading the tile set in, and it works.

I just need to spend a little time sorting the palettes out now.

Is there any chance the debugger could be modified to ONLY load the memory area specified in the load instruction, or would that cause too many issues?

[BrianHG]

Is there any chance the debugger could be modified to ONLY load the memory area specified in the load instruction, or would that cause too many issues?

Before you do the 'Load', just do a re-read / update of the 1mb DDR3 memory buffer.
Just hit the letter ' r '.
This will first read all the DDR3 buffer.
Then load binary and the portion you load will be the only portion changed...

[BrianHG]

So?  Do the tile modes/layers work?