srec_aomf(5)

📦
version 1.65.0 · 4 versions
, in opensuse-leap 16.0

💖 srec_aomf(5) — Intel Absolute Object Module Format 💖

okay bestie, this is srec_aomf(5) from the File Formats Manual — the Intel Absolute Object Module Format page. Buckle up, we're doing 8051 record layouts and honestly it's iconic 🫶

🌸 NAME 🌸

srec_aomf — Intel Absolute Object Module Format

✨ DESCRIPTION ✨

okay so AOMF — the Absolute Object Module Format — is literally a subset of the 8051 OMF. The structure of an absolute object file (meaning the order of the records in it) is similar to that of a relocatable object file. But there are three main differences, and they matter:

  1. an absolute object file contains one module only
  2. not all the records can appear in the absolute file
  3. the records can contain only absolute information

periodt. 💅

🧬 Generic Record Format 🧬

Every record starts with a record type that tells you what kind of record it is, plus a record length that contains the number of bytes in the record, exclusive of the first two fields. The record ends with a checksum byte which contains the 2s complement of the sum (modulo 256) of all other bytes in the record. Therefore the sum (modulo 256) of all bytes in the record is zero. Cute, right? 😌

The record length includes the payload and checksum fields, but excludes the type and length fields.

All 16‐bit fields are little‐endian. no cap.

                      ┌─────────┬─────────┬─────────┬─────────┐
                      │ REC     │ Record  │ Payload │ CHK     │
                      │ TYP     │ Length  │         │ SUM     │
                      │ 8 bits  │ 16 bits │         │ 8 bits  │
                      └─────────┴─────────┴─────────┴─────────┘

Here are some of the relevant record types:

  • 0x01 — Scope Definition Record
  • 0x02 — Module Start Record
  • 0x04 — Module End Record
  • 0x06 — Content Record
  • 0x0E — Segment Definition Record
  • 0x12 — Debug Items Record
  • 0x16 — Public Definition Record
  • 0x18 — External Definition Record

Names are not stored as C strings. Names are stored as a length byte followed by the contents. not me expecting C strings 💀

🏗️ Structure 🏗️

An AOMF file consists of a module header record (0x02), followed by one or more content (0x06), scope (0x01) or debug (0x12) records, and ends in a module end record (0x04).

The records with the following types are extraneous (they may appear in the file but are ignored): 0x0E, 0x16 and 0x18 (definition records). All records which are not part of the AOMF and are not extraneous are considered erroneous.

bestie, if a record is not part of AOMF and is not one of those extraneous ones, it's erroneous. full stop 🛑

🚀 Module Header Record 🚀

            ┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
            │  REC    │ Record  │ Module  │ TRN ID  │ zero    │ CHK     │
            │  TYP    │ Length  │ Name    │ 8 bits  │ 8 bits  │ SUM     │
            │  0x02   │ 16 bits │         │         │         │ 8 bits  │
            └─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Each module must start with a module header record. It is used to identify the module for the RL51 and other future processors of 8051 object files. In addition to the Module Name, the record contains:

TRN ID — The byte identifies the program which has generated this module:

  • 0xFD — ASM51
  • 0xFE — PL/M-51
  • 0xFF — RL51.

🛑 Module End Record 🛑

       ┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
       │  REC    │ Record  │ Module  │ zero    │ REG     │ zero    │ CHK     │
       │  TYP    │ Length  │ Name    │ 16 bits │ MSK     │ 8 bits  │ SUM     │
       │  0x04   │ 16 bits │         │         │ 8 bits  │         │ 8 bits  │
       └─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

This record ends the module sequence and contains the following information: characteristics.

MODULE NAME — The name of the module is given here for a consistency check. It must match the name given in the Module Header Record.

REGISTER MASK (REG MSK) — The field contains a bit for each of the four register banks. Each bit, when set, specifies that the corresponding bank is used by the module:

  • Bit 0 (the least significant bit) — bank #0.
  • Bit 1 — bank #1.
  • Bit 2 — bank #2.
  • Bit 3 — bank #3.

📦 Content Record 📦

            ┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
            │  REC    │ Record  │ SEG ID  │ Offset  │  DATA   │ CHK     │
            │  TYP    │ Length  │ 8 bits  │ 16 bits │         │ SUM     │
            │  0x06   │ 16 bits │         │         │         │ 8 bits  │
            └─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

This record provides one or more bytes of contiguous data, from which a portion of a memory image may be constructed.

SEG ID — This field must be zero.

OFFSET — Gives the absolute address of the first byte of data in the record, within the CODE address space.

DATA — A sequence of data bytes to be loaded from OFFSET to OFFSET+RECORDLENGTH−5.

🍓 Size Multiplier 🍓

In general, raw binary data will expand in size by approximately 1.02 times when represented with this format. tiny glow-up, honestly ✨

🌈 SOURCE 🌈

srec_cat version 1.65

Copyright (C) 1998... Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

🫶 MAINTAINER 🫶

  • Scott Finneran — E‐Mail: scottfinneran@yahoo.com.au
  • Peter Miller — E‐Mail: pmiller@opensource.org.au

✨ later bestie — this page is from the SRecord Reference Manual, page srec_aomf(5), with srec_cat version 1.65 energy. the footer has no date listed, so I'm absolutely not inventing one 💖🦋✨

📦 where this page comes from