Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!uwm.edu!uwvax!uwslh!lishka From: lishka@uwslh.slh.wisc.edu (a.k.a. Chri) Newsgroups: comp.sys.handhelds Subject: Re: Display offset in CHIP48 and BRIX w Message-ID: <1990Sep17.160239.19509@uwslh.slh.wisc.edu> Date: 17 Sep 90 16:02:39 GMT References: <2124@bnlux0.bnl.gov> <16800003@ux1.cso.uiuc.edu> <1990Sep17.024009.6187@uwslh.slh.wisc.edu> Organization: Wisconsin State Laboratory of Hygiene Lines: 30 lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: >I ran the CHIP48 program (with BRIX) on my HP48 and got the screen >offset problem as well. I had no luck getting the ON-C reset to >correct the display. The odd thing about my experiences is that I >have a revision *A* machine! I therefore don't think the problems are >revision-related, but rather are actual bugs in the programming. Thanks to a user "whelan" somewhere in Hawaii (I'd like to be there right now myself ;-), I discovered one of the problems affecting the CHIP48 display problems. Apparently, having any sort of *library* (from a hardware card or from a software port) will move the screen RAM. I have one system library permanently installed in software, which was the source of my problems. Once I detached *and* removed it completely from memory, the display anomaly cleared up. By the way, besides having the screen shifted over, I am seeing one other screen-related problem. With a library attached, when CHIP48 is terminated via the backspace key it does *not* restore the normal screen. Instead, it leaves the CHIP48 screen behind with some extra garbage written to it. Amazingly enough, I have had no problems with corrupted memory. ON-C also seems to always clear up the junk left behind from CHIP48. .oO Chris Oo. -- Christopher Lishka 608-262-4485 "Dad, don't give in to mob mentality!" Wisconsin State Lab. of Hygiene -- Bart Simpson lishka@uwslh.slh.wisc.edu "I'm not, Son. I'm jumping on the bandwagon." uunet!uwvax!uwslh!lishka -- Homer Simpson