mirror of
https://github.com/AppleCommander/AppleCommander.git
synced 2024-05-31 14:41:31 +00:00
A document found on the internet describing the basics of the
Apple Pascal disk format.
This commit is contained in:
parent
0f95ceb8fb
commit
cb53bedbc7
118
documentation/apple.pascal.txt
Normal file
118
documentation/apple.pascal.txt
Normal 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.
|
Loading…
Reference in New Issue
Block a user