FPGA VGA Controller for 8-bit computer

[BrianHG]

Ok, the DDR3 booted properly.

Next, the GPU, remember I told you to:

Code: [Select]

assign clk_2x_phase = clk ;
well, make it:

Code: [Select]

assign clk_2x_phase = !clk ;
If that doesn't work, then better:

Code: [Select]

always_ff @(posedge clk_2x) begin
clk_2x_phase <= !clk_2x_phase ;
end

or:

Code: [Select]

always_ff @(posedge clk_2x) begin
if (reset) clk_2x_phase  <= 0;
else clk_2x_phase <= !clk_2x_phase ;
end

or:

Code: [Select]

always_ff @(posedge clk_2x) begin
if (reset) clk_2x_phase  <= 1;
else clk_2x_phase <= !clk_2x_phase ;
end

or

Code: [Select]

always_ff @(posedge clk_2x) begin
clk_2x_phase <= !clk ;
end

or

Code: [Select]

always_ff @(posedge clk_2x) begin
clk_2x_phase <= clk ;
end


[nockieboy]

In GPU_DECA_DDR3_top, I'd done this on line 489:

Code: [Select]

.clk_2x_phase( !DDR3_CLK_25  ),
Would that not do the same thing?

[BrianHG]

Try in reverse order...
The last simple one first:

Code: [Select]

always_ff @(posedge clk_2x) begin
clk_2x_phase <= clk ;
end


[BrianHG]

the clk_2x_phase needs to be driven by a DFF clocked on the clk_2x domain for proper operation.

It just may need inverting, so you might need to make it <= !clk.

[nockieboy]

Try in reverse order...
The last simple one first:

Code: [Select]

always_ff @(posedge clk_2x) begin
clk_2x_phase <= clk ;
end


Okay, tried this one first.  This is the result with the above code added to gpu.sv.

[BrianHG]

Did you get the same without the DDR3?

Maybe try the inverted version.

Is the GPU still locked up, or, is it that just the graphics are messed up now.

Does your current code rely on reading GPU data?  Or is it all write only?

Some DDR3 reads may be messed up without the 'WAIT' command setup.

[nockieboy]

Did you get the same without the DDR3?

Without DDR3 it worked fine - full screen.

Maybe try the inverted version.

Okay, compiling for this right now.

Is the GPU still locked up, or, is it that just the graphics are messed up now.

No, not locked up at all.  Working almost fine, it seems - I can see screen text scrolling in that little top-left window etc. and behaving as I would expect it if it were working properly.

Will update in a sec with the results of the inverted clock build.

[nockieboy]

With the inverted clock, I'm getting nothing but the HW trigger lines.

[BrianHG]

Does your current code rely on reading GPU data?  Or is it all write only?

Some DDR3 reads may be messed up without the 'WAIT' command setup.

[nockieboy]

Does your current code rely on reading GPU data?  Or is it all write only?

Some DDR3 reads may be messed up without the 'WAIT' command setup.

Not really, no.  The only GPU data that is read is the BANK_ID string at the very top of GPU RAM.  Everything else is written to the RAM, unless there's some obscure routine that I've forgotten about, but at these early stages in the uCOM boot, the first page of GPU RAM is just cleared and a set of specific values are written to set up the HW registers, trigger values and MAGGIEs to display text-tiled mode initially, then full graphics mode with blitted characters when I get into the DMI or CP/M (both of which show up in the top corner and scroll perfectly as well).

I've just compiled the non-inverted clk version again and uploaded it to the GPU.  As soon as the JTAG upload has finished, the uCOM hangs as it usually does when I program the GPU but the screen displays the Z80 chip image, character set table and multi-colour text title perfectly.

When I reset the uCOM, I just get the HW trigger lines and part of the video display in that top-left corner.  When I go into the DMI and take a look at the first page of the GPU RAM (via the serial console) (the first page of GPU DDR3 RAM, in reality), it just gives me a page of $7Es, or bad reads basically.  Looks like something is going wrong due to the reads not returning true values, and that I need to get WAITs running?

[BrianHG]

If you read the same address twice, the second read should be correct as that read would have been cached and responded as fast as a core ram read.

Same goes for reads within the same 16 byte block.

Can you run the RS232 debugger to see what is inside the DDR3 ram?

Seeing that the graphics are in the wrong place, but you are getting text there means writes to the FPGA core are making it and if that text I saw was blitter generated, this means the geo unit is still accessing the core ram.

