DolphiDOS (or other) 40 track disk recognition?
"Patrycjusz R. Łogiewa"
does any one here know how DolphinDOS (and possibly other extended
DOSes) marked their 40 track format on the diskette? It must be
somewhere in the DIRECTORY as I remember that issuing I0: or reading the
dir was enough for it to recognise the 35|40 track format.
--
In a world without walls and fences, who needs windows and gates?!
Wolfgang Moser
Patrycjusz R. ?ogiewa wrote:
> does any one here know how DolphinDOS (and possibly other extended
> DOSes) marked their 40 track format on the diskette? It must be
> somewhere in the DIRECTORY as I remember that issuing I0: or reading the
Please consult http://members.tripod.com/~petlibrary/D64.HTM
and search for "Dolphin". You will surely get some hints, but
as I feel, there's no secure identification.
As I know from Professional-DOS, it changed parts of the
disk ID from xxy2A to xxy4A, when the disk was formatted
to 40 tracks.
Joe Forster used another algorithm in his Star Commander to
check, if a disk was formatted for 40 tracks. He simply tests,
if the first sector can be found on track 36. But with SC you
have to manually decide, if you want to use Dolphin- or
SpeedDOS-based 40 track disks. It cannot decide automatically
between these two.
Womo
Nicolas Welte; address is valid for replies (Re:) only!
> Hi all,
>
> does any one here know how DolphinDOS (and possibly other extended
> DOSes) marked their 40 track format on the diskette? It must be
> somewhere in the DIRECTORY as I remember that issuing I0: or reading the
> dir was enough for it to recognise the 35|40 track format.
DolphinDOS uses one of the two fill bytes in each sector header on each
track to mark 40 track disks. So it just needs to read the next header on
any track to see which type of disk is in the drive.
This is why Dolphin Copy has to rewrite the whole disk if you extend a 35
track disk to a 40 track disk.
Nicolas
Wolfgang Moser
Nicolas Welte wrote:
>
> DolphinDOS uses one of the two fill bytes in each sector header on each
> track to mark 40 track disks. So it just needs to read the next header
> on any track to see which type of disk is in the drive.
>
> This is why Dolphin Copy has to rewrite the whole disk if you extend a
> 35 track disk to a 40 track disk.
This are really some exciting news. Is this already
mentioned in some commonly available CBM related
document?
Womo
Nicolas Welte; address is valid for replies (Re:) only!
I'm sure it's not, but I told Joe several times about it :-) If you also
have this info on some speeders (Professional DOS, Speeddos), we should
start such a document, I guess. I can also try to run some tests with
Prologic DOS Classic and its 1571 brother, the Prospeed GTI 1571. We could
also add a chapter to format.txt by Peter Schepers. It does list the
extended BAM layout of those speeders, doesn't it?
With DolphinDOS, it was pretty easy to see that the 40 track format marker
is *not* in the high level data: after copying a 40 track disk with Star
Commander or with a C64 based fast copier, the disk was mis-detected as a
35 track disk. The rest was just a matter of starting up Maverick's GCR
editor and have a look at the header data.
Nicolas
Wolfgang Moser
Nicolas Welte wrote:
>> Nicolas Welte wrote:
>>> DolphinDOS uses one of the two fill bytes in each sector header on
>>> each track to mark 40 track disks. So it just needs to read the next
>>> header on any track to see which type of disk is in the drive.
>>>
>>> This is why Dolphin Copy has to rewrite the whole disk if you extend
>>> a 35 track disk to a 40 track disk.
>
> I'm sure it's not, but I told Joe several times about it :-) If you also
> have this info on some speeders (Professional DOS, Speeddos), we should
> start such a document, I guess. I can also try to run some tests with
> Prologic DOS Classic and its 1571 brother, the Prospeed GTI 1571. We
> could also add a chapter to format.txt by Peter Schepers. It does list
> the extended BAM layout of those speeders, doesn't it?
As I mentioned in my first Follow-Up, yes, Peter
explained the extended BAM entries in D64.txt. At
least for SpeedDOS and Dolphin-DOS 40 track disks.
> With DolphinDOS, it was pretty easy to see that the 40 track format
> marker is *not* in the high level data: after copying a 40 track disk
> with Star Commander or with a C64 based fast copier, the disk was
> mis-detected as a 35 track disk. The rest was just a matter of starting
> up Maverick's GCR editor and have a look at the header data.
At now, we could also use the SixPack-ZC-Copier of
SC, the only thing missing would be a good PC based
GCR editor/monitor. The built in editor isn't
capable to read sector headers yet, although it's
archetype "disk demon" does it. Maybe VICE's
monitor would be a better choice, we'll see.
Womo
Wolfgang Moser
is just checked a Professional-DOS 40 track disk.
Nicolas Welte wrote:
>>> DolphinDOS uses one of the two fill bytes in each sector header on
>>> each track to mark 40 track disks. So it just needs to read the next
>>> header on any track to see which type of disk is in the drive.
>>
> mis-detected as a 35 track disk. The rest was just a matter of starting
> up Maverick's GCR editor and have a look at the header data.
I read a Professional-DOS formatted 40 track disk
with the SixPack-Copier of Star Commander and
converted it to G64 with Markus' S2G. Firing up
VICE, starting Disk-Demon and analyzing the G64
showed, that there's no additional information
stored in the two filler bytes of the sector
headers. Not in normal sectors (track 1..35) and
nothing in the extended tracks. The values all
the time contain the value $00.
The the only secure identifiier for
Professional-DOS formatted 40 track disks is the
modified DOS type ID $4A instead of $2A
(BAM location $A5).
The BAM entry table for tracks 36 to 40 seems to
be SpeedDOS compatible at the BAM location $C0..$D3.
Womo
Nicolas Welte; address is valid for replies (Re:) only!
> I read a Professional-DOS formatted 40 track disk
> with the SixPack-Copier of Star Commander and
> converted it to G64 with Markus' S2G. Firing up
> VICE, starting Disk-Demon and analyzing the G64
> showed, that there's no additional information
> stored in the two filler bytes of the sector
> headers. Not in normal sectors (track 1..35) and
> nothing in the extended tracks. The values all
> the time contain the value $00.
well, this is strange. I always thought those two bytes normally read $0f,
and Dolphin changes one to $0e. Now it's possible that one of the programs
in the chain lost those bytes or ProfDOS formatted the disk in this weird
way right from the start.
> The the only secure identifiier for
> Professional-DOS formatted 40 track disks is the
> modified DOS type ID $4A instead of $2A
> (BAM location $A5).
>
> The BAM entry table for tracks 36 to 40 seems to
> be SpeedDOS compatible at the BAM location $C0..$D3.
Now that I think about this, it's exactly the result that we should have
expected. After all your ProfDOS is an upgrade to Speeddos, so it is
supposed to use compatible BAM entrys. Do you know if Speeddos also uses
the same modified DOS type of 4A?
Nicolas
Wolfgang Moser
Nicolas Welte wrote:
>
>> I read a Professional-DOS formatted 40 track disk
>> with the SixPack-Copier of Star Commander and
>> converted it to G64 with Markus' S2G. Firing up
>> [...]
>> nothing in the extended tracks. The values all
>> the time contain the value $00.
>
> well, this is strange. I always thought those two bytes normally read
> $0f, and Dolphin changes one to $0e. Now it's possible that one of the
> programs in the chain lost those bytes or ProfDOS formatted the disk in
> this weird way right from the start.
For now, we would better say, that I made a fault.
I did it in a hurry (we had two power failures
yesterday) and wasn't as accurate as with other
things. Maybe I should analyze the G64 directly
or use another disc editor or perhaps use it
directly on the C64.
>> The the only secure identifiier for
>> Professional-DOS formatted 40 track disks is the
>> modified DOS type ID $4A instead of $2A
>> (BAM location $A5).
>>
>> The BAM entry table for tracks 36 to 40 seems to
>> be SpeedDOS compatible at the BAM location $C0..$D3.
>
> Now that I think about this, it's exactly the result that we should have
> expected. After all your ProfDOS is an upgrade to Speeddos, so it is
Btw. The disc I used for analysis was one, that
I formatted with Tim's "ProfDOS Release" two weeks
ago. Because my version of ProfDOS hasn't got "full"
40 track support (no autodetection and other things)
I thought, this would be better.
> supposed to use compatible BAM entrys. Do you know if Speeddos also uses
> the same modified DOS type of 4A?
I could never see, that SpeedDOS ever changed the DOS
version byte. And nearly all of my disks have been
formatted with a 40 track SpeedDOS. All of them contain
the version byte $2A.
Are you calling for a structured disk formatting test
sequence??? I mean formatting blank disks with a given
name, e.g.:
OPEN 1,8,15,"N:40TRACKTESTDISK,TT"
CLOSE 1
and then reading it with SC and comparing all of them
against each other?
Oh no, please not, not more work again.
Womo
"Patrycjusz R. Łogiewa"
Wolfgang Moser wrote:
>> does any one here know how DolphinDOS (and possibly other extended
>> DOSes) marked their 40 track format on the diskette? It must be
>> somewhere in the DIRECTORY as I remember that issuing I0: or reading the
>
>
> Please consult http://members.tripod.com/~petlibrary/D64.HTM
> and search for "Dolphin". You will surely get some hints, but
> as I feel, there's no secure identification.
Well, I believe there has to be one, since the DolphinDOS itself does
recognise its 40 track format every time. Also you can change the ID in
the dir header from XX<SP>2A to whatever YYYYY you like and it still
works but it might (and probably should) be that it reads the ID from a
different place... At least that's a good starting point for the searches.
>
> As I know from Professional-DOS, it changed parts of the
> disk ID from xxy2A to xxy4A, when the disk was formatted
> to 40 tracks.
>
> Joe Forster used another algorithm in his Star Commander to
> check, if a disk was formatted for 40 tracks. He simply tests,
> if the first sector can be found on track 36. But with SC you
> have to manually decide, if you want to use Dolphin- or
> SpeedDOS-based 40 track disks. It cannot decide automatically
> between these two.
This might suggest that both use the same way of identifying their 40
track formats but use e.g. different methods of BAM extensions...
Wolfgang Moser
Nicolas Welte wrote:
> Wolfgang Moser wrote:
>
>> I read a Professional-DOS formatted 40 track disk
>> [...]
>> showed, that there's no additional information
>> stored in the two filler bytes of the sector
>> [...]
>> the time contain the value $00.
>
> well, this is strange. I always thought those two bytes normally read
> $0f, and Dolphin changes one to $0e. Now it's possible that one of the
> programs in the chain lost those bytes or ProfDOS formatted the disk in
> this weird way right from the start.
Well, this weekend I repeated the tests on the real
thing with different speeder formatted disks.
The table below shows the result of deleting the whole
disk with disc demon (vacuum command), reformatting the
disk with the desired DOS ROM enabled and watching at
the sector headers with disc demon again. The point of
interest were/are the 7th and 8th byte of the sector
header, which are unused filler bytes. Additionally the
DOS ID (4th and 5th letter of the disk ID) is written
up, too.
Disk format |Tracks|Header 7/8| DOS-ID
=====================================================
Original CBM DOS v2.6 | 35 | $0f $0f | $2A
SpeedDOS+ | 40 | $0f $0f | $2A
ProfessionalDOS Initial | 35 | $0f $0f | $2A
(Version 1/Prototype) | 40 | $0f $0f | $2A
ProfDOS Release | 40 | $0f $0f | $4A
I controlled several tracks and sectors all over the
formatted disks to check, if there are any sector
headers, that contain other filler bytes. This was
not the case with all of the formats.
The conclusion is, that you were and are right in all
discussed cases. Dolphin-DOS seems to be the only
system, that makes use of the two header filler
bytes to mark 40 track extended disks. I'll make a
little note onto an internal ToDo list as proposion
for some future speeder system, maybe it's of some
use.
But nevertheless I found some older disks, that don't
have $0f filler bytes, but $00 ones instead. It seems,
that I used a 41 track fast formatting systems 14
years ago. To my regret, I can't remember how it's
name was and didn't find it on my system disks (none
of these fast formatters).
The remaining question is: Why didn't I see the
correct $0f bytes when using SC/S2G/Vice for this
disk analysis? Which of the programs 'lost' the
bytes?
According to the FORMATS.ZIP description of the
SixPack-ZC format, it is able to hold the full header
information. Ok, after having verified on the real C64
equipment, that I'm really using a disk containing $0f
filler bytes in each header sector of track 1, I fired
up Star Commander 0.82.04b and imported the disk with
the Sixpack-Zipcode transfer method. Looking into the
the first of the six files I get this:
00000000h: FF 03 29 52 55 65 29 4B 74 DC E5 29 4A 52 55 75
00000010h: 2D 4B 74 DC E5 29 4A 52 54 E5 49 4B 74 DC E5 29
Decoding the last 5 nibbles of the first sector header
(52 55 65 29 4B 74 DC E5 29 4A) results to:
GCR: ...5 29 4A
GCR-Bit: 0101 0 010 10 01 010 0 1010
| | |
Decoded: 0 0 0 0
In other words, $00, $00. It seems, that Star Commander
lost the values of the two header filler bytes and
corroborates your former observation, that SC "removes"
the autodetection of your 40 track formatted Dolphin-DOS
disks.
I think, this results to a new bug report, doesn't it?
Womo
PS: Any news on your PETRAM PCBs?
Nicolas Welte; address is valid for replies (Re:) only!
Wolfgang Moser wrote:
> Nicolas Welte wrote:
>> well, this is strange. I always thought those two bytes normally read
>> $0f, and Dolphin changes one to $0e. Now it's possible that one of the
>> programs in the chain lost those bytes or ProfDOS formatted the disk
>> in this weird way right from the start.
> Disk format |Tracks|Header 7/8| DOS-ID
> =====================================================
> Original CBM DOS v2.6 | 35 | $0f $0f | $2A
> SpeedDOS+ | 40 | $0f $0f | $2A
> ProfessionalDOS Initial | 35 | $0f $0f | $2A
> (Version 1/Prototype) | 40 | $0f $0f | $2A
> ProfDOS Release | 40 | $0f $0f | $4A
Good work! This means I will have to do the same tests with
PrologicDOS/ProSpeed sometimes. I also tried to look up which of the two
fill bytes is set to $0e in DolphinDOS, but I couldn't find the email where
I wrote this. After all, I found out this was five years ago in 1997!
> In other words, $00, $00. It seems, that Star Commander
> lost the values of the two header filler bytes and
> corroborates your former observation, that SC "removes"
> the autodetection of your 40 track formatted Dolphin-DOS
> disks.
>
> I think, this results to a new bug report, doesn't it?
I'm sure it does :-) Will you send it?
> PS: Any news on your PETRAM PCBs?
I'm still waiting for them, delivery is scheduled for Nov. 8th. I also hope
that Kessler will send me the parts in time for the first batch I want to
build.
Nicolas
Wolfgang Moser
>> Disk format |Tracks|Header 7/8| DOS-ID
>
> PrologicDOS/ProSpeed sometimes. I also tried to look up which of the two
> fill bytes is set to $0e in DolphinDOS, but I couldn't find the email
> where I wrote this. After all, I found out this was five years ago in 1997!
Would it be less work to search fo that mail? In mean
less work than formatting a disk, starting up Disk Demon
or another good editor and looking for these bytes?
Sure, C64 equipments needs to be built up for this.
>> I think, this results to a new bug report, doesn't it?
>
> I'm sure it does :-) Will you send it?
Yes I did. I proposed a descent eMail discussion between
us three about that point, because I think, the lost of
these two bytes is by design. So we need to decide, if
these bytes are needed so much, that Joe needs to change
his copier code (much work and introducing many bugs
again).
Womo
PS: I just got a FCopy-III version for SpeedDOS 40 track
drives. How many years did I search for this? 10, 11?
Joe Forster/STA
> According to the FORMATS.ZIP description of the
> SixPack-ZC format, it is able to hold the full header
> information. Ok, after having verified on the real C64
> equipment, that I'm really using a disk containing $0f
> filler bytes in each header sector of track 1, I fired
> up Star Commander 0.82.04b and imported the disk with
> the Sixpack-Zipcode transfer method. Looking into the
> the first of the six files I get this:
>
> 00000000h: FF 03 29 52 55 65 29 4B 74 DC E5 29 4A 52 55 75
> 00000010h: 2D 4B 74 DC E5 29 4A 52 54 E5 49 4B 74 DC E5 29
>
> Decoding the last 5 nibbles of the first sector header
> (52 55 65 29 4B 74 DC E5 29 4A) results to:
>
> GCR: ...5 29 4A
> GCR-Bit: 0101 0 010 10 01 010 0 1010
> | | |
> Decoded: 0 0 0 0
>
> In other words, $00, $00. It seems, that Star Commander
> lost the values of the two header filler bytes and
> corroborates your former observation, that SC "removes"
> the autodetection of your 40 track formatted Dolphin-DOS
> disks.
Uhm, is that _really_ a 0.8_2_ beta release that you used?! Since then,
I have reworked _quite_ a few things in the disk copier... ;-) I remember
that later I introduced a constant for sector header padding (default
$0F) when converting a "normal" disk image format into a GCR-based one.
When _writing_ Commodore disks, the sector header is not touched so you
do lose this extra data. However, when _reading_ Commodore disks, even
the 0.82 public release read in the complete sector header, but - lacking
support for GCR-based disk formats - it discarded the data. Since the
disk copier was enhanced, the sector header should be copied, without
changes, between GCR-based disk formats such as Commodore disks and
sixpacked ZipCode archives. I'll check this out at home though... :-)
Bye,
Joe Forster/STA
s...@c64.org
Wolfgang Moser
Joe Forster/STA wrote:
>>In other words, $00, $00. It seems, that Star Commander
>>lost the values of the two header filler bytes and
>>corroborates your former observation, that SC "removes"
>>the autodetection of your 40 track formatted Dolphin-DOS
>>disks.
>
> Uhm, is that _really_ a 0.8_2_ beta release that you used?! Since then,
Yes, I'm very sure, that it was. Before writing the concrete
bug report to you, I just downloaded the latest beta 0.82.06b
and made the same test again. With the same result.
> I have reworked _quite_ a few things in the disk copier... ;-) I remember
> that later I introduced a constant for sector header padding (default
> $0F) when converting a "normal" disk image format into a GCR-based one.
> When _writing_ Commodore disks, the sector header is not touched so you
> do lose this extra data. However, when _reading_ Commodore disks, even
Ok, well I understand. Although, when it comes to completely
modified sector headers (transported by a.g. a G64), then you
will have to transfer _all_ the data. Yes, I _do_ know, that
the current state of the disk copier routine (it's more than
a simple routine, yes, something like a copy factory :) is
not able to this. But as development on GCR based transfers
goes on, it will have to some day.
> the 0.82 public release read in the complete sector header, but - lacking
> support for GCR-based disk formats - it discarded the data. Since the
> disk copier was enhanced, the sector header should be copied, without
> changes, between GCR-based disk formats such as Commodore disks and
> sixpacked ZipCode archives. I'll check this out at home though... :-)
Good idea. Since Nicolas didn't double check this issue until
now and I may be wrong, it needn't to be your fault.
Womo
Joe Forster/STA
You were right: only the first eight (GCR-coded) bytes are read from the
sector header but all ten are transferred to the PC. This means, part of
GCR-coded form of the padding bytes is kind of a memory garbage and is
GCR-decoded into two zero bytes. I think I did this - more or less - on
purpose... In warp transfer mode, the disk turbo in the drive:
1. Reads in _a_ sector header from the disk. After 90 tries, gives up
and returns "20,READ ERROR".
2. Manually, fast-GCR-decodes the sector number from the header.
3. Checks the sector number. If outside the valid range of sector
numbers for the current track, weird/damaged header, go to step 1.
4. Reads in the complete data block, following the sector header.
5. Checks the track map, to find out whether this sector should be
transferred or not. If not, uninteresting sector, go to step 1.
6. GCR-decodes the complete sector header, using a (slow) ROM routine.
7. Checks the track number from the header. If different from current
track, weird/damaged header, go to step 1.
8. Marks the sector as "uninteresting".
9. Transfers the GCR-coded data block to the host.
I think I was worried that if step 1 reads in all the ten GCR-coded
bytes (rather than just the first eight "important" bytes) then, after
having completed step 2 and step 3, step 4 may miss the data block that
directly follows the header. But now that I lengthened the loop to read
all ten bytes, apparently, everything is still working fine, plus the
two padding bytes are transferred, too. Check it out in SC 0.83.08 alpha
yourself,
Joe
Wolfgang Moser
Joe Forster/STA wrote:
>
> 1. Reads in _a_ sector header from the disk. After 90 tries, gives up
> and returns "20,READ ERROR".
> 2. Manually, fast-GCR-decodes the sector number from the header.
> 3. Checks the sector number. If outside the valid range of sector
> numbers for the current track, weird/damaged header, go to step 1.
> [...]
>
> I think I was worried that if step 1 reads in all the ten GCR-coded
> bytes (rather than just the first eight "important" bytes) then, after
> having completed step 2 and step 3, step 4 may miss the data block that
> directly follows the header. But now that I lengthened the loop to read
Ahhh yes, I remember weakly the time, when we discussed
this faster 'get-next-unmarked-sector' transfer routine
the first time. And yes, I can remember, that it depends
strongly on the size of the gap between the header and
the data block.
To be sure in this timing critical issue, you would need
to find the old calculation tables, where we tried to
determine the minimum cycles needed.
> all ten bytes, apparently, everything is still working fine, plus the
> two padding bytes are transferred, too. Check it out in SC 0.83.08 alpha
I'll have a look.
Do you know, what would happen, _if_ the beginning of the
data block cannot be read in time? Something like "data
block not found error"?
Womo
Joe Forster/STA
> Do you know, what would happen, _if_ the beginning of the
> data block cannot be read in time? Something like "data
> block not found error"?
We can try it, by lengthening the loop to read in a lot more bytes...
8^) I guess, it would read the data block of the _next_ sector...!
Joe Forster/STA
s...@c64.org
Wolfgang Moser
Joe Forster/STA wrote:
>
>>Do you know, what would happen, _if_ the beginning of the
>>data block cannot be read in time? Something like "data
>>block not found error"?
>
> We can try it, by lengthening the loop to read in a lot more bytes...
> 8^) I guess, it would read the data block of the _next_ sector...!
Then there should be a security check, that if a header
is found instead of the beginning of a data block, an
error is generated or simply the routine starts from the
beginning with the header just found.
Joe Forster/STA
Sorry, there's no room for that as then I'd have to code my own read
routine and stuff it into the disk turbo... <:-) We should rather do
some computations and make up a worst case scenario. So, how many clock
cycles does it take for the electronics to read in a single byte from
the disk in each speed zone?
Joe Forster/STA
s...@c64.org
Wolfgang Moser
Joe Forster/STA wrote:
>
> Sorry, there's no room for that as then I'd have to code my own read
> routine and stuff it into the disk turbo... <:-) We should rather do
I see, that's the main problem all the time.
> some computations and make up a worst case scenario. So, how many clock
> cycles does it take for the electronics to read in a single byte from
> the disk in each speed zone?
How often did we these calculations in the past?
Three times, four? Normally Nicolas would have
answered this question, but he takes a timeout, I
think. And I'll do so soon, too.
Readon at:
http://groups.google.de/groups?selm=5edvF7nr8yB%40ldb-ab.ldb.han.de
http://groups.google.de/groups?selm=3821F42D.10D1%40chemie.uni-konstanz.de
http://groups.google.de/groups?selm=331D21CA.710E%40xpress.se
According to: http://www.funet.fi/pub/cbm/transfer/1541-dos/1541-dos.txt
"The clock divisor is a 74LS193 hexadecimal counter in the 1541, and
the similar 74LS161 in the Oceanic drives. The CPU loads the number to
start counting at on its inputs and the overflow from the counter is
chained to the next portion of the circuit. Of the 4 counter inputs, the
lower two are controlled by the CPU and the higher 2 are tied to ground.
This means values of 0 through 3 on the counter inputs require 16 to 13
counts (respectively) before overflow, thus dividing the input by that
amount. The range of clock rates that can be generated with those
divisors is from 250 kHz to 307 kHz."
For the worst case we only need to take the 307kHz
clock into account, that can be calculated by:
16 MHz
---------- = 0,30769 MHz
13 * 4
16 MHz is the base oscillator clock freqeuency, 13 the
programmable divider for the differrent speed zones, and
the additional divider of 4 is found within the
controller chip (in the very first model of the 1541 you
can find it as a circuit).
So now we know, that reading one bit within the highest
speed zone requires 3.25µs or 3.25 clock cycles. Reading
a byte (8 GCR coded bits) would need 26 processor
clock cycles.
So the answer is 26 . I think you can remember to this
magic value, can't you?
Because there are some mnemonics, that have to be executed
for each byte read, the remaining clock cycles, you could
use for own stuff would be:
BVC * ; waiting, 2 cycles at least
CLV ; 2 cycles
LDA $1C01 ; 4 cycles
;...
; calc or store or something
;...
BVC *
CLV
18 clock cycles, where at least 4 cycles are needed to
store the accumulator to a memory location or another
register. So for the worst case you have more or less
14 clock cycles for own stuff.
Womo
Nicolas Welte; address is valid for replies (Re:) only!
>> some computations and make up a worst case scenario. So, how many clock
>> cycles does it take for the electronics to read in a single byte from
>> the disk in each speed zone?
>
>
> How often did we these calculations in the past?
> Three times, four? Normally Nicolas would have
> answered this question, but he takes a timeout, I
> think. And I'll do so soon, too.
Actually I didn't answer because I think I didn't understand the question.
I had no idea it was the usual cycles per byte calculation that I also did
before, as you showed us with your Google links.
Now back to sleep, work, whatever :-)
Nicolas
Joe Forster/STA
> So the answer is 26 . I think you can remember to this
> magic value, can't you?
I'll try to! 8-P The relevant code from the disk turbo:
;Step 1. Read in the ten bytes of the sector header
....
0555 50 FE BVC $0555
0557 B8 CLV
0558 AD 01 1C LDA $1C01
055B 95 25 STA $25,X
055D E8 INX
055E E0 09 CPX #$09
0560 D0 F3 BNE $0555
;Step 2. Fast-decode the sector number
0562 A5 27 LDA $27
0564 29 7C AND #$7C
0566 4A LSR A
0567 4A LSR A
0568 AA TAX
0569 BD C0 F8 LDA $F8C0,X
056C 85 0B STA $0B
056E A5 27 LDA $27
0570 2A ROL A
0571 A5 26 LDA $26
0573 29 0F AND #$0F
0575 2A ROL A
0576 AA TAX
0577 BD A0 F8 LDA $F8A0,X
057A 05 0B ORA $0B
057C 85 0B STA $0B
;Step 3. Check if sector number is within valid range for track
057E C5 43 CMP $43
0580 B0 CA BCS $054C
;Step 4. Read in data block, using a RAM copy of the ROM routine
0582 20 46 07 JSR $0746
....
Between the header and the data block, there are 9 pieces of $55
bytes, that's about 200 clock cycles. (Plus 5 pieces of $FF bytes,
the SYNC mark but we shouldn't rely on them!). Step 2 and 3 takes...
(starts computing) Oh well, I'm not gonna dig up the diagrams! So,
say, each instruction needs an average of 5 clock cycles - that's an
upper limit - and then this code still needs less than 100 clock
cycles. So, we're absolutely safe. QED (grin)
Joe Forster/STA
s...@c64.org
Wolfgang Moser
Joe Forster/STA wrote:
>>So the answer is 26 . I think you can remember to this
>>magic value, can't you?
>
> I'll try to! 8-P The relevant code from the disk turbo:
I'm sure you will. Even, if you put this value
into some comment line of the desired 6502
source code section :)
> ;Step 1. Read in the ten bytes of the sector header
> .....
> 0555 50 FE BVC $0555
[...]
> ;Step 4. Read in data block, using a RAM copy of the ROM routine
> 0582 20 46 07 JSR $0746
> .....
>
> Between the header and the data block, there are 9 pieces of $55
> bytes, that's about 200 clock cycles. (Plus 5 pieces of $FF bytes,
> the SYNC mark but we shouldn't rely on them!). Step 2 and 3 takes...
> (starts computing) Oh well, I'm not gonna dig up the diagrams! So,
> say, each instruction needs an average of 5 clock cycles - that's an
> upper limit - and then this code still needs less than 100 clock
> cycles. So, we're absolutely safe. QED (grin)
An opcode timing diagram and Excel say: 72 cycles
from the BVC reading the last byte of the header
up to the JSR shown in the code snippet here.
Some cycles more, depending on the start of the
data block read routine.
In the case, that the GAP between the header and
the data block is in fact 200 clock cyles long,
yes, we prooved it, this is safe. All standard
formatted disks and surely some not too hard
copy protected disks should work.
And if the data block read routine checks the
first GCR byte after the sync (data block marker
byte), then errors are recognized as well (if a
next header is found instead of the data block).
But if some odd copy protection didn't put a gap
between the header and the data, we would have a
problem. But since Star Commander is mainly for
unprotected disks, we don't need to take this
into account for the first time.
I wrote another article yesterday, but it got lost
somehow. I thought about not waiting for the data
block sync, but simply reading the following bytes
including the last part of the gap as well as the
sync and the data block following. All the GCR
data could be transferred to the PC then, where
the PC has to detect the sync (shifting bitwise)
then. But I know, that this would 'cost' perhaps
much to much buffer size (~400 bytes) within the
drive.
Womo
Wolfgang Moser
Nicolas Welte wrote:
>>
>> How often did we these calculations in the past?
>> Three times, four? Normally Nicolas would have
>
> Actually I didn't answer because I think I didn't understand the
??? _You_ didn't understand this?
> Now back to sleep, work, whatever :-)
I visited an external lecture today and yes,
I'm going to bed now. Pheww, what a day.
Womo