Path: utzoo!attcan!uunet!comp.vuw.ac.nz!canterbury!chem194 From: chem194@canterbury (John Davis, programmer at large, chemistry department) Newsgroups: comp.sys.amiga.games Subject: Re: Balance of Power - no mouse pointer? Message-ID: <1990Oct26.090036.9527@canterbury> Date: 25 Oct 90 20:00:36 GMT References: <4464@swi.swi.psy.uva.nl> <1990Oct25.105011.9515@canterbury> <1990Oct25.142802.28158@batcomputer.tn.cornell.edu> Organization: University of Canterbury Lines: 48 In article <1990Oct25.142802.28158@batcomputer.tn.cornell.edu>, riley@batcomputer.tn.cornell.edu (Daniel S. Riley) writes: > In article <1990Oct25.105011.9515@canterbury> chem194@canterbury (John Davis, programmer at large, chemistry department) writes: >>The solution is simple - run the program thru either FixHunk or ( better >>still ) use the HunkLab option on PowerPacker, and force ALL data hunks >>into chip memory [...] > > FixHunk, at least the version I tried, won't work. BOP uses overlays > (another sign that it was developed on a 512K machine), and FixHunk > doesn't understand overlays. Version 1 of fixhunk indeed will not handle overlayed files, version 2 ( on a more recent fish disk ) will ( with certain limits - it's a brilliant tool none the less ) > There's a program called "Hunker" that wandered across the net several > years back that does work with BOP. Dunno [sic] about the HunkLab > option in PowerPacker. Also, no guarantees about how either of these > solutions may (or may not) interact with the copy protection scheme. Shouldn't matter at all as far as copy protection goes, whether the code is in chip or fast ram doesn't really matter as far as it's concerned. ( remember that to force a hunk to chip mem you're only twiddling a couple of bits within the hunk-header, you're not touching the code within ) > BTW, it's only the mouse pointer that has this problem, so you can run > nofastmem, start the program, and then re-run nofastmem to get your > memory back once the mouse pointer has been loaded. However, this > does end up needlessly loading the lots of code into precious chip > RAM. It's better to fix the executable. exactly, I like to run BOP whilst doing other things ( although because it does some rather silly busy waits somewhere in there, this means a LOT of twiddling with TaskX :-). Running nofastmem means a lot more code is forced into chipmem than is necessary, which is not a good idea on a very limited resource like chipmem. Using fixhunk means that only _necessary_ data will be in chip. Of course, you could just take the easy solution and get BOP 1990 ( it doesn't have the mouse problem, plus it multi-tasks better ) ----------------------------------------------------------- | o John Davis - CHEM194@canterbury.ac.nz o | | o (Depart)mental Programmer,Chemistry Department o | | o University of Canterbury, Christchurch, New Zealand o | | o o | | o co-sysop AmigaINFO BBS,1200/2400 baud CCITT, o | | o 24 hours a day, ph NZ +3-3371-531 o |