FPGA VGA Controller for 8-bit computer

[nockieboy]

For some reason, the geo unit seems to freeze after 5 pixels are drawn.

Need to create a simulation test bench with all 3 modules tied together.

Could this be related to the GPU RAM issues I'm experiencing as well, perhaps? 

[BrianHG]

Nope, I've just done a complete geometry simulation.
Take a look at the blue like once the pixel writer fifo is full and it tells the rest of the system to wait.
It hangs there after the 5th pixel.

Give me a few minutes to debug...

[BrianHG]

Freeze fixed.  Every pixel now comes out, see:

Give me 10 minutes to compile & check that the FMAX is still good, then prepare the .zip.

[BrianHG]

All fixed.  Get the attached .zip below.

I also added 1 parameter which allows you to adjust the geometry input fifo margin which signals the 'fifo_cmd_busy' that many commands prior to the fifo being full.  This is so you do not need to check the 'fifo_cmd_busy' before every byte being sent.  Instead, check once before sending a block of up to 32 commands.  Or, for instance, just check once before sending a complete triangle which takes around 8 commands in a row.

[nockieboy]

Seems to be working just fine now. 

From humble beginnings... 



I'll have more time tomorrow to check the rectangle functions.

[BrianHG]

Geo tests in this order,

Line_0,0-9,9-255.png
Box_0,0-9,9-17.png
Box-Fill_0,0-9,9-102.png

I'll leave it to you to check for all the different color modes and higher resolutions.
Once verified, we will finish the pixel copy & paste/paste_mask function.

Then, back to the geometry_xy_plotter to add some missing function commands, then final drawing shapes, then a copy blitter function.  We got only 2 weeks left to finish this.

[BrianHG]

Could this be related to the GPU RAM issues I'm experiencing as well, perhaps? 

What GPU Ram issues?
This is important as the Z80 r/w supposed to get immediate overriding priority over the geometry unit's access.
Even with the geo freeze bug, the Z80 should still work fine.

[nockieboy]

What GPU Ram issues?
This is important as the Z80 r/w supposed to get immediate overriding priority over the geometry unit's access.
Even with the geo freeze bug, the Z80 should still work fine.

This one:

I've also been contending with a problem with accessing GPU RAM.  It seems the GPU doesn't like the Z80 doing block writes - i.e. I've tried to clear a block of RAM (erase the image) using LDIR and it results in some very... interesting... behaviour.  The Z80 reads the RAM and sees all zeroes, as it should be, but the RS232_debugger sees some zeroes and mostly FFs.  I have to power-off the whole thing and restart to be able to write to RAM properly again.  Odd.  Has anything changed with regard to the Z80_bridge bus timings or something?

I'll try to shed some more light on it tomorrow when I have time.

[BrianHG]

What GPU Ram issues?
This is important as the Z80 r/w supposed to get immediate overriding priority over the geometry unit's access.
Even with the geo freeze bug, the Z80 should still work fine.

This one:

I've also been contending with a problem with accessing GPU RAM.  It seems the GPU doesn't like the Z80 doing block writes - i.e. I've tried to clear a block of RAM (erase the image) using LDIR and it results in some very... interesting... behaviour.  The Z80 reads the RAM and sees all zeroes, as it should be, but the RS232_debugger sees some zeroes and mostly FFs.  I have to power-off the whole thing and restart to be able to write to RAM properly again.  Odd.  Has anything changed with regard to the Z80_bridge bus timings or something?

I'll try to shed some more light on it tomorrow when I have time.

Careful if you are in edit mode (RED BORDER) in the RS232 debugger when using the Z80 to write to the GPU ram.  What may be happening is that you successfully did the block write and read, however, the RS232 debugger may be overwriting the same memory with it's 256 byte cache.  This only happens when the hex editor has the 'RED BORDER' on.  Otherwise, it is in passive read mode when the border is green.  I'm assuming that this is not the problem.

Are you saying that access to the GPU ram goes silent?  And you need to power-cycle the GPU?
We may need to adjust the # of clock cycles for a write in the Z80_bridge_v2, however, that module should not be able to lock-up.

Once frozen, before cycling power, does the RS232 debugger still work?

Also, does pressing CTRL-R (send internal soft reset) in the RS232 debugger regain access to the ram?

Do block reads work properly?

[BrianHG]

Awww, thanks to you, I just found a minor bug in the RS232 Hex editor viewer.  Get the V1.2 patch here:

https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/msg3187578/#msg3187578

This has nothing to do with your Z80 block write freeze.

[BrianHG]

As you can see, the geometry unit works fine on 4 color layers as well without a single pixel defect:
Layer size = 76x92, 4 colors.
box-fill, then line, then box.

(This is your Zilog layer 2x zoomed moved to the center of the screen)

