Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
When DOS released in 1981, the assembler that came with it produced .OBJ files that were OMF format. However there was a predecessor to it, M80.COM that ran under CP/M and also used .OBJ as the file extension for object files.
Were these files also OMF, or did they use a different file format?
Were these files also OMF, or did they use a different file format?
Short answer: Nope, all the same (with some extensions over the years)
The long story.
Intel originally intended PL/I to be the main language for 8008 and 8080 systems and made their PL/M compiler able to produce absolute code as well as relocatable one.
There where variations for each CPU, including the 8080, but the basic format was all the same.
The original Digital Research ASM did create Intel hex files, marked .HEX. Similar did their Macro Assembler MAC.
Digital's Relocating Macro Assembler (RMAC) later added the optional ability to produce relocatable output (.REL) as described in the LINK-80 manual
Microsoft's M80 turned assembly output by default into relocatable format as it was meant to work in cooperation with other high level languages from Microsoft which only created relocatable formats.
Microsoft as well as Digital Research used Intel's format for their relocatable formats. After all, it makes sense to be compatible as newcomer, doesn't it?
Intel called their files already .OBJ, DR decided on .REL while MS stuck with .OBJ. They are all Intel OMF with the same basic logic and encoding format for all (ofc, MS added a lot over the years - already starting with M80). In theory, even the latest (separate) MS linker should be able to decode all records and produce 8080 .COM files. In theory at least :))
P.S.: The history then continued with Microsoft switching for (their version of) COFF - which by MASM 8.0 (ca.2005) even became default format.
They were .REL files, not .OBJ files. The format is fully described here. It was a bitstream containing 9-bit bytes, 18-bit addresses, and 6-bit markers some of which in their turn contained either 18-bit addresses or 3+8n-bit names or both.
I once wrote a utility which consisted of a small loader which installed the main body of the utility in high memory: thus it read the .REL file directly and relocated the code into high memory where it could be executed. An interesting exercise!
The background is that you need far more relocation in 8080 than in 8086, since in 8080 all data and program addresses are absolute, whereas in 8086 they are mostly relative, either by instruction set design (near calls and jumps are relative) or by usage (data are mostly referred to a base register rather than at absolute location). Moreover, in 8080 every bit counts, as can be seen from the format. Though they wasted bits by making the name string 3+8n bits instead of 3+7n!
