FPGA VGA Controller for 8-bit computer

[SiliconWizard]

Nope, there are a lot of Lattice IPs including memory controllers for DDR/DDR2/DDR3. Problem is, those memory controllers are NOT free. (Available on the Lattice IP server.)

That's as good as non-existent in my book.

Well, for a personal or open-source project, that's certainly an issue. For a commercial one, that's not much of an issue if the pricing is right (which I don't know) and if you get support with the license.
Despite relatively cheap and easy to use parts, that would fit well for personal/hobby/open source projects IMO, Lattice doesn't seem to care all that much for this market. The fact they recently increased the price of their dev boards drastically tends to confirm that.

There are a couple open-source boards with ECP5 FPGAs though, and at least one of them actually has a DDR3 memory chip. (The OrangeCrab board.) I haven't looked at it much so far, I'll be curious to see if there are example projects using this memory, and if so, how they managed to control it. Writing your own DDR3 controller is not exactly a picnic. I'll try to figure that out.

I admit I much prefer the free IP catalog from Xilinx.

[nockieboy]

So it looks like the IDE is available here on the support page, but you have to complete a fairly detailed registration process to access it (I don't have time to check it out properly at the moment).  It also appears you get a year's licence to use the IDE if you purchase a dev board, so from that I'm gathering the IDE isn't free.

EDIT: Yeah, you have to purchase a dev board or software licence.

[asmi]

The real question is - do you really want to design in a noname FPGA with no community, almost no public information and a vendor who doesn't seem to care about you unless you're buying a million chips?
To me the answer is very obvious, but I'm not sure about your guys.

[nockieboy]

The real question is - do you really want to design in a noname FPGA with no community, almost no public information and a vendor who doesn't seem to care about you unless you're buying a million chips?
To me the answer is very obvious, but I'm not sure about your guys.

No, I totally agree.

EDIT:  After a brief chat with Efinix's head of marketing, I got access to their IDE.  Aside from it looking like a Python IDE, it appears a little basic compared to what I'm used to with Quartus.

[nockieboy]

So where am I going with this then?  I feel a little directionless at the moment, not least because I've had little time to think about the project, let alone work on it.

If I'm honest, I feel more comfortable switching to Xilinx than Lattice if I have to switch at all (though I'm open to discussion).  If we keep the code as platform-agnostic as possible, it shouldn't pose too many issues for anyone wanting to port the project to a platform of their choosing.  If they're looking to do that then I'd expect a higher level of competence with FPGAs than I have anyway, so it shouldn't be too big a hurdle.

Whilst the Cyclone V may not have the supply and production stability of more modern FPGAs, the 5CEBA2 is available at a price point I'm comfortable with for my application and I can get JLCPCB to mount it for me if I chicken out of soldering the FBGA-256 package myself.  We've shown the Cyclone IV can handle 1080p output through a less stable test circuit than the final PCB will have, so HDMI/DVI isn't an issue.

I guess the TL;DR for this post is this:  do I need to switch to Lattice/Xilinx for the next board, because if not I need to get cracking on the DDR design for the Cyclone V.

[BrianHG]

Give me 6 more days.  I'm solving a problem your gonna have no matter the platform you choose.
Stay away from Efinix.
Work on other things in the mean time.

[asmi]

I guess the TL;DR for this post is this:  do I need to switch to Lattice/Xilinx for the next board, because if not I need to get cracking on the DDR design for the Cyclone V.

That's a your decision to make, since this is your project. Each way has it's own pro and contra, there is no universal answer. Also I suspect that a big factor in this decision would be the mid- to long-term plans, as they might require additional resources.

[BrianHG]

@Nockieboy, I hope you are doing those other things.  I'm doing a ton of leg work for you...

Remember, you haven't demonstrated the VWAIT command for smooth animation.
Reported that the last GPU upload I sent still works.
And verified I fixed the blitter bugs.  (Well, I was able to do some checking in the new simulator test bench.)
As well as some other more impressive things you could try.

[nockieboy]

@Nockieboy, I hope you are doing those other things.  I'm doing a ton of leg work for you...

Remember, you haven't demonstrated the VWAIT command for smooth animation.
Reported that the last GPU upload I sent still works.
And verified I fixed the blitter bugs.  (Well, I was able to do some checking in the new simulator test bench.)
As well as some other more impressive things you could try.

I've been using the last GPU upload since you uploaded it - it's definitely working.    As for the VWAIT testing, it works fine with my blitted text test which I modified over lunch to use it - although I'm finding any values more than 1 for hw_position with a multiplier of 1 (so low-byte values more than 0x81) make the scrolling too slow.  I can do accelerated scrolling, but it slows down scrolling to a crawl and isn't desirable as a result.  Using a value of 0x81 however, effectively replaces the 8-bit delay loop I had before and results in a nice smooth scroll. 

Video of VWAIT scrolling here.

[BrianHG]

@Nockieboy, I hope you are doing those other things.  I'm doing a ton of leg work for you...

Remember, you haven't demonstrated the VWAIT command for smooth animation.
Reported that the last GPU upload I sent still works.
And verified I fixed the blitter bugs.  (Well, I was able to do some checking in the new simulator test bench.)
As well as some other more impressive things you could try.

I've been using the last GPU upload since you uploaded it - it's definitely working.    As for the VWAIT testing, it works fine with my blitted text test which I modified over lunch to use it - although I'm finding any values more than 1 for hw_position with a multiplier of 1 (so low-byte values more than 0x81) make the scrolling too slow.  I can do accelerated scrolling, but it slows down scrolling to a crawl and isn't desirable as a result.  Using a value of 0x81 however, effectively replaces the 8-bit delay loop I had before and results in a nice smooth scroll. 

Video of VWAIT scrolling here.

How strange, at 640x480, or worse, 320x240 60fps, I expected it to be twice as fast.  Are you transmitting these 2 commands in this order?  Only once before or after a complete vertical shift.
Line# 113, VWAIT for  1 frames, until line number   1.
           TX CMD > $0f08  =  ( 15) - (  1) = (00001111 00000001).
           TX CMD > $0781  =  (  7) - (129) = (00000111 10000001).

[nockieboy]

How strange, at 640x480, or worse, 320x240 60fps, I expected it to be twice as fast.  Are you transmitting these 2 commands in this order?  Only once before or after a complete vertical shift.
Line# 113, VWAIT for  1 frames, until line number   1.
           TX CMD > $0f08  =  ( 15) - (  1) = (00001111 00000001).
           TX CMD > $0781  =  (  7) - (129) = (00000111 10000001).

Hmm, well I wasn't setting hw_position (using $0F) anyway.  I added that extra command in (0x0F08 as per your testbench example above) and it made... zero difference.   I modified it to change hw_position from 15 down to 1 with each line scrolled - no difference.

If I modify the number of frames to wait (least-significant nybble of the low byte) on each line scrolled, I can make the scroll accelerate (or decelerate), but it takes about 1.5 seconds (haven't timed it) to scroll 16 pixels if I start with a 15 frame delay and decrement that by 1 with each line scrolled.  There would be a total delay of about 120 frames using that method - which is 2 seconds at 60 fps, so that sounds about right, actually.  I need to use smaller values - I'll take a closer look at your previous post when I have more time where you suggested some values. 

Here's my code:

Code: [Select]

    LD      BC,(SCRL_CNT) ; Get number of pixels to scroll
ROW_scrl:
    ; Blit screen
    LD      HL,0100H     ; blit command
    CALL    send_gpu
    ; Use VWAIT to delay the scrolling
    LD      HL,0781H     ; Insert wait for 1 frame
    CALL    send_gpu
    DEC     BC           ; DECrement line counter
    LD      A,B
    OR      C            ; Is it zero?
    JP      NZ,ROW_scrl  ; Loop if not zero
    ; End of scroll routine

So I'm blitting the screen, then calling VWAIT.  I'm not setting hw_position as it defaults to zero, so should provide the smallest delay before the next command is executed if I understand it correctly?

[BrianHG]

Remember, if this is 1 scroll per frame being displayed, then all you can do is keep the 1 frame delay, but, jump vertically 2 lines in a single blit instead of one.

The the wait command slows down the scroll by more than 2x compared to no wait command, then the Z80 is issuing more blits than in 1/60th of a second.  There is no reason to force additional 1 line blits, just jump 2 lines in a blit and the animation will be smooth, bu double speed.

[BrianHG]

Yay, after a ton of work, I have enough of my DDR3 controller working to drive Micron Memory's DDR3 Verilog simulation model located here: https://www.micron.com/products/dram/ddr3-sdram/part-catalog/mt41j64m16tw-093  (Yes, the model supports all of Micron's DDR3's from 1gb to 8gb, x4, x8, x16 ICs at all frequencies.)

Yay, it finally compiles merged with my controller.
Yay, it reports the controls I send to the DDR3 ram bus.

Boo, now I need to clear up all the tiny violations.  (Well, the controller wasn't complete yet anyways, but the logging of an official manufacturers timing model was crucial for proper debugging...)

It will take a few more days to finish up and get it working on hardware.

[asmi]

This is exactly why I prefer using Micron parts for my memory needs. Good simulation model goes a long way in making controller design a much more pleasant experience.

[SiliconWizard]

I wasn't aware Micron had HDL simulation models. That's great. Do you guys know of any other vendor that does?

[asmi]

I wasn't aware Micron had HDL simulation models. That's great. Do you guys know of any other vendor that does?

Cypress provides models for their HyperRAM devices, I've seen some models from ISSI too. So it's not exactly unprecedented, but still I think Micron's models are the best.
They also provide IBIS models for board level signal integrity simulations, which is also very helpful.

[BrianHG]

I wasn't aware Micron had HDL simulation models. That's great. Do you guys know of any other vendor that does?

And stupid me, I created a module called : BrianHG_DDR3_GEN_tCK.sv
Which synthesizes all the data sheet's timing t## clock cycles based on ram chip selection in one of the main parameters.  However, Micron's own model Verilog code also has these 4 source codes:
1024Mb_ddr3_parameters.vh
2048Mb_ddr3_parameters.vh
4096Mb_ddr3_parameters.vh
8192Mb_ddr3_parameters.vh
Which almost does the same thing.  Though, mine 1 for all ram sizes including 512MB DDR3, and is also synthesizes the MRS MR# registers based on a few inputs to select the function state of the memory.  Mircon's ddr3.v verifies that these have been setup properly when I run the MRS commands.  Example:

Code: [Select]

#
#  Note : Cyclone IV E PLL locked to incoming clock
# Time: 2670000.0 ps  Instance: BrianHG_DDR3_PHY_SEQ_tb.DUT_DDR3_PLL.genblk3.HPLL1.cycloneiii_pll.pll3
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.reset at time 2690000.0 ps WARNING: 200 us is required before RST_N goes inactive.
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.reset: at time 2690000.0 ps ERROR: CKE must be inactive when RST_N goes inactive.
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.reset: at time 2690000.0 ps ERROR: CKE must be maintained inactive for 10 ns before RST_N goes inactive.
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task at time 2691000.0 ps WARNING: 500 us is required after RST_N goes inactive before CKE goes active.
#
#
#     MR0 Settings:
#     M[12]      - Precharge PD                 = 1     = DLL On.
#     M[11:9]    - Write Recovery               = 1     = 5.
#     M[8]       - DLL Reset                    = 0     = No.
#     M[6,5,4,2] - CAS# Latency                 = 001,0 = 5.
#     M[3]       - BT Read Burst Type           = 0     = Sequential (nibble).
#     M[1:0]     - BL Burst Length              = 00    = Fixed BL8.
#
#
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3213000.0 ps INFO: Load Mode 0
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3213000.0 ps INFO: Load Mode 0 Burst Length =  8
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3213000.0 ps INFO: Load Mode 0 Burst Order = Sequential
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3213000.0 ps INFO: Load Mode 0 CAS Latency =           5
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3213000.0 ps INFO: Load Mode 0 DLL Reset = Normal
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3213000.0 ps INFO: Load Mode 0 Write Recovery =           5
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3213000.0 ps INFO: Load Mode 0 Power Down Mode = DLL on
#
#
#     MR1 Settings:
#     M[12]      - Q Off                        = 0     = Enabled.
#     M[11]      - TDQS                         = 0     = Disabled.
#     M[9,6,2]   - Rtt                          = 0,1,0 = RZQ/2  (120 Ohm [NOM]) |  RZQ/2  (120 Ohm [NOM])
#     M[7]       - Write Levelization           = 0     = Disable (normal).
#     M[4:3]     - Additive Latency (AL)        = 00    = Disabled (AL = 0).
#     M[5,1]     - Output Drive Strength        = 0,0   = RZQ/6  (40 Ohm [NOM]).
#     M[0]       - Dll Enabke                   = 0     = Enable (normal).
#
#
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3239000.0 ps INFO: Load Mode 1
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3239000.0 ps INFO: Load Mode 1 DLL Enable = Enabled
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3239000.0 ps INFO: Load Mode 1 Output Drive Strength =          40 Ohm
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3239000.0 ps INFO: Load Mode 1 ODT Rtt =         120 Ohm
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3239000.0 ps INFO: Load Mode 1 Additive Latency = 0
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3239000.0 ps INFO: Load Mode 1 Write Levelization = Disabled
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3239000.0 ps INFO: Load Mode 1 TDQS Enable = Disabled
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3239000.0 ps INFO: Load Mode 1 Qoff = Enabled
#
#
#     MR2 Settings:
#     M[10:9]    - Dynamic ODT (Rtt(WR))        = 2     = RZQ/2  (120 Ohm [NOM]).
#     M[7]       - Self Refresh Temperature     = 0     = Normal (0c to 85c).
#     M[5]       - Auto Self Refresh (Optional) = 0     = Disabled: Manual.
#     M[5:3]     - CAS Write Latency (CWL)      = 0     = 5 CK (tCK >= 2.5ns).
#
#
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3265000.0 ps INFO: Load Mode 2
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3265000.0 ps INFO: Load Mode 2 Partial Array Self Refresh = Bank 0-7
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3265000.0 ps INFO: Load Mode 2 CAS Write Latency =           5
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3265000.0 ps INFO: Load Mode 2 Auto Self Refresh = Disabled
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3265000.0 ps INFO: Load Mode 2 Self Refresh Temperature = Normal
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3265000.0 ps INFO: Load Mode 2 Dynamic ODT Rtt =         120 Ohm
#
#
#     MR3 Settings:
#     M[2]       - Multipurpose Register MPR    = 0     = Normal DRAM Operations.
#     M[1:0]     - MPR_RF                       = 0     = Predefined Pattern.
#
#
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3291000.0 ps INFO: Load Mode 3
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3291000.0 ps INFO: Load Mode 3 MultiPurpose Register Select = Pre-defined pattern
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3291000.0 ps INFO: Load Mode 3 MultiPurpose Register Enable = Disabled
# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3355000.0 ps INFO: Refresh 
#
# End of command source ASCII file 'DDR3_SEQ_CMD_script.txt'.
#   79 lines processed.
#
# ** Note: $stop    : BrianHG_DDR3_PHY_SEQ_tb.sv(275)
#    Time: 3850 ns  Iteration: 1  Instance: /BrianHG_DDR3_PHY_SEQ_tb


The nicely spaced MR descriptions & settings are executed and sent out to the DDR3 bus by my code and reverse decoded by my code while the ugly:

Code: [Select]

# BrianHG_DDR3_PHY_SEQ_tb.sdramddr3_0.cmd_task: at time 3355000.0 ps INFO: *******

Is what the Micron ddr3.v model is reporting how a DDR3 ram chip is functioning.  As you can see at the top, the errors say I need to clean up my power-up and reset sequence.

[nockieboy]

In other news, just published a short video demonstrating a bouncing ball.  This draws an ellipse for the ball multiple times per frame, I can vary the size of the ball on the fly (not shown in video as I don't have three arms!)

I'm trying to get my head around the VWAIT command.  It's flickery at the moment (specially with bigger balls, no pun intended) and VWAIT causes the ball to disappear as it appears the Z80 is sending multiple position updates on the ball in the time VWAIT is... waiting.. causing the blanking draw to not keep up with the ball draw and artefacts to appear.

Anyway, here's the demo:



Next on my to-do list is sharpen the collision detection at the screen edges to use the ball width instead of the ball centre, or squish the ball on impact.  Might do a bit of both.

[BrianHG]

Cool...

In other news, just published a short video demonstrating a bouncing ball.  This draws an ellipse for the ball multiple times per frame, I can vary the size of the ball on the fly (not shown in video as I don't have three arms!)

I'm trying to get my head around the VWAIT command.  It's flickery at the moment (specially with bigger balls, no pun intended) and VWAIT causes the ball to disappear as it appears the Z80 is sending multiple position updates on the ball in the time VWAIT is... waiting.. causing the blanking draw to not keep up with the ball draw and artefacts to appear.

Anyway, here's the demo.

Next on my to-do list is sharpen the collision detection at the screen edges to use the ball width instead of the ball centre, or squish the ball on impact.  Might do a bit of both.

Change the position of the VWAIT command to the begining or end of all the drawing.
Also, you can change the horizontal line where the VWAIT happens at.  Say make it on line 200 of the display instead of line 0.

Also, try {erase old ball, draw new ball, vwait}...

[SiliconWizard]

Yes, as it is, there is a lot of "ghosting", to the point of the bouncing shape not really being recognizable.

[BrianHG]

I'm trying to get my head around the VWAIT command.  It's flickery at the moment (specially with bigger balls, no pun intended) and VWAIT causes the ball to disappear as it appears the Z80 is sending multiple position updates on the ball in the time VWAIT is... waiting.. causing the blanking draw to not keep up with the ball draw and artefacts to appear.

Are you monitoring the 'CMD FIFO FULL' flag before you send new commands.  With the VWAIT, the Z80 will easily out-run the animation speed and commands will get lost in the fifo as you send more draw commands than what can be executed.

Remember, with ~512 instruction FIFO pipe, everything you have done up until now has never out-paced the geometry unit, so you could essentially ignore the CMD FIFO full flag and get away with it.  Even with the smooth scrolling text using the VWAIT, you are only sending around 40 commands per carriage return, so you would have to do over 50 carriage returns instantly to overflow the geometry input command fifo.

When animating, your Z80 is piping around 40 commands per ball erase/re-render move.  The Z80 will overflow the input command fifo by the second of third frame beginning to mess up the drawing as commands get dropped since the VWAIT command literally pauses all subsequent draw commands until the specified line on the specified frame.

[nockieboy]

Cool...

In other news, just published a short video demonstrating a bouncing ball.  This draws an ellipse for the ball multiple times per frame, I can vary the size of the ball on the fly (not shown in video as I don't have three arms!)

I'm trying to get my head around the VWAIT command.  It's flickery at the moment (specially with bigger balls, no pun intended) and VWAIT causes the ball to disappear as it appears the Z80 is sending multiple position updates on the ball in the time VWAIT is... waiting.. causing the blanking draw to not keep up with the ball draw and artefacts to appear.

Anyway, here's the demo.

Next on my to-do list is sharpen the collision detection at the screen edges to use the ball width instead of the ball centre, or squish the ball on impact.  Might do a bit of both.

Change the position of the VWAIT command to the begining or end of all the drawing.
Also, you can change the horizontal line where the VWAIT happens at.  Say make it on line 200 of the display instead of line 0.

Also, try {erase old ball, draw new ball, vwait}...

It'll be because I'm not monitoring the FIFO state.  I haven't had long to put this together, so there's a lot more I can do.  Have some time today, so will see about adding FIFO checks.  A quick glance at my GPU manual seems to indicate there's no way to get the status of the FIFO though, so have tweaked the Z80_bridge to provide that info on an IO request.

I didn't mention previously, but I can slow down or speed up the ball as well - when it goes over a certain speed, all the artefacts are appearing.  This is clearly the speed at which the FIFO is getting overrun.  Am just building a new FPGA core with the updated z80_bridge so I can get the FIFO status.

[nockieboy]

Would it be useful to know if the GPU is waiting for the next frame in a VWAIT state as well?

In any case, it appears I've not done the scFIFO full check properly in the GPU.  Still getting artefacts when I speed the ball up as commands are dropped from the buffer.

Obligatory video showing FIFO buffer overrun as the ball speeds up.

Every time I send a command to the GPU, the Z80 enters a loop waiting for the scFIFO buffer 'nearly full' flag to be zero before sending the command.

In the z80_bridge, I've added/amended these lines in the appropriate places:

Code: [Select]

parameter int FIFO_STAT = 248;      // IO address for GPU FIFO status on bit 0 - remaining bits free for other data

assign port_in_range       = ((Z80_addr_r[7:0] >= IO_DATA[7:0]) && (Z80_addr_r[7:0] <= FIFO_STAT[7:0])) ; // You are better off reserving a range of ports

if ( z80_read_port_1s && Z80_addr_r[7:0] == FIFO_STAT[7:0] ) begin   // Read_port 1 clock & GPU status
   
    Z80_rData  <= GEO_STAT_RD ;
     
end
It looks as though the status isn't being reported properly as the FIFO buffer is still getting overrun at higher speeds.

[dolbeau]

There are a couple open-source boards with ECP5 FPGAs though, and at least one of them actually has a DDR3 memory chip. (The OrangeCrab board.) I haven't looked at it much so far, I'll be curious to see if there are example projects using this memory, and if so, how they managed to control it.

LiteX support the OrangeCrab, there's a platform file for it with DDR3 support. The LiteX memory controller litedram has a PHY component specific to the ECP5. There's other boards with ECP5 and DDR3 that are supported (TrellisBoard, Versa).

[BrianHG]

Would it be useful to know if the GPU is waiting for the next frame in a VWAIT state as well?

In any case, it appears I've not done the scFIFO full check properly in the GPU.  Still getting artefacts when I speed the ball up as commands are dropped from the buffer.

Obligatory video showing FIFO buffer overrun as the ball speeds up.

Every time I send a command to the GPU, the Z80 enters a loop waiting for the scFIFO buffer 'nearly full' flag to be zero before sending the command.

In the z80_bridge, I've added/amended these lines in the appropriate places:

Code: [Select]

parameter int FIFO_STAT = 248;      // IO address for GPU FIFO status on bit 0 - remaining bits free for other data

assign port_in_range       = ((Z80_addr_r[7:0] >= IO_DATA[7:0]) && (Z80_addr_r[7:0] <= FIFO_STAT[7:0])) ; // You are better off reserving a range of ports

if ( z80_read_port_1s && Z80_addr_r[7:0] == FIFO_STAT[7:0] ) begin   // Read_port 1 clock & GPU status
   
    Z80_rData  <= GEO_STAT_RD ;
     
end
It looks as though the status isn't being reported properly as the FIFO buffer is still getting overrun at higher speeds.

Make the addition in the attached block diagram.
Bit 0 will still be the GEO FIFO Star, but, bits 1 through 7 will be a frame counter.  You should be able to see it counting once per frame.  If so, then I need to check the FIFO status flag, maybe it is not wired or setup properly.