AnachronautandClaude Opus 5
b6004bdcde
"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
45 lines
2.0 KiB
NASM
45 lines
2.0 KiB
NASM
; Where the assembler's big buffers live.
|
|
;
|
|
; A map rather than a set of declarations, and it has a file of its own because the reader
|
|
; and the label table both need addresses out of it while neither includes the other.
|
|
;
|
|
#Data
|
|
|
|
; NOT #Reserve, AND THAT IS THE WHOLE POINT. Reserved space in a segment is written into
|
|
; the file as zeroes and copied at load, so 22K of scratch made a 34K file - and a loaded
|
|
; program is staged at 0x8000 before being put in place, which leaves exactly 32,768 bytes
|
|
; for the whole of it. The assembler could not load itself.
|
|
;
|
|
; None of this is initialised data. It is scratch, wanted only while the assembler is
|
|
; running, and while it is running everything above its own data is free: the system keeps
|
|
; below 0x1000, the staging area is only in use during a load, and the Stack comes down
|
|
; from the top. So the addresses are written down here and the file carries none of it.
|
|
;
|
|
; 0x8000 3072 the label index, 768 entries of four
|
|
; 0x8C00 8192 the label names, packed end to end
|
|
; 0xAC00 13312 the output file being built
|
|
; 0xE000 1792 the vector names, 64 entries of twenty eight
|
|
; 0xE700 1758 the reader's stack, six levels of 293
|
|
; 0xEE00 368 which files have been included, sixteen names of 23
|
|
;
|
|
; That ends at 0xEF70, with the Stack coming down from 0xFFFF above it - about four
|
|
; kilobytes, against the tens of bytes of CALL frames this ever nests.
|
|
;
|
|
; THE TWO THINGS THAT DECIDE THESE SIZES are the largest program it will be asked to build
|
|
; and the largest one it will be asked to read. CosmOS is 475 labels and 9,564 bytes of
|
|
; output; the assembler itself is 555 labels, about 6,800 bytes of name and 11,648 of output. The
|
|
; second is bigger than the first, which is worth knowing: the hardest thing this assembles
|
|
; is not the operating system, it is itself.
|
|
ScratchLabIndex:
|
|
0x80 0x00
|
|
ScratchLabArena:
|
|
0x8C 0x00
|
|
ScratchImage:
|
|
0xAC 0x00
|
|
ScratchVecNames:
|
|
0xE0 0x00
|
|
ScratchSrcStack:
|
|
0xE7 0x00
|
|
ScratchIncNames:
|
|
0xEE 0x00
|