You can try a dummy 'WAIT' just to give time for my controller to give you the right data.  But if you are reading sequential bytes, the answer should eventually change from 1 value.
 

[BrianHG]

Can you setup the SignalTap to monitor the ' Z80 <-> DDR3 ' read and write bus?

Try sending me the latest project after you run the above tests.

[nockieboy]

If you read the same address twice, the second read should be correct as that read would have been cached and responded as fast as a core ram read.

I'll have to go to the metal and write an assembly program to test that as my tests in the DMI all write to GPU inbetween successive reads to the GPU, unfortunately, which probably throws the cache.  What I'm seeing is the same value repeated - $7E - for all values read.

The BANK_ID is being returned properly, however.

Can you run the RS232 debugger to see what is inside the DDR3 ram?

This will require some hardware modification to the interface card.  Won't be able to do this until later (or tomorrow, possibly).

Seeing that the graphics are in the wrong place, but you are getting text there means writes to the FPGA core are making it and if that text I saw was blitter generated, this means the geo unit is still accessing the core ram.

Yes, that first image was using blitted text.  This next one shows the DMI in text-tile mode, but clearly shows that the third MAGGIE is being properly set up to display the 'Z80 Inside' logo.

You can try a dummy 'WAIT' just to give time for my controller to give you the right data.  But if you are reading sequential bytes, the answer should eventually change from 1 value.

Well, yes, it should do - it looks more like a Z80 interface timing issue?  The Z80 is reading the data bus but valid data isn't there at the right time?

I've attached the latest project below, including (very) basic setup of a SignalTap.  Please excuse any issues with the SignalTap setup - I've literally thrown it together as I'm doing three different things at once.  One thing I've noticed is that the timescale seems to be picoseconds, which doesn't produce many meaningful results.

[BrianHG]

You have typos in 'GPU.sv', lines 260-262...
Your read is still wired to the FPGA core ram.

First enable line 334 and see if everything works like it used to.  It should, or, something else went wrong.

If everything now works ok, we then know your Z80 code is reading some memory from the GPU.

Verify DDR3 contents with RS232 debugger, or verify writes using the SignalTap connected to the CMD_CLK, CMD_R/W_REQ as triggers, and monitor the CMD_R/W address and data for channel [ 1 ].

Arrrg, you didn't vertically group sort the 'data_mux_geo' IO ports.  It makes following things disruptively difficult.

Next, fix lines 260-262 so it is connected to the DDR3 read port.
Just assign the old ' gpu_rd_request = 0 ' to disable the read from the data_mux_geo.

[nockieboy]

Latest GPU.sv attached, with grouped input/output for the data_mux_geo to (hopefully) make troubleshooting a little easier.

Think I found the issue with the reads - haven't tested it yet, but looks like I've still got the gpu_rd_rdy input on the Z80_bridge connected to the data_mux_geo's gpu_rd_rdy_a output.  Replacing this:

Code: [Select]

   .gpu_rd_rdy        ( Z80_rd_rdy     ), // INPUT:  Read request data byte is ready / valid input.
   .gpu_rData         ( dat_to_Z80     ), // INPUT:  Read request GPU RAM returned 8 bit data byte.
with this:

Code: [Select]

   .gpu_rd_rdy        ( gpu_rd_rdy     ), // INPUT:  Read request data byte is ready / valid input.
   .gpu_rData         ( gpu_rData      ), // INPUT:  Read request GPU RAM returned 8 bit data byte.
in GPU.sv.  This results in the following - the DMI is actually able to read SOME memory, but looks like only the first half of a page.



And if you look closely, you'll see the first byte of each 16-byte row is $7E (the value the uCOM seems to give for a bad read by chance), but remaining bytes in each row has a valid value, so it looks like the DDR3 is returning values, just not in time for the first 'non-cache' hit.  All those $B0's should be $00s.



There's random 'snow' on the screen, too - with some odd 'noise'-type effects in vertical columns down the screen, as seen below.  These are not static, they're 'animated', looking exactly like an interference pattern or static on a badly-tuned analogue TV image.

[BrianHG]

Strange.  The display has no connection to the DDR3.  It is currently exclusively 100% core FPGA memory.

Maybe we stressed the core's FMAX too high.

Or, it is the:

Code: [Select]

