VG93 question

Thursday November 06 1997 01:32, Vyacheslav Mednonogov ─── Nicolaus Mezencef:

VM>>> That is. the contents of the sectors will still be in readable form after
VM>>> #A1,#F8? I won’t argue (I’ve never tried it myself). However, people who know
VM>>> say the opposite...

NM>> But I tried many times,

VM> There is no reason not to trust... Here SN sent an article from the latest Review.
VM> It seems that you and the author sing in one voice :)
VM> === Cut ===
[.....]

VM> 1. Read the entire command of the controller
VM> controller #E0 the entire
VM> track in RAM, through the
VM> subroutine TRDOS #3FDB <#3FE5> (give the
VM> command 4-5 times to be sure).
Extra. The image will either be read the first time, or never... In addition,
what is the point of repetitions? All the same, they all fall at the same addresses.
VM> 2. Using the IAM tags, determine:
VM> how many sectors are on the track,
As far as I remember, this cannot be _determined_, it can only be _counted_.
VM> the length of the sectors and the NUMBERS of sectors-
VM>. Save the received data somewhere.
VM> 3. Programmatically analyze
VM> and change the read dump:
VM> a) if the byte is LESS than #F4 -
VM> leave unchanged;
VM> b) if the byte is EQUAL to #A1,instead of
VM> enter #F5 and enter by
VM> adrs-1 and adrs-2 from this place
VM> the same if by adrs+1 code
VM> #FE or #FB;
VM> c) if byte Equal to #FE - leave-
VM>;
VM> d) if byte Equal to #FB - leave-
VM> turn;
VM> e) instead of the SIXTH byte (the first-
VM> first bytes from #A1; #FE) PUT
VM> byte #F7 (there should be 2
VM> checksum bytes here);
Well, yeah. But how will he deal with synchronization disruption?
VM> f) then you should simply skip the data area. The length of the
VM> area depends on the type of sector
VM> and the FIRST BYTE AFTER the
VM> DATA area MUST be replaced by by
VM> volume #F7 (2 bytes of the
VM> checksum);
And the data itself, it means, is not changing?
VM> g) Go to step "a)" and repeat-
VM> until the entire track dump is finished.
VM> 4. Now that the dump of the
VM> format is ready, write it to
I doubt that it is ready. And that in general the resulting track image corresponds to the original one, both in size, there and in content.
VM> the corresponding track of another
VM> DISK with the command #F4 through the sub-
VM> program TRDOS #3FC0 <#3FCA>
VM> (repeat recording 4-5 times for
VM>fidelity).
Well, well, well. “To be sure”... If it doesn’t help, increase the number of attempts to, say, 10. Then up to 20, etc.
VM> - Analyze which
VM> sector numbers are entered in the
VM> format and their number.
Why “analyze”? The same information was “saved” ?
VM> - Read the corresponding sectors from the copied disk
VM> (you can
VM> even with the TRDOS function, but only
VM> for ONE sector) into the allocated
VM> buffer in RAM.
VM> - Write the corresponding
VM> sectors from the RAM buffer to the disk with
VM> our format.
VM> - Repeat everything again for the remaining
VM> tracks.
But these are reasonable words. But, IMHO, nothing new...

VM> It is advisable to configure this program for TWO disk-
VM> drives, but it is possible for one (then-
VM> and after 3 minutes your hand will hurt
VM> changing disks in the disk-
VM>).
VM> === Cut ===
VM> By the way, if something is wrong here - tell me.
IMHO, everything is wrong here. These are more “theoretical calculations” than a really proven sequence of actions.

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.

It will work as a first approximation, but it is better to determine sectors
using the command to read the sector address in order to avoid stepping on
the rake from distortion, and the person, it seems, did not think that
there could be bytes F5-F7 in the sector data.
And this method is full of such things, you need to do an analyzer
and not a dumb track copier.

Nicolaus.

EM> And the data itself, it means, is not changing?

Yes, it would be nice to reset the contents of the sector, otherwise #f5-F7
will meet and spoil the raspberries :))

EM> IMHO, everything is wrong here. These are more “theoretical calculations” than a real
EM> proven sequence of actions.

Perhaps, however, the most interesting is how
“reading the track” in VG93 actually behaves...

With warm greetings, Slava!

VM> do “track reading” in VG93 if it would do it incorrectly.

By the way, they didn’t think of doing naked MFM reading and MFM writing.
Bad.

Good Luck...

... Never kiss anything that doesn't have lips.

VM> N.Mezencev claims that when “reading a track” the controller automatically
VM> fights against synchronization violations. In the absence of contrary information
VM> you have to believe :)
Yeah, but all this is only after the synchro of the A1 series (it seems), as a result
you can only guarantee the reliability of the contents of the sector and the six-seven
bytes behind it. They have checked it more than once.
VM> Although, on the other hand, why would it even be possible to “read a track” in
VM> VG93 if it did it incorrectly.
I don’t remember exactly, but there are persistent rumors that this is not a defect in the VG, but in the
Beta Disk.
[.....]

