Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5619 > unrolled thread

OMF v1.0?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  OMF v1.0? Andy McFadden <thefadden@gmail.com> - 2020-06-24 16:15 -0700
    Re: OMF v1.0? Stephen Heumann <stephen.heumann@gmail.com> - 2020-06-24 22:15 -0500
      Re: OMF v1.0? Stephen Heumann <stephen.heumann@gmail.com> - 2020-06-25 00:33 -0500
        Re: OMF v1.0? Antoine Vignau <ntn.vignau@gmail.com> - 2020-06-24 22:53 -0700
      Re: OMF v1.0? Andy McFadden <thefadden@gmail.com> - 2020-06-25 08:26 -0700
    Re: OMF v1.0? kelvin@pro-kegs.uucp (Kelvin Sherlock) - 2020-06-25 03:08 -0500
    Re: OMF v1.0? olivier.zardini@cooperteam.eu - 2020-06-25 00:14 -0700
      Re: OMF v1.0? Andy McFadden <thefadden@gmail.com> - 2020-06-25 08:42 -0700
      Re: OMF v1.0? Andy McFadden <thefadden@gmail.com> - 2020-06-27 10:25 -0700
        Re: OMF v1.0? Andy McFadden <thefadden@gmail.com> - 2020-07-12 11:29 -0700
          Re: OMF v1.0? geoff body <gbody4@bigpond.com> - 2021-10-12 17:53 -0700
            Re: OMF v1.0? fadden <fadden@fadden.com> - 2021-10-13 15:54 -0700
              Re: OMF v1.0? geoff body <gbody4@bigpond.com> - 2021-10-13 17:14 -0700
                Re: OMF v1.0? fadden <fadden@fadden.com> - 2021-10-13 22:00 -0700
                  Re: OMF v1.0? geoff body <gbody4@bigpond.com> - 2021-10-15 21:25 -0700
                    Re: OMF v1.0? geoff body <gbody4@bigpond.com> - 2021-10-16 07:47 -0700
                      Re: OMF v1.0? geoff body <gbody4@bigpond.com> - 2021-10-16 07:52 -0700
                      Re: OMF v1.0? fadden <fadden@fadden.com> - 2021-10-16 15:36 -0700
                        Re: OMF v1.0? geoff body <gbody4@bigpond.com> - 2021-10-16 21:33 -0700
    Re: OMF v1.0? geoff body <gbody4@bigpond.com> - 2020-06-25 07:47 -0700
      Re: OMF v1.0? Andy McFadden <thefadden@gmail.com> - 2020-06-25 08:22 -0700
        Re: OMF v1.0? Stephen Heumann <stephen.heumann@gmail.com> - 2020-06-25 13:41 -0500
          Re: OMF v1.0? Andy McFadden <thefadden@gmail.com> - 2020-06-25 13:01 -0700
            Re: OMF v1.0? Stephen Heumann <stephen.heumann@gmail.com> - 2020-06-25 16:44 -0500
              Re: OMF v1.0? Andy McFadden <thefadden@gmail.com> - 2020-06-25 16:41 -0700
                Re: OMF v1.0? geoff body <gbody4@bigpond.com> - 2020-06-26 06:51 -0700

Page 1 of 2  [1] 2  Next page →

#5619 — OMF v1.0?

Does anyone have an example of an Apple IIgs OMF v1.0 file?  I'm trying to figure out if they actually exist "in the wild".

The Apple IIgs Programmer's Workshop Reference says:

"This section describes Version 2.0 of the Apple IIGS object module format(OMF). The System Loader supports files written in either Version 2.0 or Version 1.0 of the OMF.  The APW Linker, however, creates load files that conform to Version 1.0 of the OMF.  Notes in this section describe the differences between Version 1.0 and Version 2.0 of the OMF.  The Compact utility program, described in Chapter 3, converts load files from Version 1.0 to Version 2.0."

The S16 files on the ProDOS 16 system disk use OMF v2.1.  v2.0 is easy to find.  Haven't seen a v1.0 yet.

One thing I can't figure out is why my code in CiderPress (reformat/Disasm.cpp) seems to diverge from the specification in the Workshop Reference book.  Specifically, CiderPress ignores the last few fields (SEGNUM, ENTRY, DISPNAME, DISPDATA, LOADNAME).  Those fields are present in the Object Module Format ERS (the internal doc used while the format was developed).  The description of the VERSION field says:

