Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Zorba 5.25 40 track DSDD diskdef for cpmtools?
427 views
Skip to first unread message
Bob
Dec 14, 2012, 12:52:15 AM12/14/12
to
Hi,
Has anyone determined a usable diskdef for this format? I'm stuck on the
skewing.
Has anyone determined a usable diskdef for this format? I'm stuck on the
skewing.
Peter Dassow
Dec 14, 2012, 11:45:41 AM12/14/12
to
is also 22disk and also a big cpmdisks.def file...
Regards
Peter
Bob
Dec 15, 2012, 12:45:29 AM12/15/12
to
track DSDD there and, if I read the binary data correctly, it is defined
as 20 sectors per track, 512 bytes per sector, skew 0. IMDV, however,
insists that there are 18 sectors per track on the file in question. If
I create a cpmtools diskdef for 18 tracks, 512 bytes per sector, I can
land properly on the file directory at a track boundary. 20 sectors per
track fails that. So something is amiss. And a skew of 0 with 18
sectors yields a weird resultant file on a cpmcp from the image. A skew
of 0 is inconsistent with IMDV's report, too. But implementing IMDV's
report for skew also fails to give a reasonable result on cpmcp.
I am starting to think that reconstructing from the original
compressed .td0 file is incorrect. By the way, this is not originating
from any .td0 file in the Maslin archive. It's from a backup of Mycroft
Lab's Compat software, which was released by the author to the public
domain (https://groups.google.com/forum/?fromgroups=#!topic/comp.os.cpm/
UDM-3fyLVYk%5B1-25-false%5D), but has not been posted, to my knowledge.
glen herrmannsfeldt
Dec 15, 2012, 3:33:42 AM12/15/12
to
Bob <Bo...@pingme.net> wrote:
(snip)
> Thanks for the pointer, Peter. There is a definition for the Zorba 40
> track DSDD there and, if I read the binary data correctly, it is defined
> as 20 sectors per track, 512 bytes per sector, skew 0.
The IBM 5.25HD format stores 15 sectors of 512 bytes on a track
(at 360RPM). The 3.5HD format stores 18 sectors/track.
For DD, the bit rate is half the HD bit rate, so I don't believe
that you can get 20 sectors per track at DD.
But, if you include both sides, as one track, then I might believe it.
Also, you have to have the gaps much smaller than recommended.
OK, the raw bits (gaps included) for DSDD are 250,000 bits/second,
and 0.2s per revolution, for 50,000 bits, or 6250 bytes. Then you
need address marks and sector headers and, yes, gaps. So, usually
nine sectors, unless your rotation speed is especially accurate,
in which case you might get 10.
> IMDV, however,
> insists that there are 18 sectors per track on the file in question. If
> I create a cpmtools diskdef for 18 tracks, 512 bytes per sector, I can
> land properly on the file directory at a track boundary. 20 sectors per
> track fails that. So something is amiss. And a skew of 0 with 18
> sectors yields a weird resultant file on a cpmcp from the image. A skew
> of 0 is inconsistent with IMDV's report, too. But implementing IMDV's
> report for skew also fails to give a reasonable result on cpmcp.
Is that supposed to include both sides?
OH, 5.25HD at 500,000 bits/sec and 360RPM gives 83333 bits, or 10416
bytes. Then subtract sector headers and address marks, not to
mention rotation speed tolerance.
-- glen
(snip)
> Thanks for the pointer, Peter. There is a definition for the Zorba 40
> track DSDD there and, if I read the binary data correctly, it is defined
> as 20 sectors per track, 512 bytes per sector, skew 0.
(at 360RPM). The 3.5HD format stores 18 sectors/track.
For DD, the bit rate is half the HD bit rate, so I don't believe
that you can get 20 sectors per track at DD.
But, if you include both sides, as one track, then I might believe it.
Also, you have to have the gaps much smaller than recommended.
OK, the raw bits (gaps included) for DSDD are 250,000 bits/second,
and 0.2s per revolution, for 50,000 bits, or 6250 bytes. Then you
need address marks and sector headers and, yes, gaps. So, usually
nine sectors, unless your rotation speed is especially accurate,
in which case you might get 10.
> IMDV, however,
> insists that there are 18 sectors per track on the file in question. If
> I create a cpmtools diskdef for 18 tracks, 512 bytes per sector, I can
> land properly on the file directory at a track boundary. 20 sectors per
> track fails that. So something is amiss. And a skew of 0 with 18
> sectors yields a weird resultant file on a cpmcp from the image. A skew
> of 0 is inconsistent with IMDV's report, too. But implementing IMDV's
> report for skew also fails to give a reasonable result on cpmcp.
OH, 5.25HD at 500,000 bits/sec and 360RPM gives 83333 bits, or 10416
bytes. Then subtract sector headers and address marks, not to
mention rotation speed tolerance.
-- glen
David Schmidt
Dec 16, 2012, 6:10:23 PM12/16/12
to
skewing:
Disk Name: Zorba DS
Type: 5 1/4 Total usable space: 390k bytes
Sector information:
- 512 bytes/sector; 10 per track; numbered 1 to 10 (Side 2 numbered
11 to 20)
- Disk is filled track 0, first side, then track 0, second side
Logical Layout:
- Allocation unit size is 2048 bytes; 195 AU's per disk
- Directory starts at logical track 2;
has 64 entries and occupies 4 sectors or 1 AU's
Standard disk parameter table entry (values in HEX):
28 00 04 0F 01 C2 00 3F 00 80 00 10 00 02 00 02 03
http://www.herne.com/jugg.htm
http://www.herne.com/cpm/details.zip
Peter Dassow
Dec 17, 2012, 4:36:06 PM12/17/12
to
On 15.12.2012 06:45, Bob wrote:
> On Fri, 14 Dec 2012 17:45:41 +0100, Peter Dassow wrote:
>
>>> Has anyone determined a usable diskdef for this format? I'm stuck on
>>> the skewing.
>>>
>> May be you can take a look into that archive file from Don Maslin, there
>> is also 22disk and also a big cpmdisks.def file...
>>
>> Regards
>> Peter
>
> Thanks for the pointer, Peter. There is a definition for the Zorba 40
> track DSDD there and, if I read the binary data correctly, it is defined
> as 20 sectors per track, 512 bytes per sector, skew 0. IMDV, however,
> insists that there are 18 sectors per track on the file in question.
As already said here, 20 sectors per track is only possible with less
> On Fri, 14 Dec 2012 17:45:41 +0100, Peter Dassow wrote:
>
>>> Has anyone determined a usable diskdef for this format? I'm stuck on
>>> the skewing.
>>>
>> May be you can take a look into that archive file from Don Maslin, there
>> is also 22disk and also a big cpmdisks.def file...
>>
>> Regards
>> Peter
>
> Thanks for the pointer, Peter. There is a definition for the Zorba 40
> track DSDD there and, if I read the binary data correctly, it is defined
> as 20 sectors per track, 512 bytes per sector, skew 0. IMDV, however,
> insists that there are 18 sectors per track on the file in question.
than 512 bytes per sector.
So it seems to be BOTH sides for one track, means 10 sectors /
surface-track ...
Regards
Peter
Ole Christensen
Dec 17, 2012, 6:29:50 PM12/17/12
to
On 2012-12-15 06:45, Bob wrote:
> There is a definition for the Zorba 40
> track DSDD there and, if I read the binary data correctly, it is defined
> as 20 sectors per track, 512 bytes per sector, skew 0. IMDV, however,
> insists that there are 18 sectors per track on the file in question. If
> I create a cpmtools diskdef for 18 tracks, 512 bytes per sector, I can
> land properly on the file directory at a track boundary. 20 sectors per
> track fails that. So something is amiss. And a skew of 0 with 18
> sectors yields a weird resultant file on a cpmcp from the image. A skew
> of 0 is inconsistent with IMDV's report, too. But implementing IMDV's
> report for skew also fails to give a reasonable result on cpmcp.
>
> I am starting to think that reconstructing from the original
> compressed .td0 file is incorrect. By the way, this is not originating
> from any .td0 file in the Maslin archive. It's from a backup of
> Mycroft Lab's Compat software,
---
> There is a definition for the Zorba 40
> track DSDD there and, if I read the binary data correctly, it is defined
> as 20 sectors per track, 512 bytes per sector, skew 0. IMDV, however,
> insists that there are 18 sectors per track on the file in question. If
> I create a cpmtools diskdef for 18 tracks, 512 bytes per sector, I can
> land properly on the file directory at a track boundary. 20 sectors per
> track fails that. So something is amiss. And a skew of 0 with 18
> sectors yields a weird resultant file on a cpmcp from the image. A skew
> of 0 is inconsistent with IMDV's report, too. But implementing IMDV's
> report for skew also fails to give a reasonable result on cpmcp.
>
> I am starting to think that reconstructing from the original
> compressed .td0 file is incorrect. By the way, this is not originating
> from any .td0 file in the Maslin archive. It's from a backup of
> Mycroft Lab's Compat software,
After: TD02IMD file.td0 (from Maslin archive)
reports: 512 byte sector, 1-10, 11-20, 2:1, 80 track
And after: IMDU file.imd file.dmk /B
tested and working diskdef for cpmtools:
#
diskdef ZOR1
seclen 512
tracks 80
sectrk 10
blocksize 2048
maxdir 64
boottrk 2
os 2
end
- 40 track and 20 sector don't work(?)
now from format.z80, (from that same disk)
; MENU definition area.
MENU1:: DEFB 'FORMAT v2.5 for TELCON CP/M '
DEFB 'COPYRIGHT (C) 1982, TELCON INDUSTRIES INC.'
DEFB $CR,$LF,$LF,$LF
DEFB 'Select Disk Format',$CR,$LF
DEFB '------ -----------',$CR,$LF,$LF
DEFB 'A - Telcon ZORBA DD',$CR,$LF
DEFB 'B - Telcon NOMIS QD',$CR,$LF
DEFB 'C - Xerox 820-2 DD',$CR,$LF
DEFB 'D - Xerox 820 SD or Cromemco 520 SD',$CR,$LF
DEFB 'E - KayComp II DD',$CR,$LF
DEFB 'F - Osborne SD',$CR,$LF
DEFB 'G - CP/M-86 SD for IBM-PC',$CR,$LF
DEFB 'H - DEC VT-18x series DD',$CR,$LF
DEFB 'X - EXIT TO CP/M, cancel this program.'
Two of this format are SS 512/9,
DEC VT-18x and KayComp II,...
try with:
#
diskdef Zqq
seclen 512
tracks 80
sectrk 9
blocksize 2048
maxdir 64
#alt maxdir 128
boottrk 2
os 2
end
Without the disk in Q it's not that easy,...
<ole>
Bob
Dec 17, 2012, 11:44:53 PM12/17/12
to
already gone down those avenues. If someone would like to try his hand,
here's a link to the .td0 file. http://www.zorba.z80.de/files/misc/
compat32.td0
My problem has been getting reasonable files off the disk after expansion
and conversion to binary format. If you do try it, check each file. For
instance, the Zqq diskdef above will read the directory, and allow for
pulling files, but they won't look sensible.
David Schmidt
Dec 18, 2012, 9:47:58 AM12/18/12
to
On 12/17/2012 11:44 PM, Bob wrote:
> Thanks to you and everyone else for your assistance. However, I've
> already gone down those avenues. If someone would like to try his hand,
> here's a link to the .td0 file. http://www.zorba.z80.de/files/misc/
> compat32.td0
>
> My problem has been getting reasonable files off the disk after expansion
> and conversion to binary format. If you do try it, check each file. For
> instance, the Zqq diskdef above will read the directory, and allow for
> pulling files, but they won't look sensible.
I stepped through the compat32.td0 disk image after going from
> Thanks to you and everyone else for your assistance. However, I've
> already gone down those avenues. If someone would like to try his hand,
> here's a link to the .td0 file. http://www.zorba.z80.de/files/misc/
> compat32.td0
>
> My problem has been getting reasonable files off the disk after expansion
> and conversion to binary format. If you do try it, check each file. For
> instance, the Zqq diskdef above will read the directory, and allow for
> pulling files, but they won't look sensible.
.td0->.imd->.bin. I'm not convinced the image made it through the
process unscathed. I agree the directory looks sensible. But just
walking through the sectors I find contiguous data most of the time
(i.e. reading those sections that are semi-textual), and then odd breaks
where one sector doesn't follow another. In one case, I was looking for
the tail end of a sentence that got cut off at the end of a sector and I
never found another beginning of a sector that would complete the sentence.
Bob
Dec 18, 2012, 1:27:32 PM12/18/12
to
information folks have uncovered point to that being wrong. Also, if you
look at the .imd file in IMDV, a skew is there, if I interpret the
display correctly. Curious.
John Elliott
Dec 18, 2012, 3:21:16 PM12/18/12
to
Peter Dassow <z8...@arcor.de> wrote:
> As already said here, 20 sectors per track is only possible with less
> than 512 bytes per sector.
> So it seems to be BOTH sides for one track, means 10 sectors /
> surface-track ...
I had a look at the file with LibDsk (the 'ibm720' is just to bypass the
> As already said here, 20 sectors per track is only possible with less
> than 512 bytes per sector.
> So it seems to be BOTH sides for one track, means 10 sectors /
> surface-track ...
automatic format detection and make it scan both sides of the disk):
% dskscan -format ibm720 compat32.td0 | less
Comment: Mycroft Labs Inc.
Compat 3.2
Cylinder 0 Head 0:
Data rate: 250
Encoding: mfm
Cyl 00 Head 0 Sec 2 size 512
Cyl 00 Head 0 Sec 7 size 512
Cyl 00 Head 0 Sec 3 size 512
Cyl 00 Head 0 Sec 8 size 512
Cyl 00 Head 0 Sec 4 size 512
Cyl 00 Head 0 Sec 9 size 512
Cyl 00 Head 0 Sec 5 size 512
Cyl 00 Head 0 Sec 10 size 512
Cyl 00 Head 0 Sec 6 size 512
Cylinder 0 Head 1:
Data rate: 250
Encoding: mfm
Cyl 00 Head 0<!> Sec 11 size 512
Cyl 00 Head 0<!> Sec 16 size 512
Cyl 00 Head 0<!> Sec 12 size 512
Cyl 00 Head 0<!> Sec 17 size 512
Cyl 00 Head 0<!> Sec 13 size 512
Cyl 00 Head 0<!> Sec 18 size 512
Cyl 00 Head 0<!> Sec 14 size 512
Cyl 00 Head 0<!> Sec 19 size 512
Cyl 00 Head 0<!> Sec 15 size 512
[plus similar output for the other 39 cylinders]
Assuming I haven't made any stupid mistakes in writing dskscan, this
suggests to me:
- Originally, the disk was formatted using the 'extended track' numbering
scheme. That is, on side 0 the sectors are numbered 1-10, and on side 1 they
are numbered 11-20.
- Not all sectors are present. There's no Cylinder 0 Head 0 Sector 1, for
example, and no Cylinder 3 Head 0 Sector 8.
I would guess that not all sectors were dumped when the Teledisk image was
made, and therefore it won't be possible to reconstruct meaningful data from
the file. Possibly one sector on each track is so close to the index hole
that an 8272-style floppy controller can't see it.
--
John Elliott
Thinks: This is what a nice clean life leads to. Hmm, why did I ever lead one?
-- Bluebottle, in the Goon Show
glen herrmannsfeldt
Dec 18, 2012, 4:13:40 PM12/18/12
to
John Elliott <j...@seasip.demon.co.uk> wrote:
(snip)
> I would guess that not all sectors were dumped when the Teledisk image was
> made, and therefore it won't be possible to reconstruct meaningful data from
> the file. Possibly one sector on each track is so close to the index hole
> that an 8272-style floppy controller can't see it.
It is supposed to only use the index hole when formatting.
Start writing at the index, stop, while writing the last gap, after
the next one.
I know the WD controllers better, but you can't rely on the results
from any "read track" command, as address marks are lost. Might be
useful for debugging, but not for actual data use.
-- glen
(snip)
> I would guess that not all sectors were dumped when the Teledisk image was
> made, and therefore it won't be possible to reconstruct meaningful data from
> the file. Possibly one sector on each track is so close to the index hole
> that an 8272-style floppy controller can't see it.
Start writing at the index, stop, while writing the last gap, after
the next one.
I know the WD controllers better, but you can't rely on the results
from any "read track" command, as address marks are lost. Might be
useful for debugging, but not for actual data use.
-- glen
Al Kossow
Dec 18, 2012, 5:14:46 PM12/18/12
to
>> I would guess that not all sectors were dumped when the Teledisk image was
>> made
I ran into this when I recently read some Zorba disks. A PC floppy controller
>> made
will miss the first sector (1 and 11). I ended up using a Catweasel to read them.
Hopefully, the physical media still exists.
ldkr...@gmail.com
Mar 3, 2014, 11:43:39 PM3/3/14
to
Bob,
I used the Zor1 Disk definition and see this as the directory:
larry@debian:~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -d compat32.td0
COMPAT COM : FORMAT COM : MS COM : INSTALL COM
MYCOPY COM : ZORBAD PRL : ZORBAD HEX : ZORBAQ PRL
ZORBAQ HEX : Z2000Q PRL : Z2000Q HEX
larry@debian:~/Downloads/cpmtools$
larry@debian:~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -l compat32.td0
0:
-rwxrwxrwx 19072 Dec 31 1969 compat.com
-rwxrwxrwx 22784 Dec 31 1969 format.com
-rwxrwxrwx 4352 Dec 31 1969 install.com
-rwxrwxrwx 11008 Dec 31 1969 ms.com
-rwxrwxrwx 9472 Dec 31 1969 mycopy.com
-rw-rw-rw- 1408 Dec 31 1969 z2000q.hex
-rw-rw-rw- 4480 Dec 31 1969 z2000q.prl
-rw-rw-rw- 1280 Dec 31 1969 zorbad.hex
-rw-rw-rw- 4224 Dec 31 1969 zorbad.prl
-rw-rw-rw- 1280 Dec 31 1969 zorbaq.hex
-rw-rw-rw- 4352 Dec 31 1969 zorbaq.prl
larry@debian:~/Downloads/cpmtools$
Does this list of files, sizes, and dates appear correct to you?
I tried cpmtools with libdsk to access the TD0 Image.
Larry
I used the Zor1 Disk definition and see this as the directory:
larry@debian:~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -d compat32.td0
COMPAT COM : FORMAT COM : MS COM : INSTALL COM
MYCOPY COM : ZORBAD PRL : ZORBAD HEX : ZORBAQ PRL
ZORBAQ HEX : Z2000Q PRL : Z2000Q HEX
larry@debian:~/Downloads/cpmtools$
larry@debian:~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -l compat32.td0
0:
-rwxrwxrwx 19072 Dec 31 1969 compat.com
-rwxrwxrwx 22784 Dec 31 1969 format.com
-rwxrwxrwx 4352 Dec 31 1969 install.com
-rwxrwxrwx 11008 Dec 31 1969 ms.com
-rwxrwxrwx 9472 Dec 31 1969 mycopy.com
-rw-rw-rw- 1408 Dec 31 1969 z2000q.hex
-rw-rw-rw- 4480 Dec 31 1969 z2000q.prl
-rw-rw-rw- 1280 Dec 31 1969 zorbad.hex
-rw-rw-rw- 4224 Dec 31 1969 zorbad.prl
-rw-rw-rw- 1280 Dec 31 1969 zorbaq.hex
-rw-rw-rw- 4352 Dec 31 1969 zorbaq.prl
larry@debian:~/Downloads/cpmtools$
Does this list of files, sizes, and dates appear correct to you?
I tried cpmtools with libdsk to access the TD0 Image.
Larry
ldkr...@gmail.com
Mar 3, 2014, 11:59:17 PM3/3/14
to
Cpmtools Version 2.18 (pre-release) and Libdsk Version 1.3.5
/usr/local/share/diskdefs Zorba Definition:
diskdef zor1
seclen 512 #= Sectors xx,512
tracks 80 #= (Cylinders * Sides) = 40*1 = 40
sectrk 10 #= Sectors 10,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 64 #= (DRM+1) = 64
skew 0 #= SKEW 0
boottrk 2 #= OFS = 2
os 2.2
end
diskdef zor2
seclen 512 #= Sectors xx,512
tracks 160 #= (Cylinders * Sides) = 40*1 = 40
sectrk 10 #= Sectors 10,xxx
blocksize 4096 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 64
skew 0 #= SKEW 0
boottrk 2 #= OFS = 2
os 2.2
end
/home/user/.libdskrc Definition:
[zor1]
description = Zorba - DSDD 48 tpi 5.25"
sides=alt
cylinders = 80
heads = 2
sectors = 10
secbase = 1
secsize = 512
datarate = DD
rwgap = 12
fmtgap = 23
fm = N
multitrack = N
skipdeleted = Y
[zor2]
description = Zorba - DSDD 48 tpi 5.25"
sides=alt
cylinders = 160
heads = 2
sectors = 10
secbase = 1
secsize = 512
datarate = DD
rwgap = 12
fmtgap = 23
fm = N
multitrack = N
skipdeleted = Y
Commands:
~/Downloads/cpmtools$ cpmls -f zor2 -T tele,zor2 -d compat32.td0
~/Downloads/cpmtools$ cpmls -f zor2 -T tele,zor2 -i compat32.td0
Larry
/usr/local/share/diskdefs Zorba Definition:
diskdef zor1
seclen 512 #= Sectors xx,512
tracks 80 #= (Cylinders * Sides) = 40*1 = 40
sectrk 10 #= Sectors 10,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 64 #= (DRM+1) = 64
skew 0 #= SKEW 0
boottrk 2 #= OFS = 2
os 2.2
end
diskdef zor2
seclen 512 #= Sectors xx,512
tracks 160 #= (Cylinders * Sides) = 40*1 = 40
sectrk 10 #= Sectors 10,xxx
blocksize 4096 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 64
skew 0 #= SKEW 0
boottrk 2 #= OFS = 2
os 2.2
end
/home/user/.libdskrc Definition:
[zor1]
description = Zorba - DSDD 48 tpi 5.25"
sides=alt
cylinders = 80
heads = 2
sectors = 10
secbase = 1
secsize = 512
datarate = DD
rwgap = 12
fmtgap = 23
fm = N
multitrack = N
skipdeleted = Y
[zor2]
description = Zorba - DSDD 48 tpi 5.25"
sides=alt
cylinders = 160
heads = 2
sectors = 10
secbase = 1
secsize = 512
datarate = DD
rwgap = 12
fmtgap = 23
fm = N
multitrack = N
skipdeleted = Y
Commands:
~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -d compat32.td0
~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -l compat32.td0
~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -F compat32.td0
~/Downloads/cpmtools$ cpmls -f zor2 -T tele,zor2 -d compat32.td0
~/Downloads/cpmtools$ cpmls -f zor2 -T tele,zor2 -i compat32.td0
Larry
Bob
Jun 22, 2014, 11:38:14 AM6/22/14
to
the extracted files I obtained were incoherent jumbles of mixed-up
sectors.
I'll give it another look, based on your input.
dott.Piergiorgio
Jun 23, 2014, 3:26:07 AM6/23/14
to
Il 22/06/2014 17:38, Bob ha scritto:
> On Mon, 03 Mar 2014 20:43:39 -0800, ldkraemer wrote:
>
>> Bob,
>> I used the Zor1 Disk definition and see this as the directory:
>> larry@debian:~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -d
>> compat32.td0 COMPAT COM : FORMAT COM : MS COM : INSTALL COM
>> MYCOPY COM : ZORBAD PRL : ZORBAD HEX : ZORBAQ PRL ZORBAQ HEX :
>> Z2000Q PRL : Z2000Q HEX larry@debian:~/Downloads/cpmtools$
>>
>> larry@debian:~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -l
>> compat32.td0 0:
>> -rwxrwxrwx 19072 Dec 31 1969 compat.com -rwxrwxrwx 22784 Dec 31
>> 1969 format.com -rwxrwxrwx 4352 Dec 31 1969 install.com -rwxrwxrwx
>> 11008 Dec 31 1969 ms.com -rwxrwxrwx 9472 Dec 31 1969 mycopy.com
>> -rw-rw-rw- 1408 Dec 31 1969 z2000q.hex -rw-rw-rw- 4480 Dec 31
>> 1969 z2000q.prl -rw-rw-rw- 1280 Dec 31 1969 zorbad.hex -rw-rw-rw-
>> 4224 Dec 31 1969 zorbad.prl -rw-rw-rw- 1280 Dec 31 1969 zorbaq.hex
>> -rw-rw-rw- 4352 Dec 31 1969 zorbaq.prl
>> larry@debian:~/Downloads/cpmtools$
>>
>> Does this list of files, sizes, and dates appear correct to you?
if Zor1 means "zork I" I'm 1000% sure it's all wrong. there should be an
> On Mon, 03 Mar 2014 20:43:39 -0800, ldkraemer wrote:
>
>> Bob,
>> I used the Zor1 Disk definition and see this as the directory:
>> larry@debian:~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -d
>> compat32.td0 COMPAT COM : FORMAT COM : MS COM : INSTALL COM
>> MYCOPY COM : ZORBAD PRL : ZORBAD HEX : ZORBAQ PRL ZORBAQ HEX :
>> Z2000Q PRL : Z2000Q HEX larry@debian:~/Downloads/cpmtools$
>>
>> larry@debian:~/Downloads/cpmtools$ cpmls -f zor1 -T tele,zor1 -l
>> compat32.td0 0:
>> -rwxrwxrwx 19072 Dec 31 1969 compat.com -rwxrwxrwx 22784 Dec 31
>> 1969 format.com -rwxrwxrwx 4352 Dec 31 1969 install.com -rwxrwxrwx
>> 11008 Dec 31 1969 ms.com -rwxrwxrwx 9472 Dec 31 1969 mycopy.com
>> -rw-rw-rw- 1408 Dec 31 1969 z2000q.hex -rw-rw-rw- 4480 Dec 31
>> 1969 z2000q.prl -rw-rw-rw- 1280 Dec 31 1969 zorbad.hex -rw-rw-rw-
>> 4224 Dec 31 1969 zorbad.prl -rw-rw-rw- 1280 Dec 31 1969 zorbaq.hex
>> -rw-rw-rw- 4352 Dec 31 1969 zorbaq.prl
>> larry@debian:~/Downloads/cpmtools$
>>
>> Does this list of files, sizes, and dates appear correct to you?
zip.com of around ~8k and a zork.dat (or zork1.dat) around ~100-110k
Best regards from Italy,
dott. Piergiorgio.
p.s. yes, I'm an old skool adventurer... and I still use much more the
keyboard than the mouse in steering my machines
Jay_in_Dallas
Jun 26, 2014, 8:59:52 PM6/26/14
to
ZORBA DISK: CANNOT READ SECTOR 1 & 11:
======================================
Sounds like the problem is an artifact in IBM format supporting FDC.
IBM Format writes a index marker section (GAP0+SYNC+IAM) on the media following the physical index pulse... before GAP1. ISO format just starts with GAP1 after seeing the physical index pulse.
IBM Format adds 47 bytes to the track in single density (FM) or 96 bytes in double density (MFM) depending on the GAP0 setting.
Usually that's not a problem with the normal sector size and count written to tracks. The IAM section is redundant and of no real value to FDCs; it was probably a plan to remove the physical index hole and detector someday which could reduce FDD costs and speed up formatting.
Previously mentioned documentation said Zorba had 20 sectors so its likely Zorba designers PUSHED the cylinder/track format to get more data on it.
They're likely using ISO format and not IBM so it would start writing GAP1 after the physical index pulse. Zorba likely shortened some of the other GAP1-4 lengths, maybe even the sync byte count.
I think it was Al that said he couldn't read Sector 1 Head 0 nor Sector 11 Head 1. Both are the first physical sector of a cylinder's two tracks. This is consistent with the information collected, suggesting the track format on the PC's FDC is running past the reappearance of the index mark and overwriting sector 1 (and 11).
When you write an extended sector count track on a FDC that adds the IAM section and normal sized GAP1-4, the last sector GAP3 may be written just past the index pulse coming around the second time. GAP4 is usually implemented to write NNN count of bytes BUT to stop immediately if the physical index pulse is seen. If you have passed the index pulse before writing GAP4, you'll never see that terminating condition so it will write out all NNN GAP4 bytes over physical sector 1 (and 11).
In effect the last of the track format overwrites the beginning; that is why Sector 1 and 11 cannot be read. If the FDC in the PC isn't intended to be flexible with various track formatting, it may not even look for that GAP4 terminating condition... leading to possible overwrite of Sector 1 (and 11).
When the FDC is later tasked to read that sector, its never found because it never gets a clean ID Address Mark and header field read.
POSSIBLE FIXES:
=============
If your PC FDC allows ISO format (no IAM section) choose that.
If the FDC always inserts the IAM section, minimize GAP0 and the SYNC before IAM.
Odds are that alone won't work so you'll need to shorten some of the normal format gaps.
If the PC's FDC doesn't stop writing GAP4 bytes when the physical index pulse reappears then you could probably tweak the GAP4 count until you can read Sector 1. Then reduce GAP4 another 10% for speed variations and you'll likely read Sector 1 and 11 thereafter.
If the PC FDC terminates GAP4 on a physical index pulse and if removing the IAM section wasn't enough to read Sector 1, then you next need to shorten GAP3.
GAP3 follows every sector so any bytes you shorten from GAP3 are multiplied by the total number of sectors on the track. This is your best adjustment if the format runs past the subsequent index pulse before writing GAP4.
Don't mess with GAP2 (between the header and data fields of the sector). That's the most critical timing to write data into sectors.
If it still overruns the sectors, GAP1 would be the last easy modification. Its timing is to allow various FDDs time to respond after seeing and index pulse. Its probably excessive.
-Jay in Dallas
======================================
Sounds like the problem is an artifact in IBM format supporting FDC.
IBM Format writes a index marker section (GAP0+SYNC+IAM) on the media following the physical index pulse... before GAP1. ISO format just starts with GAP1 after seeing the physical index pulse.
IBM Format adds 47 bytes to the track in single density (FM) or 96 bytes in double density (MFM) depending on the GAP0 setting.
Usually that's not a problem with the normal sector size and count written to tracks. The IAM section is redundant and of no real value to FDCs; it was probably a plan to remove the physical index hole and detector someday which could reduce FDD costs and speed up formatting.
Previously mentioned documentation said Zorba had 20 sectors so its likely Zorba designers PUSHED the cylinder/track format to get more data on it.
They're likely using ISO format and not IBM so it would start writing GAP1 after the physical index pulse. Zorba likely shortened some of the other GAP1-4 lengths, maybe even the sync byte count.
I think it was Al that said he couldn't read Sector 1 Head 0 nor Sector 11 Head 1. Both are the first physical sector of a cylinder's two tracks. This is consistent with the information collected, suggesting the track format on the PC's FDC is running past the reappearance of the index mark and overwriting sector 1 (and 11).
When you write an extended sector count track on a FDC that adds the IAM section and normal sized GAP1-4, the last sector GAP3 may be written just past the index pulse coming around the second time. GAP4 is usually implemented to write NNN count of bytes BUT to stop immediately if the physical index pulse is seen. If you have passed the index pulse before writing GAP4, you'll never see that terminating condition so it will write out all NNN GAP4 bytes over physical sector 1 (and 11).
In effect the last of the track format overwrites the beginning; that is why Sector 1 and 11 cannot be read. If the FDC in the PC isn't intended to be flexible with various track formatting, it may not even look for that GAP4 terminating condition... leading to possible overwrite of Sector 1 (and 11).
When the FDC is later tasked to read that sector, its never found because it never gets a clean ID Address Mark and header field read.
POSSIBLE FIXES:
=============
If your PC FDC allows ISO format (no IAM section) choose that.
If the FDC always inserts the IAM section, minimize GAP0 and the SYNC before IAM.
Odds are that alone won't work so you'll need to shorten some of the normal format gaps.
If the PC's FDC doesn't stop writing GAP4 bytes when the physical index pulse reappears then you could probably tweak the GAP4 count until you can read Sector 1. Then reduce GAP4 another 10% for speed variations and you'll likely read Sector 1 and 11 thereafter.
If the PC FDC terminates GAP4 on a physical index pulse and if removing the IAM section wasn't enough to read Sector 1, then you next need to shorten GAP3.
GAP3 follows every sector so any bytes you shorten from GAP3 are multiplied by the total number of sectors on the track. This is your best adjustment if the format runs past the subsequent index pulse before writing GAP4.
Don't mess with GAP2 (between the header and data fields of the sector). That's the most critical timing to write data into sectors.
If it still overruns the sectors, GAP1 would be the last easy modification. Its timing is to allow various FDDs time to respond after seeing and index pulse. Its probably excessive.
-Jay in Dallas
glen herrmannsfeldt
Jun 26, 2014, 10:39:41 PM6/26/14
to
Jay_in_Dallas <jay....@earthlink.net> wrote:
> ZORBA DISK: CANNOT READ SECTOR 1 & 11:
> ======================================
> Sounds like the problem is an artifact in IBM format supporting FDC.
> IBM Format writes a index marker section (GAP0+SYNC+IAM) on the
> media following the physical index pulse... before GAP1. ISO format
> just starts with GAP1 after seeing the physical index pulse.
> IBM Format adds 47 bytes to the track in single density (FM)
> or 96 bytes in double density (MFM) depending on the GAP0 setting.
> Usually that's not a problem with the normal sector size and count
> written to tracks. The IAM section is redundant and of no real
> value to FDCs; it was probably a plan to remove the physical
> index hole and detector someday which could reduce FDD costs and
> speed up formatting.
As far as I know, it is related to the disk formats that IBM has used
> ZORBA DISK: CANNOT READ SECTOR 1 & 11:
> ======================================
> Sounds like the problem is an artifact in IBM format supporting FDC.
> IBM Format writes a index marker section (GAP0+SYNC+IAM) on the
> media following the physical index pulse... before GAP1. ISO format
> just starts with GAP1 after seeing the physical index pulse.
> IBM Format adds 47 bytes to the track in single density (FM)
> or 96 bytes in double density (MFM) depending on the GAP0 setting.
> Usually that's not a problem with the normal sector size and count
> written to tracks. The IAM section is redundant and of no real
> value to FDCs; it was probably a plan to remove the physical
> index hole and detector someday which could reduce FDD costs and
> speed up formatting.
for years. OS/360 disks have R0 (record 0) before the actual data
blocks on the disk. It might be related to flagging bad tracks.
It might also be that IAM is used for the READ TRACK command on FDCs
that support it. READ TRACK reads the whole track, including address
marks (but you can't recognize AMs, as the special bits are lost).
> Previously mentioned documentation said Zorba had 20 sectors so its
> likely Zorba designers PUSHED the cylinder/track format to get more
> data on it.
have larger speed variations. I remember when I used to adjust the
speed of my drives using a fluorescent lamp and the strobe marks
on the drive pulley.
> They're likely using ISO format and not IBM so it would start
> writing GAP1 after the physical index pulse. Zorba likely shortened
> some of the other GAP1-4 lengths, maybe even the sync byte count.
that is supposed to be there.
> I think it was Al that said he couldn't read Sector 1 Head 0 nor
> Sector 11 Head 1. Both are the first physical sector of a
> cylinder's two tracks. This is consistent with the information
> collected, suggesting the track format on the PC's FDC is running
> past the reappearance of the index mark and overwriting
> sector 1 (and 11).
pretty carefully. As well as I knew it, the FDC is supposed to stop
formatting when it gets to the index pulse. The first gap has to be
large enough to allow for uncertainty in the timing of index
detection.
> When you write an extended sector count track on a FDC that adds
> the IAM section and normal sized GAP1-4, the last sector GAP3 may
> be written just past the index pulse coming around the second time.
> GAP4 is usually implemented to write NNN count of bytes BUT to stop
> immediately if the physical index pulse is seen. If you have
> passed the index pulse before writing GAP4, you'll never see that
> terminating condition so it will write out all NNN GAP4 bytes over
> physical sector 1 (and 11).
The data input during format write has to say write the IAM if you
want one written. But it is likely that formatting programs are
written to do that.
> In effect the last of the track format overwrites the beginning;
> that is why Sector 1 and 11 cannot be read. If the FDC in the PC
> isn't intended to be flexible with various track formatting, it
> may not even look for that GAP4 terminating condition... leading
> to possible overwrite of Sector 1 (and 11).
> When the FDC is later tasked to read that sector, its never found
> because it never gets a clean ID Address Mark and header field read.
and should say exactly what they do in this case. But making the
gaps smaller than the specification isn't the way they are supposed
to be used.
-- glen
Jay_in_Dallas
Jun 27, 2014, 10:00:19 AM6/27/14
to
Glen wrote:
> The IBM gaps are a little conservative, but then older drives
> could have larger speed variations. ...If they are that short,
> The IBM gaps are a little conservative, but then older drives
> I think they lose much of the speed tolerance that is supposed
> to be there.
But from the Zorba company perspective, they bought and installed all the floppy disk drives that would ever run on Zorba computers and that only Zorba computers would ever format a Zorba diskette.
> to be there.
They were competing with Kaypro and other manufacturers of "Transportable" computers (aka Luggables). As long as they bought only OEM drives that could manage any format tweaks they designed in, there was no problem.
35 Years later, we don't naturally think of it that way. When restoring systems, your choice of floppy disk drives are not as good as they were back in the day. With greater variance among drives that might now be installed in Zorbas or that now might format a Zorba disk, those gaps might not work with ever combination.
But the problem from the way I understand it is that the Zorba disk images in question were made on a PC disk drive using the controller they designed in. Those systems have a track record of working well but the Zorba case suggests it doesn't work as well when the target system (Zorba) has pushed the limits of data extension by tweaking the floppy format.
Glen wrote:
> My first systems used the WDC 1793, and I used to read the
> data sheet pretty carefully.
Jay wrote:
> ... leading to possible overwrite of Sector 1 (and 11).
Glen wrote:
> Seems possible, but it shouldn't happen with a proper format.
Zorba diskettes work fine on Zorba equipment. Technically that ends the system bound of Zorba systems working right. If they made some tweaks on the format that required better OEM drives and perhaps shorter gaps in the track formats, apparently it worked fine on Zorba systems thus making it a proper format.
> Seems possible, but it shouldn't happen with a proper format.
The problem experienced today is a different system bound; its not just Zorba equipment. It involves another system not designed for the same purpose and with its different set of system goals. That different system is trying to make a Zorba image and failing. That's not saying the system isn't good, its just saying that it appears it can't go far enough to do Zorba formats (yet).
A good reference document I have from back in the day (I don't know if its online):
--- Shugart, Format Maunal 8 Inch Floppy, December 1981.
A lot of the Floppy Disk Drive manuals also include good information about formatting 8in and 5 1/4in diskettes.
The FDC manuals have some, mostly geared to its specific use and register feeding sequences. A lot seemed to be rushed into print with many uncorrected errors. Among NEC, SMC, WD and HITACHI, I found the latter best. I think its a later model and offered more features including an ISO format with no IAM section.
-Jay in Dallas
Jay_in_Dallas
Jun 27, 2014, 10:12:48 AM6/27/14
to
Glen wrote:
> But making the gaps smaller than the specification isn't the way
> they are supposed to be used.
Actually the gap values are not set in stone.
> But making the gaps smaller than the specification isn't the way
> they are supposed to be used.
Section VII (I think) of that Shugart Disk Format document referenced above, has the worksheets for setting gaps for any intended format. It even covers some aspects of hard sector formats.
I do agree with you that when dealing with FDCs, its dangerous for most people to ignore their gap suggestions. Messing with gaps, syncs and markers is not a trivial pursuit... but that doesn't mean its improper.
-Jay in Dallas
glen herrmannsfeldt
Jun 27, 2014, 10:42:55 AM6/27/14
to
Jay_in_Dallas <jay....@earthlink.net> wrote:
(snip)
Hmmm. In that case, they could have slowed down the drives to whatever
speed they happened to want. Maybe just a tiny bit. If you aren't
following the standard, there is no reason not to do it!
-- glen
(snip)
> Glen wrote:
>> The IBM gaps are a little conservative, but then older drives
>> could have larger speed variations. ...If they are that short,
>> I think they lose much of the speed tolerance that is supposed
>> to be there.
> But from the Zorba company perspective, they bought and installed
> all the floppy disk drives that would ever run on Zorba computers
> and that only Zorba computers would ever format a Zorba diskette.
(snip)
>> The IBM gaps are a little conservative, but then older drives
>> could have larger speed variations. ...If they are that short,
>> I think they lose much of the speed tolerance that is supposed
>> to be there.
> But from the Zorba company perspective, they bought and installed
> all the floppy disk drives that would ever run on Zorba computers
> and that only Zorba computers would ever format a Zorba diskette.
Hmmm. In that case, they could have slowed down the drives to whatever
speed they happened to want. Maybe just a tiny bit. If you aren't
following the standard, there is no reason not to do it!
-- glen
Axel Berger
Jun 27, 2014, 8:58:00 AM6/27/14
to
glen herrmannsfeldt wrote on Fri, 14-06-27 04:39:
One advice given was to adjust drives to run just a little slow.
>I remember when I used to adjust the speed of my drives using a
>fluorescent lamp and the strobe marks on the drive pulley.
I remember disk formats for the Atari optimsed for space and for speed.
>fluorescent lamp and the strobe marks on the drive pulley.
One advice given was to adjust drives to run just a little slow.
glen herrmannsfeldt
Jun 27, 2014, 7:34:47 PM6/27/14
to
Axel Berger <Axel_...@b.maus.de> wrote:
(snip, I wrote)
http://bitsavers.informatik.uni-stuttgart.de/pdf/shugart/_appNotes/Lesea_Floppy_May78.pdf
also:
http://homepage.ntlworld.com/mark.woodmass/necfdc.htm
-- glen
(snip, I wrote)
>>I remember when I used to adjust the speed of my drives using a
>>fluorescent lamp and the strobe marks on the drive pulley.
> I remember disk formats for the Atari optimsed for space and for speed.
> One advice given was to adjust drives to run just a little slow.
You might look at:
>>fluorescent lamp and the strobe marks on the drive pulley.
> I remember disk formats for the Atari optimsed for space and for speed.
> One advice given was to adjust drives to run just a little slow.
http://bitsavers.informatik.uni-stuttgart.de/pdf/shugart/_appNotes/Lesea_Floppy_May78.pdf
also:
http://homepage.ntlworld.com/mark.woodmass/necfdc.htm
-- glen
Jay_in_Dallas
Jun 28, 2014, 10:03:52 PM6/28/14
to
CONCLUSION: Zorba Format Over-run wiped out sector 1 and 11:
============================================================
ZORBA DSDD MINIFLOPPY FORMAT: 10 Sectors of 512 bytes, per track:
-----------------------------------------------------------------
I looked through my various FDD, System and FDC documentation to how 10 sectors of 512 bytes was considered, back in the day.
--- Shugart, OEM Manual, 1983, SA455/465, Double-sided Minifloppy Diskette Storage Drive, P/N 39238-1
Page 1-2 lists some formatted storage capacity for the two drives and both densities:
First lists is 16 records/track at 128 (SD) and 256 (DD).
*Next lists 10 records/track at 256 (SD) and 512 (DD). (*BINGO*)
Not a typo either because the list 5120 bytes per formatted track
So SHUGART considered 10 sectors of 512 bytes to be sensible.
--- Technical User's Manual, Southern Pacific LTD, Mountain Side Computer, MSC-LAT:
(A 64180 CP/M Plus computer I bought 03/18/1986)
"LAT Disk Format Specifications" (19th page from cover)
First line in the table lists 10 sectors of 512B:
"5 1/4" DDSS 190KB 512 bytes/sector 10 sector 40 tracks (Kaypro II format)" (*BINGO*)
So 10x512 format is an existing double density format for 5.25 inch drives. Even as common as Kaypro.
FDC DOCUMENTS ONLY MENTION 8 SECTORS OF 512 BYTES DOUBLE DENSITY:
-----------------------------------------------------------------
But as I went the the FDCs for various chips among Hitachi, NEC, SMC and WD, the all gave their 512 byte sector size example (when provided) as 8 sectors of 512 bytes per track.
That means the FDC companies were generally suggesting a loss of 1K per track (2 sectors of 512 bytes).
Why, is open to speculation.
Did they base the number upon ratiometric extension of IBM Format 34 (DD)?
Did their chip really require more gap time? Was that due to register loading time?
Was the phase lock loop performing only at this level?
Perhaps they simply wanted to avoid the tech-support calls asking about more difficult formats?
SURVEY CONCLUSION:
------------------
A 5.25inch floppy using 10 sectors of 512 bytes was *not* insane or particularly risky format.
In fact one document suggests that the Kaypro II used that format.
ZORBA CONCLUSION:
---------------------------
(1) If the PC program that formatted the ZORBA diskette with previously stated problems, used the GAP3 and GAP4 lengths that the FDC suggested for 8x512 sector formatting,
(2) ...then its assured that the format went long and overwrote sector 1 head 0 and sector 2 head 1. The byte over-run was two 512 sectors and two GAP3s. This fits the theory that the index pulse reappeared before GAP4 was started, as it would normally terminate upon seeing the Index Pulse.
(3) Solution: Fix the formatting bug to support 10x512 with proper GAP1-4 values.
-Jay in Dallas
============================================================
ZORBA DSDD MINIFLOPPY FORMAT: 10 Sectors of 512 bytes, per track:
-----------------------------------------------------------------
I looked through my various FDD, System and FDC documentation to how 10 sectors of 512 bytes was considered, back in the day.
--- Shugart, OEM Manual, 1983, SA455/465, Double-sided Minifloppy Diskette Storage Drive, P/N 39238-1
Page 1-2 lists some formatted storage capacity for the two drives and both densities:
First lists is 16 records/track at 128 (SD) and 256 (DD).
*Next lists 10 records/track at 256 (SD) and 512 (DD). (*BINGO*)
Not a typo either because the list 5120 bytes per formatted track
So SHUGART considered 10 sectors of 512 bytes to be sensible.
--- Technical User's Manual, Southern Pacific LTD, Mountain Side Computer, MSC-LAT:
(A 64180 CP/M Plus computer I bought 03/18/1986)
"LAT Disk Format Specifications" (19th page from cover)
First line in the table lists 10 sectors of 512B:
"5 1/4" DDSS 190KB 512 bytes/sector 10 sector 40 tracks (Kaypro II format)" (*BINGO*)
So 10x512 format is an existing double density format for 5.25 inch drives. Even as common as Kaypro.
FDC DOCUMENTS ONLY MENTION 8 SECTORS OF 512 BYTES DOUBLE DENSITY:
-----------------------------------------------------------------
But as I went the the FDCs for various chips among Hitachi, NEC, SMC and WD, the all gave their 512 byte sector size example (when provided) as 8 sectors of 512 bytes per track.
That means the FDC companies were generally suggesting a loss of 1K per track (2 sectors of 512 bytes).
Why, is open to speculation.
Did they base the number upon ratiometric extension of IBM Format 34 (DD)?
Did their chip really require more gap time? Was that due to register loading time?
Was the phase lock loop performing only at this level?
Perhaps they simply wanted to avoid the tech-support calls asking about more difficult formats?
SURVEY CONCLUSION:
------------------
A 5.25inch floppy using 10 sectors of 512 bytes was *not* insane or particularly risky format.
In fact one document suggests that the Kaypro II used that format.
ZORBA CONCLUSION:
---------------------------
(1) If the PC program that formatted the ZORBA diskette with previously stated problems, used the GAP3 and GAP4 lengths that the FDC suggested for 8x512 sector formatting,
(2) ...then its assured that the format went long and overwrote sector 1 head 0 and sector 2 head 1. The byte over-run was two 512 sectors and two GAP3s. This fits the theory that the index pulse reappeared before GAP4 was started, as it would normally terminate upon seeing the Index Pulse.
(3) Solution: Fix the formatting bug to support 10x512 with proper GAP1-4 values.
-Jay in Dallas
Jay_in_Dallas
Jun 28, 2014, 10:46:34 PM6/28/14
to
THE UNRESOLVED SYMPTOM: SECTOR DATA SUGGESTED NO UNIFIED SKEW:
--------------------------------------------------------------
Its also wouldn't hurt to verify that the floppy image program accepts a skew of ZERO and correctly places the data in the appropriate sectors. This potential error might be indicated by the comment that some of the sector contents didn't suggest an obvious skew number.
When the original image was made, the operator might have used a SKEW of 1 instead of a skew of ZERO. Compounding chaos may lead to data being in the wrong sectors. Its not worth figuring out how to undo it until its first known to have happened.
SKEW OF ZERO LIKELY MEANS PHYSICAL SECTOR INTERLEAVE:
-----------------------------------------------------
A SKEW of ZERO may suggest that physical sector interleave was formatted into the track instead of using the CP/M skew table. In that case the imaging software wouldn't know the physical SKEW factor unless it attained the physical order of sector numbers on the track. That doesn't affect anything except giving the image diskette no interleave - with a SKEW of ZERO, it should place all sectors (and associated data) in sequentially numbered and placed sectors. That only sacrifices access speed, but allows the software to be read by the target system.
GET PHYSICAL SECTOR INTERLEAVE FORMATS ON THE TARGET SYSTEM:
------------------------------------------------------------
In the ZORBA case (or any ZERO Skew), the parameter likely indicates physical sector interleave use instead of skew tables. It would be best to use the image disk to load the system onto the target system, and immediately have the target system format new diskettes and transfer the system software to those formatted diskettes.
Only those new diskettes that the target system formats will have proper physical sector interleave as the target system was intended to use. Those new formats will have the access speed advantages of skewing.
-Jay in Dallas
--------------------------------------------------------------
Its also wouldn't hurt to verify that the floppy image program accepts a skew of ZERO and correctly places the data in the appropriate sectors. This potential error might be indicated by the comment that some of the sector contents didn't suggest an obvious skew number.
When the original image was made, the operator might have used a SKEW of 1 instead of a skew of ZERO. Compounding chaos may lead to data being in the wrong sectors. Its not worth figuring out how to undo it until its first known to have happened.
SKEW OF ZERO LIKELY MEANS PHYSICAL SECTOR INTERLEAVE:
-----------------------------------------------------
A SKEW of ZERO may suggest that physical sector interleave was formatted into the track instead of using the CP/M skew table. In that case the imaging software wouldn't know the physical SKEW factor unless it attained the physical order of sector numbers on the track. That doesn't affect anything except giving the image diskette no interleave - with a SKEW of ZERO, it should place all sectors (and associated data) in sequentially numbered and placed sectors. That only sacrifices access speed, but allows the software to be read by the target system.
GET PHYSICAL SECTOR INTERLEAVE FORMATS ON THE TARGET SYSTEM:
------------------------------------------------------------
In the ZORBA case (or any ZERO Skew), the parameter likely indicates physical sector interleave use instead of skew tables. It would be best to use the image disk to load the system onto the target system, and immediately have the target system format new diskettes and transfer the system software to those formatted diskettes.
Only those new diskettes that the target system formats will have proper physical sector interleave as the target system was intended to use. Those new formats will have the access speed advantages of skewing.
-Jay in Dallas
Axel Berger
Jun 29, 2014, 12:08:00 AM6/29/14
to
Jay_in_Dallas wrote on Sun, 14-06-29 04:03:
between Atari and IBM-PC were tackled. (N.B: Atari did things *exactly*
as per IBM's specifications and never had had any trouble reading IBM
written and formatted disks. IBM's specs and IBM's way of doing things
were quite different in parts though, and it took people some time to
learn how to write and format for the IBM.)
One insurmountable hardware bug was the 765 FC. WD's FCs could and did
read and write right after the index hole, the 765 went -- and goes! --
deaf for quite some time after it occurs. So from the index pulse you
need rather a long gap before the first sector header and ten,
certainly 11 sector formats usually did not have it.
Axel
>Solution: Fix the formatting bug
There is one more known problem. I came upon when the incompatibilties
between Atari and IBM-PC were tackled. (N.B: Atari did things *exactly*
as per IBM's specifications and never had had any trouble reading IBM
written and formatted disks. IBM's specs and IBM's way of doing things
were quite different in parts though, and it took people some time to
learn how to write and format for the IBM.)
One insurmountable hardware bug was the 765 FC. WD's FCs could and did
read and write right after the index hole, the 765 went -- and goes! --
deaf for quite some time after it occurs. So from the index pulse you
need rather a long gap before the first sector header and ten,
certainly 11 sector formats usually did not have it.
Axel
glen herrmannsfeldt
Jun 29, 2014, 2:15:17 PM6/29/14
to
Axel Berger <Axel_...@b.maus.de> wrote:
(snip)
index hole, except to count how many go by and give up if it is too
many.
But on format, you start and end by the index hole. As it won't come
out in the exact same place, there is a gap from the index to the
first address mark. If that is too short, and the index sense comes
slightly later, the end gap will write over the beginning sector.
-- glen
(snip)
> There is one more known problem. I came upon when the incompatibilties
> between Atari and IBM-PC were tackled. (N.B: Atari did things *exactly*
> as per IBM's specifications and never had had any trouble reading IBM
> written and formatted disks. IBM's specs and IBM's way of doing things
> were quite different in parts though, and it took people some time to
> learn how to write and format for the IBM.)
> One insurmountable hardware bug was the 765 FC. WD's FCs could and did
> read and write right after the index hole, the 765 went -- and goes! --
> deaf for quite some time after it occurs. So from the index pulse you
> need rather a long gap before the first sector header and ten,
> certainly 11 sector formats usually did not have it.
As far as I know it, for sector read and write you don't look for the
> between Atari and IBM-PC were tackled. (N.B: Atari did things *exactly*
> as per IBM's specifications and never had had any trouble reading IBM
> written and formatted disks. IBM's specs and IBM's way of doing things
> were quite different in parts though, and it took people some time to
> learn how to write and format for the IBM.)
> One insurmountable hardware bug was the 765 FC. WD's FCs could and did
> read and write right after the index hole, the 765 went -- and goes! --
> deaf for quite some time after it occurs. So from the index pulse you
> need rather a long gap before the first sector header and ten,
> certainly 11 sector formats usually did not have it.
index hole, except to count how many go by and give up if it is too
many.
But on format, you start and end by the index hole. As it won't come
out in the exact same place, there is a gap from the index to the
first address mark. If that is too short, and the index sense comes
slightly later, the end gap will write over the beginning sector.
-- glen
Jay_in_Dallas
Jun 29, 2014, 7:03:47 PM6/29/14
to
THE QUESTION OF GAPS AND SECTOR COUNTS:
---------------------------------------
I'm working on a spreadsheet to tabulate the format/gaps combinations for:
-- 8" and 5.24" drives, for {
---- single and double density, for {
------ various record lengths, for {
-------- various sector counts per track.
It will compute the minimum byte count for gaps rounded up to the nearest byte, and then tally the unusable left-over bytes before allocating them into GAPs for better spacing.
I'm most curious to see:
(1) the minimum gaps required versus the numbers in the FDC manuals, and
(2) the number of unusable bytes left over that will be allocated into additional GAP bytes.
I think a tabulation like this would add more clarity to track formatting because it should reveal how much of each gap is really critical.
I did one quick comparison on a 8in, MFM, 256 byte record length, format to compare actual minimum GAP3 to the WD297x document. Naturally the FDC value will be inflated as some of the unusable bytes are allocated around the track, but I was still surprised. The WD FDC showed a GAP3 (following each sector) of 54 bytes when the computed minimum was only 17 bytes.
And a big factor on GAP3 doesn't apply in most vintage cases; its for situations were you need to immediately read the subsequent sector header which is seldom applicable with skewing or physical sector interleave. I'll have to tabulate those two situations separately.
-Jay in Dallas
---------------------------------------
I'm working on a spreadsheet to tabulate the format/gaps combinations for:
-- 8" and 5.24" drives, for {
---- single and double density, for {
------ various record lengths, for {
-------- various sector counts per track.
It will compute the minimum byte count for gaps rounded up to the nearest byte, and then tally the unusable left-over bytes before allocating them into GAPs for better spacing.
I'm most curious to see:
(1) the minimum gaps required versus the numbers in the FDC manuals, and
(2) the number of unusable bytes left over that will be allocated into additional GAP bytes.
I think a tabulation like this would add more clarity to track formatting because it should reveal how much of each gap is really critical.
I did one quick comparison on a 8in, MFM, 256 byte record length, format to compare actual minimum GAP3 to the WD297x document. Naturally the FDC value will be inflated as some of the unusable bytes are allocated around the track, but I was still surprised. The WD FDC showed a GAP3 (following each sector) of 54 bytes when the computed minimum was only 17 bytes.
And a big factor on GAP3 doesn't apply in most vintage cases; its for situations were you need to immediately read the subsequent sector header which is seldom applicable with skewing or physical sector interleave. I'll have to tabulate those two situations separately.
-Jay in Dallas
glen herrmannsfeldt
Jun 29, 2014, 9:20:44 PM6/29/14
to
Jay_in_Dallas <jay....@earthlink.net> wrote:
(snip on spreadsheet)
> It will compute the minimum byte count for gaps rounded up to the
> nearest byte, and then tally the unusable left-over bytes before
> allocating them into GAPs for better spacing.
> I'm most curious to see:
> (1) the minimum gaps required versus the numbers in the FDC manuals, and
> (2) the number of unusable bytes left over that will be allocated
> into additional GAP bytes.
> I think a tabulation like this would add more clarity to track
> formatting because it should reveal how much of each gap
> is really critical.
The exact use for each gap is different. Some gaps are needed to allow
for tolerance on the rotation speed. You might write a block on a fast
drive, and rewrite it on a slow driver, or vice versa.
I believe it is GAP2 that is the write splice, that is, after reading
the AM it then waits some time to turn on writing, and writes some gap
characters before the actual data. Then, after the sector and CRC, I
believe it writes a little more before turning off the write current.
There could be a glitch as writing is turned on and off, and you want
that a little bit away from the first and last actual bit. Also, for
the PLL data separator to lock properly on reading.
> I did one quick comparison on a 8in, MFM, 256 byte record length,
> format to compare actual minimum GAP3 to the WD297x document.
> Naturally the FDC value will be inflated as some of the unusable
> bytes are allocated around the track, but I was still surprised.
> The WD FDC showed a GAP3 (following each sector) of 54 bytes when
> the computed minimum was only 17 bytes.
I am not sure what speed tolerance IBM uses, but that has some
effect on the gap size.
> And a big factor on GAP3 doesn't apply in most vintage cases;
> its for situations were you need to immediately read the
> subsequent sector header which is seldom applicable with skewing
> or physical sector interleave. I'll have to tabulate those two
> situations separately.
Processors now should be fast enough to read without interleave.
GAP3 has to be long enough to allow for write splice (turning off
the write logic) and speed variations.
-- glen
(snip on spreadsheet)
> It will compute the minimum byte count for gaps rounded up to the
> nearest byte, and then tally the unusable left-over bytes before
> allocating them into GAPs for better spacing.
> I'm most curious to see:
> (1) the minimum gaps required versus the numbers in the FDC manuals, and
> (2) the number of unusable bytes left over that will be allocated
> into additional GAP bytes.
> I think a tabulation like this would add more clarity to track
> formatting because it should reveal how much of each gap
> is really critical.
for tolerance on the rotation speed. You might write a block on a fast
drive, and rewrite it on a slow driver, or vice versa.
I believe it is GAP2 that is the write splice, that is, after reading
the AM it then waits some time to turn on writing, and writes some gap
characters before the actual data. Then, after the sector and CRC, I
believe it writes a little more before turning off the write current.
There could be a glitch as writing is turned on and off, and you want
that a little bit away from the first and last actual bit. Also, for
the PLL data separator to lock properly on reading.
> I did one quick comparison on a 8in, MFM, 256 byte record length,
> format to compare actual minimum GAP3 to the WD297x document.
> Naturally the FDC value will be inflated as some of the unusable
> bytes are allocated around the track, but I was still surprised.
> The WD FDC showed a GAP3 (following each sector) of 54 bytes when
> the computed minimum was only 17 bytes.
effect on the gap size.
> And a big factor on GAP3 doesn't apply in most vintage cases;
> its for situations were you need to immediately read the
> subsequent sector header which is seldom applicable with skewing
> or physical sector interleave. I'll have to tabulate those two
> situations separately.
GAP3 has to be long enough to allow for write splice (turning off
the write logic) and speed variations.
-- glen
Axel Berger
Jun 30, 2014, 12:51:00 AM6/30/14
to
glen herrmannsfeldt wrote on Sun, 14-06-29 20:15:
it's a 765 it takes some time to recover from the surprise.
But then with WDs the read track command never worked correctly, so we
shouldn't judge NEC too smugly.
>for sector read and write you don't look for the index hole
Correct, you don't. But the controller still receives the signal and if
it's a 765 it takes some time to recover from the surprise.
But then with WDs the read track command never worked correctly, so we
shouldn't judge NEC too smugly.
Jay_in_Dallas
Jun 30, 2014, 11:26:01 AM6/30/14
to
glen herrmannsfeldt wrote:
> I am not sure what speed tolerance IBM uses, but that
> has some effect on the gap size.
For 8in drives:
> I am not sure what speed tolerance IBM uses, but that
> has some effect on the gap size.
motor speed tolernaces of +/-3% and
oscillator frequency tolerances of +/-0.1%
glen herrmannsfeldt wrote:
> Processors now should be fast enough to read without interleave.
Even so physical sector interleave was still used on sophisticated winchester applications because it was used to match the way the application program demanded subsequent sectors, not the blind assumption that every access was a large continuous load-file.
Unlike floppy controllers supported by CP/M's skew table, you could format different interleave patterns of various winchester tracks to speed up the type of associated access; an application that would have been nice to carry to floppy bound users. In other words you could have tracks geared to quickly read application programs into memory and other tracks with more interleave supporting the fetch pattern of database programs and such.
Reliance on floppy/winchester disk controllers chips meant you only had cheap access to the limited features those chip manufacturers included; what I called the dumbing-down of data access. ;)
glen herrmannsfeldt wrote:
> Processors now should be fast enough to read without interleave.
-Jay in Dallas
glen herrmannsfeldt
Jun 30, 2014, 2:56:36 PM6/30/14
to
Jay_in_Dallas <jay....@earthlink.net> wrote:
(snip on processor speed and interleave)
> Even so physical sector interleave was still used on
> sophisticated winchester applications because it was used to
> match the way the application program demanded subsequent
> sectors, not the blind assumption that every access was a
> large continuous load-file.
> Unlike floppy controllers supported by CP/M's skew table,
> you could format different interleave patterns of various
> winchester tracks to speed up the type of associated access;
> an application that would have been nice to carry to floppy
> bound users. In other words you could have tracks geared to
> quickly read application programs into memory and other
> tracks with more interleave supporting the fetch pattern
> of database programs and such.
For 8 inch drives, it was usual for disks to come preformatted
in the IBM standard with 128 byte sectors. Disk controllers didn't
need to be able to do format write, and the factory format drives
could have their speed more accurately controlled. It was usual
for sectors to be consecutively numbered.
For 5.25in, before the IBM PC became popular enough, disks normally
came unformatted. That allowed the actual sector numbers to be
written with an interleave, instead of requiring a lookup table.
I am not so sure about earlier hard drives, but in the 5.25in in the
tradition of the ST506 (that is, using the same interface) it was
usual again to format your own disk, and you could select the
interleave.
> Reliance on floppy/winchester disk controllers chips meant you
> only had cheap access to the limited features those chip
> manufacturers included; what I called the dumbing-down of
> data access. ;)
The chips that I know of leave it up to the software to choose
interleave and gap length. Some software let the user choose,
ohters didn't.
(snip, I wrote)
>> Processors now should be fast enough to read without interleave.
> Yes, I did a feasibility study recently proving that "a design"
> could very accurately clone any floppy from one drive to another
> with minimum time on the magnetic media. I'm now exploring
> everything else that can be done with that design.
-- glen
(snip on processor speed and interleave)
> Even so physical sector interleave was still used on
> sophisticated winchester applications because it was used to
> match the way the application program demanded subsequent
> sectors, not the blind assumption that every access was a
> large continuous load-file.
> Unlike floppy controllers supported by CP/M's skew table,
> you could format different interleave patterns of various
> winchester tracks to speed up the type of associated access;
> an application that would have been nice to carry to floppy
> bound users. In other words you could have tracks geared to
> quickly read application programs into memory and other
> tracks with more interleave supporting the fetch pattern
> of database programs and such.
in the IBM standard with 128 byte sectors. Disk controllers didn't
need to be able to do format write, and the factory format drives
could have their speed more accurately controlled. It was usual
for sectors to be consecutively numbered.
For 5.25in, before the IBM PC became popular enough, disks normally
came unformatted. That allowed the actual sector numbers to be
written with an interleave, instead of requiring a lookup table.
I am not so sure about earlier hard drives, but in the 5.25in in the
tradition of the ST506 (that is, using the same interface) it was
usual again to format your own disk, and you could select the
interleave.
> Reliance on floppy/winchester disk controllers chips meant you
> only had cheap access to the limited features those chip
> manufacturers included; what I called the dumbing-down of
> data access. ;)
interleave and gap length. Some software let the user choose,
ohters didn't.
(snip, I wrote)
>> Processors now should be fast enough to read without interleave.
> Yes, I did a feasibility study recently proving that "a design"
> could very accurately clone any floppy from one drive to another
> with minimum time on the magnetic media. I'm now exploring
> everything else that can be done with that design.
Jeff Jonas
Jul 1, 2014, 11:01:00 PM7/1/14
to
>> Even so physical sector interleave was still used on
>> sophisticated winchester applications because it was used to
>> match the way the application program demanded subsequent
>> sectors, not the blind assumption that every access was a
>> large continuous load-file.
Oh noes, I wonder if that means some hard drives
>> sophisticated winchester applications because it was used to
>> match the way the application program demanded subsequent
>> sectors, not the blind assumption that every access was a
>> large continuous load-file.
had a different physical and/or logical skew
per slice/partition.
Even more annoying: dealing with systems
before the partition table was stored on the drive.
It was hard-coded into the system,
or a file contained common schemes (Unix's /etc/disktab?)
That's why friends prefer imagedsk.
It handles floppies where the first track or 2
are a different density or formatting from the rest.
>> Unlike floppy controllers supported by CP/M's skew table,
>> you could format different interleave patterns of various
>> winchester tracks to speed up the type of associated access;
Winchester controller was 3:1 interleave
since it was PIO (programmed I/O, no DMA).
Later controllers supported 2:1, then 1:1 interleave
thanks to faster CPUs and controller DMA.
SMD hard drives had dip switches for sector size,
but I don't remember how skew was handled.
>For 8 inch drives, it was usual for disks to come preformatted
>in the IBM standard with 128 byte sectors.
making pre-formatted media a requirement (and profit center).
Iomega's ZIP drives continued that tradition :-(
>For 5.25in, before the IBM PC became popular enough, disks normally
>came unformatted. That allowed the actual sector numbers to be
>written with an interleave, instead of requiring a lookup table.
for single sided drives to use both sides.
Apple ][ users did that a lot,
thanks to disk notchers for the "write allow" notch.
And Apple's GCR encoding was incompatible with anything else
and didn't care about the sector hole.
>I am not so sure about earlier hard drives, but in the 5.25in in the
>tradition of the ST506 (that is, using the same interface) it was
>usual again to format your own disk, and you could select the
>interleave.
to match the controller/formatter's requirements.
(Masscomp's controller required 600 sector bytes for 512 user data).
After decades of 512 byte sectors, we're finally going to
larger sector sizes for greater capacity and thruput.
Just like the mainframes of the late 80s.
As I keep saying "mainframes did it best,
we're still rediscovering how well".
-- jeffj
glen herrmannsfeldt
Jul 2, 2014, 1:22:56 AM7/2/14
to
Jeff Jonas <je...@panix.com> wrote:
(snip)
> Some systems didn't dare low-level format the media,
> making pre-formatted media a requirement (and profit center).
> Iomega's ZIP drives continued that tradition :-(
Some have embedded servo, which means that you can't bulk erase
them, without erasing the servo data. Many made it difficult to
do a low-level format. Some required a special program from the
drive maker to do it.
(snip)
> I'm sure SMD hard drives had DIP settable sector size,
> to match the controller/formatter's requirements.
> (Masscomp's controller required 600 sector bytes for 512 user data).
> After decades of 512 byte sectors, we're finally going to
> larger sector sizes for greater capacity and thruput.
> Just like the mainframes of the late 80s.
I remember some SCSI drives using 520, that is, 512 plus 8 extra
ECC bytes.
> As I keep saying "mainframes did it best,
> we're still rediscovering how well".
OS/360 CKD drives let you choose any block size from 1 to the
length of a track (or 32767, whichever comes first). That allowed
programs (or users) to optimize disk use vs. buffer size.
On small (8K byte) machines, you might use 80 byte blocks,
on large machines, half track was usual.
-- glen
(snip)
> Some systems didn't dare low-level format the media,
> making pre-formatted media a requirement (and profit center).
> Iomega's ZIP drives continued that tradition :-(
them, without erasing the servo data. Many made it difficult to
do a low-level format. Some required a special program from the
drive maker to do it.
(snip)
> I'm sure SMD hard drives had DIP settable sector size,
> to match the controller/formatter's requirements.
> (Masscomp's controller required 600 sector bytes for 512 user data).
> After decades of 512 byte sectors, we're finally going to
> larger sector sizes for greater capacity and thruput.
> Just like the mainframes of the late 80s.
ECC bytes.
> As I keep saying "mainframes did it best,
> we're still rediscovering how well".
length of a track (or 32767, whichever comes first). That allowed
programs (or users) to optimize disk use vs. buffer size.
On small (8K byte) machines, you might use 80 byte blocks,
on large machines, half track was usual.
-- glen
Jay_in_Dallas
Jul 2, 2014, 2:29:17 AM7/2/14
to
SMD Winchester Controllers:
===========================
Jeffj wrote:
> ...SMD hard drives had dip switches for sector size, but I
I remember one of our drive tests was a IOPB instructing the controller to retract the heads then seek to cylinder X++, incrementing the cylinder each time until a max, then restart.
The funny thing is that it performed like Telsa's "earthquake machine" (harmonic motion frequencies). At some point the retract-seek distance motion would find a harmonic frequency for the lab bench or table the drive was sitting on. It would build to an impressive shaking intensity then subside on the other side of the harmonic. On the CDC Phoenix drive I used as a test drive (not sure about the name; combo removable and fixed platters) it would take about 4 minutes to hit the lab bench harmonic, shake over the next 30 seconds then back to quiet.
Naturally we turned that into an office prank. Any newbie or sales rep would be invited into the lab and after covertly starting the test, one-by-one everyone would leave until the newbie was the only one left. Soon enough we could hear the bench banging against the wall and the newbie calling out for help. We'd stop laughing down the hall, put on our poker-faces and come back to the lab after everything was quiet again. Of course we'd never believe the stories the newbie tried to tell us about the lab. :)
Best illustration of harmonic frequencies ever. :)
Jeffj wrote:
> ...As I keep saying "mainframes did it best,
Not mainframes, certainly not home computers.
-Jay in Dallas
===========================
Jeffj wrote:
> ...SMD hard drives had dip switches for sector size, but I
> don't remember how skew was handled.
No, SMD drives were formatted by the controller board. I designed them for MultiBus boards before going to S.D.System. We used IOPB (I/O Parameter blocks) to control them. Any bus master could write a block of RAM with an instruction structure and tag our board with the address to go pick it up. The controller would DMA it onto the controller board, execute its instruction block and DMA any amount of data back where the IOPB designated.
I remember one of our drive tests was a IOPB instructing the controller to retract the heads then seek to cylinder X++, incrementing the cylinder each time until a max, then restart.
The funny thing is that it performed like Telsa's "earthquake machine" (harmonic motion frequencies). At some point the retract-seek distance motion would find a harmonic frequency for the lab bench or table the drive was sitting on. It would build to an impressive shaking intensity then subside on the other side of the harmonic. On the CDC Phoenix drive I used as a test drive (not sure about the name; combo removable and fixed platters) it would take about 4 minutes to hit the lab bench harmonic, shake over the next 30 seconds then back to quiet.
Naturally we turned that into an office prank. Any newbie or sales rep would be invited into the lab and after covertly starting the test, one-by-one everyone would leave until the newbie was the only one left. Soon enough we could hear the bench banging against the wall and the newbie calling out for help. We'd stop laughing down the hall, put on our poker-faces and come back to the lab after everything was quiet again. Of course we'd never believe the stories the newbie tried to tell us about the lab. :)
Best illustration of harmonic frequencies ever. :)
Jeffj wrote:
> ...As I keep saying "mainframes did it best,
> we're still rediscovering how well".
I'd say minicomputers did it best. That's where the leading edge of technology was.
Not mainframes, certainly not home computers.
-Jay in Dallas
Jay_in_Dallas
Jul 8, 2014, 9:36:57 PM7/8/14
to
THE ISSUE:
============
Basically we're talking about 5 1/4 inch floppy drives, double density (MFM), double sided, 512 bytes per sector. The key question is whether 10 sectors is valid, and if so, under what conditions. My spreadsheet for various permutations shines some light on the Zorba format in question.
FORMAT METHODS CONSIDERED:
==========================
During the course of the discussion, one format heuristic given was to always use the gap byte count suggested in the often FDC cited IBM-3740 (single density) and IBM-34 (double density) formats.
With that and two other formats I've defined, I looked at these three track format methods:
(1) "IBM-3740/-34" :Rule: Always use the gaps from the 8in reference.
(2) "IBM-MinPlus" :Rule: Calculate minimum gaps, allocate leftover bytes among Gaps (4 then 1,3).
(3) "ISO-MinPlus" :Rule: IBM-MinPlus with no Index Address Mark just after the Index Pulse.
GAP4 CLARIFICATION:
===================
Note: GAP4 by definition is the sum of last sector's GAP3, GAP4B (the rest of the track to the index pulse) and GAP4A (aka GAP0, which leads the IBM Index Address Mark block. Thus you would have N sectors and N-1 GAP3s in this definition.
Floppy disk controller chips made a simplifying departure; instead of complicating their integrated circuit, they required a GAP3 after the last sector and then a GAP4 value. The latter value is the GAP4B, which is GAP4 minus the GAP3 and minus the GAP4A that the format began with.
I'll use the FDC convention too. After calculating the GAP4 value, I'll use the GAP4B value as you'd use when feeding an FDC during a track format.
ASSUMPTIONS:
============
Let the SYNC byte length be equal to the IBM formats in all cases.
Let the motor speed tolerance be initially set to +/-3% like the 8 inch drive spec. Note that my Tandon series 5 1/4 drives spec +/-1.5%. It may well be that all 5 1/4 inch floppy drives use +/-1.5% motor speed tolerance but I don't have that definitively stated yet. If the loose 3% tolerance fails, I'll then test at 1.5% tolerance.
Byte capacity of each track is 6,250 bytes nominal(NM) and 6,056 worst-case(WC) under +/-3% motor speeds.
FORMAT (1) PARAMETERS: EIGHT SECTORS OF 512 UNDER IBM-34 GAP SETTINGS:
=====================================================================
Format (1) "IBM-3740/-34" EIGHT SECTORS is characterized by the IMB-34 set:
CONSTANT under(1): GAP4A=80 bytes, GAP1=50, GAP2=22, GAP3=54, GAP4=544 as (598-54).
CONSTANT under(1): 137 bytes of overhead (GAP4a through GAP1)
CONSTANT under(1): sectors of 611 bytes each (ID field sync through GAP3)
With 8 sectors of 512 bytes described under the CONSTANT cases above 1,031 leftover bytes remain under worst-case bytes per track. They can be used for GAP4B and the rest either not written, used to elongate GAP4B or possible distributed to elongate GAPS 1,3 and/or 4.
FORMAT (1) PARAMETERS: TEN SECTORS OF 512 UNDER IBM-34 GAP SETTINGS:
====================================================================
Format (1) "IBM-3740/-34" TEN SECTORS is characterized by the IMB-34 set:
With 10 sectors of 512 bytes described under the CONSTANT cases above -191 leftover bytes remain under worst-case bytes per track. That means the format is 191 bytes away from beginning GAP4B, thus it is writing 191 bytes over the beginning of the track format before it begins trying to write GAP4B.
If the FDC interrupts any track write at the second index pulse, the last sector will appear garbled. More likely it will write the last sector past the index pulse and then GAP4B begins and either terminates immediately upon a saved flag noting the index pulse or it writes its full length and stops. This latter would likely garble two sectors instead of one.
Using the nominal track byte capacity, only 3 bytes are left when GAP4B begins. If the FDC stops on the index pulse, the 10th sector is written with a GAP3 and with the GAP4A undisturbed. GAP4 would be out of spec under the format (1) method.
FORMAT (2) PARAMETERS: TEN SECTORS OF 512 UNDER IBM-MIN.PLUS GAP SETTINGS:
==========================================================================
Format (2) "IBM-MinPlus" TEN SECTORS is characterized by the following calculated GAP sizes:
CONSTANT under(2@512): GAP4A=80 bytes, GAP1=7, GAP2=10, GAP3=40, GAP4=147.
CONSTANT under(2@512): 94 bytes of overhead (GAP4a through GAP1)
CONSTANT under(2@512): sectors of 585 bytes each (ID field sync through GAP3)
With 10 sectors of 512 bytes described under the CONSTANT cases above 112 leftover bytes remain under worst-case bytes per track. This is a little short of the specified GAP4B byte count of 147. Nominal track capacity would achieve it but reliability would be lessened.
So it follows that the ISO format without the Index address mark should be looked at:
FORMAT (3) PARAMETERS: TEN SECTORS OF 512 UNDER ISO-MIN.PLUS GAP SETTINGS:
==========================================================================
Format (3) "ISO-MinPlus" TEN SECTORS is characterized by the following calculated GAP sizes:
CONSTANT under(3@512): GAP1=7 bytes, GAP2=10, GAP3=40, GAP4=147. (same as (2))
CONSTANT under(3@512): 7 bytes of overhead (GAP1 only)
CONSTANT under(3@512): sectors of 585 bytes each (ID field sync through GAP3). (same as (2))
With 10 sectors of 512 bytes described under the CONSTANT cases above 199 leftover bytes remain under worst-case bytes per track. This is sufficient for the 147 bytes for GAP4B, but only leaves 52 bytes for complete the full GAP4 (i.e. the missing 80 bytes normally written at the start for the track format).
Thus this format is short by 28 bytes under worse-case track capacity.
TIME TO TRY A BETTER 5 1/4 INCH FLOPPY DRIVE WITH +/-1.5% MOTOR SPEED TOLERANCE:
================================================================================
So next I try the +/-1.5% motor speed in the spreadsheet calculations, and yes it works in spec as I'll tabulate below. As I made the case previously in the discussion, the company that made the Zorba considered itself the unique-and-only buyer and installer of disk drives into Zorba computers. Thus if they only bought floppy drives that had +/-1.5% motor speed tolerance (or if that is the spec on *ALL* 5 1/4 inch drives), then their format is 100% valid by this example and as the tabulation will show, they'll have excess bytes to extend some of the GAP1,3,4 lengths if they want additional margin of safety.
FORMAT (3) +/-1.5% SPEED PARAMETERS: TEN SECTORS OF 512 UNDER ISO-MIN.PLUS GAP SETTINGS:
========================================================================================
Format (3) "ISO-MinPlus" +/-1.5% SPEED + TEN SECTORS is characterized by:
The better motor speed boosts the worst-case track capacity to 6,150 bytes.
CONSTANT under(3@512+): GAP1=7 bytes, GAP2=10, GAP3=24, GAP4=37.
CONSTANT under(3@512+): 7 bytes of overhead (Gap1 only)
CONSTANT under(3@512+): sectors of 569 bytes each (ID field sync through GAP3).
With 10 sectors of 512 bytes described under the CONSTANT cases above 569 leftover bytes remain under worst-case bytes per track. This is sufficient for the 37+80 bytes for GAP4B+GAP4A written last.
CONCLUSION:
===========
With 5 1/4 inch drives spec'd at +/-1.5%, 10 sectors of 512 bytes double density MFM encoded is completely in spec with margin to spare.
ADDENDUM:
=========
With the +/-1.5% motor speed variable in the spreadsheet, I confirmed its affect on the other formats. I list the results here briefly:
FORMAT (2) IBM-MIN.PLUS: The new results have 366 leftover bytes covering 37+80 bytes for GAP4B+GAP4A written last.
FORMAT (1) IMB-3740/-34: Failed to be completely within spec.
-Jay in Dallas
============
Basically we're talking about 5 1/4 inch floppy drives, double density (MFM), double sided, 512 bytes per sector. The key question is whether 10 sectors is valid, and if so, under what conditions. My spreadsheet for various permutations shines some light on the Zorba format in question.
FORMAT METHODS CONSIDERED:
==========================
During the course of the discussion, one format heuristic given was to always use the gap byte count suggested in the often FDC cited IBM-3740 (single density) and IBM-34 (double density) formats.
With that and two other formats I've defined, I looked at these three track format methods:
(1) "IBM-3740/-34" :Rule: Always use the gaps from the 8in reference.
(2) "IBM-MinPlus" :Rule: Calculate minimum gaps, allocate leftover bytes among Gaps (4 then 1,3).
(3) "ISO-MinPlus" :Rule: IBM-MinPlus with no Index Address Mark just after the Index Pulse.
GAP4 CLARIFICATION:
===================
Note: GAP4 by definition is the sum of last sector's GAP3, GAP4B (the rest of the track to the index pulse) and GAP4A (aka GAP0, which leads the IBM Index Address Mark block. Thus you would have N sectors and N-1 GAP3s in this definition.
Floppy disk controller chips made a simplifying departure; instead of complicating their integrated circuit, they required a GAP3 after the last sector and then a GAP4 value. The latter value is the GAP4B, which is GAP4 minus the GAP3 and minus the GAP4A that the format began with.
I'll use the FDC convention too. After calculating the GAP4 value, I'll use the GAP4B value as you'd use when feeding an FDC during a track format.
ASSUMPTIONS:
============
Let the SYNC byte length be equal to the IBM formats in all cases.
Let the motor speed tolerance be initially set to +/-3% like the 8 inch drive spec. Note that my Tandon series 5 1/4 drives spec +/-1.5%. It may well be that all 5 1/4 inch floppy drives use +/-1.5% motor speed tolerance but I don't have that definitively stated yet. If the loose 3% tolerance fails, I'll then test at 1.5% tolerance.
Byte capacity of each track is 6,250 bytes nominal(NM) and 6,056 worst-case(WC) under +/-3% motor speeds.
FORMAT (1) PARAMETERS: EIGHT SECTORS OF 512 UNDER IBM-34 GAP SETTINGS:
=====================================================================
Format (1) "IBM-3740/-34" EIGHT SECTORS is characterized by the IMB-34 set:
CONSTANT under(1): GAP4A=80 bytes, GAP1=50, GAP2=22, GAP3=54, GAP4=544 as (598-54).
CONSTANT under(1): 137 bytes of overhead (GAP4a through GAP1)
CONSTANT under(1): sectors of 611 bytes each (ID field sync through GAP3)
With 8 sectors of 512 bytes described under the CONSTANT cases above 1,031 leftover bytes remain under worst-case bytes per track. They can be used for GAP4B and the rest either not written, used to elongate GAP4B or possible distributed to elongate GAPS 1,3 and/or 4.
FORMAT (1) PARAMETERS: TEN SECTORS OF 512 UNDER IBM-34 GAP SETTINGS:
====================================================================
Format (1) "IBM-3740/-34" TEN SECTORS is characterized by the IMB-34 set:
With 10 sectors of 512 bytes described under the CONSTANT cases above -191 leftover bytes remain under worst-case bytes per track. That means the format is 191 bytes away from beginning GAP4B, thus it is writing 191 bytes over the beginning of the track format before it begins trying to write GAP4B.
If the FDC interrupts any track write at the second index pulse, the last sector will appear garbled. More likely it will write the last sector past the index pulse and then GAP4B begins and either terminates immediately upon a saved flag noting the index pulse or it writes its full length and stops. This latter would likely garble two sectors instead of one.
Using the nominal track byte capacity, only 3 bytes are left when GAP4B begins. If the FDC stops on the index pulse, the 10th sector is written with a GAP3 and with the GAP4A undisturbed. GAP4 would be out of spec under the format (1) method.
FORMAT (2) PARAMETERS: TEN SECTORS OF 512 UNDER IBM-MIN.PLUS GAP SETTINGS:
==========================================================================
Format (2) "IBM-MinPlus" TEN SECTORS is characterized by the following calculated GAP sizes:
CONSTANT under(2@512): GAP4A=80 bytes, GAP1=7, GAP2=10, GAP3=40, GAP4=147.
CONSTANT under(2@512): 94 bytes of overhead (GAP4a through GAP1)
CONSTANT under(2@512): sectors of 585 bytes each (ID field sync through GAP3)
With 10 sectors of 512 bytes described under the CONSTANT cases above 112 leftover bytes remain under worst-case bytes per track. This is a little short of the specified GAP4B byte count of 147. Nominal track capacity would achieve it but reliability would be lessened.
So it follows that the ISO format without the Index address mark should be looked at:
FORMAT (3) PARAMETERS: TEN SECTORS OF 512 UNDER ISO-MIN.PLUS GAP SETTINGS:
==========================================================================
Format (3) "ISO-MinPlus" TEN SECTORS is characterized by the following calculated GAP sizes:
CONSTANT under(3@512): GAP1=7 bytes, GAP2=10, GAP3=40, GAP4=147. (same as (2))
CONSTANT under(3@512): 7 bytes of overhead (GAP1 only)
CONSTANT under(3@512): sectors of 585 bytes each (ID field sync through GAP3). (same as (2))
With 10 sectors of 512 bytes described under the CONSTANT cases above 199 leftover bytes remain under worst-case bytes per track. This is sufficient for the 147 bytes for GAP4B, but only leaves 52 bytes for complete the full GAP4 (i.e. the missing 80 bytes normally written at the start for the track format).
Thus this format is short by 28 bytes under worse-case track capacity.
TIME TO TRY A BETTER 5 1/4 INCH FLOPPY DRIVE WITH +/-1.5% MOTOR SPEED TOLERANCE:
================================================================================
So next I try the +/-1.5% motor speed in the spreadsheet calculations, and yes it works in spec as I'll tabulate below. As I made the case previously in the discussion, the company that made the Zorba considered itself the unique-and-only buyer and installer of disk drives into Zorba computers. Thus if they only bought floppy drives that had +/-1.5% motor speed tolerance (or if that is the spec on *ALL* 5 1/4 inch drives), then their format is 100% valid by this example and as the tabulation will show, they'll have excess bytes to extend some of the GAP1,3,4 lengths if they want additional margin of safety.
FORMAT (3) +/-1.5% SPEED PARAMETERS: TEN SECTORS OF 512 UNDER ISO-MIN.PLUS GAP SETTINGS:
========================================================================================
Format (3) "ISO-MinPlus" +/-1.5% SPEED + TEN SECTORS is characterized by:
The better motor speed boosts the worst-case track capacity to 6,150 bytes.
CONSTANT under(3@512+): GAP1=7 bytes, GAP2=10, GAP3=24, GAP4=37.
CONSTANT under(3@512+): 7 bytes of overhead (Gap1 only)
CONSTANT under(3@512+): sectors of 569 bytes each (ID field sync through GAP3).
With 10 sectors of 512 bytes described under the CONSTANT cases above 569 leftover bytes remain under worst-case bytes per track. This is sufficient for the 37+80 bytes for GAP4B+GAP4A written last.
CONCLUSION:
===========
With 5 1/4 inch drives spec'd at +/-1.5%, 10 sectors of 512 bytes double density MFM encoded is completely in spec with margin to spare.
ADDENDUM:
=========
With the +/-1.5% motor speed variable in the spreadsheet, I confirmed its affect on the other formats. I list the results here briefly:
FORMAT (2) IBM-MIN.PLUS: The new results have 366 leftover bytes covering 37+80 bytes for GAP4B+GAP4A written last.
FORMAT (1) IMB-3740/-34: Failed to be completely within spec.
-Jay in Dallas
Jay_in_Dallas
Jul 8, 2014, 9:55:52 PM7/8/14
to
QUICK NOTE ON MAKING IMAGE-DISKS WITH SHORTENED GAP LENGTHS FOR READ-ONLY:
==========================================================================
Actually if your goal is only to create a IMAGE-DISK, it can be made easier by reducing those GAP lengths that are *ONLY* in support of READ/WRITE operations.
If you don't need to write to the IMAGE-DISK, you can remove the ZORBA issue merely by reducing the GAPs, thus assuring any format will fit.
MAKE SURE you don't write to the IMAGE-DISK on the target system; it will garble the disk.
The best process is to simply use the IMAGE-DISK to boot the system and to immediately make a system disk copy or two on the target system. Only the target system formats the bests disks for itself.
In the ZORBA case, the system will likely include the physical sector interleave.
After system disks are generated the IMAGE-DISK is recycled with a clean format. DO NOT intermix it with target system disks... it will just get garbled when someone later thinks its a valid R/W disk.
NOTE REGARDING FDC COMPATIBILITY:
=================================
Shortening the READ-ONLY IMAGE-DISK gaps won't confuse every FDC in creation, maybe some. But the Western Digital FDC 2797 was smug in declaring that their chip can respond within a couple of bytes, but recommended using gap sizes based upon the drive parameters.
In most cases the FDC would never know the difference as log as disk reads are commanded.
So its not a foregone conclusion that the FDCs were never made to be capable of using IMAGE-DISK with shortened GAPs.
-Jay in Dallas
==========================================================================
Actually if your goal is only to create a IMAGE-DISK, it can be made easier by reducing those GAP lengths that are *ONLY* in support of READ/WRITE operations.
If you don't need to write to the IMAGE-DISK, you can remove the ZORBA issue merely by reducing the GAPs, thus assuring any format will fit.
MAKE SURE you don't write to the IMAGE-DISK on the target system; it will garble the disk.
The best process is to simply use the IMAGE-DISK to boot the system and to immediately make a system disk copy or two on the target system. Only the target system formats the bests disks for itself.
In the ZORBA case, the system will likely include the physical sector interleave.
After system disks are generated the IMAGE-DISK is recycled with a clean format. DO NOT intermix it with target system disks... it will just get garbled when someone later thinks its a valid R/W disk.
NOTE REGARDING FDC COMPATIBILITY:
=================================
Shortening the READ-ONLY IMAGE-DISK gaps won't confuse every FDC in creation, maybe some. But the Western Digital FDC 2797 was smug in declaring that their chip can respond within a couple of bytes, but recommended using gap sizes based upon the drive parameters.
In most cases the FDC would never know the difference as log as disk reads are commanded.
So its not a foregone conclusion that the FDCs were never made to be capable of using IMAGE-DISK with shortened GAPs.
-Jay in Dallas
0 new messages