By the way, it is safe to go from 5 layers to 6 layers so you get that Zilog IC on your power-up screen.
I haven't tried anything higher because your logic is 86% full at 6 layers.  Adding more layers will increase compile time to a point where it just won fit into your FPGA...

[BrianHG]

Ok, here is the almost complete pixel writer. 

Pixel Writer with copy, paste, paste_mask & set_RGB legend (see photo):

A = Reset both collision counters.

B = Copy pixel @0x0ABC-2, 16 color = '0xB'

C = Paste_mask 16 color pixel '0xB' to 0x0111-1.
    Since pixel @0x0111-1 wasn't 0x0 to begin with, collision_rd +1.
    Since color '0xB' was written into 0x0111-1 which wasn't 0, collision_wr +1.

D = Copy pixel @0x0ABC-3, 16 color = '0x0'.

E = Paste_mask 16 color pixel '0x0' to 0x0111-1.
    Since pixel @0x0111-1 wasn't 0x0 to begin with, collision_rd +1 again.
    Since color '0x0' is transparent, 0x0111-1 kept the earlier '0xB'color
    and collision_wr stayed the same.

F = Normal paste 16 color pixel '0x0' to 0x0111-1.
    Since pixel @0x0111-1 wasn't 0x0 to begin with, collision_rd +1 again.
    Normal paste means the color '0x0' was written into 0x0111-1 and since
    the pixel was originally '0xB', the collision_wr +1.

G = Paste_mask 16 color pixel '0x0' to 0x0111-1.
    Since pixel @0x0111-1 is 0x0 to begin with, the collision_rd stayed the same.
    Since color '0x0' is transparent, 0x0111-1 kept the earlier '0x0'color
    and collision_wr stayed the same.

H = set_rgb = This passes the first 16 bits in the command bus directly into
    the copy pixel buffer so you may write 16 bit true color RGB pixels
    using the pixel_paste command afterwards.

New 'Pixel_writer' Quartus simulation attached.

Also, new 'Geo_Writer' Quartus simulation project attached which contains the entire geometry processor simulation path from command to ram access.  It needs the 'Pixel_writer' project to function.

Your going to need to read all my code and add your own comments and documentation yourself as I have some basic info in there with some mistakes as this was rushed.  You'll need to post your commented versions of the code for verification you understand what's going on.  For now, wait for finalization of the pixel writer.  The address generator looks complete.  And you know we need to make the filled triangles.

[BrianHG]

New main GPU build with the latest pixel writer supporting copy, paste, mask, both collision counters & set_rgb functions.  6 MAGGIE layers enabled.

Only the color conversion feature which allows you to select new colors from low color source images to different higher color values when copying & pasting onto a high color bitmap is missing.  Currently, the color is only copied verbatim.


Open up a 320x200 x 16 color screen.  You have enough ram for it.  Make a random point-point, random color lines all over the screen and see how fast it's running.  Assuming your Z80 can generate random numbers that fast.  I remember my Atari 800 was slow with RNG.  Video the results.

Also do the same with box-fills.  These eat up a magnitude more pixel write commands unless the Z80 is fast enough to keep up with the line drawings.

I wonder if you could successfully get the 'fifo_cmd_busy' to trigger.  Your only prayer may be setting up a box-fill to 320x200 x 16 color, then just continuously writing the box-fill command again and again non-stop.  It may be valuable to attempt this and report/time the speed of how many box-fills as this size can be drawn per second.

[nockieboy]

Careful if you are in edit mode (RED BORDER) in the RS232 debugger when using the Z80 to write to the GPU ram.  What may be happening is that you successfully did the block write and read, however, the RS232 debugger may be overwriting the same memory with it's 256 byte cache.  This only happens when the hex editor has the 'RED BORDER' on.  Otherwise, it is in passive read mode when the border is green.  I'm assuming that this is not the problem.

Are you saying that access to the GPU ram goes silent?  And you need to power-cycle the GPU?
We may need to adjust the # of clock cycles for a write in the Z80_bridge_v2, however, that module should not be able to lock-up.

Once frozen, before cycling power, does the RS232 debugger still work?

Also, does pressing CTRL-R (send internal soft reset) in the RS232 debugger regain access to the ram?

Do block reads work properly?

I can't replicate the issue today in the latest build - I didn't pay too much attention to it yesterday as I didn't want to sidetrack away from getting the drawing to work, and I figured I could just look at it today in more detail and give you more information on it.   I've just done block writes and reads to GPU RAM with no errors or artefacts at all just now, so it could have been user error on my part - I'm aware of the issues caused by the RS232_debugger being in edit/write mode when the Z80 accesses the RAM, but can't remember if it was in edit mode or not when I was having the issues yesterday.  It probably was, as it's all working now (without the RS232_debugger attached).  I'll draw a line under this one unless it crops up again. 