"This 1 byte field indicates the version number of the Object Module Format with which the Segment is compatable[sic].  This field should be 1 for the initial specification of the Object Module Format."

A value of 1 corresponds to v2.0.  So the ERS, from Aug 1986, indicates that v2.0 was the standard when the IIgs shipped.  Perhaps v1.0 was a pre-release thing that only visible to early-access developers?

Unfortunately I don't remember what my source of information was when I wrote the code in CiderPress.  I haven't been able to find anything that says OMF v1.0 lacked those fields, but maybe the code was written to handle real-world examples that I can no longer find.

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

[toc] | [next] | [standalone]

#5620

On 2020-06-24 23:15:40 +0000, Andy McFadden said:
> One thing I can't figure out is why my code in CiderPress 
> (reformat/Disasm.cpp) seems to diverge from the specification in the 
> Workshop Reference book.  Specifically, CiderPress ignores the last few 
> fields (SEGNUM, ENTRY, DISPNAME, DISPDATA, LOADNAME).  Those fields are 
> present in the Object Module Format ERS (the internal doc used while 
> the format was developed).  The description of the VERSION field says:
> 
> "This 1 byte field indicates the version number of the Object Module 
> Format with which the Segment is compatable[sic].  This field should be 
> 1 for the initial specification of the Object Module Format."
> 
> A value of 1 corresponds to v2.0.  So the ERS, from Aug 1986, indicates 
> that v2.0 was the standard when the IIgs shipped.  Perhaps v1.0 was a 
> pre-release thing that only visible to early-access developers?

There seems to be some confusion about version numbers. Appendix B of 
the (16-bit) ORCA/M 2.0 manual contains documentation for OMF and says 
the following:

"There are now three versions of the object module format. The first, 
used with [eight-bit] ORCA/M 4.0, is labeled as version zero in the 
header. The second, used by ORCA/M 4.1 on both eight-bit and 
sixteen-bit Apple II computers, and by early versions of ORCA/M and the 
Apple Programmer's Workshop on the Apple IIGS, has a one as the version 
number. The newest version, version two, is currently used by ORCA/M. A 
variant of this OMF format, known as version 2.1, adds an optional 
field to the end of the header. The optional field is not needed, nor 
is it created, by native development systems, although the ORCA 
utilities and linker will accept OMF 2.1 format files."

It contains diagrams showing the headers for "Version 0", "Version 1", 
and "Version 2.1". I believe version 2.0 would be the same as 2.1, 
except without the extra TEMPORG field (the difference could be 
detected based on DISPNAME).

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.

Incidentally, the even earlier versions of ORCA/M running on DOS 3.3 
apparently used an even earlier version of OMF (pre-"Version 0"), as 
documented in their manual:

https://archive.org/details/stx_Hayden_Software_ORCA-M_Macro_Assembler_manual/page/n277/ 


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.

-- 
Stephen Heumann

[toc] | [prev] | [next] | [standalone]

#5622

On 2020-06-25 03:15:35 +0000, Stephen Heumann said:
> 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.

I looked through Opus ][ a bit and was able to find one OMF "version 0" 
file on it:

ByteWorks/Eight.Bit/ORCA4.1/LIBRARIES/A..CLIB.A

This is the library for the eight-bit ORCA version of Small-C, which 
was probably compiled with ORCA/M 4.0.  The source code for it is also 
on Opus ][, if you want to reference that.

-- 
Stephen Heumann

[toc] | [prev] | [next] | [standalone]

#5623

History and more within the single-sided document at http://www.brutaldeluxe.fr/documentation/cortland/v1_05_ObjectModuleFormatERS.pdf

Antoine

[toc] | [prev] | [next] | [standalone]

#5627

On Wednesday, June 24, 2020 at 8:15:37 PM UTC-7, Stephen Heumann wrote:
> 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.

This makes sense.  CiderPress is interpreting the version field incorrectly.

Since VERSION=0 wasn't really used for 16-bit code, it can be ignored entirely by the IIgs code formatter.

[toc] | [prev] | [next] | [standalone]

#5621

Before OMF was the IIgs executable format, it was the 8-bit ORCA
object module format.

quoting the 8-bit ORCA/M Assembler 4.1 documentation (circa 1986):

> ORCA languages take source files as input and produce object modules
as output. These object modules are then used as input to the link
editor. Object modules are contained in a special file type with a
file type number of $B1, which shows up as OBJ when cataloged from
ORCA.

> 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
second, used by ORCA/M 4.1 on both eight and sixteen bit Apple II
computers, and by the Apple IIGS Programmers Workshop on the Apple IIGS,
has a one as the version number. ...

--

The Byte Works has a copy of Cortland Programmer's Workshop 4.1A11,
the final version before it was APW. Note this is based on 8-bit ORCA/M
and included library files are version 2.0 OMF.

http://www.byteworks.us/Byte_Works/Morgue.html

The RELEASE.NOTES mentions in the Change History:

> (V1.0 A2  3 Feb 86)
> Version number for load file is now 1.

So if you want a version 1.0 file, you'll need to track down CPW Alpha 1
or ORCA/M 4.0 (for object files)

-------
ProLine: kelvin@pro-kegs

[toc] | [prev] | [next] | [standalone]

#5624

Le jeudi 25 juin 2020 01:15:41 UTC+2, Andy McFadden a écrit :

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

   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 can't exclude a look into your CiderPress source code at the time but I don't think so :-)

    Olivier

