jake/SplitBit-Emulator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Say "boot image" where that is what is meant

Browse Source 
"Binary" was doing three jobs. It meant an SPBT file that the machine starts
from; it meant whatever the assembler happened to produce, which is now
either that or a loadable program; and it meant a compiled host tool. A word
that means three things means none of them, and the first of the three has a
name already - this project has been calling them boot images for a while
and the manuals had not caught up.

  Where it means an SPBT file       -> boot image
  Where it means either output      -> output
  Where it means a host executable  -> left alone
  Where it means base two           -> left alone

The user facing messages move with it:

  Error: No boot image specified.
  Usage: ./SplitBit [OPTIONS] <boot image>
  Error: This is not a SplitBit boot image.
  Error: This boot image is in format version 2, and this emulator reads 1.
  Successfully wrote SplitBit boot image to "hello.bin".

The assembler's own help was the interesting case. Its -o writes either
format, so "the binary" there was never right - it is "the output" now, and
the message that names the format is the one that says which it wrote.

No recorded output contained the word, so nothing needed re-blessing.
Checked before starting rather than after.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
Anachronaut
2026-08-21 14:50:03 -04:00
co-authored by Claude Opus 5
parent 306b4dce92
commit b6004bdcde
12 changed files with 41 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Source/Assembler/assembly.h
+7 -7
View File
@@ -8,13 +8,13 @@
#ifndef ASSEMBLY_H
#define ASSEMBLY_H
// ---- The SplitBit binary format ----
// ---- The SplitBit boot image format ----
//
// A binary starts with a file header, then the Program Segment, then the Data
// A boot image starts with a file header, then the Program Segment, then the Data
// Segment. All multi byte numbers are stored most significant byte first.
//
// Offset Size Field
// 0 4 "SPBT", so a file that is not a SplitBit binary is spotted at once
// 0 4 "SPBT", so a file that is not a boot image is spotted at once
// 4 1 Format version
// 5 4 Required feature flags
// 9 3 "PRG"
@@ -27,14 +27,14 @@
// .. 2 Vector Segment length, in bytes
// .. K Vector Segment, four bytes per entry
//
// The Vector Segment is optional and comes last, so a binary written before it existed
// The Vector Segment is optional and comes last, so an image written before it existed
// simply ends after its Data Segment and still loads. Each entry is two bytes saying
// where in Program Memory the vector sits, then two bytes saying where its handler is,
// most significant byte first. It is a list rather than an image of the table, so a
// program with three handlers costs twelve bytes instead of a padded kilobyte.
//
// The feature flags are how a binary says it needs something the base machine does
// not provide, so that an emulator which cannot provide it refuses to run the binary
// The feature flags are how a boot image says it needs something the base machine does
// not provide, so that an emulator which cannot provide it refuses to run the image
// rather than quietly doing the wrong thing. No features are defined yet; the field
// is here so that adding one later does not need another format version.
@@ -110,7 +110,7 @@
#define SPLITBIT_HEADER_BYTES (SPLITBIT_MAGIC_LENGTH + 1 + SPLITBIT_FLAGS_LENGTH \
+ 2 * (SEGMENT_MARKER_LENGTH + SEGMENT_LENGTH_BYTES))
// Features this build of the emulator can provide. A binary asking for anything
// Features this build of the emulator can provide. An image asking for anything
// outside this set is refused.
#define SPLITBIT_FEATURES_SUPPORTED 0x00000000u