Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Commodore » Commodore Emulation » New release 0.4.0 of opencbm (cbm4win/cbm4linux)
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: New release 0.4.0 of opencbm (cbm4win/cbm4linux) [message #142371 is a reply to message #142368] Wed, 10 May 2006 20:28 Go to previous messageGo to next message
Pete Rittwage is currently offline  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 Go to previous messageGo to next message
Wolfgang Moser is currently offline  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 Go to previous messageGo to next message
Wolfgang Moser is currently offline  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 Go to previous messageGo to next message
Pete Rittwage is currently offline  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 Go to previous messageGo to next message
Pete Rittwage is currently offline  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 Go to previous message
Wolfgang Moser is currently offline  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
Pages (3): [ «    1  2  3]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Problems with re-compiled Vice 1.19 x Linux
Next Topic: W64Asm,Would anyone like to test??
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 03:18:30 EDT 2024

Total time taken to generate the page: 0.51797 seconds