Difference between revisions of "Talk:Master System emulators"
(→TwoMBit is not cycle accurate: new section) |
DylwinTFTW (talk | contribs) (→Where's Exodus?: new section) |
||
Line 12: | Line 12: | ||
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) | 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) | ||
+ | |||
+ | == Where's Exodus? == | ||
+ | |||
+ | Why isn't Exodus on this page? |
Revision as of 03:26, 30 June 2019
TwoMBit is not cycle accurate
It claims to be, but most likely predates the latest VDP discoveries. In particular:
See the documentation 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. — Tommy (talk) 22:01, 2 March 2019 (EST)
Where's Exodus?
Why isn't Exodus on this page?