Hi
 I was wondering if anyone knew where and what fornat
was used for the bad track record in most CP/M hard
disk implementations. Although, not for CP/M, I'm working
on a machine ( Olivetti M20 ) that uses PCOS. I'm
trying to bring up a hard disk on this machine but
I think it expects to see a table on the disk with a
map of the bad tracks.
 I've run the format operation but it tells me that it can't
read the bad track information. I believe that for
this machine, this data was originally on the hard drive,
from the manufacture.
 The problem is that the disk I have was previously
formatted with 256 byte sectors. The M20 uses 128
byte sectors.
 If I know the location, on the disk, of the bad track information
and the format of that data, I can recreate a table on
the disk I'm using.
 Does anyone have this information for CP/M?
Dwight

On 10 May 2006 14:51:29 -0700, dkelvey@hotmail.com wrote:

>Hi
> I was wondering if anyone knew where and what fornat
>was used for the bad track record in most CP/M hard
>disk implementations. Although, not for CP/M, I'm working
>on a machine ( Olivetti M20 ) that uses PCOS. I'm
>trying to bring up a hard disk on this machine but
>I think it expects to see a table on the disk with a
>map of the bad tracks.
> I've run the format operation but it tells me that it can't
>read the bad track information. I believe that for
>this machine, this data was originally on the hard drive,
>from the manufacture.
> The problem is that the disk I have was previously
>formatted with 256 byte sectors. The M20 uses 128
>byte sectors.
> If I know the location, on the disk, of the bad track information
>and the format of that data, I can recreate a table on
>the disk I'm using.
> Does anyone have this information for CP/M?
>Dwight

First, usually for hard disks it's not bad tracks but bad sectors.

CP/M did not do bad track formatting or bad sectors.   That was a 
BIOS functional problem left to the bios programmer.  That said, there
is no standard for CP/M bad sectors.

Most I've seen presumed all tracks good and had a supply of
replacement sectors that would be remapped using a table
in the BIOS as partt of the hard disk code. 

Allison

On 2006-05-10, dkelvey@hotmail.com <dkelvey@hotmail.com> wrote:
>  If I know the location, on the disk, of the bad track information
> and the format of that data, I can recreate a table on
> the disk I'm using.

I'm no expert, but I have seen such information for RL01/RL02 disk
packs. A quick google should bring it up.

On those packs, the first few sectors of the last track contained a
table describing the location of the bad sectors.

Of course, that's easy for the RL01/RL02 because they're hard-sector
disks. ST-506 disks might be formatted FM, MFM, or RLL. Makes it a bit
hard for the manufacturer to store a bad block table on them.
-- 
roger ivie
rivie@ridgenet.net

<dkelvey@hotmail.com> wrote in message
news:1147297889.246046.278840@q12g2000cwa.googlegroups.com...
>  I was wondering if anyone knew where and what fornat
> was used for the bad track record in most CP/M hard
> disk implementations.

All the machines I worked on, bad sector (not "track," that I ever saw)
handling was done in BIOS and was pretty much machine dependent.  As to the
initial bad sector list, it was always printed on the top of the drive.  I've
got a 5.25" full height drive here (I use it as a door stop) and the table is
on the top.  It's a 5M drive and lists some 30 or so bad sectors.

How it's formatted can be important too.  I reused a few of these MFM drives
with an RLL controller (in a PC) and had to translate the sector list to allow
for the change in sectors per track.

    - Bill

dkelvey@hotmail.com wrote:
> 
> I was wondering if anyone knew where and what fornat
> was used for the bad track record in most CP/M hard
> disk implementations. Although, not for CP/M, I'm working
> on a machine ( Olivetti M20 ) that uses PCOS. I'm
> trying to bring up a hard disk on this machine but
> I think it expects to see a table on the disk with a
> map of the bad tracks.

For CP/M we just used the disk as it came.  There was a generalized
system where a BLOCKS.BAD file was created and assigned all bad
blocks on the drive.  By marking the file as r/o and sys we could
preserve it and prevent using bad areas.  Never read that file.

-- 
 Some informative links:
   news:news.announce.newusers
   http://www.geocities.com/nnqweb/
   http://www.catb.org/~esr/faqs/smart-questions.html
   http://www.caliburn.nl/topposting.html
   http://www.netmeister.org/news/learn2quote.html

