Modified file from the official MAME binary are below

###############################################
#1 https://github.com/mamedev/mame/pull/10849/commits/83a6f1397e4638b001df42df42cbabb247a622eb

More accurate CV1000 Blitter timings
- Implement cv1000 blitter delay timing for Upload and Draw operations as described in my research here:  https://buffis.com/docs/CV1000_Blitter_Research_by_buffi.pdf . All timing data is analyzed by me.
- Remove epic12 "unsafe" Blitter mode. The delay introduced here doesn't really have much to do with how things behave on proper hardware, and trying to tune it doesn't make a lot of sense.
- Remove some old commented out lines in epic12.cpp which seem to not add much value.
- If EP1C_PRINT_BLITTER_DELAYS is set, print out when a Blitter delay triggers.
- Add documentation for 6 unhandled Blitter command offsets (see blitter_w). Thanks rtw for looking at these.
- Update some docs in cv1k.cpp

This is still not perfect, and further work is needed on slowdowns, especially on CPU waitstates. I think this is fairly accurate in terms of Blitter timings though.
###############################################
#2 https://github.com/mamedev/mame/pull/10849/commits/5944c4dce9169097c33d05141223e44adb659f28

Improve cv1000 Blitter delay logic
- Fix a off-by-one bug when setting dst_x_end and dst_y_end which caused destination writes to be one pixel too big
- Correct Blitter calculations to utilize both source and destination VRAM row counts
- Update VRAM overhead. After looking at it more carefully with logic analyzer, the read-to-read overhead is 6 CLK, not 5. Write-to-read is 11 CLK, not 10. Per-sprite overhead is 12 CLK.
- Keep track of when Blitter is idle (not drawing), since long sequences of clipped draws can cause the Blitter to not do any work, while remaining busy. This needs to be compensated for in the delays.
- Remove the edge case for "pixel widths need to be evenly divisable by 8". This is very rare, and while I think it's true, I would like to see more examples of it first.
- Pad draws to be on even 4-byte boundaries, since VRAM accesses are always 4 pixels at the time (to such addresses).

From inspecting the delays simulated here, things are getting very close to hardware behavior. It's still not 100% perfect though, and may have things I'm missing.

###############################################

Feel free to build yourself by forking: https://github.com/buffis/mamefork

Built with:
- make
- make SUBTARGET=misc IGNORE_GIT=1 SOURCES=src/mame/misc/cv1k.cpp -j 4

###############################################

More info at https://buffis.com/category/research/

Pull request to MAME: https://github.com/mamedev/mame/pull/10849