User avatar
pixeljunkie
Posts: 12
Joined: 11 May 2018, 20:59

Re: CDROM Seek time

16 Aug 2019, 20:10

Following this closely as it's a feature I heavily want.

dshadoff
Posts: 21
Joined: 18 Jun 2019, 02:20

Re: CDROM Seek time

17 Aug 2019, 15:02

neodev wrote:
04 Jul 2019, 17:26
Yes, I mean that the seek time is currently enabled just for a few games, instead of being an user accessible option. Seek time is calculated from the current sector to the destination sector.
The calculation should be a little more complicated than that, but if implemented properly you wouldn't need to try to recognize any games.

seek time = head movement time + settling time + rotation time to destination sector

For purpose of simplicity, the spiral of the CD can be considered as a number of tracks during movement. At the inner edge there are roughly 8 sectors per "track", and at the outer edge there are a lot more (should be in my public notes; I recall it was around 20).

For head movement time, you first need to calculate distance; you can use a lookup table with zones (i.e. "8 sector per track zone starts here and ends here"). This helps calculate how many tracks are traversed, based on sectors to travel and start/end disc position.

Next, the head movement is not linear, but I provided a bunch of measurements in my notes. Calculations don't need to be exact, but should at least be close; there are only a few games sensitive to minimum times, and the original hardware also had variances.

For short distances, head rotation is the biggest factor. Moving 2 sectors will definitely incur a penalty of at least one rotation which is minimum 106ms (minimum 8 sectors, at 75 sectors pre second regular playback rate), but depends on where the head is on the disc, since rotation becomes slower toward the outer edge.

The head settling time usually doesn't come into play, but is a random element which has a greater effect on shorter-distance seeks. My measurements randomly had additional 1-rotation penalties, as the head occasionally needed to refocus.

I did not try to calculate the rotational position of the disc at the arrival of the head (in order to identify how much of a rotation is required after the head settles). It's a very difficult calculation, and probably won't be correct anyway, as this would depend on the exact disc master. Instead, a full rotation should be used when the movement is close, and a partial rotation (>= 50%) should be used for distant movements. But there should be no harm in keeping it 100% of a rotation.

User avatar
neodev
Posts: 297
Joined: 09 Apr 2018, 14:47

Re: CDROM Seek time

17 Aug 2019, 16:11

Yes, bit it doesn't need to be that accurate. it just doesn't need to be immediate. In megasd, there is a fixed term of around 120ms added every seek (it's 10 sector interrupts IIRC, and those happen 75 times per second) plus a variable amount based on the difference between the current and the destination sector. I think the maximum seek time is around 1.7 seconds. It seems to work pretty well.

dshadoff
Posts: 21
Joined: 18 Jun 2019, 02:20

Re: CDROM Seek time

17 Aug 2019, 21:42

You are both correct and not completely correct.

The truth lies in the nature of the problems which occur due to inaccurate seek times - and from my perspective, there are basically two types:

1) Insufficient seek time, causing a race condition in hardware or code.

The most common form of this is when the ADPCM is playing, and will play for a fixed period due to the amount of data in the buffer. During the play period, either (a) the CDORM directly loads data into the buffer (causing a change in pointers or data end, or overwriting unplayed data), or (b) the CDROM loads data into memory, which then enables the processor to do something similar to the above.

In all of these cases, you need to meet a "minimum" seek time appropriate to the situation, but those are different for each game. You could wait longer than necessary, but if you wait too long, eventually the feeling of gameplay could be impacted. You can afford to be a bit sloppy for these.

These games are small in number, but the effect is pronounced.


2) Inaccurate seek time, causing a visual de-synchronization.

These are situations where, for example, a sound played by CDROM and visual display driven by the processor need to be synchronized. The impact of a desynchronization affects the *atmosphere* rather than the gameplay. There are a very large number of games affected by this, and if the calculation is a little too short or too long, you will enter the "uncanny valley". As long as you calculate within about 20-50ms, you'll probably be OK. More than 100ms will lose the effect.

Many people these days have only ever played on emulators (which have never implemented seek time waits), and have simply never experienced a properly-synchronized track - so they attribute a low value to this synchronization. It's very much the same case as watching a dubbed movie... you can go along with it, but the impact couldn't possibly be the same depth as the original. One might need to see a properly-synched game in order to feel its value.

After Upergrafx implemented this properly, I was actually surprised that it was better-synched than the original machine, and the visual scenes really gained a lot more impact. I myself had also undervalued its significance.

Return to “Super SD System 3 General Discussion”