The AMB (Ancient Machine Book) format specification[rational]


The AMB format is, by design, burdened by several limitations. These limitations might be misunderstood as shortcomings, while in essence the AMB format's primary objective is to stay as primitive as possible - so it is easy (and fast) for software to parse and display. Below are listed some of these limitations, with explanations about the reasons that led to them. * Line length limited to 78 characters The hard-coded limit of 78 chars is meant to ensure that the reader will not have to worry about line wrapping, which highly simplifies the reader's code thus allowing for faster processing and minimizing potential bugs. It is also meant to allow the content creator to design his screens in a deterministic way - that is, without any risk that his semigraphic tables, ASCII drawings or overall screen disposition will be broken by a reader that attempts to rewrap the text at an unpredictable width. The 80-columns width was ubiquitous since the early 80' and seems to be a reasonable baseline expectation, and a 78-characters limit allows the reader to use two columns for its own needs (vertical cursor, border, etc). * No control over style (colors) applied to text The AMB format defines a set of semantic tags (like "%h" for "heading"). It does not allow control over the exact colors or attributes that will be used by the output device to render the document. This is designed on purpose: AMB documents should be displayable also on monochrome devices. There may also be devices that allow for text attributes like "underlined", "bold", etc - it is up to the AMB reader to make sure the semantic tags are translated into colors/shades/attributes combinations that are nicely rendered on the target hardware. * Article size limit of 64 KiB A single article (AMA file) is limited to a maximum length of 64 KiB (minus one byte). This limitation makes it easier for MS-DOS readers to load the content: in real-mode Intel memory models, a single memory segment is addressable via 16-bit offsets, hence processing content larger than 64 KiB becomes tricky, as it involves crossing memory segment boundaries, or relying on some kludges like "huge" memory pointers (slow), or dynamically reloading parts of the file from disk (very slow). 64 KiB still allows for more than 30 pages of 80x25 packed text, which should be more than enough even for very complex subjects (and larger contents should simply be dispatched into two or more different articles, which can only be beneficial for readability). * Maximum number of 65535 articles An AMB book may contain up to 65535 articles and not a single more, because the number of articles is written as a 16-bit integer in the file's header. This allows AMB software to use 16-bit integers when addressing the articles, which is very convenient (and fast) for platforms with 16-bit CPUs. And honestly - is that really a limitation? Even the entire Bible has "only" 1189 chapters, or 31103 verses. * Short filenames + low-ascii characters only Filenames inside an AMB container are limited to 12 (8+3) characters so an AMB container can be unpacked on an old MS-DOS system. The filenames must contain only low-ascii (7-bit) characters -- for two reasons: so it is possible to unpack an AMB container on any filesystem, independently of the codepage said filesystem relies on, and to make it possible to reliably perform case-insensitive matching of filenames.