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