diff --git a/documentation/apple.pascal.txt b/documentation/apple.pascal.txt new file mode 100644 index 0000000..46a81bf --- /dev/null +++ b/documentation/apple.pascal.txt @@ -0,0 +1,118 @@ +HTTP 200 Document follows +Date: Tue, 10 Dec 2002 02:54:19 GMT +Server: NCSA/1.5.1 +Last-modified: Sun, 18 Jan 1998 23:41:02 GMT +Content-type: text/plain +Content-length: 4381 + +Path: news1.icaen!news.uiowa.edu!news1.chicago.iagnet.net!iagnet.net!128.223.220.30!logbridge.uoregon.edu!news.uoregon.edu!!nparker +From: nparker@inferno.uoregon.edu (Neil Parker) +Newsgroups: comp.sys.apple2.programmer +Subject: Re: Q: Pascal file system? +Date: 18 Jan 1998 11:58:17 GMT +Organization: Chaos +Lines: 96 +Message-ID: <69sqop$mpu$1@pith.uoregon.edu> +References: <69sl3k$6sv$1@elna.ethz.ch> +NNTP-Posting-Host: ssil.uoregon.edu +X-Trace: pith.uoregon.edu 885124697 23358 nparker 128.223.108.115 +X-Complaints-To: usenet@news.uoregon.edu +Originator: nparker@ +Xref: news1.icaen comp.sys.apple2.programmer:9640 + +In article <69sl3k$6sv$1@elna.ethz.ch>, +Henrik 'Ratte' Gudat wrote: +>Hi there, +> +>I'm currently looking for a few infos on the Pascal disk format. Anyone knows +>the specs off hand? +> +>Like.. +>- does the Pascal system work with 3.5" media and hard disks? + +Yes and no. Version 1.3 works with 3.5-inch disks. Version 1.1 doesn't +(unless you patch it). I don't think either version will use a Pascal +partition on a hard disk, except that there was a program called Pascal +Profile Manager that could put a Pascal volume into a specially-formatted +file on a ProDOS-formatted Profile hard disk (I don't think it recognized +any hard disk other than a Profile). + +(This, by the way, is the reason why ProDOS has storage type 4 (Pascal +area) and file type $EF (PAS). See ProDOS Technical Note #25, +"Non-Standard Storage Types".) + +>- has a Pascal disk the same track/sector layout as a ProDOS disk? + +Yes. + + +And in case you're interested, here's the Pascal disk layout: + +Blocks 0 and 1 are the boot blocks. The directory occupies blocks 2 +through 5. It contains 78 entries, each 26 bytes long. Block boundaries +are ignored--the entire directory is treated as a single contiguous +2048-byte array. + +The first entry is the volume name. It has the following format: + + +0 word: block number of 1st directory block (always 0) + +2 word: block number of last directory block +1 (always 6) + +4 word: entry type (0=volume header) + +6 string[7]: volume name (with length byte) + +14 word: number of blocks on disk + +16 word: number of files on disk + +18 word: last access time + +20 word: most recent date setting + +22 4 bytes: reserved + +The remaining entries are file entries: + + +0 word: block number of file's 1st block + +2 word: block number of file's last block +1 + +4 word: bits 0-3: file type + 1=xdskfile (for bad blocks) + 2=codefile + 3=textfile + 4=infofile + 5=datafile + 6=graffile + 7=fotofile + 8=securedir (whatever that means) + bits 4-14: reserved + bit 15: used by Filer for wildcards + +6 string[15]: file name (with length byte) + +22 word: number of bytes used in file's last block + +24 word: file modification date + +The last 20 bytes of the directory are unused. + +The date setting and last modification date are stored in a word as +follows: + + Bits 0-3: month (1-12) + Bits 4-8: day (1-31) + Bits 9-15: year (0-99) + +When you find an entry whose name is the null string, you've reached the +end of the directory. There are no special "deleted file" entries--when a +file is deleted, it is "squeezed out" of the directory by moving the +following entries one slot forward. + +Files are stored contiguously on the disk...that is, each file occupies +all the blocks starting at the first block number listed in its directory +entry, and ending at one less than the last block number listed in its +directory entry. Directory entries are sorted in order of increasing block +number. There is no block map--due to the contiguous allocation scheme, +free space can easily be located by scanning the directory: if a +directory entry's last-block-number field doesn't match the next entry's +first-block-number field, then you've found some free space. + +All "word" entries are, of course, stored in standard Apple II +low-byte-first order. + + - Neil Parker +-- +Neil Parker, nparker@inferno.uoregon.edu, nparker@axis.llx.com, +http://axis.llx.com/~nparker/ (Note new addresses and home page!) + +Unsolicited commerical e-mail is not welcome, and will be discarded unread.