Very sad...I can propose to repeat the reading two or three times before setting R#18
in f,(c) ; db EDh,70h ; read data port
in f,(c) ; db EDh,70h ; read data port
in f,(c) ; db EDh,70h ; read data port
out (0x9B),a
There could be a byte in a buffer preventing actual vram acces
Very sad...I can propose to repeat the reading two or three times before setting R#18
in f,(c) ; db EDh,70h ; read data port
in f,(c) ; db EDh,70h ; read data port
in f,(c) ; db EDh,70h ; read data port
out (0x9B),a
There could be a byte in a buffer preventing actual vram acces
I will do that and report results.
EDIT: I tried with 2 & 3 of in (c) and results are very similar to the singe read.
Thanks again for testing
I do not have other proposals... Unless one returns to the idea of testing the HR flag to try to change the R18 while the VDP has no access to the VRAM (between cycle 98 and 140 in the VDP timeline).
I do not have other proposals... Unless one returns to the idea of testing the HR flag to try to change the R18 while the VDP has no access to the VRAM (between cycle 98 and 140 in the VDP timeline).
It does appear that this approach do not work. I agree with ARTRAG, no other ideas and i think even the HR trick is something hard to achieve because of tight timing constraints
I will try to provide a test based on HR sync
The problem is that the minimum step in cycles for the delay is 5 z80 cycles which correspond to 30 vdp ticks
Aiming to a window of about 40 cycles (98-144), become essential to know when during the out instruction (14x6 =84 vdp cycles) the register value changes...
I will try to provide a test based on HR sync
The problem is that the minimum step in cycles for the delay is 5 z80 cycles which correspond to 30 vdp ticks
Aiming to a window of about 40 cycles (98-144), become essential to know when during the out instruction (14x6 =84 vdp cycles) the register value changes...
Long ago on ZX-Sepctrum we had a demo that was heavily relying on timing.
Since not all models were the same, we had few buttons to increase/decrease
delay by 1 Z80 cycle to synchronize demo on any clone system. Maybe we can
take a similar approach here.
If you can write the code, I can add ability to press let's say left/right to increase/decrease
delay and see the results instantly without need to recompile multiple versions.
Or we can have one button to have delay go from 0 to a certain number.
This is untested but it should do what we want to do. My computations on the number of vdp cycles are in the comments. Maybe Grauw could double check them. I expect that the R#18 is set at about 110 vdp cycles (198-88) in the timing diagram
ModifyR18: PROC di ld a,2 ; read S#2 out (0x99),a ld a,0x8f out (0x99),a ld a,18 + 128 ; write R#18 no auto increment out (0x99),a ld a,17 + 128 out (0x99),a ld bc,0x009B ld e,0FH Loop: ld a,b and e ld d,a reverse: equ $ cpl ; Lower Bound ; 88 vdp cycles rightborder+erase time ; 98 vdp cycles synchronize ; tot 186 vdp cycles = 31 z80 cycles ; Upper Bound ; 88 vdp cycles rightborder+erase time ; 144 vdp cycles synchronize ; tot 232 vdp cycles = 38 z80 cycles waitHR: in a,(0x99) ; not included and 32 ; 8 z80 - 48 vdp cycles jp z,waitHR ; 11 z80 - 66 vdp cycles out (c),d ; 14 z80 - 84 vdp cycles ;tot 33 z80 - 198 vdp cycles djnz Loop xor a ; read S#0 out (0x99),a ld a,0x8f ei out (0x99),a ret ENDP
I compiled new version and tried delays between 31 and 38 Z80 cycles. It didn't produce any good results.
Same kind of corruption?