11 Nov 97 23:16, Nicolaus Mezencef reported by Vyacheslav Mednonogov about {VG93
question}:

VM>> By the way, if something is wrong here, tell me.
NM> a rake from distortions, and the person did not seem to think that
NM> there could be bytes in the sector data F5-F7.

Exactly, although, theoretically, because of this, the sectors will have a
CRC Error during formatting, but this will be corrected when they are further recorded (he did not forget about this)

NM> As a first approximation, it will work, but it is better to determine the sectors
NM> with the command of reading the sector address in order to avoid stepping on

Or maybe there is something crammed between the sectors?

By the way, I found a phrase that confused people for many years - from the book
MOA+Rodionov:

“Reading track 11100е00.
...
Due to some hardware features of the Beta Disk, when this command is executed, the microcontroller loses data synchronization. Thus,
it is difficult to use the command.”

However, it is not said “impossible”, but “difficult” :))

C Warm greetings, Slava!

VM> Or maybe there’s something crammed between the sectors?
So anyway, the image won’t be accurate. Let's say I'm formatting on a drive with 297 rpm, you're reading at 303. Sure thing, the length of the images will be different between you and me (maybe by a byte or two, but it's different). Although
I have been experimenting with this for a long time, I might have forgotten something.

VM> By the way, I found a phrase that confused people for many years - from the book
VM> MOA+Rodionov:

VM> "Reading track 11100e00.
VM> ...
VM> Due to some hardware features of the Beta Disk when When executing
VM> this command, the microcontroller loses data synchronization.
VM> Thus, it is difficult to use the command."
VM> However, it is not said “impossible”, but “difficult” :))
So, IMHO, no one says “impossible to use _command_”. :)))
Personally, I say that it is impossible to copy “one to one” with its help.

Hi, Evgeny!

19 Nov 97, Evgeny Milun writes to Vyacheslav Mednonogov:

EM> So anyway, the image will not be accurate. Let's say I
EM> format on a drive with 297 revolutions, you read at 303. That's it,
EM> bolt - the length of the images will be different between you and me (even if it's a byte or two, but
EM> it's different). Although, I have been experimenting with this for a long time, I could
EM> forget something.

Have you been stoned for an hour?
Actually, the number of bits on a track is a constant (on a single disc,
it’s over). And little depends on how fast it spins.
Well, the DRQ will twitch more often...

In general, you amaze me so much with your revelations that I’m already thinking about
giving up collecting HUMOR.FILTERED and starting collecting information for
a book about the Spectrum...

EM> So, IMHO, no one says “impossible to use
EM> _team_". :))) Personally, I say that it is impossible to copy
EM> “one to one” with it.

It depends on the straightness of the hands and the quality of the flops and controller.

With best wishes - Andrey Khristov (ha...@robin.alt.ru)

[Team Horse Aviation] [Team beer, girls & sofa]
[Team For Garage] [Team Khasan border guards]

AK> Haven't you been stoned for an hour?
Hic... hic... hic... what... hic... looks... like... looks like... ? iiiiiiiiiikkkkkk.
;))
AK> Actually, the number of bits on a track is a constant (on a separate disk,
AK> it’s over).
Can you read? Can you write? Can you think? Read again what we're talking about - the _image_ of the disk read by the track read command. Moreover,
a command about which they say “due to an error, a synchronization failure occurs”
AK> And little depends on how fast it spins.
AK> Well, the DRQ will twitch more often...
Well, just think, one or two extra synchronization pulses will appear, well, decrease...
What difference, right? And why are all the defenses with such a large overlap analyzing this image? They're probably delusional.

AK> In general, you amaze me so much with your revelations that I'm already
AK> thinking about giving up collecting HUMOR.FILTERED and starting collecting
AK> information for a book about the Spectrum...
Wow. Do you collect filtered stuff? What a coincidence, I’m reading the same thing.
:) And get busy with the book...

AK> Haven't you been stoned for an hour?
AK> Actually, the number of bits on a track is a constant (on a separate
AK> disk, of course). And little
AK> depends on how fast it spins. Well, DRQ will twitch more often...

I would add that the number of bytes on a track depends on how fast (at what quartz frequency) this track was recorded.

By the way, protection against Amiga is made on this basis (no, well, you can
copy, but it’s crazy slow ;))))

AK> It depends on the straightness of your hands and the quality of the flops and controller.

1:1 making a copy of a track is unrealistic on a ZX/PC. Iron won't allow it.

Good Luck...

... It's not hard to meet expenses, they're everywhere.

EM> diminish... What's the difference, really? And why do all the defenses with such a large overlap analyze this image? They are probably delusional.

Such protections are not reliable, because... copied easily.

Good Luck...

... SENILE.COM found . . . Out Of Memory. . .