Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!newsrelay.iastate.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!nntp-server.caltech.edu!nathan From: nathan@cco.caltech.edu (Nathan Mates) Newsgroups: comp.sys.apple2.gno Subject: Re: FixKern204D Date: 7 Jun 1994 20:23:07 GMT Organization: California Institute of Technology, Pasadena Lines: 86 Message-ID: <2t2kvb$nee@gap.cco.caltech.edu> References: <4DLJNc7w165w@lablues.AVCNet.org> NNTP-Posting-Host: piccolo.cco.caltech.edu In article <4DLJNc7w165w@lablues.AVCNet.org>, Lawrance A. Schneider wrote: >Nathan, put FixKern204D on cba2 please. Thanks Larry Larry- I don't know if you've been reading this newsgroup and csa2.p, but Mike Westerfield, the author of Orca/M and the whole Orca series didn't want a patching init for Orca/M to exist. He was afraid that it would cause conflicts with future Orca/M programs, even though I took a number of steps to make sure such a thing would not happen. Therefore, FixKern204C should be removed from circulation, and 204D never made it off my HD. With Mike's permission, I might write up a quick basic program to patch it, if he thinks that is acceptible. Mike has said that he can distribute patched binaries to those on AOL and GENie who are registered owners. For those of us out here on the internet, there isn't too much that can be done. The best thing is for those of you with enough computer skills in patching things is to manually patch out your personal copies of the orca/m assembler. David Epsom posted a thing about a week ago that noted where the bad byte was in the 2.0.1 binary; look that up. In case you can't look back that far, here's my origial bug report: ---- My Bur report, 5/30/94 Orca/M 2.0.1 contains a fairly nasty bug that zeros out one byte of memory past what it owns. If that extra 0 lands on empty space, fine, no big deal. If it lands on something that's already a zero, no big deal. If it lands on my Message List (thanks to MessageChecker for catching this one), big deal. This was one of the more insidious Message List trashers I've found; it redirected the Message List to some other list in memory that was "valid" (a nil-terminated linked list of handles) 90% of the time, but I caught it in the action. Anyhow, enough background info, here's the scoop on the memory- trasher. Orca/M 2.0.1 allocates 3 blocks of length $000DB4 for whatever use. But, at the end, it zeroes out one of them with this segment of code. Orca/M 2.0.1's main block loaded at 13/0000, so the addresses here are relative to that: 13/ longa on longi on ;gotta be on for what we're doing 8722: ldy #$0DB3 ;NO! lda |0FAB ;ptr to start of first block sta <24 ;Direct page for [],y access lda |0FA9 sta <22 ;normal copy. lda #0 ;zero it out ZapIt sta [22],y dey dey bpl ZapIt Well, the problem with this little routine is that in a block of length $0DB4, a word access to +$DB3 drops a zero on the last byte of the block, and goes one step beyond. Plus, since DB3 is odd, the very first byte of this block won't get zeroed out. ---- End quoted section Thus, if you scan on disk for the "lda #0/sta [22],y/dey/dey/bpl zapit" sequence (the bpl instruction comes out as 10 FA; remember that this code chunk has the accum in long mode), and change the A0 B3 0D (the ldy instruction) to a "A0 B2 0D". That's it. For those of you who don't have Orca/M 2.0.1, this bug also exists in 2.0[.0]. It's at +$871F instead, I think. But, a simple disk search for these bytes should still find it. I'd like to be able to distribute 204D, but seeing as I can't, you'll have to patch things out by hand. Nathan Mates -- * Nathan Mates nathan@cco.caltech.edu * MSC #850, Pasadena CA 91126 * * Ftp humor archiver: ftp to cco.caltech.edu, look in pub/humor * * Largest collection of Clinton Jokes, other canonical lists * * Support Twilight II, the best screen saver for the Apple IIGS! *