Skip to content

09-text-and-strings.md

Latest commit

 

History

History
232 lines (176 loc) · 10.6 KB

09-text-and-strings.md

File metadata and controls

232 lines (176 loc) · 10.6 KB
Raw

Text, strings, and the version cookies

The definition, stated before the figure

Prose is a printable run of at least 12 bytes containing a space, a lower-case letter, and at least two words. A defensible floor, not a maximum.

And the second measurement the checklist asks for when the definition might not see the disc — the same run test with the lower-case requirement relaxed to "any letter" — because Myth's visible text was all upper case and the standard definition saw none of it.

denominator standard prose case-insensitive prose
on disc (1,261,776 B) 7,659 B = 0.607 % (250 runs) 7,808 B = 0.619 % (257 runs)
resident (1,636,635 B) 7,659 B = 0.468 % 7,808 B = 0.477 %

The two definitions differ by 149 bytes. Unlike Myth, the standard definition sees this disc, and the second measurement is reported to show that rather than to replace the first.

Set comparison, on disc: Universe 13.70 %, Superfrog 1.054 %, Alfred Chicken 0.607 %, Gunship 0.18 %, Myth 0.068 %.

Who the prose belongs to

The denominator matters more than the percentage, and on this disc almost none of the text is the game's.

owner bytes on disc prose share of all prose
the game (alfred, intro, alf) 1,085,728 6,034 78.8 %
Commodore's commands (c/assign, c/execute, c/setpatch) 20,852 1,502 19.6 %
libs/lowlevel.library 6,920 36 0.5 %
s/startup-sequence 119 87 1.1 %
all assets (.PAK, .map, .unpack, .info) 148,157 0 0.0 %

Zero prose in every asset file on the disc. Not one byte, across 148,157 bytes of level archives, tile banks, maps and the icon.

And the 6,034 bytes credited to "the game" are mostly not game text either:

  • 1,533 bytes are the descriptive names of Amiga custom hardware registers in intro — Commodore's own comment text from hardware/custom.i, carried into a debugger (see docs/10-code-and-engine.md);
  • several hundred more are SAS/C runtime boilerplate: ** User Abort Requested **, *** Break: , Can't open version , 0123456789abcdef, con:10/10/320/80/, /auto/close/wait;
  • the debugger's own format strings: vpos=%d,hpos=%d, instruction %x, %x, ,vcomp=%d,hcomp=%d, UNKNOWN_OPCODE, copdis: copper list pointer is null;
  • alf's entire prose contribution is 29 bytes, and alfred's is 338 bytes in 5 runs, all of them C runtime.

So the honest statement is not "0.607 % of this disc is prose". It is:

The game itself contributes essentially no text at all. The prose on this disc belongs to Commodore, to the SAS/C runtime, and to a debugger.

Gunship's version of this was that 47.6 % of its text belonged to a game that does not start. This is a stronger form of the same warning.

Where the words went: they are drawn

A platform game has a title, a menu and a credit screen. None of them is text on this disc, and the reason is visible: frontend.pak decodes to a 320 × 184 four-bitplane image of the words ALFRED CHICKEN with a ™, drawn as artwork.

That is the answer to the string-table question, and it is a fifth answer rather than one of the four known models:

model disc
an offset table into flat strings Universe
everything inline in code Gunship
separate text files parsed at run time Superfrog
a relocated page index over position-prefixed record chains Myth
no string table, because there is no text — the words are pixels Alfred Chicken

My prediction was "inline in code, the Gunship model, under 0.5 % on disc". The percentage is right on the resident denominator (0.468 %) and wrong on the disc denominator (0.607 %), and the model is wrong — there is no table of any kind because there are no strings to put in one. The three string-table traps the checklist lists (length not stored; entries repeating and pointing backwards; a zero entry being a kept empty slot) do not apply, because there is no table, and saying so is the result.

Encoding

range bytes on disc share
control, < 0x20 647,946 51.35 %
ASCII 0x20–0x7E 207,005 16.41 %
0x80–0x9F 51,606 4.09 %
0xA0–0xFF 355,219 28.15 %

32.24 % of the disc is above 0x7F, but that is a byte census of packed streams and planar artwork, not an encoding fact. Inside the actual prose runs there is not one byte above 0x7F: the text on this disc is pure 7-bit ASCII, measured rather than assumed, in all 7,659 bytes.

That places it with Gunship and Myth, and away from Superfrog's correct ISO 8859-1 in four languages.

Version cookies

$VER: — three, and all three belong to Commodore

file cookie
c/assign $VER: assign 37.4 (25.4.91)
c/execute $VER: execute 37.11 (14.5.91)
c/setpatch $VER: setpatch 40.14 (7.10.93)

None of the three game programs has a $VER:. alf, alfred and intro carry no version cookie at all.

