Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Q: Pascal file system?

44 views
Skip to first unread message

Henrik 'Ratte' Gudat

unread,
Jan 18, 1998, 3:00:00 AM1/18/98
to

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?
- has a Pascal disk the same track/sector layout as a ProDOS disk?

Thanks a lot,
henrik


Neil Parker

unread,
Jan 18, 1998, 3:00:00 AM1/18/98
to

In article <69sl3k$6sv$1...@elna.ethz.ch>,

Henrik 'Ratte' Gudat <GUD...@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, npa...@inferno.uoregon.edu, npa...@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.

David Wilson

unread,
Jan 19, 1998, 3:00:00 AM1/19/98
to

npa...@inferno.uoregon.edu (Neil Parker) writes:
>In article <69sl3k$6sv$1...@elna.ethz.ch>,
>Henrik 'Ratte' Gudat <GUD...@EZINFO.VMSMAIL.ETHZ.CH> wrote:
>>- 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).

Pascal 1.3 should work with any ProDOS Block Device or SmartPort Device.
It works with Apple's 1MB Slinky RAMDisk card. I have certainly had it
running on my hard disk (the entire partition).
--
David Wilson Sch of Informatics, Uni of Wollongong, Australia da...@uow.edu.au

Jeff Blakeney

unread,
Jan 19, 1998, 3:00:00 AM1/19/98
to

On 18 Jan 1998 11:58:17 GMT, npa...@inferno.uoregon.edu (Neil Parker)
wrote:

[snip]


>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.

[snip]

What happens if you need 100 blocks of space but there is only 50
blocks available between, say, file 2 and 3? Do you just keep
skipping free spaces until you find a big enough free space? If so,
what happens if you don't end up with one space big enough to hold
your data but do have enough by adding the free spaces together? Does
Pascal compress the contiguous files together to make one big free
space at the end of the disk?

Inquiring minds are analyzing more important things but I'd sure like
to know. :-)

=== I've had enough SPAM. Cut the obvious from my address to email me. ===

Nathan Mates

unread,
Jan 19, 1998, 3:00:00 AM1/19/98
to

In article <34c2e03d...@news.bconnex.net>,

Jeff Blakeney <CUTj...@bconnex.net> wrote:
>What happens if you need 100 blocks of space but there is only 50
>blocks available between, say, file 2 and 3? Do you just keep
>skipping free spaces until you find a big enough free space?

Apparently so. Remember, this is a very minimal filesystem, not
exactly one designed to be flexible :)

>If so, what happens if you don't end up with one space big enough to
>hold your data but do have enough by adding the free spaces
>together?

Then the write fails. As I said, minimal.

>Does Pascal compress the contiguous files together to make one big
>free space at the end of the disk?

The Pascal environment had a disk 'Kruncher' which could do that,
but that was an external program, not part of the OS.

Nathan Mates
--
<*> Nathan Mates http://www.visi.com/~nathan/ <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places? -R.A. Heinlein

Steven Nelson

unread,
Jan 20, 1998, 3:00:00 AM1/20/98
to

From article <6a0c4m$m9a$1...@darla.visi.com>, by nat...@visi.com (Nathan Mates):

>
> The Pascal environment had a disk 'Kruncher' which could do that,
> but that was an external program, not part of the OS.
>
The Pascal Filer had a K)runch option to move all files into contiguous
blocks leaving contiguous freespace at the end. The Filer was an integral
part of the OS, but not part of the Pascal OS kernel. I never saw an
external 'Kruncher' program but I am sure one could have been written. I
found it easier to chain to the Filer K)runch option and return to my
program when I found the need to krunch after a file I/O error of
insufficient space.

--Steve

David Empson

unread,
Jan 20, 1998, 3:00:00 AM1/20/98
to

Neil Parker <npa...@inferno.uoregon.edu> wrote:

> In article <69sl3k$6sv$1...@elna.ethz.ch>,
> Henrik 'Ratte' Gudat <GUD...@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).

Mostly correct, but Pascal 1.3 will work on a SCSI hard drive; it
requires an entire partition, and the SCSI card must be in slot 4, 5 or
6. I'm not sure whether it requires a SmartPort-compatible controller:
I think it uses the ProDOS block driver. You can have two volumes if
you partition the drive. It almost certainly won't support more than
two volumes per slot (though I haven't tried).

Since Apple II Pascal has a fixed limit of 77 files per volume, this is
of somewhat limited use.

Pascal ProFile Manager (PPM) lets you subdivide the Pascal area on a
ProFile into multiple logical volumes of arbitrary sizes. Unfortunately
you cannot boot Pascal from the ProFile (echos of the Apple III), and it
doesn't work on anything other than a ProFile.

--
David Empson
dem...@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand

Neil Parker

unread,
Jan 21, 1998, 3:00:00 AM1/21/98
to

In article <1d34plo.d2...@dempson.actrix.gen.nz>,
David Empson <dem...@actrix.gen.nz> wrote:
>[...]

>Mostly correct, but Pascal 1.3 will work on a SCSI hard drive; it
>requires an entire partition, and the SCSI card must be in slot 4, 5 or
>6. I'm not sure whether it requires a SmartPort-compatible controller:
>I think it uses the ProDOS block driver. You can have two volumes if
>you partition the drive. It almost certainly won't support more than
>two volumes per slot (though I haven't tried).

Interesting. Does it use its own partition type, or does it put a Pascal
directory structure in an Apple_ProDOS partition?

(I ask because I think I remember something about Apple SCSI cards ignoring
any partition type other than Apple_ProDOS.)

David Empson

unread,
Jan 23, 1998, 3:00:00 AM1/23/98
to

Neil Parker <npa...@inferno.uoregon.edu> wrote:

> In article <1d34plo.d2...@dempson.actrix.gen.nz>,
> David Empson <dem...@actrix.gen.nz> wrote:

> >[Pascal partitions on a SCSI hard drive]


>
> Interesting. Does it use its own partition type, or does it put a Pascal
> directory structure in an Apple_ProDOS partition?

It just uses the ProDOS (or possibly SmartPort) firmware, which only
knows about Apple_ProDOS partitions, so the end result is Pascal
filesystem on ProDOS partition.

(These are not recognised by the Pascal FST in GS/OS, by the way.)

0 new messages