FPGA VGA Controller for 8-bit computer

[BrianHG]

Everything else looks ok.
Give it a try.
If the Z80 can read/write to DDR3, you should be able to draw pixels direct by the Z80.
1 byte = 1 pixel.

[BrianHG]

line 681: assign CMD_R_priority_boost[1] = 0; // The boost feature on read channel 1 is not being used.

Add a disable for the priority boost on read port#2 as well.
Same for write port #1.

[nockieboy]

Weird things are happening now.  I'm getting the technicolour snow display, no problems there.

Accessing memory is odd, however.   If I dump the first page of GPU memory, I get a page of 0x0F.  I can't write to that page.  If I switch to the second bank (second 16KB of GPU RAM), the first page displays 0x43s.  Writing to any byte in that page changes all the displayed values in that bank, and they persist if I swap banks and read another bank then switch back and read it again.

I can't see any change on the screen with writes to the GPU RAM.  I'll only be able to access a fraction of the screen though until I change the Z80 bridge settings to allow writes to larger RAM spaces.

[BrianHG]

Ok, here you go.

Things I've changed:
Temp patch in the VPG to properly support 8 bit.  (Y_POS was inverted and on the wrong line.)
Fixed the .sdc as it was missing half the GPIO ports.
Disabled smart_bank to improve FMAX.
I corrected the palette mem 2 pixel delay.

New file '640x480_raw_8bit_bitmap.zip' has a binary .raw file you can use the rs232-debugger to upload and view.
Note, I made your palette B&W to support the bitmap.


The only thing you missed but could have caught was line 660 in GPU_DECA_DDR3_TOP.sv

