A document found on the internet describing the basics of the

Apple Pascal disk format.
This commit is contained in:
Robert Greene 2002-12-10 05:09:22 +00:00
parent 0f95ceb8fb
commit cb53bedbc7
1 changed files with 118 additions and 0 deletions

View File

@ -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 <GUDATH@EZINFO.VMSMAIL.ETHZ.CH> 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.