Ok i see that the M1 cycle is a halve clockpuls shorter then M2, M3 and M4 so that is why the insert the wait on M1. I don't have a timing problem with memory but i will insert the M1 wait cycle and test if that solves me I/O (vdp) problem. If not i still need to know if they also insert a wait on de VDP I/O. I will test this evening and get back to you
I have tested the M1 delay only, annd that seems to be the solution. I will make a small pcb for it and the mapper problem and build it on the PCB somewhere
Thanks for all your help
I know that on the TMS9918 the worstcase scenario is supposed to need 29 t-states wait time between VRAM access, but I'm not sure where the start counting this time.
I supposed that if both access instruction use the same t-states cost, it's simple because the needed wait time is just 29 minus the instruction duration.
For example:
OUT (n),A ; 12 t-states
; wait 17 t-states
INT A,(n) ; 12 t-states
But what if both access instructions don't have the same duration?
OUT (C),A ; 14 t-states
; wait for?
INT A,(n) ; 12 t-states
; wait for?
OUT (C),A ; 14 t-states
Actual I/O operation occurs in the last M-cycle of the instruction (the last few T-cycles). So, count from the end of the instruction to the end of the next.
I discussed this with Calindro (creator of Emulicious) and with his information, I established the precise timing of VDP I/O operation for each instruction.
Here is a summary table.
The vertical bar represents the VDP I/O timing.
// Instruction TS I/O
//-------------------------------------
// in a,(n) / out (n),a 12 9|3
// in a,(c) / out (c),a 14 11|3
// outi / outd 18 15|3
// ini / ind 18 12|6
// otir / otdr 23 15|8
// 18 15|3
// inir / indr 23 12|11
// 18 12|6
