To anyone interested after having had a poke about MPW tool LinkIIgs there is a procedure check_header, the code is interesting with regard to revision field.
It appears that the revision field for version 2.X reuses the LCBANK field from OMF 1.0.

if ( *(Buf + 14) != 0x04
|| *(Buf + 32) != 0x00
|| *(Buf + 8) > 0x00FFFFFF
|| *(Buf + 24) > 0x00FFFFFF
|| *(Buf + 28) > 0x00FFFFFF
|| *(Buf + 36) > 0x00FFFFFF
|| *Buf < 48 )
{
fprintf(stderr, "%sBad Segment Header found in Segment $%hX in file \"%s\\r", );
fatal(2, 0);
}

else if (*(Buf + 15) < 0x01 || *(Buf + 15) > 0x02)
{
fprintf(stderr, "%sUnsupported OMF Version (%hX) found in Segment $%hX in file \"%s\"\r");
fatal(2, 0);
}
else
{
if ( *(Buf + 15) == 0x02)
{
if ( *(Buf + 33) > 0x01)
{
fprintf(stderr, "%sUnsupported OMF Revision (%hX) found in Segment $%hX in file \"%s\"\r",);
fatal(2, 0);

On Tuesday, October 12, 2021 at 5:53:36 PM UTC-7, gbo...@bigpond.com wrote:
> 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",);

Interesting... you think at some point the tools used the "undefined" (nee LCBANK) field to differentiate between v2.0 and v2.1 segments?

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?

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

On Wednesday, October 13, 2021 at 5:14:28 PM UTC-7, gbo...@bigpond.com wrote:
> Do you have samples that you believe are OMF V2.1 files and where to find them?

YankIt and the HardPressed PIF have OMF v2.1 segments. YankIt is here: https://fadden.com/apple2/dl/yanksrc.shk

I'm looking at the header with the SourceGen OMF conversion tool. For example:

BYTECNT $00e4f7 bytes
RESSPC $000000
LENGTH $00c962
undefined $00
LABLEN $00 variable length
NUMLEN $04 must be 4
VERSION $02 v2.1
BANKSIZE $010000
KIND $0000 Code
undefined $0000
ORG $000000 relocatable
ALIGN $000000 no alignment
NUMSEX $00 must be 0
undefined $00
SEGNUM $0002
ENTRY $000000
DISPNAME $0030
DISPDATA $0045
TEMPORG $000000
LOADNAME
SEGNAME

The only way to tell v2.0 from v2.1 is by looking at DISPNAME. If it's 44 ($2c) then it's a v2.0 header, if it's greater than that then it has additional fields (TEMPORG). LCBANK is the undefined field after NUMSEX, but it always seems to hold zero.

Going to try and generate a OMF 2.1 segment with MPW AsmIIGS.
Then see if it flows through the other tool(s) including the linker -> LinkIIgs.

MPW AsmIIgs v1.1 generates Obj files with the TempOrg flagged in the header if used as a directive in the source.
discussed in the manual for MPW AsmIIgs manual
Linking produces output no longer needing the TempOrg detail.
based on changes for the MPW IIgs tools Apple made changes to MakelibIIgs to handle output by produced by ORCA 2.0 that was adding an empty TempOrg, see reference below.

MPW IIGS Tools V1.3

MakeLibllGS:
• ORCA 2.0 assembler is producing object files with the TempOrg field in the segment
headers, even though it's not using the field. This offsets the dispName and dispData
field values. MakeLib is not adjusting these values when it writes the segment headers
out to the library file without the TempOrg field. Fixed by having WriteSegmentHeader
calculate the proper values.

LinkUGS:
• LinklIGS v.1.1 is much faster and uses less memory than v.1.0.
• LinklIGS will use MultiFinder memory during links if the '-mf option is specified. This allows
the memory partition for MPW itself to be kept smaller, leaving more room for other applications
when LinklIGS is not being used.
• LinklIGS supports OMF Version 2.1 which includes: Object Segments having a tempORG
(temporary origin); Skip Object Segments; and Bank Relative Object Segments..

MPW sample files with associated MPW dumped segment headers.
https://drive.google.com/drive/folders/1cY67HANwb6NsQhogJhc1Ijz2Y9ERM1p2?usp=sharing

Updated the sample link to just the file.
https://drive.google.com/file/d/1zj-bhCGcZrOHe9_ZuFmbMtMCT5V6j-Pq/view?usp=sharing

ProDOS.FST.Obj has one v2.1 segment (BOOT_CODE), and sure enough:

Alignment : $00000000 0
Number sex : $00 0
Revision : $01 1

gquit.obj also has one v2.1 segment (LOAD_APP), also with a nonzero value. So the Mac tools appear to be using the "undefined" field that follows NUMSEX to be the minor version number.

The v2.1 segments in YankIt/HP have a tempORG field with zero in it, which is probably what the remarks about "not using the field" mean. The segments are not technically v2.0, since the tempORG field didn't exist in the v2.0 definition... but if it's not really being used, does it count?

Maybe the Orca-generated segments should be called v2.0.1?

According to GSOS reference V5.0 and later.
tempORG A 4-byte field indicating the temporary origin of the Object segment. A nonzero value indicates that all references to globals within this segment
will be interpreted as if the Object segment started at that location.
However, the actual load address of the Object segment is still
determined by the ORG field.

It would appear that a OMF 2.1 header would/should only apply to these Object segments, which also includes Libraries that have included a OBJ with OMF 2.1.

Maybe should ask Mike Westerfield if there is any further documentation on OMF 2.1 format.