First, there isn't one.  What Zenith did was to collect bad sectors into 
a hidden system file (can't remember the name, but something like 
BAD.SYS).  But it was an issue that CP/M itself just ignored.

Second, while you could do this for an MFM drive from the 1980's, there 
is no way for any OS (not even Windows XP) to know about or manage bad 
sectors on any IDE device.  This is done entirely within the drive and 
it's transparent to the OS.  The drive can even "move" sectors without 
the knowledge of the OS.  Technology has moved this out of the realm of 
operating systems.


dkelvey@hotmail.com wrote:

> Hi
>  I was wondering if anyone knew where and what fornat
> was used for the bad track record in most CP/M hard
> disk implementations. Although, not for CP/M, I'm working
> on a machine ( Olivetti M20 ) that uses PCOS. I'm
> trying to bring up a hard disk on this machine but
> I think it expects to see a table on the disk with a
> map of the bad tracks.
>  I've run the format operation but it tells me that it can't
> read the bad track information. I believe that for
> this machine, this data was originally on the hard drive,
> from the manufacture.
>  The problem is that the disk I have was previously
> formatted with 256 byte sectors. The M20 uses 128
> byte sectors.
>  If I know the location, on the disk, of the bad track information
> and the format of that data, I can recreate a table on
> the disk I'm using.
>  Does anyone have this information for CP/M?
> Dwight
> 

On Wed, 10 May 2006 22:34:12 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote:

>dkelvey@hotmail.com wrote:
>> 
>> I was wondering if anyone knew where and what fornat
>> was used for the bad track record in most CP/M hard
>> disk implementations. Although, not for CP/M, I'm working
>> on a machine ( Olivetti M20 ) that uses PCOS. I'm
>> trying to bring up a hard disk on this machine but
>> I think it expects to see a table on the disk with a
>> map of the bad tracks.
>
>For CP/M we just used the disk as it came.  There was a generalized
>system where a BLOCKS.BAD file was created and assigned all bad
>blocks on the drive.  By marking the file as r/o and sys we could
>preserve it and prevent using bad areas.  Never read that file.

Thats how I handle it too.  It's easiest and the utility to read and
test all sectors is then generic(works for all media).

Allison

On 10 May 2006 14:51:29 -0700, dkelvey@hotmail.com wrote:

>Hi
> I was wondering if anyone knew where and what fornat
>was used for the bad track record in most CP/M hard
>disk implementations. Although, not for CP/M, I'm working
>on a machine ( Olivetti M20 ) that uses PCOS. I'm
>trying to bring up a hard disk on this machine but
>I think it expects to see a table on the disk with a
>map of the bad tracks.
> I've run the format operation but it tells me that it can't
>read the bad track information. I believe that for
>this machine, this data was originally on the hard drive,
>from the manufacture.
> The problem is that the disk I have was previously
>formatted with 256 byte sectors. The M20 uses 128
>byte sectors.
> If I know the location, on the disk, of the bad track information
>and the format of that data, I can recreate a table on
>the disk I'm using.
> Does anyone have this information for CP/M?
>Dwight

There was a utility findbad.com that verified sectors and those that
were bad and not in use were assigned to a file. Periodically you ran
it and it would lock out a couple of sectors a year.

Ideally you would run it right after formatting the drive, to get the
initial batch of bad sectors then once a year or so to pick up the
others. As I recall it told you what files were occupying bad areas of
the drive (wish windows 9x scandisk did this) so that you could
immediately try to recover them to another drive, or delete them so
that findbad could assign those sectors into its file.

Good hard drive formatting utlities allowed entering of the bad sector
table that they used to include with hard drives, so that you could
avoid the bad sectors they found at the factory.

I think with the Montezuma Micro hard drive utility, it would lock out
entire tracks when entering the bad sector table. (Been 20 years or so
since I had a 5 later 15 meg drive on my 4p).

On Wed, 10 May 2006 21:51:29 UTC, dkelvey@hotmail.com wrote:

> Hi
>  I was wondering if anyone knew where and what fornat
> was used for the bad track record in most CP/M hard
> disk implementations. Although, not for CP/M, I'm working
> on a machine ( Olivetti M20 ) that uses PCOS. I'm>  Does anyone have this information for CP/M?
> Dwight
> 

Under CP/M there was the utility findbad which makes a file called  
[UNUSED].BAD. That file lockedout the bad sectors.

There are several version for CP/M 2.2 and CP/M+  and a version using 
RSX. 

