Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!news.uoregon.edu!cie.uoregon.edu!nparker From: nparker@cie.uoregon.edu (Neil Parker) Newsgroups: comp.sys.apple2 Subject: Re: Need Disk Format Info Date: 7 Apr 1993 10:57:09 GMT Organization: The Universal Society for the Prevention of Reality Lines: 201 Distribution: world Message-ID: <1puc25$7c1@pith.uoregon.edu> References: <1prg71INNmvp@irau40.ira.uka.de> NNTP-Posting-Host: cie.uoregon.edu In article <1prg71INNmvp@irau40.ira.uka.de> voss@i40s16.ira.uka.de (Stefan Voss) writes: >In article , Christopher James Larson writes: >|> >|> I need to find out some information about the format of a 5.25" disk on the >|> Apple IIe. >|> [stuff deleted] >|> Track 11hex is the track that contains the catalog info, I think. >|> I need to know how it assigns the program names to where they are located >|> on the disk. > >Yes, you are right. Track $11 contains the catalog information, beginning at >sector $F and continuing towards sector $0. Each catalog entry contains: >- the file name >- the file type (BAS, BIN, TXT, ...) >- a pointer to the track-sector-list (TSL) (I believe, it's in SS TT order. > i.e. SS is the sector number and TT is the track number.) >- ... (can't remember other things. Please also note that I'm unsure about > the order of file name, file type and TSL.) > >The TSL itself just consists of up to 128 SS-TT-pairs (pointers to the data >sectors). Because the TSL is just 1 sector, a DOS3.3 file is limited to >128*256 = 32768 bytes (= 32k). Almost, but not quite. On track $11 sector 0, you will find the Volume Table of Contents (VTOC). This is the key sector from which all searches start out. Format of VTOC: Byte Meaning ---- ------- $00 Unused (always $04 on my disks) $01 Track number of first catalog sector $02 Sector number of first catalog sector $03 DOS version number ($03 for DOS 3.3) $04-05 Unused $06 Volume number ($01-$FE) $07-26 Unused $27 Number of track/sector pairs in a track/sector list (always $7A on normal disks) $28-2F Unused $30 Last track where sectors were allocated $31 Direction of allocation ($01=inward, $FF=outward) $32-33 Unused $34 Number of tracks per disk (normally $23) $35 Number of sectors per track (normally $10) $36-37 Number of bytes per sector (normally $0100) $38-3B Bit map for track 0 $3C-3F Bit map for track 1 .... $C0-C3 Bit map for track $22 $C4-FF Unused on normal disks (may contain extra bit maps on disks with more than 35 tracks) Bit map format: Byte 0 Byte 1 Byte 2 Byte 3 FEDCBA98 76543210 ........ ........ A 1-bit in any bit position indicates that the corresponding sector is free. Bytes 2 and 3 in the bit map are always $00 on normal disks. Bytes 1 and 2 in the VTOC point to the first catalog sector. On most disks, the first catalog sector is track $11 sector $0F, and subsequent catalog sectors occupy track $11 sector $0E, track $11 sector $0D, and so on down to track $11 sector $01. However, DOS 3.3 doesn't really care where the catalog sectors are or how many there are, as long as there is a pointer to the first one in the VTOC. (Note, however, that some utilities, such as Copy II Plus, DO care, and will get lost if the catalog isn't in its normal position and exactly 15 sectors long.) Each catalog sector contains a pointer to the next catalog sector, and seven file entries. The format of a catalog sector is as follows: Byte Meaning ---- ------- $00 Unused $01 Track number of next catalog sector ($00 if there aren't any more) $02 Sector number of next catalog sector ($00 if there aren't any more) $03-0A Unused $0B-2D First file entry $2E-50 Second file entry $51-73 Third file entry $74-96 Fourth file entry $97-B9 Fifth file entry $BA-DC Sixth file entry $DD-FF Seventh file entry Each file entry looks like this: Byte Meaning ---- ------- $00 Track number of this file's first track/sector list $01 Sector number of this file's first track/sector list $02 File type: Bit Meaning --- ------- 7 0=unlocked, 1=locked 6-0 File type ($00=Text, $01=Integer, $02=Applesoft, $04=Binary, $08=S, $10=Relocatable, $20=A, $40=B) $03-20 File name (high bits set; padded with blanks on the right) $21-22 Number of sectors allocated to this file Every file has a set of one or more track/sector lists which point to the actual data sectors of the file. Each track/sector list points to up to 122 data sectors; if the file is too long for one track/sector list, a second one is allocated, and a pointer to it is stored in the first one. Likewise, if the file is too long for two track/sector lists, a third is allocated, and so on. Note that DOS 3.3 supports "sparse" files...there may 0/0 pairs in the track/sector list indicating parts of the file that were never written. When DOS 3.3 is reading a file and encounters a 0/0 pair in the track/sector list, it passes a buffer full of binary zeros back to the calling program. A track/sector list looks like this: Byte Meaning ---- ------- $00 Unused $01 Track number of next track/sector list sector ($00 if no more) $02 Sector number of next track/sector list sector ($00 if no more) $03-04 Unused $05-06 Sector number in file of first sector number represented in this track/sector list sector (0 ($0000) for first T/S sector, 122 ($007A) for second, 244 ($00F4) for third, etc.) $07-0B Unused $0C Track number of 0th (or 122nd, or 244th...) sector $0D Sector number of 0th (or 122nd, or 244th...) sector $0E Track number of 1st (or 123rd, or 245th...) sector $0F Sector number of 1st (or 123rd, or 245th...) sector .... $FE Track number of 121st (or 243rd, or 365th...) sector $FF Sector number of 121st (or 243rd, or 365th...) sector A machine-language program is free to store whatever it wants in any file, but most programs (including DOS 3.3's own command interpreter) expect the data in each type of file to conform to certain formats: A sequential text file consists of lines of ASCII text separated by carriage returns, and ending with a $00 byte. The high bit of each character (except the $00 at the end) is set. A random-access file may be thought of as a set of "mini sequential access files" separated by strings of $00 bytes. Each "mini-file" begins at a file position which is a multiple of the random-access record length. (Note that sequential and random-access text files share the same file type. It is up to individual programs to know whether their data files are sequential or random-access.) Applesoft and Integer BASIC files have the following format: Byte Meaning ---- ------- $00-01 Length of tokenized BASIC program $02-end Tokenized BASIC program Binary files have the following format: Byte Meaning ---- ------- $00-01 Load address $02-03 Length of binary image $04-end Binary image A Relocatable contains the image of a program, followed by a relocation dictionary containing the information necessary to relocate the program to an arbitrary memory location. The file format is as follows: Byte Meaning ---- ------- $00-01 Original program load address $02-03 File length (program image + relocation dictionary) $04-05 Length of program image alone (not including relocation dictionary) $06-xx Program image $xx-yy Relocation dictionary (The format of the relocation dictionary is a bit too complex to describe here. I can provide details if anybody's interested...send e-mail.) The other three file types (S, A, and B) have never been consistantly defined by anybody. Several programs use these file types (especially type S) to store their private data files, but there doesn't seem to be any agreement on their internal format. >For further information I recommend the book "Beneath Apple DOS" by Don Worth >and Pieter Lechner. If I find the time I'll take a look at it myself and email >you a more detailed description of the DOS3.3 catalog track. - Neil Parker P.S. By the way, all two-byte fields in the above are stored in normal Apple II byte order, low byte first. -- Neil Parker No cute ASCII art...no cute quote...no cute nparker@cie.uoregon.edu disclaimer...no deposit, no return... parker@corona.uoregon.edu (This space intentionally left blank: )