Re: 8050 which will write but not format

From: Julian Perry <>
Date: Sun, 2 Dec 2012 01:34:03 +1100
Message-ID: <>
Hello Rob,

Saturday, December 1, 2012, 11:47:58 AM, you wrote:

> Hmm, thanks Julian - I have checked and adjusted the speed with the 
> 8296D diagnostic tool and it claims they are bang on. It also measures
> the variation, which it also claims is OK. Should I have reason not to
> trust it?

I'm not familiar with the diagnostics tool (wouldn't mind a copy,
actually - I have an 8296LP).

With a 1541 format,  the whole track is overwritten with Sync ($FF)
bytes (about a track and a half), then a chunk of NON sync bytes ($55,
or 01010101) is written out, guestimated to be about 1/2 the track.
Sync and Non-sync bytes are counted, and the ratio used to calculate
the number of "tail" bytes" after the data sector. I can't see that
there would be much difference between that, and the higher density
8050 format.

Once again, with the 1540/1541, whilst data is read from a shift
register after the data is clocked in, Sync is detected by a separate
circuit (integrated into a single chip in the case of the 1541).
The thing I can't understand is that 5 sync marks are written out
whenever you write out a data block - and you say that works OK.
If there was a problem reading sync marks written by that analogue
board when (re)writing sectors, then you would get error 22 (Data block not found) messages on
sectors rewritten using that drive - but you don't..

More thinking (and rom study) is needed :)


> rob

> On 01/12/2012 01:41, Julian Perry wrote:
>> Rob
>> You will get that problem if the drive spindle is running to fast.
>> Julian
>> Saturday, December 1, 2012, 11:17:18 AM, you wrote:
>>> Gents,
>>> I would not normally post 'please help me fix' type questions here but
>>> this one has me stumped. Some may already have seen the thread on
>>> vintage-computer forums here:
>>> In a nutshell, drive 1 works 100%, drive 0 will read and write but not
>>> format. It usually stops on track 1 with a #21 read error but
>>> occasionally will go as far as track 3 or 4. If I swap the mechanisms,
>>> the problem stays with drive1. This implies a problem in the analogue
>>> board (micropolis pcb #8050006) but I can't find it and I don't
>>> understand what kind of problem would allow it to write but not format.
>>> I know the mechanisms are good and well aligned and, as the drives read
>>> OK, they are properly speed adjusted.
>>> Do any of you disk wizards know the algorithms by which these drives
>>> format a disk? I hoped this might give me a clue.
>>> Rob
>>>         Message was sent through the cbm-hackers mailing list

>        Message was sent through the cbm-hackers mailing list

Best regards,

       Message was sent through the cbm-hackers mailing list
Received on 2012-12-01 15:00:46

Archive generated by hypermail 2.2.0.