dg%DEImos.Caltech.Edu%Hamlet.Caltech.Edu@Jpl-VLSI.ARPA@caip.RUTGERS.EDU (03/07/86)
From: dg%DEImos.Caltech.Edu@Hamlet.Caltech.Edu (fairly long) >Thought the whole list might be interested in this. Hack is available for >anonymous FTP from TRANTOR.UMD.EDU in /info-amiga/hack.[1-13] > >> Date: Tue, 4 Mar 86 13:42:56 PST >> From: walton%DEImos.Caltech.Edu@Hamlet.Caltech.Edu >> Reply-To: walton%DEImos.Caltech.Edu@Hamlet.Caltech.Edu >> Comment: The answer is 42 >> >> We have uploaded the HACK files from Trantor using FTP from node HAMLET, ... >> Everything appeared to come over OK, and rather >> than try to rebuild from source, we attempted to use the ASCII-fied binary >> files. All of the .info files converted fine, but the executable file in >> hack.13 consistently gives a checksum error in byte 62,300 something. > >I had the exact same problem; the checksum error trying to binify the hack.13 >file. I ended up rebuilding hack from the sources. Note that you need to >have a file "signal.h" with SIGQUIT, SIGINT, SIGHUP and SIG_IGN defined to >something. > >Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU > University of Maryland, Computer Science Center - Systems Programming In view of the above, I decided to try to compile and link Hack from the source code and encountered many problems. I eventually solved them (at some level) and succeeded in obtaining a running (limping) Hack. I thought some of you would be interested in how I solved the various problems, and maybe someone can come up with better solutions for some of them. Everything was done on an Amiga with 512k and an external disk drive. It will be very clear the the following that I am not a hacker. The first steps are well documented in the separate postings by John A. Toebes, VIII, whose messages include the source explode.c (essential), which separates the modules. After exploding the source code and running the execute file 'setup', you are ready to begin compiling. First I made the following changes to the ccall execute file: (1) preface all lines with LC: (this assumes you have assigned LC: to Lattice_C:c). (2) change all the -ii: to -iINCLUDE: (or assign I: to Lattice_C:include). (3) delete the reference to -dTINY in the lc2 line that runs the second phase of the compiler on the module _main.c. (4) add 2 lines (lc1 and lc2) to compile the module hack.graphics.c, which was left out. The physical disk setup I used was to have all the .c and support modules on a disk called Hack_Game, including the modified ccall. I had a second disk, empty but initialized and named Hack_Source, to receive the .o files created by the compiler. Next, I created the signal.h file as suggested in Mamakos' message above. I used #define SIGQUIT 1, etc., defining these as integers 1, 2, 3, 4. I have no idea if that was, in fact, what he means. It gave no problems. Next, I had to address the bug in workbench.h that was mentioned by someone in a previous message (gives error 'invalid bitmap assignment'). I deleted the :1 from each of the four offending lines, which allowed Hack to compile, but this is *not* the correct solution. Does anyone have the correct one? Next, I found that most modules have include statements such as #include <stdio.h>, whereas they should be #include <lattice/stdio.h>. Rather than changing all the modules, I solved this problem by copying the include:lattice files to include:. Next, I found that my version of def.objects.h has blank lines (probably <CR><LF> pairs) every other line. This doesn't hurt anything except where there are continuation lines in #define statements. I just deleted the blank line between the first and second lines of each continued #define and it compiled fine. Finally, I put the Lattice_C disk in one drive and Hack_Game in the other and executed ccall. It works fine, but requires 118 disk swaps! The compiler runs lc1 off Hack_Game, then puts up a requestor for Hack_Source, then runs lc2, then requests Hack_Game and so on. *Very* tedious. If anyone has a way around it, speak up. You can safely ignore all the warnings about uninitialized and/or unreferenced autovariables. Okay, all the Hack modules are compiled. Put the Link_Hack file from Hack_Game onto Hack_Source, *then reboot*, but without workbench. This is necessary because when I tried it with a bare workbench (376k free memory), the link failed because of insufficient memory. It just barely squeaks by with 400k. To link, type LC:ALINK WITH LINK_HACK from the Hack-Source directory. It takes about 20 minutes. After all this, the executable will not fit on Hack_Game because the individual modules leave only about 400 blocks on the disk (the executable is about 490 blocks). I did a diskcopy of Hack_Game and deleted all the .c files from the copy (don't delete any of the support files--they are needed). After copying the executable to this new Hack_Game disk, Hack ran great. ------------------------------------------------------------------------ Now for the bad news, the system crashes whenever I try to exit. I found that I got several warnings about unreferenced structure tags (KeyMap, VSprite, collTable, etc.) when compiling the Amiga specific modules, so that is probably the cause, but when I tried to include the missing .h files, I got a compiler error. If someone knows how to include these modules (the same problem occurs when compiling the SetAlternate code posted earlier), please let me know. If this information saves anyone some grief, it will be worth it. Happy Hack_Gaming. Dale E. Gary ARPA: dg%deimos@hamlet.caltech.edu Caltech Solar Astronomy BITNET: dgary@caltech.bitnet Physics DECNET: DEIMOS::DG
fnf@unisoft.UUCP (Fred Fish) (03/08/86)
In article <1440@caip.RUTGERS.EDU> dg%DEImos.Caltech.Edu%Hamlet.Caltech.Edu@Jpl-VLSI.ARPA@caip.RUTGERS.EDU writes: >Next, I found that most modules have include statements such as >#include <stdio.h>, whereas they should be #include <lattice/stdio.h>. >Rather than changing all the modules, I solved this problem by copying >the include:lattice files to include:. The prefered way to deal with this situation if to leave the source code alone (#include <stdio.h> is right) and tell the compiler where to look for the files. Manx C got this right and put stdio.h, along with some other "standard" header files, in the <something>:include directory, rather than in their own non-standard <something>:include/<C_compiler_vender> directory. Any code that has a line like #include <lattice/foo.h> is going to be very non-portable! Off course, you could use my cc frontend, posted to the net a long time ago, that hides all the Lattice bogosity's from the user, but that is another story... -Fred