AnachronautandClaude Opus 5
2ad8edf9bc
Every file service took a name a program already knew - read it, save it, rename it, delete it, ask how big it is - and none of them could find out what names there are. dir could list only because it lives in the shell and calls the filesystem directly. So a file manager, a backup, and the package manager still to come were each unwritable for want of this. osDirFirst and osDirNext. DP0 says where to put the name and B how much room, the same bargain osArgument and osWhereAmI offer. Q ANSWERS THE KIND rather than a yes or no, so one value says both whether there is an entry and what it is: 0 a file, 1 a directory, 2 a save that stopped before it committed, 0xFF nothing more. A caller that only wants names tests for 0xFF and ignores the rest. The size is deliberately not in it. A walk hands back a name, and a program that wants the size asks osFileInfo about that name - the alternative being a record in memory whose shape both sides have to agree on, which services.asm went out of its way to avoid for file sizes. Walk.asm is the first program that can see a directory, and it asks osFileInfo about each entry BETWEEN two steps of the walk. That is the hazard rather than decoration: where a walk has got to and where the last file asked about lives are both held by the system, and two things sharing one position would show as a listing that stopped early or said a name twice. Then the same walk in /Apps, since one that only ever ran at the root would not have proved it walks where you are. A directory is not asked about at all. osFileInfo answers for one perfectly well and says nought blocks, which is true and reads as a size - and nought is a size a file can genuinely have. The lint baseline moves by one. The kind is decided by a chain of bit tests in the shape dir already uses five hundred lines away, and arms of a comparison chain each loading the same variable are the case this project's own rule says not to collapse: the repetition is what lets a new arm be dropped in anywhere. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
138 lines
3.0 KiB
NASM
138 lines
3.0 KiB
NASM
; A program that says what is on the disk.
|
|
;
|
|
; Which no program could do until now. Everything the system offered took a name a program
|
|
; already knew - read it, save it, rename it, delete it, ask how big it is - and there was no
|
|
; way to ask what names there are. dir could list only because it lives in the shell and calls
|
|
; the filesystem directly. So a file manager, a backup, and the package manager still to come
|
|
; were all unwritable for want of two services.
|
|
;
|
|
; This is those two, used as simply as they can be: walk, say what each thing is, and ask
|
|
; about it.
|
|
;
|
|
; > Walk
|
|
; f Say.sbx 1
|
|
; d Apps 0
|
|
; u halfsaved.txt 3
|
|
;
|
|
; ---- And it asks about each one AS IT GOES, which is the point ----
|
|
;
|
|
; Where a walk has got to is the system's, and so is where the last file it was asked about
|
|
; lives - the same eight bytes of filesystem state. A program that walks a directory and asks
|
|
; osFileInfo about each entry is using both at once, which is the obvious thing to write and
|
|
; the thing that would quietly go wrong if the two shared a position.
|
|
;
|
|
; Calling osFileInfo between two steps of the walk is therefore not decoration here. It is the
|
|
; check, and a walk that came back wrong afterwards would show up as a short listing or a
|
|
; repeated name rather than as an error.
|
|
|
|
#Include services.asm
|
|
|
|
#Program
|
|
|
|
#Base 0x5000
|
|
|
|
start:
|
|
SETD.0 Name
|
|
INIB 0d24
|
|
SWI osDirFirst
|
|
BRI walkCheck
|
|
|
|
walkStep:
|
|
SETD.0 Name
|
|
INIB 0d24
|
|
SWI osDirNext
|
|
|
|
walkCheck:
|
|
; The kind is written down before anything else wants the registers: the comparison below
|
|
; is an ALU operation and Q is where its answer goes.
|
|
MVQA
|
|
SETD.0 Kind
|
|
STA.0
|
|
INIB 0xFF
|
|
CCF
|
|
SUB
|
|
BRQ walkDone
|
|
|
|
; f, d or u. A chain rather than a table, because three is not enough to index - and A is
|
|
; still the kind, since SUB writes Q and leaves it alone.
|
|
BRA walkFile
|
|
INIB 0d1
|
|
CCF
|
|
SUB
|
|
BRQ walkDirectory
|
|
SETD.0 Unfinished
|
|
BRI walkSay
|
|
walkDirectory:
|
|
SETD.0 Directory
|
|
BRI walkSay
|
|
walkFile:
|
|
SETD.0 File
|
|
|
|
walkSay:
|
|
SWI osPrintString
|
|
SETD.0 Name
|
|
SWI osPrintString
|
|
SETD.0 Space
|
|
SWI osPrintString
|
|
|
|
; ---- And how big it is, asked BETWEEN two steps of the walk ----
|
|
;
|
|
; The name is the only thing the walk hands over, which is what keeps it from being a record
|
|
; both sides have to agree the shape of. A program that wants more asks about the name, the
|
|
; same way anything else does.
|
|
;
|
|
; A directory is not asked about. osFileInfo answers for one perfectly well and says nought
|
|
; blocks, which is true and reads as a size - and nought is a size a file can genuinely
|
|
; have, so the two would be indistinguishable in the listing.
|
|
SETD.0 Kind
|
|
LDA.0
|
|
INIB 0d1
|
|
CCF
|
|
SUB
|
|
BRQ walkNoSize
|
|
|
|
SETD.0 Name
|
|
SWI osFileInfo
|
|
BNQ walkNoSize
|
|
|
|
PSHD.3
|
|
POPB
|
|
POPA
|
|
SWI osPrintNumber
|
|
BRI walkEnded
|
|
|
|
walkNoSize:
|
|
SETD.0 NoSize
|
|
SWI osPrintString
|
|
|
|
walkEnded:
|
|
SETD.0 NewLine
|
|
SWI osPrintString
|
|
BRI walkStep
|
|
|
|
walkDone:
|
|
RSTA
|
|
SWI osExit
|
|
|
|
#Data
|
|
|
|
#Base 0x3000
|
|
|
|
File:
|
|
"f "
|
|
Directory:
|
|
"d "
|
|
Unfinished:
|
|
"u "
|
|
Space:
|
|
" "
|
|
NoSize:
|
|
"-"
|
|
NewLine:
|
|
0x0A 0x00
|
|
|
|
Kind:
|
|
0x00
|
|
Name:
|
|
#Reserve 0d24
|