always_ff @(posedge clk_2x) begin
clk_2x_phase <= clk ;
end
In the original PLL code, I had a special phase setup to feed the clk_2x_phase which does not exist here.

There are 2 things to try...

a)  Try both a '1' and a '0'.

Code: [Select]

always_ff @(posedge clk_2x) begin
if (reset) clk_2x_phase  <= 1 ;
else clk_2x_phase <= !clk_2x_phase ;
end
b)  Switch compiler to Optimization mode to 'Performance - High Effort'.

If A & B doesn't work, then we will slow down the DDR3 PLL to 400MHz and test, though, you video out will be 48Hz instead of 60Hz.  The compiler may be trying too hard to reach the impossible 500 MHz and it is ignoring some crucial paths down at the 250MHz and 125MHz.  If your monitor cannot sync up to 48 Hz, we can also try 250Mhz and run the DDR3 in half speed mode instead of quarter speed mode.

(The odd video frame rate will be temporary as we upgrade the video output path.)

[nockieboy]

In the original PLL code, I had a special phase setup to feed the clk_2x_phase which does not exist here.

There are 2 things to try...

a)  Try both a '1' and a '0'.

Code: [Select]

always_ff @(posedge clk_2x) begin
if (reset) clk_2x_phase  <= 1 ;
else clk_2x_phase <= !clk_2x_phase ;
end

Okay, with a '1', the display initially shows a corrupted version of the initial RAM contents (the Z80 CPU image), then reverts back to just the HW trigger lines and a tiny portion of the (blitted-text) screen in the top-left quadrant.  No 'snow' or interference though, what I can see is clean.

Code: [Select]

     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C000 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C010 7E 10 B0 10 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C020 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C030 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C040 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C050 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C060 7E B0 0F B0 12 B0 00 50 02 7F 01 DF 00 00 00 00  .......P........
C070 7E 01 0F B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C080 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C090 FE B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0A0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0B0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0C0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0D0 FE B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0E0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0F0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................Page dump from the first page of RAM returned by the GPU.

With a '0', I get a 'snow'-free display, nice clear 'test page' with the initial memory image and character set, but when the uCOM tries to set up the screen how it wants, it just goes black with the HW trigger lines.  The first page of GPU RAM (DDR3) indicates that 0x00's are being read as 0xB0s, with the usual 0x7E for the first byte in each row.  Values that have been set by the uCOM are being read okay, it's just the rest of the page that's 0xB0's.

Code: [Select]

     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C000 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C010 7E 10 B0 10 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C020 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C030 FE B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C040 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C050 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C060 7E B0 0F B0 12 B0 00 50 02 7F 01 DF 00 00 00 00  .......P........
C070 7E 01 0F B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C080 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C090 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0A0 FE B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0B0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0C0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0D0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0E0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0F0 7E B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................Page dump from the first page of RAM returned by the GPU.

Let me know if you want me to continue on to the B) test, but at the moment it doesn't seem it'll be of much value.

[BrianHG]

The corrupt snow is because the FPGA cannot reach the requested speed along certain critical paths.

Revert the clk_2x_phase and try slowing down the system:

Code: [Select]

// ****************  System clock generation and operation.
parameter int        CLK_KHZ_IN              = 50000,            // PLL source input clock frequency in KHz.
parameter int        CLK_IN_MULT             = 32,               // Multiply factor to generate the DDR MTPS speed divided by 2.
parameter int        CLK_IN_DIV              = 4,                // Divide factor.  When CLK_KHZ_IN is 25000,50000,75000,100000,125000,150000, use 2,4,6,8,10,12.
parameter int        DDR_TRICK_MTPS_CAP      = 600,              // 0=off, Set a false PLL DDR data rate for the compiler to allow FPGA overclocking.  ***DO NOT USE.

Right at the top of the _top.sv, the _MULT = 32,  will run the system at 400MHz instead of 500MHz.
Also, change the compiler optimization to my option 'B'.

If your monitor cannot run at 48Hz, try a _MULT = 34,  . This should output a 50Hz video signal.

If this doesn't work, I'll show you how to do the 250MHz mode.

[BrianHG]

The first page of GPU RAM (DDR3) indicates that 0x00's are being read as 0xB0s, with the usual 0x7E for the first byte in each row. 

Ok, the first 7E means for reading that byte, you need a 'WAIT' state for my DDR3 to retrieve the 16 byte block of ram while the other bytes are correct since they are cached & read as fast as core FPGA memory, so they appear fine until you enter a new block of ram.

