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.