http://oldcomputers.dyndns.org/public/pub/cdrom/cpm/FOG/STARTER/FBAD58
X.DOC
http://oldcomputers.dyndns.org/public/pub/cdrom/cpm/SIMTEL/SIGM/VOLS00
0/VOL067/findbd54.asm

I think I have a *.com fiele anywhere 


-- 
Greetings

Fritz Chwolka

What you call Findbad was not a CP/M utility.  If it didn't come with a 
generic copy of the OS, and didn't come from Digital Research, then it 
was one particular OEM's software, and quite possibly specific to one 
particular computer and/or one particular disk drive or controller.


Fritz Chwolka wrote:
> On Wed, 10 May 2006 21:51:29 UTC, dkelvey@hotmail.com wrote:
> 
> 
>>Hi
>> I was wondering if anyone knew where and what fornat
>>was used for the bad track record in most CP/M hard
>>disk implementations. Although, not for CP/M, I'm working
>>on a machine ( Olivetti M20 ) that uses PCOS. I'm>  Does anyone have this information for CP/M?
>>Dwight
>>
> 
> 
> Under CP/M there was the utility findbad which makes a file called  
> [UNUSED].BAD. That file lockedout the bad sectors.
> 
> There are several version for CP/M 2.2 and CP/M+  and a version using 
> RSX. 
> 
> http://oldcomputers.dyndns.org/public/pub/cdrom/cpm/FOG/STARTER/FBAD58
> X.DOC
> http://oldcomputers.dyndns.org/public/pub/cdrom/cpm/SIMTEL/SIGM/VOLS00
> 0/VOL067/findbd54.asm
> 
> I think I have a *.com fiele anywhere 
> 
> 

On Sat, 13 May 2006 21:36:41 GMT, Barry Watzman
<WatzmanNOSPAM@neo.rr.com> wrote:

>What you call Findbad was not a CP/M utility.  If it didn't come with a 
>generic copy of the OS, and didn't come from Digital Research, then it 
>was one particular OEM's software, and quite possibly specific to one 
>particular computer and/or one particular disk drive or controller.

While it was not a DRI software item is was run under CP/M as a
transient app.   I have it and it's generic.   It uses the BIOS IO
vectors and it's very portable in that the interface under CP/M is 
very standardized.    All of the information needed to get the
geometry and read and write are standard calls.   The actual
file with the bad blocks allocated to it is however written using
BDOS IO (CP/M standard filsystem calls).

It's portable enough by testing that the same copy (binary) works for:

-My AMPROLB+ for the 3.5" 781k floppy, the SCSI 45mb HD.
- SB180 using both floppy and SCSI bridge to MFM disk
-Both kaypros (a II and turborom 4/84), 
-All of the S100 crates (Horizon II/hard sector, homebrew disk based,
and Compupro),
-Visual 1050 both floppy and SASI disk (under cpm-3).
-It even works fine  under MyZ80 though it will never see errors 
there as the PC hides them.

Thats a sufficiently diverse group to say yes it works.  If anything
I'd call it a good example of a well written CP/M utility.


Allison

>
>
>Fritz Chwolka wrote:
>> On Wed, 10 May 2006 21:51:29 UTC, dkelvey@hotmail.com wrote:
>> 
>> 
>>>Hi
>>> I was wondering if anyone knew where and what fornat
>>>was used for the bad track record in most CP/M hard
>>>disk implementations. Although, not for CP/M, I'm working
>>>on a machine ( Olivetti M20 ) that uses PCOS. I'm>  Does anyone have this information for CP/M?
>>>Dwight
>>>
>> 
>> 
>> Under CP/M there was the utility findbad which makes a file called  
>> [UNUSED].BAD. That file lockedout the bad sectors.
>> 
>> There are several version for CP/M 2.2 and CP/M+  and a version using 
>> RSX. 
>> 
>> http://oldcomputers.dyndns.org/public/pub/cdrom/cpm/FOG/STARTER/FBAD58
>> X.DOC
>> http://oldcomputers.dyndns.org/public/pub/cdrom/cpm/SIMTEL/SIGM/VOLS00
>> 0/VOL067/findbd54.asm
>> 
>> I think I have a *.com fiele anywhere 
>> 
>> 

On 2006-05-14, Allisonnospam@nouce.bellatlantic.net <Allisonnospam@nouce.bellatlantic.net> wrote:

> On Sat, 13 May 2006 21:36:41 GMT, Barry Watzman
><WatzmanNOSPAM@neo.rr.com> wrote:
>
>>What you call Findbad was not a CP/M utility.  If it didn't come with a 
>>generic copy of the OS, and didn't come from Digital Research, then it 
>>was one particular OEM's software, and quite possibly specific to one 
>>particular computer and/or one particular disk drive or controller.
>
> While it was not a DRI software item is was run under CP/M as a
> transient app.   I have it and it's generic.   It uses the BIOS IO
> vectors and it's very portable in that the interface under CP/M is 
> very standardized.    All of the information needed to get the
> geometry and read and write are standard calls.   The actual
> file with the bad blocks allocated to it is however written using
> BDOS IO (CP/M standard filsystem calls).
>
> It's portable enough by testing that the same copy (binary) works for:
>
> -My AMPROLB+ for the 3.5" 781k floppy, the SCSI 45mb HD.
> - SB180 using both floppy and SCSI bridge to MFM disk
> -Both kaypros (a II and turborom 4/84), 
> -All of the S100 crates (Horizon II/hard sector, homebrew disk based,
> and Compupro),
> -Visual 1050 both floppy and SASI disk (under cpm-3).
> -It even works fine  under MyZ80 though it will never see errors 
> there as the PC hides them.
>
> Thats a sufficiently diverse group to say yes it works.  If anything
> I'd call it a good example of a well written CP/M utility.

It also works on the Epson QX-10 and QX-16 computers.

-- 

John (john@os2.dhs.org)

Hi
 Yes, it usually just maps out bad sectors and not trakes.
I've been trying to get a ST251 to work but It acts like it
expects to see some sector(s) with this information. It
is most likely expected from the manufacture of the origonal
disk.
 The more I look into things, the more I think I have other
problems first. The controller seems to be trashing all the
sectors when trying to format. I've been writing some low
level code to format a track but not getting the best results
yet. I've already found dependencies on the specific drive
in this controller. It expect a signal on pin 5 of the data connector.
The ST251 has nothing connecter there. There may be other
things as well.
 I've resorted to looking at short burst of write data with my
non-memory type analog oscilloscope. I'm making progress
so it doesn't look too bad.
 If I get clean formatting I suspect that I can figure out the bad
sector record. I've seen several that will put the FFFF record
to indicate the end of the records. Once I get the format working,
writing FFFF to the first few sectors should make the machine happy.
Dwight

On 15 May 2006 16:03:30 -0700, dkelvey@hotmail.com wrote:

>Hi
> Yes, it usually just maps out bad sectors and not trakes.
>I've been trying to get a ST251 to work but It acts like it
>expects to see some sector(s) with this information. It
>is most likely expected from the manufacture of the origonal
>disk.
> The more I look into things, the more I think I have other
>problems first. The controller seems to be trashing all the
>sectors when trying to format. I've been writing some low
>level code to format a track but not getting the best results
>yet. I've already found dependencies on the specific drive
>in this controller. It expect a signal on pin 5 of the data connector.
>The ST251 has nothing connecter there. There may be other
>things as well.
> I've resorted to looking at short burst of write data with my
>non-memory type analog oscilloscope. I'm making progress
>so it doesn't look too bad.
> If I get clean formatting I suspect that I can figure out the bad
>sector record. I've seen several that will put the FFFF record
>to indicate the end of the records. Once I get the format working,
>writing FFFF to the first few sectors should make the machine happy.
>Dwight

What machine is that.  Most will operate with a null table.  
Format should not care of there is bad block info as once written
you should go back anyway and run a test of the disk too see if any
new bad block appeared.

FYI: most st251s are suspect, heat is bad news for them and 
their lifetimes were usually short.


Allison

Allison

On 2006-05-15, dkelvey@hotmail.com <dkelvey@hotmail.com> wrote:
>  The more I look into things, the more I think I have other
> problems first. The controller seems to be trashing all the
> sectors when trying to format. I've been writing some low
> level code to format a track but not getting the best results
> yet. I've already found dependencies on the specific drive
> in this controller. It expect a signal on pin 5 of the data connector.
> The ST251 has nothing connecter there. There may be other
> things as well.

This is probably a stupid question, but are you certain you're not
dealing with an ESDI controller? They had different pinouts; on ESDI,
pin 5 of the radial cable is listed as "reserved for step mode" over on
pinouts.ru.
-- 
roger ivie
rivie@ridgenet.net