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