1The implementation of dungeon on unix systems 2Randy Dietrich 17 Nov 1981 3 4When we set out to get dungeon running on unix we figured 5it wouldn't be too big a problem. After all a fortran 6compiler (F77) existed and with relatively little problem 7managed to get everything to compile. 8Then the Zorkmids hit the volcano. 9We thought that a program which would run in 28k on an 10RSX system would have fit just fine in 64k, especially 11with seperate i & d. We did not realize just how hostile 12unix is to FORTRAN programs. 13The first link indicated about 130 k (text only) was needed 14for the whole game (Ieeeeee). Recompiling with short (I2) 15integers brought this down to about 100k. Throwing out 16the game debug package (9k) and the save and restore code (3k) 17got us to within 20k. 18At this point we discovered that the fortran library that 19was being used was about 25k (A HA !!). If we could just 20eliminate that we would be in business. A great game with 21no I/O !! further work allowed us to write the I/O in C 22with the bulk of the game using only standard input and output. 23The initialization and message printing were "moved out" 24into seperate processes and the whole mess piped together. 25it is a real kludge but seems to work (mostly). 26 27The Input process is called 'listen'. It first reads the init 28file and shoves it in the pipe and then switches to pass 29keyboard input to the main game. This keeps the main program 30from having to read anything but 'standard input'. 31 32The output process is currently called 'speak'. 33this process does the lookup in the file 'dtext.dat' and 34sends out the messages that give dungeon it's flavor. This 35process also passes clear text from the main program to 36allow the output of other messages for such things as the 37echo room, puzzle room, and score. These functions 38were also 'moved out' so the main program would not have 39to access any disc files. 40 41The main program is sandwitched between listen and speak. 42It really does the work of the game. I/O is handled 43thorugh C routines in 'cio.c'. this keeps any fortran 44I/O from being used and calling in the whole #$%@ fortran 45library. 46 47The current lash-up does save or restore but not both. 48It is going to take a while to work in as we are out of room 49in the main program and will have to re-write something 50to make it all fit. I guess we will just have to play 51without being able to cheat for a while. 52 53Restores are done by initializing the game with a second argument 54(some day the file name) of 'r'. This causes the init process 55to send a 'R' down down the pipe followed by the restore data. 56normally the init process ends with a '?'. The trailing '?' 57will follow the restore data. 58 59Saves are done from within the game. The game sends a 's' 60down the pipe to signal the speak process to do a save opperation. 61The save data then goes down the pipe followed by 'e' to 62signal the end of data. The save data is 'dungeon.sav'. 63