Re: Tips for making Twiggy images

From: Natalia Portillo <claunia_at_email.domain.hidden>
Date: Mon, 16 Feb 2015 08:38:10 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Tom,

I can tell you that the MDDF seems correct:

claunia_at_zeus ~ $ mono
/Development/DiscImageChef/DiscImageChef/bin/Debug/DiscImageChef.exe analyze -i ~/Downloads/PascalWorkshop1.0_3of3_682-0051-B.dc42 The Disc Image Chef 2.2.5365.5370
Copyright © 2011-2014 Natalia Portillo

Image format identified by Apple DiskCopy 4.2. Identified by Apple Lisa File System.
LisaFS v1
Volume name: "Pascal.3"
Volume password: ""
Volume ID: 0x9B8C4DD721000180

Backup volume ID: 0x0000000000000000

Master copy ID: 0x00000000
Volume is number 0 of 0
Serial number of Lisa computer that created this volume: 384 Serial number of Lisa computer that can use this volume's software 384 Volume created on 12/09/1983 10:47:05
Some timestamp, says 01/01/1901 0:00:00
Volume backed up on 01/01/1901 0:00:00
Volume scavenged on 01/01/1901 0:00:00
MDDF is in block 41
1683 blocks minus one
1642 blocks minus one minus MDDF offset
1684 blocks in volume
536 bytes per sector (uncooked)
512 bytes per sector
1 blocks per cluster
1643 blocks in filesystem
27 files in volume
925 blocks free
128 bytes in LisaInfo
Filesystem overhead: 25
Scanvenger result code: 0x00000000
Boot code: 0x00000000
Boot environment: 0x00000000
Overmount stamp: 0x0000000000000000

Volume is clean

About the tag size, as you can see the MDDF clearly says there should be 536-512 bytes (that's, 24 bytes in a twiggy tag). In Sonys, it says 20 bytes.

But you should think about one thing, that is, how much can you read talking to the floppy controller, and how much it is really stored in the disk. We'll need something like DiscFerret to really know.

Really why haven't someone yet taken a cheap ARM Msomething and made one that works in a simple development board, like, say, TI LaunchPad I don't know.

Anyway, you got a sep83 disk :p Cheers!

My tool can also compare sector by sector and tag by tag of any DC42 image.

Free, opensource, http://github.com/claunia/DiscImageChef feel free to use it and bomb me with suggestions.

Someday in 2015, if destiny allows, I'll implement reading LisaFS, as I have already decoded it an I'm able to do without using the tags to find the files.

Regards,
Natalia Portillo

El 16/2/15 a las 4:28, Tom Stepleton escribió:
> Hi everyone,
>
> Hopefully I've now obtained a successful image of Disk 3 of the
> Pascal Workshop v1.0. I've put it online here:
>
> https://drive.google.com/open?id=0B0_fWRp3VVS4Qll2U0FyMnk1a2c&authuser=0
>
> My only basis for saying that the read was successful is the fact
> that BLU managed to read each sector successfully, or at least
> that's what I interpret its messages to say.
>
> Several sectors on both sides were marked as "** Difficult". One in
> particular was marked with "<- ****** Error".
>
> After a bit of futzing around with the option to vary the disk
> speed, the happy message "<- == Vary Speed Succeeded" appeared.
> This is surely due to luck more than skill---I am pretty sure that
> I hit the wrong key on several occasions. A few more "Difficult"
> sectors were read after that, but the rest of the disk loaded
> normally.
>
> You can see a complete log from the BLU read operation here:
>
> https://drive.google.com/open?id=0B0_fWRp3VVS4d196WDlLWnRBbXc&authuser=0
>
> I hope that the experts can confirm that this log indicates a
> successful read.
>
> (More details)
>
> Prior to attempting the copy, I went ahead and tried to clean away
> some of the dust on the disk. These efforts did not seem to help
> much, and the term "dust" seems not to have been accurate to
> characterize the kind of degradation seen on the media surface.
>
> I removed the media from the disk jacket first, and sprayed it with
> air from a compressed gas duster (e.g. "DustOff"). This seemed not
> to do anything. (Dunno if it matters, but chemistry buffs might
> want to ponder the can's warning about how the gas contains
> 1,1-difluoroethane
> <http://en.wikipedia.org/wiki/1,1-Difluoroethane>. No idea whether
> disk media has any particular sensitivity to that chemical.)
>
> Several of you mentioned wiping dust from disks with a damp
> lint-free cloth. I attempted techniques like this on a single side
> of the media, the one that seemed to be more dramatically affected
> by the degradation.
>
> First, I placed lens paper over an affected portion of the media
> surface. (Nearly all of the visible degradation appeared on the
> parts of the media that had been at the location of the four r/w
> head apertures.) Using a straw as a pipette, I dripped distilled
> water onto the lens paper, in hopes of getting dust to cling to the
> moistened paper. After wetting, I carefully lifted the paper. No
> dust was visible there, and the surface looked unchanged (albeit
> moist). I used the spray duster to dry the media. Spots on the
> media where water had dried were visible.
>
> Next, I attempted to lightly brush away some of the dust with a
> damp cloth. Both moist lens paper and moist AlphaLite wipers
> <http://www.texwipe.com/store/p-696-alphalite.aspx> appeared to
> lighten the appearance of the degraded area, although they also
> seemed to leave small scratches in the media surface regardless. No
> residue appeared on the lens paper or on the cloth.
>
> I noticed after this that the surface of degraded area appeared to
> dry more rapidly than other areas did. This may have been due to
> absorption of the water into the media in those places, or perhaps
> to the media surface becoming more hydrophobic there (think
> RainX).
>
> After all this had finished, I placed the media into a "clean"
> jacket and performed the BLU read process described above. I did
> not attempt to verify the read, to read the disk more than once, or
> to read it on more than one drive. After reading, the media surface
> looked to have been scoured or polished by the read heads (or
> perhaps the foam pads opposing the heads). The degraded regions
> were still visible beneath the scour.
>
> My concluding hypotheses are as follows:
>
> 1. The "dust" apparent on my Pascal 3 disk wasn't really dust: it
> wasn't really dissociating from the disk surface like ordinary dust
> would. Instead, I expect it was probably a more gummy substance. 2.
> Even "scratch free" cloths can still cause scratches. 3. To the
> extent that I was able to recover data from this disk, it was more
> luck than anything, and my actions probably did more harm than
> good. Hopefully not too much harm.
>
> We'll see how it went when I try to install the Workshop from
> copies of the Twiggies. I'll need to clean the heads of the drive I
> used to make the image before I attempt this (and perhaps the foam
> pads as well?). For now, I've been attempting to format a known-bad
> scratch disk in the drive, just to get something moving in front of
> the heads. Lens paper and alcohol will come later.
>
> --Tom
>
>
> On Sunday, January 25, 2015 at 1:43:53 PM UTC-5, Tom Stepleton
> wrote:
>
> Hi LisaListers,
>
> I took a chance the other day and bought an unopened 1.0 edition
> of the Pascal Workshop. I intend to open it once it arrives; since
> they aren't online yet, it'll be good to scan those manuals and
> hopefully get some disk images.
>
> (I don't know if there are disk images of the released 1.0
> workshop on bitsavers; there's a set of images called "wshp84" in
> /bits/Apple/Lisa/monitor, with "26 April 84" and "backup" showing
> on the pictures of the disk label, so it certainly could be a real
> copy instead of some Apple-internal prerelease, perhaps
> serialized.)
>
> In any case, the Twiggies inside the box are surely of official
> Apple FileWare manufacture, which means that the magnetic media
> may have degraded somewhat already; such are the risks of buying
> unopened.
>
> From previous discussions on this list, it sounds like some of you
> archivists may have managed some successful reads of disks with
> some degradation. What were your techniques? How did you deal with
> some of the material accumulating on drive heads and pads?
>
> Thanks for any guidance, --Tom

>
> -- -- ----- You received this message because you are a member of
> the LisaList group. The group FAQ is at
> http://lowendmac.com/lists/lisa.html To post to this group, send
> email to lisalist_at_email.domain.hidden To leave this group, send email
> to lisalist+unsubscribe_at_email.domain.hidden For more options, visit
> this group at http://groups.google.com/group/lisalist --- You
> received this message because you are subscribed to the Google
> Groups "LisaList" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> lisalist+unsubscribe_at_email.domain.hidden
> <mailto:lisalist+unsubscribe_at_email.domain.hidden>. For more options,
> visit https://groups.google.com/d/optout.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAlThrHIACgkQSCoUxoi1n+v3mgD+O/SnNgObN1rfrC5GWhBg3Y4X CeZ1py3+DY6iWo4lycoA/0OAfClTzI59CgOwixO11ZvszZ4dE1cR1/0vfbcb/16a =6GP9
-----END PGP SIGNATURE-----

-- 
-- 
-----
You received this message because you are a member of the LisaList group.
The group FAQ is at http://lowendmac.com/lists/lisa.html
To post to this group, send email to lisalist_at_email.domain.hidden
To leave this group, send email to lisalist+unsubscribe_at_email.domain.hidden
For more options, visit this group at http://groups.google.com/group/lisalist
--- 
You received this message because you are subscribed to the Google Groups "LisaList" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisalist+unsubscribe_at_googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Received on 2015-07-16 12:39:50

This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:16 EST