[toc] | [prev] | [next] | [standalone]

#5628

On Thursday, June 25, 2020 at 12:14:23 AM UTC-7, olivier...@cooperteam.eu wrote:
>    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).

That would make sense.  There's a comment in the CiderPress sources that says:

 * Orca/APW libs seem to use version 1 with a byte count in the
 * first field, but the "LLRE" app has version 1 with a block count.
 * The spec is pretty clear, so it looks like somebody's library
 * builder screwed up.

This behavior is explained in the Apple IIgs Programmers Workshop Reference, so I was clearly getting my 1.0/2.0 info from somewhere else.  I just couldn't figure out where. :-)

[toc] | [prev] | [next] | [standalone]

#5634

On Thursday, June 25, 2020 at 12:14:23 AM UTC-7, olivier...@cooperteam.eu wrote:
>    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).

For anyone else looking for this: on the Opus ][ CD, look in the "Documentation:PDF Documentation" folder.  The file "GS-04 ORCA/M 2.0.pdf" is the relevant one.  Appendix B describes OMF; page 488 shows v0, v1, and v2.1 side-by-side.

It uses slightly different names (e.g. BLOCKCOUNT vs. BLKCNT), and doesn't describe the v1 Object/Library behavior, noting simply "several features that deal with relocatable code and libraries have been omitted."  Only Load files are documented.

[toc] | [prev] | [next] | [standalone]

#5641

CiderPress has been updated.  The fixed OMF version reporting is in a pre-release, v4.0.4-d2.  https://github.com/fadden/ciderpress/releases if you're dying to see the correct value.

The OMF viewer in SourceGen handles all versions, including "v0" (tested with the library mentioned earlier in this thread).  It also goes deeper than CiderPress, decoding records in object and library files, so if you were curious to see expressions in compiler intermediates you can now do so from the comfort of Windows. :-)

The OMF converter does more or less what the GS/OS system loader does, though I'm still a little vague on the interaction with some of the KIND flags when ORG is zero.

[toc] | [prev] | [next] | [standalone]

#5882

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);

[toc] | [prev] | [next] | [standalone]

#5883

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?

[toc] | [prev] | [next] | [standalone]

#5884

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

[toc] | [prev] | [next] | [standalone]

#5885

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.

[toc] | [prev] | [next] | [standalone]

#5886

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.
 

[toc] | [prev] | [next] | [standalone]

#5887

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

[toc] | [prev] | [next] | [standalone]

#5888

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

[toc] | [prev] | [next] | [standalone]

#5889

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?

[toc] | [prev] | [next] | [standalone]

#5890

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.

[toc] | [prev] | [next] | [standalone]

#5625

Andy, 
I believe you are in the right section of the Apple IIgs Programmers Workshop Reading. Chapter 7 of the APW V1.0 draft, starting at 232-237 there is a clear definition of both OMF 1.0 and 2.0. 
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. Having looked at the disk for TML PASCAL for APW vers 1.0 using Ciderpress and using the descriptions from Chapter 7, the header for TMLPASCAL and sample compiled programs have 1 in the Version field. The file structure matches the OMF 1.0 with segments also starting on block boundaries. 
This confirms that The Version field in the segment header is the version number of the OMF.
  http://www.goldstarsoftware.com/applesite/Documentation/AppleIIgsProgrammersWorkshop.PDF

Geoff B

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web