The naive order of the assembly files given to the assembler was to
put the st?.s files first followed by fop.s at the end. This caused
Space Travel to crash, why that happend is explained below.
st1.s through st5.s contain code, while st6. and st7.s contain
constants and data storage respectively. The order of the given
assembler files meant that the code st?.s ended up at 010000 onwards,
while the code in fop.s ended up after the data storage defined in
st7.s. In particular the function fmp ended up immediately after dspl.
At the end of st7.s there is a display list, dspl. At runtime this
list is pointed to by the clistp variable stored at the auto-indexing
memory register at address 017. Auto-indexing means that the pointer
will be incremented after use. However the display list dspl does not
reserve memory for the entire list, instead it assumes that the memory
immediately after dpsl is unused. This conflicts with storing fmp from
fop.s immediately after st7.s!
Despite this conflict the first few frames of space travel could be
rendered because clistp was never referenced. By the time it was
referenced it changed the code in fmp to invalid code. At a later
stage when fmp was called the program crashed.
The solution I chose is to reorder the files at the command-line given
to the assembler; specifically I opted to put fop.s after all the code
in st1.s though st4.s.
This means that Space Travel now runs without crashing!
simplify boot paper tape (do one xfer of 4K, instead of 3K+1K)
Combine cmd/scope.cas cmd/cas.cas into sys/cas.in
Add src/other/chrtbl.s
write chrtbl.out in "ptr" format
mkfs: if neither --dotdot or --dot options given, create .. link to current dir
accept -1 for inum in add_direntry to mean "use previous i-num" for links
proto: use inum -1 to make "list" a link to "nls"
Sebastian Rasmussen