Re: SOS file system information

[dempson@actrix.gen.nz (David Empson)]

Toinet <antoine.vignau@laposte.net> wrote:

> To be honest, the idea is to add a SOS File System Translator for GS/
> OS.

That would be a wasted effort. SOS and ProDOS are the same file system.
A disk formatted by SOS can be used by SOS and ProDOS, and accessed from
GS/OS using the ProDOS FST, hence there is no need for a separate SOS
FST. A disk formatted by ProDOS or by GS/OS (using the ProDOS file
system) can be used by SOS.

There is no way to tell whether a particular disk was used with an Apple
/// or an Apple ][ (or both), apart from assuming that based on the file
types found on the disk (some of which are equally likely to be used on
either platform, so that would be inconclusive).

A bootable SOS disk should be reasonably identifiable because it must
contain valid SOS boot code and the SOS.KERNEL file, but SOS data disks
may be indistinguishable from ProDOS data disks. You could also have a
disk which contains both the PRODOS and SOS kernels, so how would you
classify that?

> Not now, not tomorrow but later. I have so many things to do
> before.
>
> But, SOS disks need to be identified. It can be with a checksum of
> block 0, check some bytes in the volume directory, etc. That's why I
> needed such information.

Block 0 contains boot code. It is irrelevant for accessing the file
system, and cannot be reliably used to identify which platform is using
the disk.

Even if you did a checksum, there could be multiple versions of that
boot code over the lifetime of the SOS tools which format/erase disks.

A disk could be formatted by early versions of ProDOS disk formatting
utilities (which include SOS boot code in block 1) and give you the
misleading impression that it is a SOS disk when it has never been near
an Apple ///.

A disk could be formatted by late versions of ProDOS disk formating
utilities (with ProDOS-only boot code) and used as a data disk with SOS,
without any clues that SOS was involved.

> I'm a little bit lost with block 0 (ProDOS) vs block 1 (SOS) - Let's
> take an example: imagine I own an Apple I!/ and I also have some
> disks. Am I right to say that the boot driver loads block 0 of the
> disk or are there the two blocks (ProDOS and SOS) on such disks?

It depends which tool wrote the boot blocks.

Early versions of ProDOS disk utilities write ProDOS boot code in block
0 and SOS boot code in block 1, relying on the different entry points.
The Apple ][ expects byte 0 to be $01 and starts executing from byte 1.
The Apple /// starts executing from byte 0. The $01 byte is an illegal
opcode for the 6502, but it is parsed as if it is a three byte
instruction (if I remember right). With some careful coding, this allows
the initial sequence of instructions to diverge depending on whether you
started executing at offset 0 or 1.

The Apple /// ends up executing the code in block 1 to load SOS.KERNEL,
while the Apple ][ ends up executing the code in block 0 to load PRODOS.

Later versions of ProDOS don't write any SOS boot code. Block 1 contains
all zero bytes, and block 0 has no Apple /// boot code, so the disk
won't boot an Apple ///.

SOS doesn't write any ProDOS boot code (unless that was added in late
updates to SOS), so a SOS-formatted disk won't boot an Apple ][.

You could also have a disk that has been erased by a tool which doesn't
write anything in the boot blocks, so they are both filled with zero
bytes (or some stub boot code which displays a message saying "This disk
is not bootable").

-- 
David Empson
dempson@actrix.gen.nz