FPGA VGA Controller for 8-bit computer

[BrianHG]

@Nockieboy, are you getting a really dim image on the DECA board?

IE, do you need to boost your monitor's contrast really high?

[nockieboy]

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.

First page of GPU RAM (DDR3) without WAITs inserted:

Code: [Select]

Ready
DUMP &C000
     +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 7E 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 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  ................

Same page with WAITs inserted for all GPU memory ops:

Code: [Select]

OUT 249,1    <---- set minimum WAIT insertion time
Ready
DUMP &C000
     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C000 00 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C010 B0 10 B0 10 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C020 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C030 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C040 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C050 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C060 08 B0 0F B0 12 B0 00 50 02 7F 01 DF 00 00 00 00  .......P........
C070 B0 01 0F B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C080 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C090 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0A0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0C0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0D0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0E0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
C0F0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0 B0  ................
I'd call that a preliminary 'win' for WAITs.

All those 0xB0s are annoying, though.  I can write 0x00 with individual POKE commands, or even by copying RAM as I showed in a previous post, but for some reason the DDR3 isn't taking to LDIR block memory ops without corrupting 0x00s into 0xB0s.

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

Will get started on that this morning.

Could you also send me a .bin of the last default power-up .mif.

Sorry, not sure I understand what you're asking for here?  You mean the GPU_MIF_CE10_10M.mif file that's in the project?  Do you mean a download via the debugger from the FPGA?

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.

Hopefully will get that done today.

@Nockieboy, are you getting a really dim image on the DECA board?

IE, do you need to boost your monitor's contrast really high?

Whoah.  How did you know that?  I've had my TV's brightness at 60 and contrast at 70 all this time since using the DECA's HDMI output.  Normal values of 50/50 give a very dim screen.

[BrianHG]

@Nockieboy, are you getting a really dim image on the DECA board?

IE, do you need to boost your monitor's contrast really high?

Whoah.  How did you know that?  I've had my TV's brightness at 60 and contrast at 70 all this time since using the DECA's HDMI output.  Normal values of 50/50 give a very dim screen.

You honestly didn't think I haven't already gotten the GPU working with the RS232 debugger...

I'll sen you an updated project with a few fixes in an hour.

In the mean time, the SignalTap trace of reading byte 0x00000 is important to see what's going on internally.

[BrianHG]

Take a look at C06C and C000, why are those 2 = to 0x00?
Are you sure you haven't poked all 0s to the ram?

Also, the Z80 bridge might not know for how long to hold the output enable if the DDR3 controller reads back data immediately.

[nockieboy]

Take a look at C06C and C000, why are those 2 = to 0x00?
Are you sure you haven't poked all 0s to the ram?

They're set to zero with two 16-bit register (HL) writes from the Z80.  Here's the code in my graphics driver:

Code: [Select]

    ; X & Y scale (set to 0 for 1:1 scaling)
    LD      HL,0000H
    LD      (GPU_RAM+6CH),HL
    ; X & Y sub-pixel position (set to 0,0)
    LD      (GPU_RAM+6EH),HL
EDIT: Not sure why the first byte (C000) is zero.  This is probably because the very first write to DDR3 RAM is accepted, but each subsequent one performed by LDIR is causing timing issues and winding up as 0xB0s?

Also, the Z80 bridge might not know for how long to hold the output enable if the DDR3 controller reads back data immediately.

Surely it only holds it open as long as it's waiting for gpu_rd_rdy to go high?

[nockieboy]

Okay, hoping these provide something useful.  These are the Signal Tap results from reading C000 (0x0000 in GPU RAM) and C010 (0x0010 in GPU RAM).  If you check the memory dumps in my earlier posts, you'll see C000 should be 0x00 and C010 should be 0xB0.

Reading from 0x0000:



Reading from 0x0010:

[BrianHG]

I need to see the Z80 clk input plus disable the 'wait'.

