Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!rpi!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga.games
Subject: Re: Balance of Power - no mouse pointer?
Message-ID: <1990Oct25.142802.28158@batcomputer.tn.cornell.edu>
Date: 25 Oct 90 14:28:02 GMT
References: <4464@swi.swi.psy.uva.nl> <1990Oct25.105011.9515@canterbury>
Organization: Cornell Theory Center
Lines: 28

In article <1990Oct25.105011.9515@canterbury> chem194@canterbury (John Davis, programmer at large, chemistry department) writes:
>It's not a bug so much as an oversight, the original BOP made the ( then
>common ) mistake of not _explicitly_ locating things like the mouse 
>pointer image data in chip mem. Hence, on a machine with fast memory
>you'd get a non-existent pointer due to the data not being accesible
>to the custom chips. 

>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.

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.

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.

-Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell University