f



Zorba 5.25 40 track DSDD diskdef for cpmtools?

Hi,

Has anyone determined a usable diskdef for this format?  I'm stuck on the 
skewing.
0
Bob
12/14/2012 5:52:15 AM
comp.os.cpm 3422 articles. 0 followers. Post Follow

46 Replies
4376 Views

Similar Articles

[PageSpeed] 9

On 14.12.2012 06:52, Bob wrote:
> Hi,
>
> 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

0
Peter
12/14/2012 4:45:41 PM
On Fri, 14 Dec 2012 17:45:41 +0100, Peter Dassow wrote:

> On 14.12.2012 06:52, Bob wrote:
>> Hi,
>>
>> 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.  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.
0
Bob
12/15/2012 5:45:29 AM
Bob <BobP@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
0
glen
12/15/2012 8:33:42 AM
On Dec 14, 12:52=A0am, Bob <B...@pingme.net> wrote:
> Hi,
>
> Has anyone determined a usable diskdef for this format? =A0I'm stuck on t=
he
> skewing.

The Jugg'ler says this about Zorba DSDD - doesn't seem to mention
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
0
David
12/16/2012 11:10:23 PM
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 
than 512 bytes per sector.
So it seems to be BOTH sides for one track, means 10 sectors / 
surface-track ...

Regards
  Peter

0
Peter
12/17/2012 9:36:06 PM
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,
---

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>

0
Ole
12/17/2012 11:29:50 PM
On Tue, 18 Dec 2012 00:29:50 +0100, Ole Christensen wrote:

> 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,
> ---
> 
> 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>

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.
0
Bob
12/18/2012 4:44:53 AM
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 
..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.

0
David
12/18/2012 2:47:58 PM
On Tue, 18 Dec 2012 09:47:58 -0500, David Schmidt wrote:

> 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
> .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.

This started me down the path of suspecting a non-zero skew, but the 
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.
0
Bob
12/18/2012 6:27:32 PM
Peter Dassow <z80eu@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 
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
0
John
12/18/2012 8:21:16 PM
John Elliott <jce@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
0
glen
12/18/2012 9:13:40 PM
 >>   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
will miss the first sector (1 and 11). I ended up using a Catweasel to read them.
Hopefully, the physical media still exists.


0
Al
12/18/2012 10:14:46 PM
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 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
0
ldkraemer
3/4/2014 1:01:01 AM
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
0
ldkraemer
3/4/2014 4:43:39 AM
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?
> 
> I tried cpmtools with libdsk to access the TD0 Image.
> 
> Larry

Thanks.  I did get this far eventually, by some method or other.  Then 
the extracted files I obtained were incoherent jumbles of mixed-up 
sectors.

I'll give it another look, based on your input.
0
Bob
6/22/2014 3:38:14 PM
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 
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




0
dott
6/23/2014 7:26:07 AM
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
0
6/27/2014 12:59:39 AM
Jay_in_Dallas <jay.c.box@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
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.

The IBM gaps are a little conservative, but then older drives could
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.

If they are that short, I think they lose much of the speed tolerance
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).

My first systems used the WDC 1793, and I used to read the data sheet
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 FDCs that I know of, only write what they are told to write.
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).

Seems possible, but it shouldn't happen with a proper format.
 
> 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.

The data sheets for the floppy controllers are not hard to find,
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
0
glen
6/27/2014 2:39:41 AM
glen herrmannsfeldt wrote on Fri, 14-06-27 04:39:
>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.

0
Axel_Berger
6/27/2014 12:58:00 PM
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.

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.

Yeah I had a few WD based FDC systems too. Thirty one years ago I designed the IEEE-696 floppy+winchester board for S.D.Systems about a year before the S100 manufacturers started dropping like flies. That design (The Versa-Floppy-Winchester III) was based on an expanded WD chip set (about 4 LSI chips) by the product specification I received. I thought that was a poor choice as WD was still working on it... given the freedom, Id have designed it with an 8X300 micro as we used in Multibus winchester controllers and just bit-banged the interface out in less development time.

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.

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
0
6/27/2014 2:00:06 PM
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.

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
0
6/27/2014 2:12:34 PM
Jay_in_Dallas <jay.c.box@earthlink.net> wrote:

(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)

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
0
glen
6/27/2014 2:42:55 PM
Axel Berger <Axel_Berger@b.maus.de> wrote:

(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:

http://bitsavers.informatik.uni-stuttgart.de/pdf/shugart/_appNotes/Lesea_Floppy_May78.pdf

also:

http://homepage.ntlworld.com/mark.woodmass/necfdc.htm

-- glen
0
glen
6/27/2014 11:34:47 PM
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
0
6/29/2014 2:03:35 AM
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
0
6/29/2014 2:46:18 AM
Jay_in_Dallas wrote on Sun, 14-06-29 04:03:
>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

0
Axel_Berger
6/29/2014 4:08:00 AM
Axel Berger <Axel_Berger@b.maus.de> wrote:

(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
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
0
glen
6/29/2014 6:15:17 PM
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
0
6/29/2014 11:03:29 PM
Jay_in_Dallas <jay.c.box@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

0
glen
6/30/2014 1:20:44 AM
glen herrmannsfeldt wrote on Sun, 14-06-29 20:15:
>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.

0
Axel_Berger
6/30/2014 4:51:00 AM
glen herrmannsfeldt wrote:
> I am not sure what speed tolerance IBM uses, but that
> has some effect on the gap size.

For 8in drives:
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.

They could read without interleave back in the day too - the primary problems were (1) cost-sensitivity of home computers buyers and (2) a system architecture that supported intelligent controllers.

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.

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.


-Jay in Dallas
0
6/30/2014 3:25:43 PM
Jay_in_Dallas <jay.c.box@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
0
glen
6/30/2014 6:56:36 PM
>> 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
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;

I remember the WD1003 PC-AT (16 bit ISA bus)
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.

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 :-(

>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.

And allowed for "hacks" such as flipping the disk over
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.

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.

As I keep saying "mainframes did it best,
we're still rediscovering how well".

-- jeffj

0
jeffj
7/2/2014 3:01:00 AM
Jeff Jonas <jeffj@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
0
glen
7/2/2014 5:22:56 AM
SMD Winchester Controllers:
===========================
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
0
7/2/2014 6:28:56 AM
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
0
7/9/2014 1:36:47 AM
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
0
7/9/2014 1:55:42 AM
Reply:

Similar Artilces:

OS 3.5 application compatibility with OS 5
I want to get a new palm pilot. But i've heard that not all applications for os 3.5 (or others) will work with OS 5 This is terrible, im not going to get a OS 5 if only half of my current applications work! can someone give me some info on this? is it only a few applications? In article <1143077981.263753.196860@g10g2000cwb.googlegroups.com>, williams.davidmw@gmail.com wrote: > I want to get a new palm pilot. > But i've heard that not all applications for os 3.5 (or others) > will work with OS 5 > > This is terrible, im not going to get a OS...

Upgrade palm os 3.5 to palm os 5.4
Hi there can anyone help me out as to how do i upgrade palm os 3.5 to palm os 5.4. Also can anyone tell me where to find the HotSync Manager 3.1.1. On Thursday 02 of February 2006 09:39 loki wrote: > Hi there can anyone help me out as to how do i upgrade palm os 3.5 to > palm os 5.4. You can't. -- Life is a beach and then you dive... Marcin On 2006-02-02, loki <lokimetalhead@gmail.com> wrote: > Hi there can anyone help me out as to how do i upgrade palm os 3.5 to > palm os 5.4. You can't. Palm OS 5.x only runs on Palms with ARM CPUs. And P...

Small Apple // auction on eBay
Working CH Products Mach 3 Joystick for Apple // http://www.ebay.com/itm/231106096431?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1558.l2649 Apple //GS System 3 MB RAM, 40 MB HD, 1.44 MEG SuperDrive Floppy, ZIP 250, 2 3.5 and 2 5.25 drives http://www.ebay.com/itm/231106095249?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1558.l2649 MINIMUM BID LOWERED 50% Syndicomm Reprinted Apple //c+ Technical Reference Manual with Tech Notes http://www.ebay.com/itm/231106091495?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1558.l2649 Nice IIgs system. The UPS shipping fee to France is really too high for me to bid on your auction. Arrrgghh, too bad! antoine b.dunphy.342@gmail.com wrote: > Apple //GS System 3 MB RAM, 40 MB HD, 1.44 MEG SuperDrive Floppy, ZIP > 250, 2 3.5 and 2 5.25 drives > http://www.ebay.com/itm/231106095249?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1558.l2649 > MINIMUM BID LOWERED 50% 1.000 and plus dollars for the shipping in Italy? But you take the airplane and get personally the system on my home for this price? You're fool!!!! -- >>> I have a family and a full time job, but still have time to get much hours of Amiga hacking a day :-) <<< On Friday, December 6, 2013 11:08:45 AM UTC-6, mousemiki wrote: > 1.000 and plus dollars for the shipping in Italy? But you take the airplane > and get personally the system on my home for this price? You're fool!!!! No need for that, it...

Apple 5.25" drive vs Unidisk 5.25"
What are the differences between these drives apart from the Unidisk requiring 12v ? rob wrote: > What are the differences between these drives apart from the Unidisk > requiring 12v ? There isn't any difference, except daisy-chain cabling and the case. Both require +12v., +5v, and -12v. -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused." Michael J. Mahon wrote: > rob wrote: > > What are the differences between these drives apa...

Diasy Chaining Apple 5.25" Drive and Unidisk 5.25" Drive
Is it ok to daisy chain a Apple 5.25" Drive and a Unidisk 5.25" Drive? Also, other than the color, is there a difference between the two? Tempest wrote: > Is it ok to daisy chain a Apple 5.25" Drive and a Unidisk 5.25" Drive? > Also, other than the color, is there a difference between the two? No functional difference that I know of. -michael Music synthesis for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused." Tempest wrote: > Is it ok to daisy chai...

5.25" disc for RISC OS
Didn't an interface used to exist for Acorn machines to use 5.25 inch discs? Is it still possible to locate one? regards, A.Weston -- Staffordshire, Great Britain. In article <ant150038f7fzokP@ukonline.co.uk>, Andrew W <nospam@invalid> wrote: > Didn't an interface used to exist for Acorn machines to use 5.25 > inch discs? Is it still possible to locate one? > regards, > A.Weston Yes. See Acorn Application Note number 208 "Adding external floppy disc drives to the RISC OS family of machines". This has full details of what can be connect...

360K 5.25's vs. 1.2MB 5.25's
Is there any advantage to reading an original TRS-80 disk using: - a 40 Track 300 RPM 360K 5.25" PC floppy drive vs. - an 80 Track 360 RPM 1.2M 5.25" PC floppy drive? I have one older 360K drive (assuming it's the 300 RPM speed) and am wondering if it would ever read a troublesome disk better. Specifically does the rotation speed make any difference? (Weren't there some early 1.2MB drives that were dual speed?) In article <1126419597.451414.229280@g14g2000cwa.googlegroups.com>, Vadiv Ziward II <colos44@gmail.com> wrote: >Is there any advanta...

good source for 5.25" dsdd or ssdd?
Greetings, I've been looking around online and have found a couple places that have boxes of blank 5.25"s that I can use for both my c64 and my apple iie (don't flame me, i love 'em all ;) The sources i've found seem just a tad pricey, though I guess when supply goes way down that is to be expected. Nevertheless, I wanted to pose the question to those with the real scoop: Where is a good place to pick up boxes of 5.25" DSDD or SSDD floppies that I can use for C64 & apple II ? (Quant. 25-50 or so) I'm not concerned about name brands, but would at least like a large percentage of the box to be useable. To that end, new manufactures would probably be preferred to old stock... correct me if i'm wrong. A comparativel low price would be a real score as well...... Thanks a million for any and all input :) On a side note, I'm looking for an affordable datassette unit if anyone has one... -Jayson On 10/29/07 2:39 AM, in article ajvai3tebn5hvhbo3maqesf0q6sv33tbj4@4ax.com, "Zero dB" <no@email.com> wrote: > Greetings, > > I've been looking around online and have found a couple places that > have boxes of blank 5.25"s that I can use for both my c64 and my apple > iie (don't flame me, i love 'em all ;) > > The sources i've found seem just a tad pricey, though I guess when > supply goes way down that is to be expected. > > Nevertheless, I wanted to pose the ques...

5.25" drives blink lights when in GS OS
Hi, Whenever I'm running GS OS off my hard drive I notice that my 5.25" drive's lights flicker in tandom every couple seconds. is this normal? -Matthew S. Carpenter > Whenever I'm running GS OS off my hard drive I notice that my 5.25" > drive's lights flicker in tandom every couple seconds. is this normal? If you have a 3.5" drive on the same chain, yes. I seem to recall that GS/OS polls the 3.5" drives to check for a new disk being inserted and the 5.25" drive picks this up and flickers the LED. "David Wilson" <mcs6502@gmail.c...

WTD: Dual 5.25" 40/80 disk for BBC
Hi, Yes - I've fried another bit of beeb hardware - this time my trusty cumana disk drive :-( This time due to a power surge rather than "user error" ;-) Consequentially, if anyone has a working dual 40/80 5.25" disk drive set up (pref cumana) that they'd be willing to sell, I'd be interested. Can you email me at: c [dot] s [at] scratchmonkey [dot] org [dot] uk Many Thanks, - Chris. c.s@scratchmonkey.spammenot.org.uk said... > if anyone has a working dual 40/80 5.25" disk drive set up > (pref cumana) that they'd be willing to sell, I'd be...

(FA) Apple Disk )( 5.25 Black disk drive and Clone 5.25. Plus just an hour left on 3 Apple cards
http://search.ebay.com/_W0QQsassZappleii-guyQQhtZ-1 3 Apple II/gs cards with less then an hour to go!!!! -- The only good spammer is a dead one!! Have you hunted one down today? (c) 2006 I Kill Spammers, inc, A Rot in Hell. Co. ...

Beebug RISC OS disc buffers for 5.25" drives?
I'm trying to connect a 5.25" floppy to an RPC (RO 3.7 but may swap in 4.02 later) via Beebug/Risc Dev disc buffers. I have two versions of the buffer. One is a half length podule pcb with two standard discrete chips and is marked 'Archimedes Disc Buffer'. The other uses surface mount chips on a mini pcb mounted behind a podule external socket plate and is marked 'Risc Developments A5000 Disc Buffer'. They seem to use a near identical circuit. The RPC motherboard is marked 0197 100 which I believe makes it an issue 2 and it should therefore be able to address ...

Flightcheck 5.5 on OS X?
Is anyone here running FC 5.5? If so, is it useable? Worth the upgrade cost from 4.5? Feedback on version 5 was almost entirely negative, so we never upgraded and dropped it from the toolkit, but my staff miss it. djb -- "The thing about saying the wrong words is that A, I don't notice it, and B, sometimes orange water gibbon bucket and plastic." -- Mr. Burrows Dave Balderstone <dave@N_O_T_T_H_I_S.balderstone.ca> wrote: > Is anyone here running FC 5.5? If so, is it useable? Worth the upgrade > cost from 4.5? > > Feedback on version 5 was almost entirely n...

(FA) Last Hours
Vintage Apple 5.25 Black Faced Disk Drive Apple Clone 5.25 Black Disk Drive Made by Micro-SCI http://search.ebay.com/_W0QQsassZappleii-guyQQhtZ-1 -- The only good spammer is a dead one!! Have you hunted one down today? (c) 2006 I Kill Spammers, inc, A Rot in Hell. Co. ...

Memorial Day Specials, 2 Days Only: Sunday
http://www.sogiant.idv.tw/ COMPUTING & HOME OFFICE Sunday =96 Monday Only: Select Monitors 23" and Up On Sale. Valid 5/24-5/25 Sunday =96 Monday Only: $50 Off D-Link Xtreme N Wireless=96N Gigabit Gaming Router with 4=96Port Switch. Valid 5/24-5/25 Sunday =96 Monday Only: Free Shipping on Select Laptop Cases, Batteries and Mobile Accessories. Valid 5/24-5/25 Sunday =96 Monday Only: Free Shipping on Select Canon Laser Printers. Valid 5/24-5/24 Sunday =96 Monday Only: Free Shipping on Select Epson Printers. Valid 5/24-5/25 Sunday =96 Monday Only: Free Shipping on Select PC Speakers. Va...

IBM OS/2 OS2 2.0 5.25" Disk Format Plus RARE STACKER! auction
>http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=4619&item=7162276443< Ends Jun-15-05 19:18:53 PDT -- Reply to ohland@charter.net ...

Screensaver Factory 5 Pro 5.25
Create amazing screensavers for yourself, for promotion or unlimited royalty-free commercial distribution. Make screensavers from images, video and flash animation, add background music and smooth picture display and transition effects. You can even create clock, calendar and RSS screensavers. Screensaver Factory is very easy to use, and it enables you to make standalone self-installing screensaver files and CDs for easy setup and distribution. You can make screensavers for sale using special features for shareware authors - registration keys (single and per-customer), functionality...

DAT 20/40 on 5.0.5
I replaced a DAT 12/24 with a DAT 20/40 on a 5.0.5 system. The 12/24 was on an Adaptec controller, the 20/40 is on an LSI (slha). I used to be able to do a "tape getcomp" command to find the compression setting of the drive. Now, when I do the same command I get: tape: unable to do 'getcomp' command on '/dev/xct0' : Invalid argument Is there something inherently different about 20/40 drives, is the LSI driver cause a problem? Thanks, Fabio "news.nuvox.net" <fabiog@venmar.com> wrote in message news:10vfrnt1qhofe60@corp.supernews.com... >...

OS-5.0.5 Graphic Driver
Hello I have installed sco 5.0.5. In the PC is a Matrox G450. Unfortunately, there are no new drivers for this. I must use the driver VESA , unfortunately, only 1280x1024 supported are there there new drivers of it?! Sorry for my bad English!! In article <dm23a3$ftf$1@ns1.fe.internet.bosch.com> "Frank.Hauer" <Frank.Hauer@de.bosch.com> writes: $I have installed sco 5.0.5. In the PC is a Matrox G450. $Unfortunately, there are no new drivers for this. $I must use the driver VESA , unfortunately, only 1280x1024 supported $ $are there there new drivers of it?! The late...

Java 5.5 on mac os x?
I don't seem to be able to get java 5.5 installed and running on MAC OS X. I tried the system prefrences update.. but I don't seem see 5.5 in /System/Library/Frameworks/JavaVM.framework/Versions I tried to install the xcode developers tools to see if that would do it.. Nope... Maybe I've mis-read this wiki? http://mircwiki.rsna.org/index.php?title=MIRC_Installation_on_Macintosh In article <101fb13c-49dd-4f7c-9db0-38e5a3e29119@d7g2000prl.googlegroups.com>, SpreadTooThin <bjobrien62@gmail.com> wrote: > I don't seem to be able to get java 5.5 installed and runn...

Minicom binary for OS 5.0.5?
Does anyone have a Minicom binary for OpenServer 5.0.5? I don't have the 5.0.5 development system otherwise I would attempt to compile Minicom from the source. For user compatibility with Linux systems at the same site running Minicom, I need to install it on one SCO system. -- Bill Burns, Long Island, NY, USA mailto:billb@ftldesign.com History of Technology Websites: http://ftldesign.com Bill Burns typed (on Wed, Dec 24, 2003 at 02:48:03AM +0000): | Does anyone have a Minicom binary for OpenServer 5.0.5? I don't have | the 5.0.5 development system otherwise I would attempt t...

Printing in FMP 5.5 OS X
When I want to print a range of pages in FMP 5.5, OS X, It will eject blank sheets of all the pages I don't want to print, leading up to the first page I want to print. It does this regardless of the printer I choose. It even will create blank pages if I print to PDF. 5.5 did not do this in OS 9 and it also works fine with the demo of 6.0 that I an trying. Anyone else experiencing this? I would hate to have to pay for the upgrade just to get something that should work in my current version ...

OS 5.3 to 5.4 upgrade
Hi. My client is preparing to OS400 upgrade. They use V5R3M0 now and wants to install V5R4M0. I was wondering LIC upgrade from V5R3M0 to V5R4M0 is enough or they need to upgrade to V5R3M5 before upgrade to V5R4M0. Tomasz On May 27, 8:30=A0am, tomasz <tom...@nospam.com> wrote: > Hi. > > My client is preparing to OS400 upgrade. > They use V5R3M0 now and wants to install V5R4M0. > > I was wondering LIC upgrade from V5R3M0 to V5R4M0 is enough or > they need to upgrade to V5R3M5 before upgrade to V5R4M0. > > Tomasz I do not believe you need to go to the interm...

is it working correct if i used mysql-connector-java-5.1.32 to newer mysql 5.5.40 on ubuntu 14.04
sir, i am making a connection between MySQL database 5.5.40 between eclipse Kepler Ide on Ubuntu for my java project(not a web based project). I have older version of jar connector and newer version of MySQL server. how can I connect Mysql to Eclipse without or with jdbc?? and how can i set the classpath for mysql ?? thanking you.. ...

Web resources about - Zorba 5.25 40 track DSDD diskdef for cpmtools? - comp.os.cpm

Resources last updated: 3/6/2016 6:44:24 PM