Re: New release 0.4.0 of opencbm (cbm4win/cbm4linux) [message #142371 is a reply to message #142368] |
Wed, 10 May 2006 20:28 |
Pete Rittwage
Messages: 444 Registered: March 2005
Karma: 0
|
Senior Member |
|
|
Dag Lem wrote:
> Wolfgang Moser <wnhp@d81.de.invalid> writes:
>
> [I wrote]
>
>>> 1/2 bit out of 10 bits amounts to 5%. 5% of 26 cycles amounts to 1.3
>>> cycles, i.e. a byte can be read in 24.7 cycles, in theory.
>>> So, spending 25 cycles on average in each iteration of a read loop
>>> seems pretty safe.
>>
>> This is an interesting point of view and an
>> interesting result, too.
>
>
> Note that this assumes the GCR scheme Commodore used. V-MAX used a
> different scheme of groups of four bytes instead of five (at least
> that's how I understand Harald Seeley's mention of "75% data, 25%
> clock" opposed to Commodore's "80% data, 20% clock).
>
> If V-MAX guarantees denser clocking (synchronization) than 10 bits, a
> V-MAX byte can be read even faster than 24.7 cycles. If my theory
> holds water, that is.
>
> Assuming 8 bits, we get a possible speedup of 6.25% (0.5/8*100%),
> i.e. a minimum time frame of 24.375 cycles (26*(1-0.0625)).
>
> However, are the V-MAX bytes really recorded at maximum speed (26
> cycles)?
>
> Harald Seeley mentions 32 cycles a few times, perhaps all V-MAX tracks
> are recorded at minimum speed? If this is the case, we have nothing to
> worry about. Pete: Can you clear this up?
Harald recorded his later disks that were completely his own DOS at
density 3 up to track 18, then the rest of the disk (usually up to track
37 or 38) at density 2. Most have very short syncs that are still
detectable through software, but a few tracks lack it completely. MNIB
ignores syncs and just reads straight GCR always, so we don't wait for
it or care, just like VMAX-DOS. This was one fix I did early on that
helped our imaging process.
Here is the output from a scan of the disk with my tools:
-------
pscan - Commodore G64 disk image scanner / comparator
(C) Pete Rittwage
Version 0.40 (Built May 8 2006 22:03:06)
file1: images\vmax\arkanoid[taito_1987](vmax3).nib
Loading GCR image [ooooooooooooooooooooooooooooooooooooooooo] loaded
disk id: 00
cosmetic disk id: V-
Scanning...
Track 1.0: 7681 (3) weak:2
Track 2.0: 7680 (3)
Track 3.0: 7681 (3)
Track 4.0: 7678 (3)
Track 5.0: 7681 (3)
Track 6.0: 7679 (3)
Track 7.0: 7681 (3)
Track 8.0: 7680 (3)
Track 9.0: 7681 (3)
Track 10.0: 7681 (3)
Track 11.0: 7681 (3)
Track 12.0: 7679 (3)
Track 13.0: 7679 (3)
Track 14.0: 7681 (3)
Track 15.0: 7678 (3) weak:2
Track 16.0: 7680 (3)
Track 17.0: 7681 (3) weak:2
Track 18.0: 7132 (2) weak:2
Track 19.0: 7416 (2) weak:8
Track 20.0: 7127 (2) weak:10
Track 21.0: 7119 (2) weak:9
Track 22.0: 7118 (2:NOSYNC) weak:9
Track 23.0: 7119 (2) weak:9
Track 24.0: 7118 (2) weak:9
Track 25.0: 7119 (2!=1?) weak:10
Track 26.0: 7118 (2:NOSYNC!=1?) weak:9
Track 27.0: 7119 (2!=1?) weak:8
Track 28.0: 7118 (2!=1?) weak:8
Track 29.0: 7119 (2!=1?) weak:9
Track 30.0: 7119 (2!=1?) weak:9
Track 31.0: 7119 (2!=0?) weak:9
Track 32.0: 7119 (2!=0?) weak:9
Track 33.0: 7119 (2!=0?) weak:8
Track 34.0: 7118 (2!=0?) weak:9
Track 35.0: 7119 (2!=0?) weak:9
Track 36.0: 7118 (2:NOSYNC!=0?) weak:9
Track 37.0: 7123 (2!=0?) weak:9
Track 38.0: 0
Track 39.0: 0
Track 40.0: 0
Track 41.0: 0
341 disk errors detected.
0 empty sectors detected.
177 bad/weak gcr bytes detected.
0 fat tracks detected.
0 rapidlok tracks detected.
----
You'll notice that a few later tracks say NOSYNC-- these tracks actually
don't have any sync at all, not even 8 bits of it. Similar to the
latter Vorpal, except in this case the track is all in the same framing
so we can detect a valid track cycle from the overlap. I believe that
Harald is using the 0x49 bytes as a marker in these for the duplicator,
since they must be aligned to this when remastering.
Track 19 appears very long. However, when analyzed, it is actually just
a very long sync mark followed by only a little data. As mentioned
before, we cannot accurately measure sync length. That means the track
really isn't this long- it's just slippage.
-
Pete Rittwage
C64 Preservation Project
http://c64preservation.com
|
|
|
Re: New release 0.4.0 of opencbm (cbm4win/cbm4linux) [message #142372 is a reply to message #142369] |
Thu, 11 May 2006 02:56 |
Wolfgang Moser
Messages: 632 Registered: July 2003
Karma: 0
|
Senior Member |
|
|
Hi Pete,
Pete Rittwage schrieb:
> In this case, Star Rank Boxing, we have:
>
> Track 16.0: 8024 (3) weak:230
> Track 17.0: 8023 (3) weak:234
4,000,000 * 60
RPM = ----------------- = 287,599
8,024 * 13 * 8
26 * 4,000,000 * 60
Cycles = --------------------------
8,024 * 13 * 8 * 303
= 24.678
Womo
|
|
|
Re: New release 0.4.0 of opencbm (cbm4win/cbm4linux) [message #142373 is a reply to message #142371] |
Thu, 11 May 2006 03:13 |
Wolfgang Moser
Messages: 632 Registered: July 2003
Karma: 0
|
Senior Member |
|
|
Hello Dag, Pete,
Pete Rittwage schrieb:
>
> Harald recorded his later disks that were completely his own DOS at
> density 3 up to track 18, then the rest of the disk (usually up to track
> 37 or 38) at density 2. Most have very short syncs that are still
> [...]
> Here is the output from a scan of the disk with my tools:
> [...]
from Pete's data, now let's do some calculations
for another speed zone.
> [...]
> Track 16.0: 7680 (3)
> Track 17.0: 7681 (3) weak:2
> Track 18.0: 7132 (2) weak:2
> Track 19.0: 7416 (2) weak:8
In speedzone 2 the divisor is 14 instead
of 13 and the "base" cycles are 28 instead
of 26:
4,000,000 * 60
RPM = ----------------- = 288.951
7,416 * 14 * 8
28 * 4,000,000 * 60
Cycles = --------------------------
7,416 * 14 * 8 * 303
= 26.702
> Track 19 appears very long. However, when analyzed, it is actually just
> a very long sync mark followed by only a little data. As mentioned
> before, we cannot accurately measure sync length. That means the track
> really isn't this long- it's just slippage.
Maybe. If we assume, it _would_ be that long,
it must have get written with ~288 rpm again.
From the cycles calculation we see one thing:
Instead of beeing read with the bitrate of
speed zone 2, this track maybe better gets
read with the speed zone value preset to
3 since the actual bitrate is much more near
to speed zone 3 setting than it is to the
2 setting... ?
If track 19 from above would actually have
been recorded with speedzone 3 bitrate
setting, what does this result to?
4,000,000 * 60
RPM = ----------------- = 311.177
7,416 * 13 * 8
(assuming a very slow spinning read drive
with 297rpm)
26 * 4,000,000 * 60
Cycles = --------------------------
7,416 * 13 * 8 * 297
= 27,241
Hmmmm, nevertheless a very ambiguous value.
Womo
PS: Pete, maybe your pscan utility may try to
estimate the rpm value the disk was recorded
at? Actually two rpm values should be printed
from the two next possible speed zone settings
that could have been used.
|
|
|
Re: New release 0.4.0 of opencbm (cbm4win/cbm4linux) [message #142374 is a reply to message #142373] |
Thu, 11 May 2006 20:13 |
Pete Rittwage
Messages: 444 Registered: March 2005
Karma: 0
|
Senior Member |
|
|
Wolfgang Moser wrote:
> PS: Pete, maybe your pscan utility may try to
> estimate the rpm value the disk was recorded
> at? Actually two rpm values should be printed
> from the two next possible speed zone settings
> that could have been used.
Sure this could be added to pscan as well. Elsewhere in the bitrate
calculation part of MNIB, I calculate it this way:
motor_speed = (float) 2309195 / (capacity[3] + CAPACITY_MARGIN);
Where capacity[3] is the length of the track as measured in average
bytes written at density 3. The 'margin' of 16 bytes is an extra amount
we don't pad out past, or else we'd wrap around and overwrite the
beginning of the track.
The 2,309,195 number came from 300 revolutions of 7697.3 bytes, which
must have been a calculation I took from my 1571, which runs right near
300rpm in the various RPM tests. Does this match up to the theoretical
calculations you are doing?
-
Pete Rittwage
C64 Preservation Project
|
|
|
Re: New release 0.4.0 of opencbm (cbm4win/cbm4linux) [message #142375 is a reply to message #142373] |
Thu, 11 May 2006 20:13 |
Pete Rittwage
Messages: 444 Registered: March 2005
Karma: 0
|
Senior Member |
|
|
Wolfgang Moser wrote:
> PS: Pete, maybe your pscan utility may try to
> estimate the rpm value the disk was recorded
> at? Actually two rpm values should be printed
> from the two next possible speed zone settings
> that could have been used.
Sure this could be added to pscan as well. Elsewhere in the bitrate
calculation part of MNIB, I calculate it this way:
motor_speed = (float) 2309195 / (capacity[3] + CAPACITY_MARGIN);
Where capacity[3] is the length of the track as measured in average
bytes written at density 3. The 'margin' of 16 bytes is an extra amount
we don't pad out past, or else we'd wrap around and overwrite the
beginning of the track.
The 2,309,195 number came from 300 revolutions of 7697.3 bytes, which
must have been a calculation I took from my 1571, which runs right near
300rpm in the various RPM tests. Does this match up to the theoretical
calculations you are doing?
-
Pete Rittwage
C64 Preservation Project
|
|
|
Re: New release 0.4.0 of opencbm (cbm4win/cbm4linux) [message #142376 is a reply to message #142374] |
Fri, 12 May 2006 04:04 |
Wolfgang Moser
Messages: 632 Registered: July 2003
Karma: 0
|
Senior Member |
|
|
Hello Pete,
> Sure this could be added to pscan as well. Elsewhere in the bitrate
> calculation part of MNIB, I calculate it this way:
>
> motor_speed = (float) 2309195 / (capacity[3] + CAPACITY_MARGIN);
>
> Where capacity[3] is the length of the track as measured in average
> bytes written at density 3. The 'margin' of 16 bytes is an extra amount
> we don't pad out past, or else we'd wrap around and overwrite the
> beginning of the track.
>
> The 2,309,195 number came from 300 revolutions of 7697.3 bytes, which
> must have been a calculation I took from my 1571, which runs right near
> 300rpm in the various RPM tests. Does this match up to the theoretical
> calculations you are doing?
hmmmm, let's see. What you _actually_ are getting with
this is the number of bytes per _minute_ that passes
away under the R/W head:
4,000,000 * 60 s
b/min = ------------------ = 2307692.308 b/min
13 * 8 * 1 min
13 is the divisor for the highes speed zone, 4,000,000
is the base clock frequency divided by 4. 8 is the
number of bits per byte, the rest is the conversion
from "per second" to "per minute".
So for speed zone 1 it merely does match, but could
be improved a bit (I recommend to but in symbolic
calculations in your code with the hlep of #defines).
For other speed zones (the speed zones the desired
track of that disk is suspected to be written at)
you should take other divisors (14, 15, 16) into
your calculation.
Womo
|
|
|