Path: news1.icaen!news.uiowa.edu!news.physics.uiowa.edu!math.ohio-state.edu!howland.erols.net!europa.clark.net!newsfeed.nacamar.de!nntp.uio.no!news.uoregon.edu!cie-2.uoregon.edu!nparker
From: nparker@cie-2.uoregon.edu (Neil Parker)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: S16 Files - First $45 bytes
Date: 10 Apr 1997 07:49:40 GMT
Organization: University of Oregon Campus Information Exchange
Lines: 45
Message-ID: <5ii62k$ii5@pith.uoregon.edu>
References: <5igv38$50u$1@news.ptd.net>
NNTP-Posting-Host: cie-2.uoregon.edu
NNTP-Posting-User: nparker

In article <5igv38$50u$1@news.ptd.net> rajal@postoffice.ptd.net (Jason A Long)
writes:
>I've noticed that on all GS/OS system files there are $45 bytes in the
>beginning of the file that do not seem to be actual code.  What information
>is stored here?
>
>I'm currently working on a IIgs assembler, so I need to know what to put here
>when creating a system file.  Any information will be helpful.

Those extra bytes are the segment header of the file's first segment.  The
segment header includes lots of information which is vital to the System
Loader, including the size of the segment (both on disk and in memory), the
segment's memory load address (not usually necessary), alignment
restrictions (if any), segment type (code segment, data segment, DP/stack
segment, jump table, etc.), and other things.

Following the header comes the segment data, which consists of records of
several different types.  First come the CONST records (containing the
actual code and data) and DS records (which reserve unitialized memory).
Then come the relocation records, which allow the Loader to patch the code
so that it will run at the address it was loaded into.

The segment ends after the relocation records, but the file doesn't
necessarily end there--there can be more segments after the first.  The
second and subsequent segments have the same structure as the first.

The full layout of a GS/OS executable is much too long and complex to
describe here.  Appendix F of the _Apple_IIGS_GS/OS_Reference_ tells all
about the Object Module Format (OMF), of which a GS/OS executable is a
subset.  

You *really* need the _GS/OS_Reference_ if you're going to succeed in
writing your assembler.  Unfortunately, it doesn't appear to be available
commercially at the moment (though Byteworks is working on getting it).
You might be able to find a used copy on comp.sys.apple2.marketplace.

I'm not sure, but I think the description of OMF is also printed in one of
the ORCA language manuals (which *are* currently available from Byteworks).

            - Neil Parker
-- 
Neil Parker                       | Unsolicited commercial e-mail to my
nparker@cie-2.uoregon.edu         | address is not welcome, and will be
nparker@cie.uoregon.edu           | discarded unread.
http://cie-2.uoregon.edu/~nparker |