New main GPU build with the latest pixel writer supporting copy, paste, mask, both collision counters & set_rgb functions.  6 MAGGIE layers enabled.

Wow. Thank you. (I'm gonna need a bigger FPGA...) 

Open up a 320x200 x 16 color screen.  You have enough ram for it.  Make a random point-point, random color lines all over the screen and see how fast it's running.  Assuming your Z80 can generate random numbers that fast.  I remember my Atari 800 was slow with RNG.  Video the results.

Yeah, the old 8-bit computers weren't built for speed.  I did briefly look at RNG HDL to see if the FPGA could do it on behalf of the Z80 - but I'll use a quick pseudo-random generator based on the R register for the graphics test program.

Also do the same with box-fills.  These eat up a magnitude more pixel write commands unless the Z80 is fast enough to keep up with the line drawings.

I wonder if you could successfully get the 'fifo_cmd_busy' to trigger.  Your only prayer may be setting up a box-fill to 320x200 x 16 color, then just continuously writing the box-fill command again and again non-stop.  It may be valuable to attempt this and report/time the speed of how many box-fills as this size can be drawn per second.

I've got my work cut out - I'll be back when I have some video footage.

[nockieboy]

I can't replicate the issue today in the latest build - I didn't pay too much attention to it yesterday as I didn't want to sidetrack away from getting the drawing to work, and I figured I could just look at it today in more detail and give you more information on it.   I've just done block writes and reads to GPU RAM with no errors or artefacts at all just now, so it could have been user error on my part - I'm aware of the issues caused by the RS232_debugger being in edit/write mode when the Z80 accesses the RAM, but can't remember if it was in edit mode or not when I was having the issues yesterday.  It probably was, as it's all working now (without the RS232_debugger attached).  I'll draw a line under this one unless it crops up again. 

Can confirm - no issues encountered so far and I'm doing lots of block writes to the GPU RAM. 

[nockieboy]

I seem to be having some trouble setting a base memory address of 0x1200.

I've hit the simulator to work out what's happening, and as best I can see, it looks like when the DSTRWIDTH is called, the bit-order on the high byte is reversed?

i.e:

    Sending 255 as the low byte, 1 as the high byte should result in an address of 01FF being passed to the pixel_writer.  Instead I see 10FF.
    Sending 0 as the low byte, 6 as the high byte should result in an address of 0600 being passed to the pixel_writer.  Instead I see 6000.

Am I going mad or is this is a bug that we've missed by pure chance so far?

EDIT:
Hmm... maybe not reversed, but some odd behaviour (in the simulator at least).  I've just entered (LOW) 200 (HI) 1 and got an address of 10C8.  So it would appear the highest address I can reference in any block of 1000 addresses is the first 256?

Changing the HI byte to 02 changes the address output to 20C8.  Changing HI byte to 20 changes the address output to 140C8.

[BrianHG]

Remember, for some reason, in the simulator we chose showing decimal for the CMD inputs.
Here, I changed it to hex and here is how the address is sent.

Since we wanted 24 bits and the CMD uses 4, then sending 12 bits to the X&Y, the final X&Y were stacked together and transmitted as the final address.  See here:

H command byte                                      L command byte
(CDM 4bit)   +   (4 top bits of X[n]/Y[n])    (Bottom 8 bits of X[n]/Y[n])

Base address out
Y[n][12],X[n][12]
X holds the least significant 12 while Y holds the most.

Note this is still in flux and we can make changes...
See attached image.


(OPTIONAL CHANGE) If you will never be going above 20 bits, it would be much easier to use:
Y[n][12],X[n][8] - a sum of 20 address bits only.
This way, you only feed the lower address 8 bits into X and feed the upper address 8 bits into Y[7:0] and for above 64k, send the next 4 bits into the lower 4 bits of CMD when setting Y where you feed Y[11:8]. Much less fragmentation like this way.  This may or may not also be of benefit when using the set_rgb function for setting a 16 bit color.

[nockieboy]

 

I was able to correctly set the address thanks to the image you included in your reply - the ABCDE address gave it away. 

Hmm.. okay, so I'm probably making a stupid mistake as I've just tried to draw a line and it's just appeared as a load of scattered dots on the screen.  I'm not confident I really know what's going on with YINC_ADDR_L/H, for starters - anywho, here's the setup:

I've set up MAGGIE0 like this:

0x000010 - 00 10 00 10  - HV triggers
0x000060 - 0A 00 00 00 12 00 01 00 01 40 00 C7 01 01 00 00 - 256 colours, 320x200, scaled 2x2

Here's my assembly setup (send_gpu just sends HL's low byte L to port 246, then the high byte H to 247), so the setup should mirror what we've done previously:

Code: [Select]

; set GPU base_addr for graphics
LD HL,0F001H ; set Y[3] to 01
CALL send_gpu
LD HL,0B200H ; set X[3] to 200
CALL send_gpu
LD HL,7F00H ; send cmd 127 to set destination base address
CALL send_gpu
; set raster width (H) and bit depth (L)
LD HL,0B140H ; set X[3] to 320
CALL send_gpu
LD HL,7102H ; set dest raster width to X[3] and bpp to 2
CALL send_gpu
; set X & Y limits
LD HL,8140H ; set X[0] to 320
CALL send_gpu
LD HL,0C0C8H ; set Y[0] to 200
CALL send_gpu
LD HL,5F00H ; set max X & Y to X[0],Y[0]
CALL send_gpu

;------------------------------------------------------------------------------
; drawLine
;
; Draws a line - what else?
;------------------------------------------------------------------------------
drawLine:
LD HL,8000H ; set X[0] to 0
CALL send_gpu
LD HL,0C000H ; set Y[0] to 0
CALL send_gpu
LD HL,90DCH ; set X[1] to 220
CALL send_gpu
LD HL,0D096H ; set Y[1] to 150
CALL send_gpu
LD HL,01FFH ; draw white line X[0],Y[0] to X[1],Y[1]
CALL send_gpu
RET

It's also writing into the symbol table as well, as some characters have artefacts in them, so I'm doing something wrong. 

[BrianHG]

Bpp of 2 is invalid unless you are translating something...

Code: [Select]

LD HL,0B140H ; set X[3] to 320
CALL send_gpu
LD HL,7102H ; set dest raster width to X[3] and bpp to 2
bpp 0 = 1 bit color, 2 colors
bpp 1 = 2 bit color, 4 colors
bpp 3 = 4 bit color, 16 colors
bpp 7 = 8 bit color, 256 colors
bpp 15 = 16 bit color, 65536 true colors

(we can change these numbers to bpp 0,1,2,3, & 4, or even match the maggie color settings as they are look up table driven.)

Your maggie must match the number of color bits as well.  But remember, it's setting orientation may be different.

Also, in the maggie, when you have 4 bit color, it's screen bytes/line setting isn't 320, it's width setting is set in bytes/line.  Since each line is 320 pixels and there are 2 pixels in a byte, then the maggie bytes/line should be set to 180.

[BrianHG]

0x000060 - 0A 00 00 00 12 00 01 00 01 40 00 C7 01 01 00 00 - 256 colours, 320x200, scaled 2x2

0x000060 - 0A 00 00 00 12 00 00 A0 01 40 00 C7 01 01 00 00 - 16 colours, 320x200, scaled 2x2

0x00A0 bytes per 320 pixel line of video when in 4 bit color mode.

This layer begins at memory address $1200, ie 4608 bytes.

[BrianHG]

Code: [Select]

; set raster width (H) and bit depth (L)
LD HL,0B140H ; set X[3] to 320
CALL send_gpu
LD HL,7102H ; set dest raster width to X[3] and bpp to 2
CALL send_gpu


It's also writing into the symbol table as well, as some characters have artefacts in them, so I'm doing something wrong. 

You didn't set Y[3] to 0 in advance.  The geometry unit can address screens widths up to 65535 pixels wide.  12 bit width of X[3] alone is not enough and you previously set Y[3] with a value when setting the address earlier.

[nockieboy]

That's sorted it.  Thank you.

I should have taken better notes back when we built BART and MAGGIE...

Will update shortly.

[nockieboy]

Okay, random line drawing test is done. 

It's not the fastest as I've got a keyboard input check going on every time a line is drawn, so I can quit back to CP/M if I want, and it's checking the line colour before it's drawn to exclude the two blacks in the palette. 

Oh, my RNG only goes up to 255 as well, hence the full screen isn't used. 

Artefacts at the bottom of the screen are from a previous run of the program - I'm obviously not clearing the full GPU RAM area at startup. 

[nockieboy]

Each loop now draws a random line, rectangle and filled rectangle.

[BrianHG]

Arrrgg, I don't even think your flexing the geometry at all.
How about just adding 3,7x5,9 to 8 bit only xy,xy coordinates, and add 1 on color with the line or box fill and plot all in an assembly loop with nothing else.  No os or kb scans.  Or loop for 255 draws, then do 1 assembly hw kb to check for a character to break, if not, then do another 255.

Who cares about the 2 black colors, let them draw.

I need to see this thing swing...

I'm trying to keep everything in 8 bit and only do adds or inc.

I think I could do better with a PIC16C54 microcontroller from the mid 1990s.

We might need to store graphic programs on the GPU to do any real work.
However, with the current rate of development, this would take forever.

Do you have any 20MHz Z80s?