Credits

2012-01-07T21:29:07Z

Philpem:

== Credits and acknowledgements ==

''If you update this page, please sign your additions with: <nowiki>--~~~~</nowiki>''

The DiscFerret team would like to extend their thanks to every single one of the people who bought a DiscFerret, anyone who threw money at us without asking for a DiscFerret (or in some cases anything) in return, and everyone on the Classiccmp mailing lists who participated in the many and varied DiscFerret threads.

Without you guys, the DiscFerret would never have come to be. You guys are awesome, and I seriously value every bit of feedback, every email, and every comment on the IRC channel and the various message boards. You people are the reason the DiscFerret has gotten to be as good as it has, and why it keeps on improving. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)

The DiscFerret team would also like to thank the following people and companies for their assistance during the development of the DiscFerret.

* '''The Icarus Verilog and GTKWave Projects''' Your Verilog simulator and waveform viewer are second to none, are easy to use, and continually make ModelSim look like a (very expensive) toy. Were it not for these tools, DiscFerret design verification would have taken a lot longer. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''Rob Northen''' Copylock repeatedly broke the old disc reader engine. It no longer does. Thanks for exposing the bugs in my HDL code! (-Phil)
* '''Sarayan''', '''Lord Nightmare''' and '''Balrog''' (in no particular order) For occupying #discferret@irc.freenode.net, providing test data, breaking stuff and suggesting fixes. I couldn't ask for a better development team. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''Michelle Van Zandt''' (http://graphix.ginpu.us) The graphic designer who created the DiscFerret logo. You did an excellent job, Michelle. Seriously. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''Bioware''' I don't know if I should thank you or curse you. Mass Effect is far more addictive than it should be...! --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''TotalPhase''' I really don't know what I'd have done without the Beagle USB480. Probably torn my hair out several times over trying to debug the Microchip USB stack. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''Microchip Technology''' I sent you a bug report for the USB stack, and within a week or so you'd sent me a workaround. The bug was fixed in the next release. I really can't argue with customer service like that (especially when other semiconductor companies were trying to get rid of me as quickly as possible)! --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)

The DiscFerret team would also like to extend rude gestures and curses to the following entities:

* '''Altera''' Your FPGAs are great, are easier to find than Xilinx parts, and your synthesis software is awesome. '''BUT YOUR DESIGN VERIFICATION TOOLS SUCK!''' Really. SignalTap has been broken since 10.0, that's two major revisions at the time of writing. JTAG still doesn't work reliably on Linux with a USB Blaster. Your tools have wasted enough of my time that I'm seriously considering using Xilinx parts for my next design. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''The USB Implementers' Forum (USB-IF)''' (or as I prefer to call them, the USB Impairment Forum) For making it so difficult and so expensive to get a USB Vendor ID. Is it any wonder that nearly every backstreet Chinese manufacturer just picks a random VID and uses it? I mean, $2000 for a number?! I don't need 65536 PIDs, I need maybe 128 at most. Do what the IEEE do with OUIs -- sell smaller blocks for a hundred dollars or so. I don't care about being able to use your stupid logo, I just want to make USB devices which don't conflict with anyone else's. For bonus points, the non-logo license fee has '''doubled''' to $2,000 per year. Where do you guys get off? --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)

Credits

2012-01-07T21:28:04Z

Philpem: Created page with "== Credits and acknowledgements == ''If you update this page, please sign your additions with: <nowiki>--~~~~</nowiki>'' The DiscFerret team would like to extend their thanks t..."

== Credits and acknowledgements ==

''If you update this page, please sign your additions with: <nowiki>--~~~~</nowiki>''

The DiscFerret team would like to extend their thanks to every single one of the people who bought a DiscFerret, anyone who threw money at us without asking for a DiscFerret (or in some cases anything) in return, and everyone on the Classiccmp mailing lists who participated in the many and varied DiscFerret threads.

Without you guys, the DiscFerret would never have come to be. You guys are awesome, and I seriously value every bit of feedback, every email, and every comment on the IRC channel and the various message boards. You people are the reason the DiscFerret has gotten to be as good as it has, and why it keeps on improving. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)

The DiscFerret team would also like to thank the following people and companies for their assistance during the development of the DiscFerret.

* '''The Icarus Verilog and GTKWave Projects''' Your Verilog simulator and waveform viewer are second to none, are easy to use, and continually make ModelSim look like a (very expensive) toy. Were it not for these tools, DiscFerret design verification would have taken a lot longer. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''Rob Northen''' Copylock repeatedly broke the old disc reader engine. It no longer does. Thanks for exposing the bugs in my HDL code! (-Phil)
* '''Sarayan''', '''Lord Nightmare''' and '''Balrog''' (in no particular order) For occupying #discferret@irc.freenode.net, providing test data, breaking stuff and suggesting fixes. I couldn't ask for a better development team. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''Michelle Van Zandt''' (http://graphix.ginpu.us) The graphic designer who created the DiscFerret logo. You did an excellent job, Michelle. Seriously. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''Bioware''' I don't know if I should thank you or curse you. Mass Effect is far more addictive than it should be...! --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''TotalPhase''' I really don't know what I'd have done without the Beagle USB480. Probably torn my hair out several times over trying to debug the Microchip USB stack. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''Microchip Technology''' I gave you a bug report for the USB stack, and within a week or so you'd sent me a workaround. The bug was fixed in the next release. I really can't argue with customer service like that! You need to work on testing your appnote software a bit better, though, and the USB Stack docs are a mess. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)

The DiscFerret team would also like to extend rude gestures and curses to the following entities:

* '''Altera''' Your FPGAs are great, are easier to find than Xilinx parts, and your synthesis software is awesome. '''BUT YOUR DESIGN VERIFICATION TOOLS SUCK!''' Really. SignalTap has been broken since 10.0, that's two major revisions at the time of writing. JTAG still doesn't work reliably on Linux with a USB Blaster. Your tools have wasted enough of my time that I'm seriously considering using Xilinx parts for my next design. --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)
* '''The USB Implementers' Forum (USB-IF)''' (or as I prefer to call them, the USB Impairment Forum) For making it so difficult and so expensive to get a USB Vendor ID. Is it any wonder that nearly every backstreet Chinese manufacturer just picks a random VID and uses it? I mean, $2000 for a number?! I don't need 65536 PIDs, I need maybe 128 at most. Do what the IEEE do with OUIs -- sell smaller blocks for a hundred dollars or so. I don't care about being able to use your stupid logo, I just want to make USB devices which don't conflict with anyone else's. For bonus points, the non-logo license fee has '''doubled''' to $2,000 per year. Where do you guys get off? --[[User:Philpem|Philpem]] 21:28, 7 January 2012 (GMT)

DFI image format

2012-01-07T18:27:23Z

Philpem:

2011-12-23T03:04:56Z

Philpem: Unprotected "Main Page": user account creation has been disabled and only developers have access. no need to protect individual pages.

#REDIRECT [[DiscFerret]]

2011-06-14T13:26:07Z

Philpem:

CWTool image format

2011-06-14T13:25:45Z

Philpem: Created page with "Category:Disc image files *Format originator:* CWTool by Karsten Scheibler (http://www.unusedino.de/cw/) == Common features == Track numbers are stored as 'absolute' tracks..."

[[Category:Disc image files]]

*Format originator:* CWTool by Karsten Scheibler (http://www.unusedino.de/cw/)

== Common features ==
Track numbers are stored as 'absolute' tracks. If a drive has only one magnetic head, the track number will match the physical track number used to read the given track.

When a drive has more than one head (e.g. a 3.5-inch double-sided 80-track drive), the following conversions are used:

* '''Converting from physical track/head numbers to absolute track number''': AbsTrack = (PhysTrack * NumHeads) + PhysHead
* '''Converting from absolute track number to physical track/head numbers''': PhysTrack = AbsTrack / NumHeads, PhysHead = AbsTrack % NumHeads (forward-slash denotes integer division, percent denotes an integer modulo operation)

This means that our typical 3.5-inch floppy disc with two physical heads and 80 physical tracks will -- to CWTool -- be seen as having 160 absolute tracks. Thus, in order to decode back to a cyl/head address, we need to know how many heads the original drive had, and how many were used to image the disc. Failing that, we can make an educated guess based on the maximum absolute track number seen in the image (e.g. a greater than 85 absolute tracks is likely to indicate that the image was created from a double-sided disc).

== Binary file formats ==
All CWTool binary image formats begin with a 32-byte "magic string" which identifies the file format version. Possible magic strings include:

* "cwtool raw data" -- binary format 1
* "cwtool raw data 2" -- binary format 2
* "cwtool raw data 3" -- binary format 3

Binary formats store tracks as a sequence of data blocks with a header prepended. This header consists of:

* TRACK_MAGIC -- one byte, 0xCA
* Physical track number -- one byte
* Clock -- one byte
* Flags -- one byte
* Payload size -- 32-bit unsigned integer, little endian (most significant byte first)

== Text-based file formats ==
This format is unique in that it stores the track data as decimal or hex numbers. The magic string detected by CWTool is "# cwtool raw text 3\n", where '\n' is an ASCII newline.

<nowiki># cwtool raw text 3
track_data track clock flags {
</nowiki>

Apple DiskCopy 4.2

2011-06-12T19:35:08Z

Philpem:

[[Category:Disc image files]]

'''Attribution: This article was sourced from the 68kMLA Wiki at http://68kmla.org/wiki/DiskCopy_4.2_format_specification. Permission was given in IRC by Balrog and Lord Nightmare to copy the article here for safe-keeping.'''

This article describes the '''file format for Apple Disk Copy 4.2''' .image files

Much information comes from the [[CiderPress]] and [[Mini vMac]] source codes. More authoritative information comes from [http://www.nulib.com/library/FTN.e00005.htm nulib.com]. Some info on tags from [http://www.pagetable.com/?p=50 Inside Macintosh, 1st ed. page II-212]. This format is also used in DiskCopy 4.1. DiskCopy 6.3.3 uses a variant with tags omitted. DART is a variant which adds compression.

==Resource fork notes==
Disk Copy 4.2 files have a [[resource fork]], but it only contains a copy of the data and tag checksums and can be safely ignored; files without the fork will still work perfectly.

* Disk copy 4.2 images have a type of 'dImg' and creator of 'dCpy', without these the program will not recognize the file; they can be easily added to images missing them with resedit.

{| border="1" cellpadding="2"
|+DC42 File format Overview
|-
!offset !! type/size !! contents
|-
|0x00||byte||Length of image name string ('Pascal name length')
|-
|0x01-0x3F||63 bytes||Image name, in ascii, padded with NULs
|-
|0x40-0x43||BE_UINT32||Data size in bytes (of block starting at 0x54)
|-
|0x44-0x47||BE_UINT32||Tag size in bytes (of block starting after end of Data block)
|-
|0x48-0x4B||BE_UINT32||Data Checksum
|-
|0x4C-0x4F||BE_UINT32||Tag Checksum
|-
|0x50||byte||Disk encoding
|-
|0x51||byte||Format Byte
|-
|0x52-0x53||BE_UINT16||'0x01 0x00' ('Private Word') AKA Magic Number
|-
|0x54-...||variable||Image data
|-
|...-EOF||variable||Tag data
|}

== Specifics of data fork sections ==
=== 0x00: Length of image name string ===
Technically this is part of the 0x01-0x3f area, as pascal strings apparently store their length as their first byte. Effectively the address of the last non-NUL byte of the image name. bytes after the end address are ignored, and sometimes are used to hold extra information, or hold garbage (in the case of the 1.44mb system 6.0.8 startup disk, this is leftovers in memory from the System Additions disk, so the string ends up being System Startupns)
* Note: A special (bug) case happens when the disk name is "-not a Macintosh disk", which the name is set to when using dc42 on non-mac diskettes. In that case, the length is set one byte too high; this is probably a bug in dc42 that was just never fixed.

=== 0x01-0x3F: Image name ===
This is the image name string. It is copied from the volume name of the disk or diskette being imaged.

=== 0x40-0x43: Data block size in bytes ===
This has one of 4 values on most diskettes:
00 06 40 00 (409600 bytes) for 400k GCR disks
00 0c 80 00 (819200 bytes) for 800k GCR disks
00 0b 40 00 (737280 bytes) for 720k MFM disks
00 16 80 00 (1474560 bytes) for 1440k MFM disks

=== 0x44-0x47: Tag size in bytes ===
This is typically 12 bytes for every 512 bytes in the image, apparently stored in the data mark in each sector on the media. The format for Tag data is described at the bottom of the document, and is important for repairing damaged disks using disk doctor. It is also very important on Lisa Diskettes (according to LisaEM source).
00 00 25 80 (9600 bytes) for 400k disks w/tags
00 00 4b 00 (19200 bytes) for 800k disks w/tags
00 00 00 00 for diskettes with no tags

=== 0x48-0x4B: Data Checksum ===
The algorithm for this is: start with 00000000, add each consecutive 16 bit Big Endian word of the section, then rotate the 32 bit result right by 1 bit.

=== 0x4c-0x4F: Tag Checksum ===
The algorithm for this is the same as for the data, however the first 12 bytes of the tag section, if present, are skipped (probably due to a bug in an older disk copy version and kept for compatibility).
* Tag Checksum is 00 00 00 00 if no tag data is present.

=== 0x50: Disk encoding ===
This byte describes the encoding used for the disk the data was imaged from, from a 'what type of disk is this?' perspective.
00 = GCR CLV ssdd (400k)
01 = GCR CLV dsdd (800k)
02 = MFM CAV dsdd (720k)
03 = MFM CAV dshd (1440k)
Other encodings may exist, as DC42 was originally designed to be able to image HD20 disks.

=== 0x51: Format Byte ===
This byte has one of two meanings, depending on whether the disk is GCR format 400k or 800k, or MFM format. The byte is completely ignored for the rare GCR-on-HD format (which always has a 1:1 interleave and is always 2 sided).
* If disk is GCR format 400k or 800k:
This byte is a copy of the GCR format nybble (6 bits),
which appears in the headers of every GCR sector.
$02 = Mac 400k
$12 = (documentation error claims this is for mac 400k disks, but this is wrong)
$22 = Disk formatted as Mac 800k
$24 = Disk formatted as Prodos 800k (AppleIIgs format)
$96 = INVALID (Disk was misformatted or had GCR 0-fill (0x96 which represents data of 0x00)
written to its format byte)
Values for bitfield:
76543210
||||||||
|||\\\\\- These 5 bits are sector interleave factor:
||| setting of 02 means 2:1 interleave: 0 8 1 9 2 10 3 11 4 12 5 13 6 14 7 15
||| setting of 04 means 4:1 interleave: 0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15
||\------ This bit indicates whether a disk is 2 sided or not. 0 = 1 sided, 1 = 2 sided.
\\------- always 0, as GCR nybbles are only 6 bits
*If disk is MFM format:
This byte is used to define MFM sector size and whether the disk is
two sided or not.
Interleave is ALWAYS 1:1 for these formats.
$22 = double-sided MFM diskettes with 512 byte sectors
Values for bitfield:
76543210
||||||||
|||\\\\\- These 5 bits are sector size as a multiple of 256 bytes
||| i.e. 02 = 2*256 = 512 bytes per sector
||\------ This bit indicates whether a disk is 2 sided or not. 0 = 1 sided, 1 = 2 sided.
\\------- unused, always 0

=== 0x52-0x53: Private Word/Magic Number ===
This is more or less the 'magic number' of any DC42 format file; if it is not $01 $00, it is not a DC42 format file.

=== 0x54-...: Image data ===
The size in bytes of the data stored here is the value at 0x40-0x43.

=== ...-EOF: Tag data ===
The size in bytes of the data stored here is the value at 0x44-0x47.

== Tag Data format ==
The tag data is 12 bytes per 512-byte disk sector, and is stored, like the Image data, in sector order.
The actual format for each 12-byte block of the Tag data differs for Lisa, MFS and HFS disks,
and for MFS or HFS any of them may be wrong or absent! be warned!
* The Tag format for Lisa 400k or 800k disks is currently unknown, but without tags the disks will not function.
*For MFS filesystems the Tag format is as follows:
BE WARNED: when reading tag data, if the bit at 00 40 00 00 of any of the 3 32 bit words of the tag is set, the tag
data for the sector it is part of is trashed and can be ignored. There IS a puprose to the data written when 0x40 is set, I'm just not sure what it is.
offset type/size contents
0x00 BE_UINT32 File number on disk, within MFS filesystem
0x04 BE_UINT16 Flags bitfield:
FEDCBA98 76543210
|||||||| ||||||||
|||||||| |||\\\\\- unknown, seems unused
|||||||| ||\------ If set, Tag for this sector is not valid.
|||||||| \\------- unknown
|||||||\---------- sector content type: 0: system file; 1: user file (guessed)
||||||\----------- sector is part of a: 0: data fork; 1: resource fork
|\\\\\------------ unknown
\----------------- unknown, sometimes set on the last few sectors of a data or resource fork
0x06 BE_UINT16 Logical block number within the file
0x08 BE_UINT32 Time of last modification, in seconds since 0:00:00, 1/1/1904
Note that the last mod time may be different on the final sector of a file; this may indicate something special.

Apple DiskCopy 4.2

2011-06-12T19:34:02Z

Philpem:

[[Category:Disc image files]]

'''Attribution: This article was sourced from the 68kMLA Wiki at http://68kmla.org/wiki/DiskCopy_4.2_format_specification. Permission was given in IRC by Balrog and Lord_Nightmare to copy the article here for safe-keeping.'''

This article describes the '''file format for Apple Disk Copy 4.2''' .image files

Much information comes from the [[CiderPress]] and [[Mini vMac]] source codes. More authoritative information comes from [http://www.nulib.com/library/FTN.e00005.htm nulib.com]. Some info on tags from [http://www.pagetable.com/?p=50 Inside Macintosh, 1st ed. page II-212]. This format is also used in DiskCopy 4.1. DiskCopy 6.3.3 uses a variant with tags omitted. DART is a variant which adds compression.

==Resource fork notes==
Disk Copy 4.2 files have a [[resource fork]], but it only contains a copy of the data and tag checksums and can be safely ignored; files without the fork will still work perfectly.

* Disk copy 4.2 images have a type of 'dImg' and creator of 'dCpy', without these the program will not recognize the file; they can be easily added to images missing them with resedit.

{| border="1" cellpadding="2"
|+DC42 File format Overview
|-
!offset !! type/size !! contents
|-
|0x00||byte||Length of image name string ('Pascal name length')
|-
|0x01-0x3F||63 bytes||Image name, in ascii, padded with NULs
|-
|0x40-0x43||BE_UINT32||Data size in bytes (of block starting at 0x54)
|-
|0x44-0x47||BE_UINT32||Tag size in bytes (of block starting after end of Data block)
|-
|0x48-0x4B||BE_UINT32||Data Checksum
|-
|0x4C-0x4F||BE_UINT32||Tag Checksum
|-
|0x50||byte||Disk encoding
|-
|0x51||byte||Format Byte
|-
|0x52-0x53||BE_UINT16||'0x01 0x00' ('Private Word') AKA Magic Number
|-
|0x54-...||variable||Image data
|-
|...-EOF||variable||Tag data
|}

== Specifics of data fork sections ==
=== 0x00: Length of image name string ===
Technically this is part of the 0x01-0x3f area, as pascal strings apparently store their length as their first byte. Effectively the address of the last non-NUL byte of the image name. bytes after the end address are ignored, and sometimes are used to hold extra information, or hold garbage (in the case of the 1.44mb system 6.0.8 startup disk, this is leftovers in memory from the System Additions disk, so the string ends up being System Startupns)
* Note: A special (bug) case happens when the disk name is "-not a Macintosh disk", which the name is set to when using dc42 on non-mac diskettes. In that case, the length is set one byte too high; this is probably a bug in dc42 that was just never fixed.

=== 0x01-0x3F: Image name ===
This is the image name string. It is copied from the volume name of the disk or diskette being imaged.

=== 0x40-0x43: Data block size in bytes ===
This has one of 4 values on most diskettes:
00 06 40 00 (409600 bytes) for 400k GCR disks
00 0c 80 00 (819200 bytes) for 800k GCR disks
00 0b 40 00 (737280 bytes) for 720k MFM disks
00 16 80 00 (1474560 bytes) for 1440k MFM disks

=== 0x44-0x47: Tag size in bytes ===
This is typically 12 bytes for every 512 bytes in the image, apparently stored in the data mark in each sector on the media. The format for Tag data is described at the bottom of the document, and is important for repairing damaged disks using disk doctor. It is also very important on Lisa Diskettes (according to LisaEM source).
00 00 25 80 (9600 bytes) for 400k disks w/tags
00 00 4b 00 (19200 bytes) for 800k disks w/tags
00 00 00 00 for diskettes with no tags

=== 0x48-0x4B: Data Checksum ===
The algorithm for this is: start with 00000000, add each consecutive 16 bit Big Endian word of the section, then rotate the 32 bit result right by 1 bit.

=== 0x4c-0x4F: Tag Checksum ===
The algorithm for this is the same as for the data, however the first 12 bytes of the tag section, if present, are skipped (probably due to a bug in an older disk copy version and kept for compatibility).
* Tag Checksum is 00 00 00 00 if no tag data is present.

=== 0x50: Disk encoding ===
This byte describes the encoding used for the disk the data was imaged from, from a 'what type of disk is this?' perspective.
00 = GCR CLV ssdd (400k)
01 = GCR CLV dsdd (800k)
02 = MFM CAV dsdd (720k)
03 = MFM CAV dshd (1440k)
Other encodings may exist, as DC42 was originally designed to be able to image HD20 disks.

=== 0x51: Format Byte ===
This byte has one of two meanings, depending on whether the disk is GCR format 400k or 800k, or MFM format. The byte is completely ignored for the rare GCR-on-HD format (which always has a 1:1 interleave and is always 2 sided).
* If disk is GCR format 400k or 800k:
This byte is a copy of the GCR format nybble (6 bits),
which appears in the headers of every GCR sector.
$02 = Mac 400k
$12 = (documentation error claims this is for mac 400k disks, but this is wrong)
$22 = Disk formatted as Mac 800k
$24 = Disk formatted as Prodos 800k (AppleIIgs format)
$96 = INVALID (Disk was misformatted or had GCR 0-fill (0x96 which represents data of 0x00)
written to its format byte)
Values for bitfield:
76543210
||||||||
|||\\\\\- These 5 bits are sector interleave factor:
||| setting of 02 means 2:1 interleave: 0 8 1 9 2 10 3 11 4 12 5 13 6 14 7 15
||| setting of 04 means 4:1 interleave: 0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15
||\------ This bit indicates whether a disk is 2 sided or not. 0 = 1 sided, 1 = 2 sided.
\\------- always 0, as GCR nybbles are only 6 bits
*If disk is MFM format:
This byte is used to define MFM sector size and whether the disk is
two sided or not.
Interleave is ALWAYS 1:1 for these formats.
$22 = double-sided MFM diskettes with 512 byte sectors
Values for bitfield:
76543210
||||||||
|||\\\\\- These 5 bits are sector size as a multiple of 256 bytes
||| i.e. 02 = 2*256 = 512 bytes per sector
||\------ This bit indicates whether a disk is 2 sided or not. 0 = 1 sided, 1 = 2 sided.
\\------- unused, always 0

=== 0x52-0x53: Private Word/Magic Number ===
This is more or less the 'magic number' of any DC42 format file; if it is not $01 $00, it is not a DC42 format file.

=== 0x54-...: Image data ===
The size in bytes of the data stored here is the value at 0x40-0x43.

=== ...-EOF: Tag data ===
The size in bytes of the data stored here is the value at 0x44-0x47.

== Tag Data format ==
The tag data is 12 bytes per 512-byte disk sector, and is stored, like the Image data, in sector order.
The actual format for each 12-byte block of the Tag data differs for Lisa, MFS and HFS disks,
and for MFS or HFS any of them may be wrong or absent! be warned!
* The Tag format for Lisa 400k or 800k disks is currently unknown, but without tags the disks will not function.
*For MFS filesystems the Tag format is as follows:
BE WARNED: when reading tag data, if the bit at 00 40 00 00 of any of the 3 32 bit words of the tag is set, the tag
data for the sector it is part of is trashed and can be ignored. There IS a puprose to the data written when 0x40 is set, I'm just not sure what it is.
offset type/size contents
0x00 BE_UINT32 File number on disk, within MFS filesystem
0x04 BE_UINT16 Flags bitfield:
FEDCBA98 76543210
|||||||| ||||||||
|||||||| |||\\\\\- unknown, seems unused
|||||||| ||\------ If set, Tag for this sector is not valid.
|||||||| \\------- unknown
|||||||\---------- sector content type: 0: system file; 1: user file (guessed)
||||||\----------- sector is part of a: 0: data fork; 1: resource fork
|\\\\\------------ unknown
\----------------- unknown, sometimes set on the last few sectors of a data or resource fork
0x06 BE_UINT16 Logical block number within the file
0x08 BE_UINT32 Time of last modification, in seconds since 0:00:00, 1/1/1904
Note that the last mod time may be different on the final sector of a file; this may indicate something special.