Members 
Search 
Help 
Register 
Login 
Home Show: Today's Messages :: Show Polls :: Message Navigator
|
   |
| PC Engine Seek Time data [message #5690] | Sat, 20 October 2018 01:32 | |||
| ||||
|
I have noticed several games where seek times affect enjoyment (and beyond these, it may even contribute to emulation effectiveness). So I ran a series of tests. seektest2.zip contains the HuC program I used to run on a real TurboDuo for taking the measurements. Enter a starting point and an offset, and it takes 10 measurement samples. I ran a series of real-machine measurements, included in the seek_analysis.xlsx attachment. These include: - from near start of disc, in the forward direction (tab 1) - from near end of disc, forward (tab 2) - from near start of disc, backward (tab 3) - from near end of disc, backward (tab 4) The good news is that the times aren't really dependent on direction or start location, so a simpler model can be created. Currently, line 1928 of scsicd.cpp is the only adjustment to seek time, and it is both (a) scalar, and (b) limited to data fetches. CD Audio seek delays are not currently treated in Mednafen. If somebody can implement these suggested changes, it would be very helpful. While the following model isn't perfect, and doesn't try to push the limits of seek speed, it's a pretty close, simple model. Note that there is significant variance between samples, so the model covers normal(ish) values for all seeks. It also takes advantage of a few areas of apparent linearity in the readings. 1) I suggest that the model use 18 VSYNCs as the minimum seek time, in order to make Double Dragon run. Strictly speaking, this is slower than real hardware by about 8 VSYNCs on short reads, but I doubt that could break anything, so cost/benefit is probably appropriate. 2) Any seek between 0x00 and 0x400 sectors should use the minimum seek time of 18 VSYNCs 3) Between 0x400 and 0x800 sectors, an additional 3 VSYNCs is needed (pro-rata, this means 341 sectors of seek (0x155) per VSYNC of time) 4) Between 0x800 and 0x4000 sectors, an additional 21 VSYNCs are needed (pro-rata, 3 VSYNCS per 0x800 sectors of seek, or 682 sectors of seek (0x2AA) per VSYNC of time) 5) Between 0x4000 and 0x10000 sectors, an additional 36 VSYNCs are needed (pro-rata, 3 VSYNCs per 0x1000 sectors, or 1365 sectors of seek (0x555) per VSYNC of time) 6) Beyond 0x10000 sectors, 1 VSYNC of time per 4096 (0x1000) sectors of seek is needed The following games (at least) will be improved: - Double Dragon II, press run @ start screen and ADPCM will be cut off 0x0C seek (from sector 0x135A to 0x1366): Model would give 18 VSYNC (current = 3) (needs at least 18 VSYNC to function properly) -> OK - Downtown Nekketsu Monogatari, set text to fast, enter/exit bookstore quickly, and ADPCM will keep speaking beyond proper message 0x5A seek (from sector 0xBBA to 0xC14): Model would give 18 VSYNCs (current = 3) (needs at least 7 VSYNC to function properly) -> OK - Super Darius, press run @ start screen and audio will play over top of ADPCM 0x1BAE seek (from 0xE92 to 0x2A40) Model would give 29 VSYNC (current = 3) (needs 27 VSYNC for no overlap; 35 sounds better) -> OK, but perhaps a couple more would be better - Mugen Senshi Valis, initial cinema, after entering schoolyard, video/audio become desynced 0x2DBE1 seek (from 0x801 to 0x2E3E2): Model would give 108 VSYNC (current = 0, as this seek is associated with an audio command) (needs as close to 104 as possible) -> OK, but perhaps a couple less would be better Please adjust the model to suit your tastes; I am just providing one suggestion. Based on 
Attachment: seektest2.zip(Size: 1.45MB, Downloaded 174 time(s)) 
Attachment: seek_analysis.xlsx(Size: 18.39KB, Downloaded 161 time(s)) | ||||
| ||||
| |
| Previous Topic: | Debugging features |
| Next Topic: | OpenBSD audio driver |
]