Re: 8050 which will write but not format

From: Julian Perry <>
Date: Sun, 2 Dec 2012 09:28:51 +1100
Message-ID: <>
Hello Rob,

Sunday, December 2, 2012, 2:50:42 AM, you wrote:

> Here you go Julian, this is the 8296D diagnostic disk :


Awesome - thanks... I've pulled it down..

> Well, I cranked the speed down to around -6ms to slow (I assume that's
> milliseconds per revolution) and it appears to format more - it got to
> around track 20 before barfing.
Hmm - so drive speed affects the problem.
It couldn't be anything as silly as the test program not working
correctly on 50Hz mains?? (I can't see that the drive would have any
internal reference to mains frequency - the only CBM machine I know
that can do that is the C64)
Does the drive have a strobe disk on the spindle?

> You're right in that when I had it set to 0ms I can write to the whole
> disk. I filled all 2260 blocks on the suspect drive and verified the 
> contents on the other one. Go figure... :-/

Very weird.  I've a full dance card right now (don't we all) - but I'd
love to have a look at the ROM, and determine the formatting code on
the drive.. I'm sure there roms exist on the 'net.


> Rob

> On 01/12/2012 15:34, Julian Perry wrote:
>> 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 :)
>> Julian
>>> 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

>        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 23:00:06

Archive generated by hypermail 2.2.0.