@SteveF, @KenLowe
Thanks both for the pointers to other threads and for your time and advice. There is quite a learning curve around Econet and FS3 as I have found.
a) *DIR ^ - I was initially using FS3 v 0.92, as the first source of FS3 that I came across. *DIR ^ is only supported from v1.24 onwards. That was the main source of my problems with Ozmoo.
b) having found the Stardot Github repository of L3FS, I tried to install 1.33 and discovered that Copyfiles as provided with L3Utils seems to have some problems with copying load and exec addresses - at least, when I changed to Treecopy 1.63a these addresses appeared correctly on my ADFS partition on my FS drive and I was able to start it and redo my user accounts so that home directories supported *DIR ^ - I am not clear on how this is implemented, but it seems that each directory folder entry must have a field denoting the parent directory - so only home folders created in 1.24 or later behave correctly.
c) Using a minizork build including the -a and --nfs-install-only modifiers, copied the disc image contents to $.ZORK, added a SAVES directory, sorted permissions and edited !BOOT so that the third line was the absolute address of the user home directory - ie *DIR $.ZORK. Then uttered the magical incantation *OPT4,3
Now *I AM ZORK cleanly starts miniZork. This is achieved with no amendments to LOADER. Which is where I had initially hoped to get to.
The issue on a server is of course that one would like multiple users to be able to use this code, including simultaneously, but these games were all created in a time of single user machines and floppy discs and in many cases, hard wired file/pathnames. So there is the thorny issue of saving game states. Ken's structure of a games directory appeals. What I have also found is that the save command in Zork will accept an NFS pathname. $.ZORK.savename gets an insufficient access error, BUT &.savename succeeded - &.SAVES.savename ditto. I will experiment with this, but I think that if the games are stored in a read-only gamesLib folder, and if the user correctly enters pathnames for saves, this could work. This is therefore the next experiment.![Smile :-)]()
Peter
Thanks both for the pointers to other threads and for your time and advice. There is quite a learning curve around Econet and FS3 as I have found.
a) *DIR ^ - I was initially using FS3 v 0.92, as the first source of FS3 that I came across. *DIR ^ is only supported from v1.24 onwards. That was the main source of my problems with Ozmoo.
b) having found the Stardot Github repository of L3FS, I tried to install 1.33 and discovered that Copyfiles as provided with L3Utils seems to have some problems with copying load and exec addresses - at least, when I changed to Treecopy 1.63a these addresses appeared correctly on my ADFS partition on my FS drive and I was able to start it and redo my user accounts so that home directories supported *DIR ^ - I am not clear on how this is implemented, but it seems that each directory folder entry must have a field denoting the parent directory - so only home folders created in 1.24 or later behave correctly.
c) Using a minizork build including the -a and --nfs-install-only modifiers, copied the disc image contents to $.ZORK, added a SAVES directory, sorted permissions and edited !BOOT so that the third line was the absolute address of the user home directory - ie *DIR $.ZORK. Then uttered the magical incantation *OPT4,3
Now *I AM ZORK cleanly starts miniZork. This is achieved with no amendments to LOADER. Which is where I had initially hoped to get to.
The issue on a server is of course that one would like multiple users to be able to use this code, including simultaneously, but these games were all created in a time of single user machines and floppy discs and in many cases, hard wired file/pathnames. So there is the thorny issue of saving game states. Ken's structure of a games directory appeals. What I have also found is that the save command in Zork will accept an NFS pathname. $.ZORK.savename gets an insufficient access error, BUT &.savename succeeded - &.SAVES.savename ditto. I will experiment with this, but I think that if the games are stored in a read-only gamesLib folder, and if the user correctly enters pathnames for saves, this could work. This is therefore the next experiment.

Peter
Statistics: Posted by PeterTheGrey — Thu Jul 18, 2024 9:22 am