VG93 question — ZXNet «zx.spectrum»

From Vladimir Yudin To All 19 October 1997

Hello All!

In some VG93 controller commands, bit 2 is responsible for
the mode for checking the head position. What happens if
this check does not match the real track number with
the number in the track register? Is the search error bit turned on?

The description of the track read command contains a note about the fact that when it is executed, a loss of synchronization occurs.
What are we talking about? Does the controller have time to count at least part of the track? As a result, the command ends with a loss
data error?

Best regards
┬ ┬┌┐┬┐ ┐┬┬
╨╜╨╙╜╨╙ ╨ ╨

From Evgeny Milun To All 21 October 1997

Hello Vladimir !

Sunday October 19 1997 20:16, Vladimir Yudin ─── All:

[.....]
VY> The description of the track reading command contains a note about
VY> that when it is executed, a loss of synchronization occurs.
VY> What are we talking about? Does the controller have time to read at least part of the
VY> track? As a result, the command ends with the error of losing
VY> data?
I don’t remember exactly now, but there is something connected with zero bytes
(i.e. = 0), it is when they are read that something happens. If the memory does not change, then the VGshka in this case does not correctly calculate the number of incoming data pulses...
The result of all this is that the data of the track image
is read, but starting from some byte everything is shifted by one or
several bits (this is a bit array) to one or another side.

Good luck! Evgeny.

■ The night is shorter than the day... The day will kill me... The world of illusions burns down in it. (C) Aria.

From Vyacheslav Mednonogov To All 21 October 1997

Synchronization fails at the end of the 'data block' of sectors, because When recording
there is always a deviation in the disk rotation speed and new sector information
cannot be absolutely accurately superimposed on top of the old one. In addition, control
bytes (start of header, start of data block, etc.) are encoded 'incorrectly' from the MFM point of view and when reading them, something different is obtained.

That is. reliable when 'reading a track' will be the information written before the
first sector (imho).

Max Romanov came up with a protection where the read track command is used to
determine the length of the track (this was recently discussed here). But here, according to him, the deviation is ~20 bytes.

Warm greetings, Slava!

From Alex Letaev To All 22 October 1997

Hello Vyacheslav Mednonogov! In a message of 21 Oct 97 Vyacheslav Mednonogov wrote to Vladimir Yudin:

VM> That is. When 'reading a track', the information recorded by
VM> before the first sector will be reliable (imho).

Nope. The information will be reliable until a bad
sequence of 9 bits is encountered, in which the controller loses synchronization.
The cause of this bug in TR-DOS was determined by Titus, and I lost the specific values
of these bits. If there is no such sequence on the track, then the controller
will read the entire track without losing information.

Regards, Alex from FFC COMPUTERS.

From Alex Letaev To All 25 October 1997

Hello Vyacheslav Mednonogov! In a message of 24 Oct 97 Vyacheslav Mednonogov wrote to me:

VM> That is, synchronization is “cut off” at the beginning of address markers (which
VM> are at the beginning of the sector header and at the beginning of the sector data block), where
VM> there are “incorrectly” encoded _marker bytes_.

Interesting information, it’s a pity I haven’t seen it before. Although now there is a reason to
experiment again.

From Nicolaus Mezencef To All 25 October 1997

Nothing of the kind, synchronization is not cut off anywhere, the read
sector command works normally, therefore, the track read command also
works normally, only incomplete MFM decoding is carried out.
So Titus is right.
If you paid attention, then on a spin-up disk the distortion
of information always occurs in the same place, accurate to
bits, and on address marks (AA) synchronization is restored again.
This suggests that this is not a “glitch” of the 93rd, but a feature of the work of the track reading command
, which, in turn, is stated in the technical documentation.

VM> That is. The first desynchronization when reading a track will occur at the beginning
VM> of the first sector, and then at the beginning of other sectors. It also occurs
VM> in the places where the sector data ends (if the sector has been overwritten at least once
VM>), in “floating bits”, in places of scratches and other
VM> defects ;)

In the case of “defects” it is simply not readable, and the performance characteristics of the VG93 have nothing to do with it.

Nicolaus.