Psych was added to the build system. It requires fops.s
for maths. Two notable things need to be fixed to make it
assemble:
* d1 must be defined, presumably to a 1 following the
patterns of other decimal numbers.
* variable xx must be renamed so it doesn't clash with
the xx instruction mnemonic used by the perl cross assembler.
Recently Wordle has piqued the interest of many (like me):
https://www.powerlanguage.co.uk/wordle/
A recent video by Tech Tangents links Wordle to Master Mind
and also mentions it being based on Bulls and Cows or Moo:
https://www.youtube.com/watch?v=rLUmER9dn9A&t=141shttps://en.wikipedia.org/wiki/Bulls_and_Cows#The_numerical_version
Judging by the assembler listing I thought moo.s might
be an implementation of the game for PDP-7 UNIX. I
debugged the game deduced why it exits early.
The game statistics are saved in the file moostat.
Prior to this commit there was no such file which
caused moo to exit immediately at start. Now, once
the file exists, the game can run successfully.
This is how to play the game:
1. after having logged in as ken, enter "moo" ENTER at prompt
2. moo asks "wru?" which means "who are you?"
3. answer "ken" ENTER
4. moo says "name not found; enter?"
5. answer "y" to participate in the game
6. moo says "ready?"
7a. answer "s" to see the current standings between participants listing name, number of games, average guesses, average time
7b. answer "a" to see your average, showing number of games, average guesses and average time
7c. answer "r" to reset the game from step 2 above
7d. answer "q" to quit the game if you wish
8. answer "y" to begin the game
9. moo generates a secret number that you must guess
10. enter a four digit number like "2874" and press ENTER
11. if your guess is correct, moo says "g=<number of guesses> t=<time in some unit>", goto step 6
11. if your guess is not correct, moo says "bc=" followed by two numbers
12. 1st digit is the number of correct digits in the correct place in your guess
13. 2nd digit is the number of correct digits in the wrong place in your guess
14. goto 10
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"