Now for the rest of the '0B'.  This is actually because reading the DDR3, the DDR3 is actually blank or filled with random data.  Originally when you read the FPGA ram, that ram at power-up had the .mif initialization file with it's power-up data.  This is no longer the case with the DDR3 which does not contain any such data in it.  You need to fill write everything into the DDR3 if you want to see all the data.

[BrianHG]

I don't get it, are you saying that when the text window is up to the left, the text is ok without garbage.
Maybe your code is reading the GPU ram and editing the window coordinates, but because the DDR3 has lemon values since there is no .mif file, the screen is messed up.  Yet, everything else is ok.

Just a possibility.

[nockieboy]

I don't get it, are you saying that when the text window is up to the left, the text is ok without garbage.
Maybe your code is reading the GPU ram and editing the window coordinates, but because the DDR3 has lemon values since there is no .mif file, the screen is messed up.  Yet, everything else is ok.

Just a possibility.

Yes, text is okay, no garbage:



Latest project version attached so we're on the same page.

[BrianHG]

Have you tried editing the first 32 bytes where the video window positions and cursors are located?
Can you tell if  this corruption happen before the Z80 boots up?
I'll check your code later tonight.

[nockieboy]

I've cleared a page of RAM to zero, set it up as per the startup of the graphics driver (i.e. setting up HW triggers and MAGGIE0), then I've copied that page of RAM into the GPU RAM.  Below is the source, after is the result read back from the DDR3:

Code: [Select]

     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
8000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
8010 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00  ................
8020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
8030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
8040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
8050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
8060 08 00 0F 00 12 00 00 00 02 7F 01 DF 00 00 00 00  ................
8070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
8080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
8090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
80A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
80B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
80C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
80D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
80E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
80F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Here's what I'm reading back from the DDR3:

Code: [Select]

     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C000 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C010 7E 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00  ................
C020 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C030 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C040 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C050 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C060 7E 00 0F 00 12 00 00 00 02 7F 01 DF 00 00 00 00  ................
C070 7E 01 0F 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C080 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C090 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0A0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0B0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0C0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0D0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0E0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0F0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
The screen is black, but I see flickers of vertical white lines here and there when text (should) scroll up the screen - but only when the text should scroll.  It looks like the blitter isn't set up properly, but there's no reason why it should be having issues as *nothing* has changed on that side - the blitter doesn't use DDR3 for its settings and I've not changed how the Z80_bridge handles IO writes/reads, which is how the blitter is set up.

Have you tried editing the first 32 bytes where the video window positions and cursors are located?
Can you tell if  this corruption happen before the Z80 boots up?
I'll check your code later tonight.

Yes - have just been playing with the HV triggers.  I can get additional H/V lines on the screen by setting values in the first 32 bytes.  i.e.:

Code: [Select]

POKE &C001,&80
Ready
POKE &C003,&F0
Ready
DUMP &C000
     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C000 7E 80 00 F0 00 00 00 00 00 00 00 00 00 00 00 00  ................
C010 7E 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00  ................
C020 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C030 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C040 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C050 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C060 7E 00 0F 00 12 00 00 00 02 7F 01 DF 00 00 00 00  ................
C070 7E 01 0F 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C080 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C090 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0A0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0B0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0C0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0D0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0E0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0F0 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
So the above shows that I've poked 0x80 into the first horizontal trigger and 0xF0 into the first vertical trigger.  This results in the screen below, but all the text above should also be visible on the screen below, but isn't.



EDIT: Hopefully will have some time tomorrow to put into SignalTap and see what's going on.

[BrianHG]

Ok, the first 7E means for reading that byte, you need a 'WAIT' state for my DDR3 to retrieve the 16 byte block of ram while the other bytes are correct since they are cached & read as fast as core FPGA memory, so they appear fine until you enter a new block of ram.

Ok, could you try adding the dummy wait-state during any and all Z80 read GPU ram.

If done, this might fix the $7E read byte errors.

Could you setup Signaltap to capture a Z80 read cycle showing the added CMD_R/W bus, including the 'busy' signals.

[BrianHG]

Could you also send me a .bin of the last default power-up .mif.
Get the rs232 debugger working.
I will add a patch where the DDR3 writes will be copied to the 'data_mux_geo's .wr_ena_b, .address_b & .data_in_b  so it will affect the core GPU ram.