Re: UniDisk 3.5 write-protect bug

[dempson@actrix.gen.nz (David Empson)]

Edhel Iaur <drsmooth@relex.com> wrote:

> I d/l'ed SMARTPORT.SHK (I don't remember where from), and it contained
> a single file, SMARTPORT (BAS, 36 Blocks, Created 15-Jan-91, Modified
> 6-Sep-89 [dates don't sound right, but it's possible]).  I ran it on
> my system (//c w/ 3.5 disk rev., (1) Unidisk, (1) Disk ][, 512K
> MultiRam C card), and it told me:
> 
> This Smartport has the UniDisk 3.5 write-protect bug.  Eject this
> disk, cover the write-protect hole, and don't ever put a
> write-protected disk in this Smartport again."

Ah, the good old Open-Apple SmartPort program.  Open-Apple is the
original name of A2-Central magazine, which was published by Resource
Central.

> Am I pessimistic in thinking I have a serious problem that can't be
> remedied?

This is a bug in the "UniDisk" version of the IIc firmware (for which
PRINT PEEK(64447) reports 0), however it is not mentioned in the
technical note on IIc revisions.

The problem is described in some detail in Apple's UniDisk technical
note number 3 (STATUS Call Bug).  There is some background information
(somewhat misleading) in Open-Apple Vol. 1 p  98a, and Vol. 2 pp
93a-93b.

According to the technical note, the problem also affects the Apple
II+/IIe UniDisk controller (the "Liron" card), but was fixed in later
versions of the IIc firmware (and presumably in the IIgs and other
SmartPort implementations).


The main case in which a problem occurs is when an attempt is made to
write less than one block of data to a file that already exists.  This
leaves ProDOS in a state where it is impossible to close the file or to
re-use the buffer.  The computer may crash if you try to quit from the
current application and run another one.

This technote mentions another problem that can occur in a similar
situation: an attempt to create then write to a file on a write
protected disk will fail, but if the disk is then write enabled and
another file created, a block is marked as being reserved which is not
allocated to any file.


The solution is to never attempt to save or write to a file on a write
protected disk, but some programs may try to do this without asking you.

Everything is fine if the disk is not write protected.

> Is this what trashed/gave me errors on various 3.5" disks on various
> occasions (Is it coincidence that said errors only occured on the
> Kodak Verbatim disks I bought with my drive?)?

It is more likely to be the disks that are the problem, especially if
they are actually high density 3.5" disks (do they have a hole in the
case on the opposite side from the write protect switch?)

> Can I fix this by exchanging my UniDisk for another?

No - the problem is in the IIc, not the UniDisk.  You would have to
exchange your IIc for a later model, or try to get hold of a later ROM
version (which has never been available without a motherboard exchange,
and then only if you needed to install Apple's IIc memory expansion
card).

-- 
David Empson
dempson@actrix.gen.nz
Snail Mail: P.O. Box 27-103, Wellington, New Zealand