mirror of
https://github.com/fadden/nulib2.git
synced 2024-05-28 08:41:29 +00:00
3d91d2edd4
For some reason Expression Web 4 is doubling or tripling the navigation header. Looks like some weird interaction between EW4 and the old FrontPage-generated content. I keep smacking it but it keeps coming back, so I may just need to rebuild these pages without the navigation.
274 lines
12 KiB
HTML
274 lines
12 KiB
HTML
<html>
|
|
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
|
<title>FTN.e00005</title>
|
|
<meta content="t, default" name="Microsoft Border">
|
|
</head>
|
|
|
|
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
|
|
|
|
<p align="center"><font size="6"><strong></strong></font><br>
|
|
</p>
|
|
<hr>
|
|
|
|
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" dir="ltr" width="100%"><tr><!--msnavigation--><td valign="top"><!--msnavigation--><msnavigation border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
|
|
|
|
<p align="center"><font size="6"><strong></strong></font><br>
|
|
</p>
|
|
<hr>
|
|
|
|
</td></tr><!--msnavigation--></table><!--msnavigation--><msnavigation border="0" cellpadding="0" cellspacing="0" dir="ltr" width="100%"><tr><!--msnavigation--><msnavigation valign="top"><!--msnavigation--><msnavigation border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
|
|
|
|
<p align="center"><font size="6"><strong></strong></font><br>
|
|
</p>
|
|
<hr>
|
|
|
|
</td></tr><!--msnavigation--></table><!--msnavigation--><msnavigation border="0" cellpadding="0" cellspacing="0" dir="ltr" width="100%"><tr><!--msnavigation--><msnavigation valign="top"><!--msnavigation--><msnavigation border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
|
|
|
|
<p align="center"><font size="6"><strong></strong></font><br>
|
|
</p>
|
|
<hr>
|
|
|
|
</td></tr><!--msnavigation--></table><!--msnavigation--><msnavigation border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><msnavigation valign="top">
|
|
<h2>Apple II FTN - DiskCopy disk image</h2>
|
|
<p><a href="index.htm">Back to nulib.com library</a></p>
|
|
<hr><pre>
|
|
Apple II
|
|
File Type Notes
|
|
_____________________________________________________________________________
|
|
Developer Technical Support
|
|
|
|
File Type: $E0 (224)
|
|
Auxiliary Type: $0005
|
|
|
|
Full Name: DiskCopy disk image
|
|
Short Name: DiskCopy disk image
|
|
|
|
Written by: Matt Deatherage, Dave Lyons & Steve Christensen May 1992
|
|
|
|
Files of this type and auxiliary type contain disk images from Apple's
|
|
DiskCopy program on the Macintosh.
|
|
_____________________________________________________________________________
|
|
|
|
DiskCopy is a program written by Steve Christensen of Apple Computer, Inc.,
|
|
for internal use in duplicating and distributing 3.5" floppy disks. Because
|
|
of its utility in distributing disk images on the Macintosh, DiskCopy is used
|
|
in several Apple developer products even though DiskCopy is not an official
|
|
Apple product and is not supported as such.
|
|
|
|
Since the monthly Developer CD Series discs contain many DiskCopy disk images,
|
|
and since the AppleShare and HFS FSTs in System Software 6.0 and later
|
|
automatically translate DiskCopy files (HFS file type dImg and creator dCpy)
|
|
to Apple II file type $E0 and auxiliary type $0005, the format is provided
|
|
here for your utility use only. Apple does not guarantee that files not
|
|
generated by DiskCopy will work with DiskCopy.
|
|
|
|
|
|
DEFINITIONS
|
|
|
|
DiskCopy uses a simple checksum algorithm to help insure data integrity for
|
|
archived disk images. The algorithm for generating the 32-bit checksum is as
|
|
follows:
|
|
|
|
Initialize checksum to zero
|
|
For each data REVERSE WORD:
|
|
Add the data REVERSE WORD to the checksum
|
|
Rotate the 32-bit checksum right one bit (wrapping bit 0 to bit 31)
|
|
|
|
The following 65816 assembly language routine calculates a DiskCopy checksum.
|
|
It's not a speedy operation--it takes about 12 seconds to calculate the
|
|
checksum on an 800K disk image. Anyone finding an assembly routine that can
|
|
perform this task in under 5 seconds may apply for their IIgs Certificate of
|
|
Deityship, as documented in the File Type Note for file type $B6.
|
|
|
|
(Oh, by the way, any entries have to be under 1K in size--the following
|
|
routine is 88 bytes. So don't think unwinding loops is your ticket to fame
|
|
and fortune.)
|
|
|
|
****************************************************************************
|
|
*
|
|
* Compute checksum for DiskCopy data
|
|
*
|
|
* v1.2 by David A. Lyons, 18-May-92
|
|
*
|
|
* MPW IIgs assembly format
|
|
*
|
|
* Inputs on stack:
|
|
* Push pointer to data (long)
|
|
* Push size of data (long) (Must be even!)
|
|
* JSL CalcChecksum
|
|
* STA TheChecksum+2
|
|
* STX TheChecksum
|
|
*
|
|
* Output:
|
|
* Checksum in A and X (bytes +0 and +1 in X, bytes +2 and +3 in A)
|
|
* (The inputs have been removed from the stack)
|
|
*
|
|
****************************************************************************
|
|
CalcChecksum PROC
|
|
phd ;save caller's direct page reg
|
|
lda #0
|
|
pha
|
|
pha ;push initial checksum value (zero)
|
|
tsc
|
|
tcd
|
|
|
|
checksum equ 1
|
|
oldD equ checksum+4
|
|
theRTL equ oldD+2
|
|
dataSize equ theRTL+3
|
|
dataPtr equ dataSize+4
|
|
|
|
*** Set dataSize to -(dataSize/2)-1 so we can count up by one
|
|
*** (instead of down by two) to see when we're done
|
|
lda <dataSize+2
|
|
lsr a
|
|
eor #$ffff
|
|
sta <dataSize+2
|
|
lda <dataSize
|
|
ror a
|
|
eor #$ffff
|
|
sta <dataSize
|
|
|
|
ldy #0
|
|
nextWord inc <dataSize
|
|
bne moreData
|
|
inc <dataSize+2
|
|
beq noMoreData
|
|
moreData
|
|
|
|
*** Get next 16-bit word from the data buffer
|
|
lda [<dataPtr],y
|
|
xba ;swap to 65816 byte order
|
|
|
|
*** Add the data word to the checksum
|
|
clc
|
|
adc <checksum
|
|
sta <checksum
|
|
bcc noCksumRoll
|
|
inc <checksum+2
|
|
noCksumRoll
|
|
*** Rotate the 32-bit checksum right one bit, wrapping bit 0 into bit 31
|
|
lda <checksum+2
|
|
lsr a
|
|
ror <checksum
|
|
bcc bit0was0
|
|
ora #$8000 ;if we rotated a 1 out of bit 0,
|
|
bit0was0 sta <checksum+2 ; then set bit 31
|
|
|
|
*** Advance to the next word and go back for more
|
|
iny
|
|
iny
|
|
bne nextWord ;go back for more data
|
|
inc <dataPtr+2
|
|
bra nextWord ;go back for next bank of data
|
|
|
|
noMoreData pla
|
|
xba
|
|
tay
|
|
pla
|
|
xba
|
|
tax ;pull checksum into YX (put in 68000
|
|
order)
|
|
|
|
pld ;restore caller's direct page reg
|
|
|
|
lda 2,s
|
|
sta 2+8,s
|
|
lda 1,s
|
|
sta 1+8,s
|
|
pla
|
|
pla
|
|
pla
|
|
pla ;discard input values
|
|
|
|
tya
|
|
rtl
|
|
|
|
EndP
|
|
|
|
END
|
|
|
|
The following definition is used in this document in addition to those defined
|
|
for all Apple II file types:
|
|
|
|
Checksum A 32-byte quantity calculated using the previously-defined
|
|
algorithm. When these are contained in the file, they are in
|
|
REVERSE order.
|
|
|
|
|
|
FILE STRUCTURE
|
|
|
|
All of the information for a DiskCopy disk image is in the data fork. The
|
|
resource fork usually contains Macintosh resources (in Macintosh resource fork
|
|
format), including vers resources listing the checksums. This allows
|
|
Macintosh users to use the Macintosh Finder's "Get Info..." function to
|
|
quickly examine the checksums.
|
|
The File Format
|
|
|
|
Because this is a native Macintosh file format, all the multi-byte constants
|
|
are stored in Reverse order.
|
|
|
|
diskName (+000) 64 Bytes A Pascal String containing the name of the
|
|
disk. This field takes 64 bytes
|
|
regardless of the length of the String.
|
|
dataSize (+064) Rev. Long The number of bytes (not blocks) of user
|
|
data. User data is the 512 bytes of each
|
|
block that a normal block-reading command
|
|
returns.
|
|
tagSize (+068) Rev. Long The number of bytes of tag data. Tag data
|
|
is the extra 12 bytes of "scavenger"
|
|
information present on 400K and 800K
|
|
Macintosh disks. Apple II operating
|
|
systems always leave these bytes zeroed,
|
|
and they're not present on 720K or 1440K
|
|
disks. If there are no tag bytes, this
|
|
field will be zero.
|
|
dataChecksum (+072) Checksum Checksum of all the user data on the disk.
|
|
The checksum algorithm is called for the
|
|
entire disk, not on a block-by-block or
|
|
sector-by-sector basis. This is in
|
|
Reverse order (most significant byte
|
|
first).
|
|
tagChecksum (+076) Checksum Checksum of all the tag data on the disk.
|
|
If there is no tag data, this should be
|
|
zero. This is in Reverse order (most
|
|
significant byte first).
|
|
diskFormat (+080) Byte 0 = 400K
|
|
1 = 800K
|
|
2 = 720K
|
|
3 = 1440K (all other values are reserved)
|
|
formatByte (+081) Byte $12 = 400K
|
|
$22 = >400K Macintosh (DiskCopy uses this
|
|
value for all Apple II disks not
|
|
800K in size, and even for some of
|
|
those)
|
|
$24 = 800K Apple II disk
|
|
private (+082) Rev. Word Must be $0100. If this field is not
|
|
$0100, the file may be in a different
|
|
format.
|
|
userData (+084) dataSize Bytes
|
|
The data blocks for the disk. These are
|
|
in order from block zero through the end
|
|
of the disk.
|
|
tagData (+xxx) tagSize Bytes The tag data for this disk, starting with
|
|
the tag data for the first block and
|
|
proceeding in order. This field is not
|
|
present for 720K and 1440K disks, but it
|
|
is present for all other formats even if
|
|
all the data is zeroes.
|
|
Further Reference
|
|
_____________________________________________________________________________
|
|
|
|
o GS/OS Reference
|
|
</pre><hr>
|
|
|
|
<address>This document is Copyright by Apple Computer, Inc.</address>
|
|
|
|
<!--msnavigation--></td></tr><!--msnavigation--></table><!--msnavigation--></td></tr><!--msnavigation--></table><!--msnavigation--></td></tr><!--msnavigation--></table><!--msnavigation--></td></tr><!--msnavigation--></table></body>
|
|
|
|
</html>
|