The exact form matters, because "the disc is versioned but the games are not" and "the only version string on the disc belongs to somebody else" are different statements. Myth was the second. This disc is the first: it has three, all Commodore's, and its own three executables have none. Prediction 19 said "at least one $VER: exists" — technically correct, and correct for the wrong reason, which is scored as a miss in docs/13-prediction-scoring.md.

Bare build banners — none

Checked for, because three discs in the set have one where a $VER: is missing. There is no bare banner in any of the three executables.

But there is a third kind, and the set has not had it before

Expanded RCS $Header: keywords, one in each game executable:

/alfred : $Header: Hard0:alfred/rcs/amiga.c,v 1.1 93/11/19 16:40:55 JJS Exp $
/intro  : $Header: Hard0:alfred/intro/intro/rcs/amiga.c,v 1.1 92/09/29 17:57:54 JJS Exp $

A $VER: is typed by a person and can say anything. An RCS keyword is stamped by the version control system at check-out, so it records a real event, and it carries four fields where a $VER: carries two: a path, a revision, a timestamp and a user name.

tools/idstrings.py was written for this pipeline to find all three kinds together — RCS and SCCS keywords, $VER: cookies, and library/device names — because on this disc the strongest dating instrument is the one the checklist did not have a step for. Full analysis in docs/05-timestamps.md.

Library and device names, with the Nu trap live

4E 75 is rts and reads as Nu. The trap is active on this disc and a naive run dump produces Nudos.library, Nuscsi.device, Nucd.device, Nugameport.device, Nulowlevel.library, PONudos.library and _Nuintuition.library — seven inventions.

tools/libscan.py resolves it by walking backwards from the NUL terminator through the character set a real name uses, and reports what it stripped:

file real names
alf dos.library*, intuition.library
alfred cd.device, dos.library*, freeanim.library, graphics.library, input.device, intuition.library*, lowlevel.library
intro the same seven as alfred

* a leading u was stripped: the preceding byte is 0x4E, so the pair is rts and the u is opcode, not name.

The exact test — if a name begins with u and the byte immediately before it is 0x4E, that u is the low half of an opcode — fires on every one of them.

Libraries shipped versus libraries opened

The checklist's standing instruction: a shipped library is not a used library, cross libs/ against who actually opens it.

  • libs/ contains exactly one file: lowlevel.library, 6,920 bytes.
  • alfred and intro both name and open it. Shipped and used.
  • freeanim.library is named by both executables but is not on the disc — it comes from CD32 ROM. Liberation shipped a copy of it in c/; this disc relies on the ROM.
  • nonvolatile.library is named nowhere in the game. It appears twice on the disc, in c/setpatch (Commodore's own patch list) and inside lowlevel.library itself — never in alf, alfred or intro.

The save-system question, answered two ways

  1. no $00B80030 load anywhere — the game never touches the EEPROM's I²C port directly (docs/07-graphics.md);
  2. no nonvolatile.library reference in any game binary — and the disc does not ship the library either.

This game has no save system. Confirmed by two independent routes, which is the standard the Superfrog and Myth entries set.

It is worth noting how it differs from Superfrog's version of the same answer: Superfrog shipped nonvolatile.library and opened it from nowhere. This disc does not ship it at all. Same conclusion, one fewer red herring.

The one reference that does not resolve

Every name reference inside every file was resolved against the disc, case- insensitively as AmigaDOS does:

  • alf names intro and alfred — both resolve;
  • alfred names baby.pak, book.pak, cheese.pak, glass.pak, scifi.pak, wood.pak and lowlevel.library — all resolve, with a case difference: the executable spells them lower case, the directory records spell them BABY.PAK, BOOK.PAK and so on. AmigaDOS is case-insensitive so they resolve; this is the Superfrog ManGFX/Superfrog.iff versus SuperFrog.iff situation exactly;
  • s/startup-sequence names setpatch, assign, execute and alf — all resolve;
  • the .map and .unpack files are named by no literal string anywhere — and they are not orphans. alfred carries the format strings %s.map and %s.unpack and builds the names at run time. A literal-name search would have reported fourteen orphan files totalling 79,232 bytes, which would have been wrong, and the check that caught it was looking for the printf conversions;
  • JJSDISK:startup does not resolve, and cannot. It is the one reference on the disc with no target, and the boot script tests for its volume before using it. See docs/06-compression.md.

Twelve of thirteen references resolve; the thirteenth is guarded.

The three device paths, none of which is on the disc

path where what it is
JJSDISK: s/startup-sequence, twice a developer's volume, tested for and branched around
alf2: alfred, as the format string alf2:%s a development assign for asset loading
Hard0: alfred and intro, inside the RCS keywords the build machine's hard disk

No DF0:–DF3:, no CD0:, no disk-change prompt. The only volumes this disc names are three that belong to the machine it was built on.