ORCA languages take source files as input and produce object modulesas output. These object modules are then used as input to the link
There are now two versions of the object module format. The first,used with ORCA/M 4.0, is labeled as version zero in the header. The
(V1.0 A2 3 Feb 86)
Version number for load file is now 1.
I haven't tracked down the old eight-bit versions of ORCA/M to get
examples of the OMF files they generate, but I think that's where you
would have to look if you want to find them.
Adding to my confusion is the Brutal Deluxe OMF Analyzer, which treats v1.0 the same way. I don't know if their code is based on the behavior of the system loader, or if they just saw my code and assumed I knew what I was doing. :-)
Ciderpress interprets the version 1.0 OMF header correctly, but displays as Version as 2.0. The first item in the segment header is bytecnt for 2.0, while for 1.0 it is BLKcnt.
I think my source of information for OMF Analyzer was a chapter in the Orca/M 2.0 Manual (+ GS/OS Reference book for 2.1 format).
I think "Version 1", "Version 2.0", and "Version 2.1" (as defined in
the ORCA/M manual) can all be found in various IIGS programs and object/library files. If you're asking about "Version 0" then AFAIK it
was never used with IIGS stuff, only with eight-bit ORCA/M 4.0.
According to the manual, that version is indeed missing the SEGNUM,
ENTRY, DISPNAME, DISPDATA, and LOADNAME fields.
Oh, if only. For VERSION=1, the first field is *either* BLKCNT or
BYTECNT. For Load and Object files, it's a block count, and the
overall file *usually* has a length that is a multiple of 512 (see e.g. BRIDGE.S16 on the Davex v1.23 disk for an example of a "short" binary).
For static libraries, they apparently didn't want to waste space
between segments, so it holds a byte count instead.
You have to know the ProDOS file type to interpret the file contents unambiguously. (This annoys me deeply.)
Anyway. I'm looking at the docs and think you're correct that I've mis-interepted the OMF version. The docs for OMF 2.0 and 2.1 (in the
APW Ref and GS/OS ref, respectively) both say that the VERSION field is
set to 2. The GS/OS ref also describes a REVISION field that is
supposed to have the value 1, but declines to identify its location in
the figure on page 447.
You have to know the ProDOS file type to interpret the file contents unambiguously. (This annoys me deeply.)
Well, static libraries would normally start with a library dictionary segment, which could be detected independently of the file type. Are
there version 1 files where the presence or absence of a library
dictionary segment does not line up with the use of BLKCNT vs. BYTECNT?
AFAIK that REVISION field doesn't really exist. I think the
documentation updates for version 2.1 were done a bit sloppily. There
are also a couple places in the GS/OS Reference where the specified
offsets do not properly account for the tempORG field.
ByteWorks/Eight.Bit/ORCA4.1/LIBRARIES/A..CLIB.A
My approach is to parse assuming it's not a library. If the parsing
fails, or a LibDict segment is encountered, restart with the assumption
that it is a library and see if that works.
AFAIK that REVISION field doesn't really exist. I think the
documentation updates for version 2.1 were done a bit sloppily. There
are also a couple places in the GS/OS Reference where the specified
offsets do not properly account for the tempORG field.
Yup, I think the only way to tell the difference is by DISPNAME > $2a.
ByteWorks/Eight.Bit/ORCA4.1/LIBRARIES/A..CLIB.A
Thanks! CiderPress does handle that one. Interesting that the other
libs in that dir use the newer OMF format.
[...]Yup, I think the only way to tell the difference is by DISPNAME > $2a.
DISPNAME is normally 44 ($2C) in OMF v2.0
also shows DISPDATA and tempOrg as both being at offset $2A in Figure
F-2, when tempOrg must actually be at offset $2C.
I think my source of information for OMF Analyzer was a chapter in the Orca/M 2.0 Manual (+ GS/OS Reference book for 2.1 format).
It appears that the revision field for version 2.X reuses the LCBANK field from OMF 1.0.[...]
{
if ( *(Buf + 15) == 0x02)
{
if ( *(Buf + 33) > 0x01)
{
fprintf(stderr, "%sUnsupported OMF Revision (%hX) found in Segment $%hX in file \"%s\"\r",);
It doesn't appear to be nonzero in the v2.1 files I've looked at that were generated on a IIgs. Maybe someone thought it *might* be used and planned ahead?
Do you have samples that you believe are OMF V2.1 files and where to find them?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 81:36:18 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,096 |
Messages: | 5,276,771 |