Code: [Select]

   .DISP_pixel_bytes    (  3'd4                 ),    // 4=32 bit pixels, 2=16bit pixels, 1=8bit pixels.
You had to change it to a 1.

I thought you were supposed to get 512k access from your Z80.  The display is only 300kb.  So you should be able to clear and draw on this display the slow way...

Make sure the Z80 works correctly with the ram.
Then add the geometry processor.

I have V1.5 of the DDR3 controller coming tomorrow (my time, may be day after for you).
The only change is each port is a read/write port instead of separate read and write ports.
This actually simplifies wiring to the Z80 bus and I will do an example update for you to test then.

I will have to mangle together a new display processor to replace the VPG as you will want switchable modes and multiple layers with a tiny sequential display line cache buffer.

[nockieboy]

Note, I made your palette B&W to support the bitmap.

Ah, I had included a greyscale palette in the project (palette_greyscale.mif), but never mind.

I thought you were supposed to get 512k access from your Z80.  The display is only 300kb.  So you should be able to clear and draw on this display the slow way...

Yes that's true - the Z80 can access the bottom 512K as 16KB banks.

The Z80_Bus_Interface, however, controls what is read within that 512K.  The MEM_SIZE_BYTES parameter determines a hard limit beyond which the Z80 can't read the GPU RAM - this was to stop the Z80 reading beyond the top of the FPGA's block RAM.  It's currently set to 98,304 bytes.  Any reads beyond this value are ignored and the bridge will return 0xFF for addresses up to the last 16 bytes of the 512K.  The last 16 bytes are the BANK_ID section.  Any reads below that value should return valid DDR3 data.  Obviously that isn't an issue now, so I need to look at that limit and either remove it entirely or disable it.

The three wires at lines 252-254 in Z80_Bus_Interface.sv determine where in the GPU RAM the Z80 is trying to read/write:

mem_in_bank  is HIGH if the Z80 is addressing somewhere in the GPU's 512K window.  It should really be called mem_in_window.
mem_in_range is HIGH if the Z80 is addressing somewhere in the GPU's actual block RAM limits.  This can effectively be replaced with mem_in_bank above, as the DDR3 will always be larger than 512KB.
mem_in_ID      is HIGH if the Z80 is addressing the last 16 bytes of the 512KB window.  These last 16 bytes are the BANK_ID and allow the uCOM to identify that a GPU is available and show it's name/identifier.

Make sure the Z80 works correctly with the ram.

Unfortunately there's no change in behaviour between this latest version and the previous one, aside from a static greyscale snow pattern on the screen.

If I dump a page from a 16KB bank, the initial values seem to be one higher than the bank number.  i.e., if I dump the first page of (or any page within) bank 0x43, the initial values will all be 0x44.  Bank 0x42 is all 0x43 values, etc.  Only bank 0x40 is different (the first 16KB of GPU RAM) with 0x0F values, but probably because that could be the last value written to it as part of the screen setup in the DMI.  It seems the last value written to any bank is the only value displayed in that bank thereafter.

When I get some time (maybe tomorrow), I'll try to get some Signal Tap traces of the read/write timings for you, unless you identify the issue before then.

[BrianHG]

I'm not sure what you have done.
Maybe a bad IO assignment?
Are you using the latest Z80 interface?
I doubt this could be the issue, but, you can try setting the DDR3 to 500MHz so that the Z80bus is running at 125MHz like it used to instead of 100MHz.  (I know with DDR3 v1.5, you could then run it at 200MHz with the DDR3 at 400MHz, but really, needing a 200MHz section to run an 8MHz CPU.)

What does the RS232 debugger tell you?
Did you load the .raw binary fine in the debugger and send it to the DDR3?

Everything seemed to work fine here except for that I don't have a Z80 to test with.

[nockieboy]

I'm not sure what you have done.
Maybe a bad IO assignment?
Are you using the latest Z80 interface?
I doubt this could be the issue, but, you can try setting the DDR3 to 500MHz so that the Z80bus is running at 125MHz like it used to instead of 100MHz.  (I know with DDR3 v1.5, you could then run it at 200MHz with the DDR3 at 400MHz, but really, needing a 200MHz section to run an 8MHz CPU.)

I'll double-check the IO assignments later, but they're basically a copy-paste from GPU.sv that fed the Z80_Interface the IOs.

What does the RS232 debugger tell you?
Did you load the .raw binary fine in the debugger and send it to the DDR3?

Didn't have time last night to set up the debugger.  Likewise was unable to get Signal Tap traces.  Will hopefully be able to do both at some point today.

Everything seemed to work fine here except for that I don't have a Z80 to test with.

I'll be sending you a basic system to test on very shortly.  I'm just waiting on a component which should arrive today/tomorrow, then I can assemble and test the latest DECA interface card and get a system on its way to you.

[nockieboy]

Okay, fixed the memory access issue.  I'd not copied some key lines from the GPU.sv file to the new _top file that were setting default directions/enables for the address buffers and command control outputs.

New (working) GPU_DECA_DDR3_top.sv attached.  Lines 438-450 are the fix.

I'm able to clear the screen and read and write values to anywhere in the lower 512KB of DDR3, with the uCOM detecting the GPU thanks to the BANK_ID at the very top of the 512KB.  All looking good so far!

Haven't tested the image via the debugger yet - maybe have time tomorrow for that - but can't see that the debugger should have issues read/writing the DDR3 RAM, unless it's not wired up correctly.

[BrianHG]

Ok, next, wire in the 'geometry_processor   GEOFF' and get the accelerated text working.

[nockieboy]

Hit a minor syntax issue with wiring GEOFF up.  Line 700 in the attached GPU_DECA_DDR3_top file - I can't work out how to write that I need the first 20 bits of (PORT_ADDR_SIZE)'(CMD_waddr[2]).  Wherever I put the [19:0] it causes Quartus to throw a wobbly.

Also, while you're looking at it, can you confirm that I've not messed up PORT_R/W_TOTAL and associated DATA_WIDTH and PRIORITY arrays?

[BrianHG]

Ok, I cleaned everything up.
On the number of write channels, you go 1 extra write channel which wasn't in use.

Also, I had to add and clean up the unused input assignments.

Also, I made an addition to the geometry processor and pixel writer adding a separate output for the read address of the copy pixel channel to help with quartus routing.

You still need to assign a copy of the main pixel write channel's address read channel to it's write address.  See line 714.

System clock 4 is only achieving 80MHz out of the required 100.  Hopefully the system will still work as with my DDR3 V1.5, this FMAX bottleneck in the multiport controller has been solved 3 fold, though, now it's the speed of the ellipse generator which maxes out at ~150MHz though you will be able to run the multiport in v1.5 in half-rate mode at 200MHz with 400MHz ram.

[nockieboy]

You still need to assign a copy of the main pixel write channel's address read channel to it's write address.  See line 714.

Bit confused by this - is this something I need to do, or something you've done that you're pointing out I missed?

I've tried variations on:

Code: [Select]

assign CMD_raddr           [3] = CMD_waddr[2] ; // Read address 2 shares write address 2.
With assigning raddr to waddr and vice versa, changing the port numbers, but nothing is compiling.

[BrianHG]

I tried compiling the project I sent you in the last thread.  It works.  It should compile.
This is how I know that the FMAX of clock[4] was 80MHz.
IE: the file 'GPU_DECA_DDR3_DDR3only_with_GEO.zip' was a complete functional compiling project.

Line 714 is there.  I did the assign for you.

You should be rendering text by now.

[nockieboy]

I tried compiling the project I sent you in the last thread.  It works.  It should compile.
This is how I know that the FMAX of clock[4] was 80MHz.
IE: the file 'GPU_DECA_DDR3_DDR3only_with_GEO.zip' was a complete functional compiling project.

Line 714 is there.  I did the assign for you.

Ah, well chalk that one up to me misunderstanding what you'd written.  It looked (to me) like you were asking me to add another assign.

You should be rendering text by now.

Unfortunately, no.  The project you posted compiles, but it doesn't work very well.  There's a funny pattern on the screen consisting of vertical bars, fading from white to black with dark horizontal lines every other line.  If I try to view GPU memory - any page or bank - it takes a couple of seconds to display the dump (i.e. it looks like WAIT states are being inserted) and all I'm seeing are 0x7Es, no actual DDR3 RAM contents.  I'm unable to write to GPU RAM.

[BrianHG]

Ok, I see the pattern.
Need to hook up the RS232 debugger and see whats going on.

[BrianHG]

Ok, it looks like the problem is on line 739 of the gpu_deca_DDR3_top.sv.

Code: [Select]

   .PORT_R_DATA_WIDTH   ( PORT_R_DATA_WIDTH[2]  )   // Width of read port.  Always use the 'PORT_CACHE_BITS' for the read port for the most efficient continuous bursts.

You forgot to change the data width to port number 4 where the display is reading memory from.

IE:

Code: [Select]

   .PORT_R_DATA_WIDTH   ( PORT_R_DATA_WIDTH[4]  )   // Width of read port.  Always use the 'PORT_CACHE_BITS' for the read port for the most efficient continuous bursts.


[BrianHG]

  You also made changes to the Z80 bus interface.

Update the version in the project with your working one here:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3774773/#msg3774773

[nockieboy]

You also made changes to the Z80 bus interface.

That's why I attached it earlier in the post you'd linked.  I should have mentioned that I'd made some adjustments for the RAM size and BANK_ID.

Ok, it looks like the problem is on line 739 of the gpu_deca_DDR3_top.sv.

Code: [Select]

   .PORT_R_DATA_WIDTH   ( PORT_R_DATA_WIDTH[2]  )   // Width of read port.  Always use the 'PORT_CACHE_BITS' for the read port for the most efficient continuous bursts.

You forgot to change the data width to port number 4 where the display is reading memory from.

IE:

Code: [Select]

   .PORT_R_DATA_WIDTH   ( PORT_R_DATA_WIDTH[4]  )   // Width of read port.  Always use the 'PORT_CACHE_BITS' for the read port for the most efficient continuous bursts.


Ah yes, that's sorted it. 

Don't know if GEOFF is supposed to be fully working, but it's not changing RAM at all when I attempt to draw, say, a filled rectangle or anything.  It might be because I haven't updated the graphics driver for the new 8 bpp mode yet, but there should be something written even if it doesn't make sense in the new 8bpp mode?

[BrianHG]

Yes, data should write, even if the depth is wrong.
remember, with a monochrome palette, color 1 will be practically invisible.  You need to plot color 255 for white.

Try plotting a pixel at 0x0 and read the DDR3 contents in the Z80 and/or debugger.

Also, change the HSE and VSE inputs to the CMD_CLK versions (lines 682/683):

Code: [Select]

   .hse              ( CMD_vid_xena ), // Horizontal sync signal from VIGEN.
   .vse              ( CMD_vid_yena ), // Vertical   sync signal from VIGEN.

If it stays black, try setting the pixel to white with the Z80 writing mem, the plot the pixel again.  Maybe it will write black.

If you cannot get it to write, then you will need to roll back the:
geometry_processor and pixel_writer
to the one we had when the DDR3 text functioned properly.
It is the one where the 'CMD_raddr[3]' is a copy of '.ram_addr' instead of the new '.ram_addr_C'.  I might have made a mistake in the modifications.

Also make sure the write mask for channel 2 is enabled.

[BrianHG]

If all fails, make sure that the working DDR3 geo version is actually writing to the DDR3, not just reading from it.  To do this, draw using the geometry unit and read back using the Z80 making sure there is a change.

You can also try changing the compiler optimization technique from balanced to speed.  Right now, we are overclocking the multiport and it may just be failing to send writes to the DDR3 from port number 2.  You can also try slowing down the DDR3 from 400MHz to 300MHz.  This should make achieving timing much easier.


ALSO:  Are you sure the write port to the geometry unit is working?  Maybe it's not receiving any commands.  Maybe due to the paging or MMU stuff you changes...

[BrianHG]

Also move lines 666 through 672 to before the initiation of Z80 bus interface at line 498.  You need to define the wires before you begin to use them, not after.

[nockieboy]

I haven't got the time to put into this that I need today, unfortunately, otherwise I'd be doing Signal Taps and confirming RAM contents with the debugger.  Just by way of a quick update, though:

Yes, data should write, even if the depth is wrong.
remember, with a monochrome palette, color 1 will be practically invisible.  You need to plot color 255 for white.

I can see pixels changing value at the top of the screen where text-tile mode is used by the bootstrap when I first turn on the uCOM, but not a lot happens once I switch to the DMI which uses blitting instead of text-tile mode.  I'm wondering if you might be on to something with this comment:

Also make sure the write mask for channel 2 is enabled.

I don't think I've got a write mask for channel 2 at all.  I can only see references to CMD_wmask[0] in the _top file.  I've got to rush out again.   Hopefully I'll have more time tomorrow or late tonight.

[nockieboy]

Okay, I have no idea what's going on with the write masks it seems.  It appears that a write mask exists for Port 3, as it's set in line 717 of the _top file to 3, which means writes should be possible to the first two bytes (or 16 bits, which is the bit-width of that port).

The write port width array on line 91 appears incorrect, however.  It specifies 8, 8, 16, 32 - so 8-bit-wide ports for the debugger and Z80 bridge, 16-bits wide for GEOFF.  Not sure what the 32 is for - there are only three write ports, so that port isn't used?

Updated _top and bridge files attached - these are my latest versions containing the changes made as as a result of your previous post, so the line numbers above are relevant to these files.  Tomorrow I'll start Signal Tracing and debugging to find out what's going on with the GEOFF writes.

[BrianHG]

Ok, item 1 in geo_pixel_writer.sv, (My bad...)

Comment out line 172, comment in line 171.

Item 2 in _top.sv, lines 664,665:
Change one of those 'CMD_R_priority_boost' into a 'CMD_W_priority_boost'.

Also, to help FMAX, try changing line 711 from:

Code: [Select]

   .ram_mux_busy     ( CMD_W_busy[2] || CMD_R_busy[2] || CMD_R_busy[3] )  // || geo_port_full ), // input from geo_port_full
to

Code: [Select]

   .ram_mux_busy     ( CMD_W_busy[2] )  // input from geo_port_full


[nockieboy]

That's working now. 



That's the old blitted-text mode (1 bpp) you can see at the top of the screen, showing CP/M and a large white triangle drawn across the screen using GEOFF.

Just need to update the graphics driver for the new 8 bpp mode.

These are the timings I'm getting from this build: