Re: Tips for making Twiggy images

From: Shirl Casner <shirlgato_at_email.domain.hidden>
Date: Wed, 4 Feb 2015 18:36:33 -0700


Hi Tom,

Concerning Twiggy disk images, if you can create the Lisa Workshop 1.0 disk images, that would be great.

I looked at the Lisa disk images on Bit Savers (www.mirrorservice.org/sites/www.bitsavers.org/bits/Apple/Lisa/monitor/), and found there is already a set of Workshop twiggy disk images here, but it would be good to have others images in case the Bit Savers images have some type of problem.

I also found that these disk images do seem to have complete TAG DATA. Per the Macintosh Disk Copy v4.2 format ( https://wiki.68kmla.org/DiskCopy_4.2_format_specification) the size of the TAG DATA is found at image file offset 0x44-0x47 (hex). These images have 0x00004FC8 as the tag data size which in decimal is 20,424. When divided by 12 (the tag size the BLU utility seems to use), this produces 1,702 which is the number of 512-bye blocks on a Twiggy disk (holds 860K total).

If you do produce an image of these Workshop Twiggy disks, please include the TAG DATA too. I don't know how BLU works, so don't know if including tag data is the default.

The tag data is important since it allows you to easily determine which blocks on a disk belong to a specific file. Per the Apple Lisa Device Drivers Manual dated January 11, 1984 (attached) the Pascal record format of a tag (called a PAGE LABEL in Lisa parlance, see page 136) is ({x} means number of bytes):

pagelabel = packed record

   {2} version: integer; 
   {1...} datastat: (dataok, datamaybe, databad); 
   {...1} filler: -32..31; 
   {1} volume: int1; 
   {2} fileid: integer; 
   {2} dataused: integer; 
   {4} abspage: int4; 
   {4} relpage: int4; 
   {4} fwdlink: int4; 
   {4} bkwdlink: int4; 

end;

Note that Lisa tags contained 24 bytes whereas the Macintosh tags contained 12 bytes.

Key fields here to identify a file's data blocks are FILEID (file id) and ABSPAGE (absolute page) which the 12 byte tag data produced by BLU (and Macintosh DiskCopy) just contain these fields.

I noticed on the Monitor disks which exist on Bit Savers that the majority of the TAG DATA is empty, except for a few with FILEID 0xAAAA. This is a special ID which represents boot blocks. Other special files such as directory files have other ID such as 0xBBBB. Seems Apple's Lisa file system assumes there will never be more than 32,767 files on a disk and the signed negative IDs were allocated to special files.

Bit Saver's disk image for a Lisa Office System v1 Twiggy disk contains more complete TAG DATA.

Reason for mentioning how Lisa tag data is useful for finding file data is that there were several versions (believe at least 3) of Lisa disk formats which makes it difficult to extract Lisa file data unless you know the specifics of each format. It is my understanding that the Lisa tag format did not change so this data can be used regardless of the file system version.

Hope this info helps.

Regards,
David Craig

-- 
-- 
-----
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.


-- -- ----- 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.
=== On January 25, 2015, at 11:43 AM, 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_googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Received on 2015-07-16 12:39:45

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