190
edits
Changes
Jump to navigation
Jump to search
→TwoMBit is not cycle accurate: new section
== TwoMBit is not cycle accurate ==
It claims to be, but most likely predates the latest VDP discoveries. In particular:
See the documentation [http://www.smspower.org/forums/16485-GenesisMode4VRAMTiming|provided by Mask of Destiny here]. The VDP has a certain number of 'external slots' per line — these are when it will permit a CPU-directed memory access to occur. The net timing cost for the CPU to put a byte into video memory is: (i) a fixed delay; plus (ii) the variable amount of time until the next external slot. It *is not a fixed amount*.
However, check out TwoMBit's VDP.cpp: the one-two of initDelay() and updateDelay(), initiated by write_port_BE(...), apply a fixed cost to memory accesses of the worst-case access time.
TwoMBit therefore does not accurately model the real hardware.
Any one deviation is sufficient to establish the point, but I note also just from a cursory glance that it doesn't calculate sprite overflow as the raster runs, so will set that flag at the wrong time.
For these reasons, I have demoted its table entry from 'cycle' accurate to 'very high' accuracy. — [[User:Tommy|Tommy]] ([[User talk:Tommy|talk]]) 22:01, 2 March 2019 (EST)
It claims to be, but most likely predates the latest VDP discoveries. In particular:
See the documentation [http://www.smspower.org/forums/16485-GenesisMode4VRAMTiming|provided by Mask of Destiny here]. The VDP has a certain number of 'external slots' per line — these are when it will permit a CPU-directed memory access to occur. The net timing cost for the CPU to put a byte into video memory is: (i) a fixed delay; plus (ii) the variable amount of time until the next external slot. It *is not a fixed amount*.
However, check out TwoMBit's VDP.cpp: the one-two of initDelay() and updateDelay(), initiated by write_port_BE(...), apply a fixed cost to memory accesses of the worst-case access time.
TwoMBit therefore does not accurately model the real hardware.
Any one deviation is sufficient to establish the point, but I note also just from a cursory glance that it doesn't calculate sprite overflow as the raster runs, so will set that flag at the wrong time.
For these reasons, I have demoted its table entry from 'cycle' accurate to 'very high' accuracy. — [[User:Tommy|Tommy]] ([[User talk:Tommy|talk]]) 22:01, 2 March 2019 (EST)