Is the rd_DAT_ready tied to my CMD_read_ready?

Where are the CMD_R/W_busy signals?

[nockieboy]

Is the rd_DAT_ready tied to my CMD_read_ready?

Where are the CMD_R/W_busy signals?

I'm not sure, but it looks like they're getting optimised away?  I've been selecting nodes with the Signal Tap: post-fitting filter.  Have had to switch to Signal Tap: pre-synthesis to find the extra nodes you've requested.

[nockieboy]

Okay, no WAITs, added what I could to the node list with the proviso mentioned in my previous post about Quartus seeming to optimise out certain signals.

This below trace is the result of reading C000 (0x0000):

[BrianHG]

Hang on, need to find my Z80 data sheets...

Where are the output enable and the 245 dir controls?

My guess the transition from 81h to 00h at time 22 is happening too late.

Your labels are messing me up.  Need to analyze...

[BrianHG]

Hmmm, considering that what we see already has additional delays involved...

It may be possible to get the read to return in time without the wait state, but, it looks like we will still need it on occasion no matter what.

Let me just update you with some code fixing the other problems and we will look at the Z80 bridge tomorrow.

Take a look at what happens when you read 2 adjacent GPU ram bytes.  Lets see how fast the second byte (which would be in my DDR3 controller's cache unless you read outside the 16 byte read cache) returns the data.

[BrianHG]

Okay, no WAITs, added what I could to the node list with the proviso mentioned in my previous post about Quartus seeming to optimise out certain signals.

This below trace is the result of reading C000 (0x0000):

Go into Z80 Bridge, line 259 and make this change:

Code: [Select]

Z80_CLKr           <= !Z80_CLK            ; // Register delay the Z80_CLK input.
Redo the test and post a new Signaltap screenshot please.

[BrianHG]

Here you go, a bunch of little patches.

Everything seems to work OK, other than I cannot test the Z80 interface.

Note that you will need to move the RS232 debugger's RXD/TXD pins.  They are located on lines 561-563 in file 'GPU_DECA_DDR3_top.sv'.

Also, to disable my forced video ON even without a Z80 connected, goto line 555 and enter ( 1'b0 ) for that input.

I have not included the inverted Z80 clock test with these files.
Your picture brightness should now be correct.
You might need to re-enter your latest signal-tap nets.

Lest's get the Z80 working fine with the DDR3.  Once done, we will move the geometry unit over to the DDR3, then, we will need to make the new MAGGIE & OSD / PALETTE system which will then run a display right from the DDR3 releasing you from your tiny 128k screen memory limit.

[nockieboy]

Where are the output enable and the 245 dir controls?

I can only find the 245_dir_r signal - the z80_245_oe_r signal isn't in the post-fitting node list...

My guess the transition from 81h to 00h at time 22 is happening too late.

Highly likely looking at the Signal Tap output, yes.  The data bus is sampled on the falling edge of the last clock pulse before RD and MREQ go high. 

Take a look at what happens when you read 2 adjacent GPU ram bytes.  Lets see how fast the second byte (which would be in my DDR3 controller's cache unless you read outside the 16 byte read cache) returns the data.

Below are the results of a sequential read to C000 and C001, using an 8-byte program that immediately reads from C000, then the next command reads from C001, so there are no reads/writes to GPU RAM inbetween:

Read from C000:



Following read from C001:



Both merged, with the Z80's prefetch step removed:

Here you go, a bunch of little patches.

Everything seems to work OK, other than I cannot test the Z80 interface.

Note that you will need to move the RS232 debugger's RXD/TXD pins.  They are located on lines 561-563 in file 'GPU_DECA_DDR3_top.sv'.

Also, to disable my forced video ON even without a Z80 connected, goto line 555 and enter ( 1'b0 ) for that input.

I have not included the inverted Z80 clock test with these files.
Your picture brightness should now be correct.
You might need to re-enter your latest signal-tap nets.

Lest's get the Z80 working fine with the DDR3.  Once done, we will move the geometry unit over to the DDR3, then, we will need to make the new MAGGIE & OSD / PALETTE system which will then run a display right from the DDR3 releasing you from your tiny 128k screen memory limit.

Thank you. 

[nockieboy]

Update on your patched version of the project:

Compiled with no issues.  I've made the changes you mentioned for the RS232_debugger.  Upon resetting the uCOM after writing to the FPGA, got the same issue with the HW trigger lines and small quarter display in the top left.

BUT:

If I reset the uCOM or just restart the DMI (and thus set up the screen again), every now and again it will work.  Here's a couple of pics to prove it (and yes, it's much brighter - thanks!):

Here's the bootstrap, which uses text-tile mode:



And here's the DMI, running in 1bpp 640x480 graphics mode with blitted text, showing the first page of GPU RAM:



So it seems randomly (about 1 time in 8 if was forced to make a guess) the screen (or blitter) setup works as intended.  Note the lack of 0xB0s in the first half of the page - perhaps this is related to the screen not being set up properly?

I'm off to try and get the UART debug port wired on the current DECA interface card.  I think being able to see the contents of GPU RAM as well is a must now.

[nockieboy]

RS232 debugger is now connected via a wire hack I'm not proud of, but once the new PCBs arrive it'll all be good.

First time I reset the uCOM, it worked fine. 

Here's the output from a bad start-up:

[BrianHG]

Well, the debugger should be reading and writing memory properly.

So, where are those '0B' errors coming from.  They must be from Z80 writes.  They cannot be from blits as those do not yet access the DDR3, they go exclusively to the FPGA block ram.

[nockieboy]

Well, the debugger should be reading and writing memory properly.

So, where are those '0B' errors coming from.  They must be from Z80 writes.  They cannot be from blits as those do not yet access the DDR3, they go exclusively to the FPGA block ram.

But nothing has changed on the Z80 side.  The pre-DDR3 project worked perfectly, with no errors in reads or writes to GPU RAM.   

[BrianHG]

Well, the debugger should be reading and writing memory properly.

So, where are those '0B' errors coming from.  They must be from Z80 writes.  They cannot be from blits as those do not yet access the DDR3, they go exclusively to the FPGA block ram.

But nothing has changed on the Z80 side.  The pre-DDR3 project worked perfectly, with no errors in reads or writes to GPU RAM.   

Try editing/clearing the DDR3 in the debugger.  Read back with the Z80 hex display.  Re-check after a Z80 write and block write fill.
Try signaltap capturing the writes.
The DDR3 may be responding to bad/multiple write requests or a deleayed data byte.

Remember, the RS232 debugger has identical 8 bit access to the DDR3.
The old mux_geo module at one time had some tweaking to make the Z80 work error free before feeding the FPGA blockram which is no longer there with the properly functioning high speed DDR3 multiport controller.  We might be seeing the effect here.

It is most likely a bug in the Z80 bridge which just needs fixing.

[BrianHG]

Reset bug/glitch may be connected to the 'B0' error writes.
For now, let's live around it until we solve the other issues.

Note that the DDR3 takes around 0.1 second to boot up.  There is a signal coming from my controller called 'DDR3_READY'.  Your Z80 should be held in reset until that signal goes high.

[BrianHG]

Ok, according to the Z80 datasheet,

The 'WAIT' needs to be set 70ns prior to fall of Z80_CLK cycle T2, yet we only get the valid read req 90ns after the fall of T1.

(Worst case 4MHz Z80...)

So, we need to make a decision of whether to output the 'wait' prior/within 1 Z80 next clock.

As you can see, when I have the data ready in my DDR3 cache, the read is fast enough to handle this.
However, when it is not, with some modding to the Z80 bridge, to react on the fall of the Z80_rd_n, we can still make it so long as the time read_ack time you see remains constant.  This wont always hold true.  So, since we cannot predict that delay in advance, we will have not choice to set the 'wait' if the read isn't ready within 1/2 of a Z80_clk just to make sure the Z80 stops.

It looks like it is time for a new Z80_bridge_v3.sv.  It also looks like I will have to stay up tonight and make it for you if we expect to make headway here at any speed.  Then, you will need to debug it.

[nockieboy]

Try editing/clearing the DDR3 in the debugger.  Read back with the Z80 hex display.  Re-check after a Z80 write and block write fill.

Single-byte edits by the Z80 (POKE-ing individual bytes) works without error and is reflected correctly by the debugger and DDR3 RAM (viewed by the Z80).

A block copy (using LDIR) seems to have worked just fine as well, copying 256 bytes of data from the uCOM's memory to the GPU.

This just leaves the 'block clear' routine the bootstrap and DMI uses to clear out the first page of GPU RAM before setting up...

I've just tried to clear the first page of GPU memory and the page is corrupted again, but now I know what's going on.  I've tested my theory in code and it's confirmed what I thought:  it's not LDIR itself, but the way I'm using it to clear the screen and the underlying issue with DDR3 reads.  When my driver clears the screen it uses a technique for faster clearing of the RAM block - instead of loading 0x00 into the accumulator and writing that value to every byte required to clear the screen, I'm using a trick with LDIR that writes 0x00 to the first byte (hence the first byte is always 0x00 at C000), then uses LDIR to copy that byte to the next memory position, increments both pointers (source and target), then copies the 0x00 from the new position to the next position and so on.

Problem is, writing the first byte is fine as we've seen, but when LDIR copies that byte to the next position, could it be hitting the cache miss problem and getting a value of 0xB0 back instead of 0x00?  Once it's got 0xB0, it writes it to position 2, then moves on and copies 0xB0 to position 3 and so on, resulting in a page of 0xB0s with an 0x00 at the start.

I've replaced the 'block clear' routine with a slower one that just writes the value (0x00 in the case of a block clear) to every byte in the specified range, so it doesn't rely on reading back the value written and bad values can't be introduced due to cache misses.

This has fixed the corrupted screen every time I've tried it.  I'm now getting valid screen displays and stable DMI and CP/M screen output.

[BrianHG]

Ok, here is an update to the Z80_bridge now called 'Z80_Bus_Interface.sv'

Now, I cleaned up a bunch of junk and relabeled things.  I've gone all the way PRIOR to the point of adding my 'wait' routine.
I need you to test the design.  If it runs and Signaltap works, let me know so I can add the smart 'wait' routine.
There are also some other extra useless regs in it most likely originally for security reasons, but now with signaltap, we can properly tune the module and get rid of some of the junk.

You'll probably need to re-setup the signal tap.

Modules changed:
Z80_Bus_Interface.sv
GPU.sv
GPU_DECA_DDR3_top.sv   (Don't forget to change you RS232 RXD/TXD IO pins at lines 553-555)

[nockieboy]

I need you to test the design.  If it runs and Signaltap works, let me know so I can add the smart 'wait' routine.

It's not working properly, unfortunately.  My screen looks like this:



A memory dump of the first page of GPU RAM (as read by the Z80) indicates that the majority of the time, the first byte in a row is being returned as valid - only had one $7E (C0B0 in first dump) in two reads of the page:

Code: [Select]

dump &C000
     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C010 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00  ................
C020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C060 08 00 0F 00 12 00 00 50 02 7F 01 DF 00 00 00 00  .......P........
C070 00 01 0F 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0A0 00 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Ready
DUMP &C000
     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C010 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00  ................
C020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C060 08 00 0F 00 12 00 00 50 02 7F 01 DF 00 00 00 00  .......P........
C070 00 01 0F 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Ready

[BrianHG]

What in the world?
I get a good picture on my side...

In GPU.SV, please change line 265 to a 1 and re-test.