DANFUZZ@BROWNVM.BITNET (Dan Bornstein) (03/18/89)
On the IIgs, the border color is stored in the LOW-NIBBLE of $C034. When you set it you should be sure not to disturb the top nibble; do something like this (assuming native-mode) LDA $C034 AND #$FFF0 ORA #$000x <---- x is the color # you want STA $C034 (8-bit mode) LDA $C034 AND #$F0 ORA #$0x STA $C034 -dan
krazy@claris.com (Jeff Erickson) (03/18/89)
From by DANFUZZ@BROWNVM.BITNET (Dan Bornstein): > On the IIgs, the border color is stored in the LOW-NIBBLE of $C034. When > you set it you should be sure not to disturb the top nibble; do something > like this (assuming native-mode) > > LDA $C034 > AND #$FFF0 > ORA #$000x <---- x is the color # you want > STA $C034 > Uh, almost. You need to be careful about the data bank register. If, for example, it was set to 2, and you executed that code, you'd modify 2/C034. Here's the code I use: lda >$e0c034 and #$fff0 ora #$000? sta >$e0c034 This will work under the standard GS desktop environment. Any other environment is your own problem. -- Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4 Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy 415/960-2693 \________________________________________________________ ____________________/ "I'm so heppy I'm mizzabil!" -- Krazy Kat
mdavis@pro-sol.cts.com (Morgan Davis) (03/19/89)
Dan Bornstein describes the method by which one changes the border color register on the IIGS. You have to be careful with the upper nibble in this register because it is used by the Real Time Clock (RTC). However, Dan's example showed 16-bit memory access being made to the $E0Cxxx area. Is it not unsafe to do this? When you fetch 16 bits from a location here you could possibly be hitting a softswitch. I think it might be better to drop into 8-bit accumulator mode when working in the peripheral RAM area. UUCP: crash!pnet01!pro-sol!mdavis ProLine: mdavis@pro-sol ARPA: crash!pnet01!pro-sol!mdavis@nosc.mil MCI Mail: 137-6036 INET: mdavis@pro-sol.cts.com APE, BIX: mdavis
wombat@claris.com (Scott Lindsey) (03/19/89)
From article <8903181756.AA05520@crash.cts.com>, by mdavis@pro-sol.cts.com (Morgan Davis): > Dan Bornstein describes the method by which one changes the border color > register on the IIGS. You have to be careful with the upper nibble in this > register because it is used by the Real Time Clock (RTC). However, Dan's > example showed 16-bit memory access being made to the $E0Cxxx area. Is it not > unsafe to do this? When you fetch 16 bits from a location here you could > possibly be hitting a softswitch. I think it might be better to drop into > 8-bit accumulator mode when working in the peripheral RAM area. As a general rule, probably so. However, in this case, there is no soft- switch at 0xE0C035 or in the high nibble, so it _is_ safe. To add my macros to the fray, these two are used in tandem to set the border on entry to a section of code and restore it on exit. Admittedly, these are not the most efficient pieces of code, but they're fairly clear and only for debugging anyway. #define SETBORDER(color) asm{ lda >0xE0C034 \ and #0xF \ pha \ lda >0xE0C034 \ and #0xFFF0 \ ora #color \ sta >0xE0C034 \ } /* Reset border back to what SETBORDER saved */ #define RESETBORDER() asm{ lda >0xE0C034 \ and #0xFFF0 \ ora 1,s \ sta >0xE0C034 \ pla \ } -- Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or dead.
krazy@claris.com (Jeff Erickson) (03/20/89)
From by mdavis@pro-sol.cts.com (Morgan Davis): > Dan Bornstein describes the method by which one changes the border color > register on the IIGS. You have to be careful with the upper nibble in this > register because it is used by the Real Time Clock (RTC). However, Dan's > example showed 16-bit memory access being made to the $E0Cxxx area. Is it not > unsafe to do this? When you fetch 16 bits from a location here you could > possibly be hitting a softswitch. I think it might be better to drop into > 8-bit accumulator mode when working in the peripheral RAM area. I've never, never, never had any problems with the smattering of code I posted, and I used it for over two years. No, I don't think its a problem. The rest of that word doesn't contain soft switches like $E0C030 does. (That's the speaker, isn't it?) I don't remember the details, and I don't have the manulas any more, but you can find out for sure in _The Apple IIgs Firmware Reference Manual_ (Addison-Wesley -- one of the GS Developer's Bibles). -- Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4 Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy 415/960-2693 \________________________________________________________ ____________________/ "I'm so heppy I'm mizzabil!" -- Krazy Kat
mattd@Apple.COM (Matt Deatherage) (03/20/89)
In article <9105@claris.com> krazy@claris.com (Jeff Erickson) writes: > >I've never, never, never had any problems with the smattering of code I >posted, and I used it for over two years. No, I don't think its a problem. >The rest of that word doesn't contain soft switches like $E0C030 does. Yes, but that doesn't mean it never will. >Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4 >Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy >415/960-2693 \________________________________________________________ >____________________/ "I'm so heppy I'm mizzabil!" -- Krazy Kat ============================================================================== Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that AppleLink PE: Matt DTS GEnie: AIIDTS | Apple Computer, Inc., or any of its CompuServe: 76703,3030 | subsidiaries, in whole or in part, Usenet: mattd@apple.com | have any opinion on any subject." UUCP: (other stuff)!ames!apple!mattd | "So there." =============================================================================
throoph@jacobs.CS.ORST.EDU (Henry Throop) (09/12/89)
In the past month or so, the border color on my gs has been getting messup up more and more often. This always starts when I press ctrl-oa-reset out of a program (no specific program - has happened after 8 and 16 bit ones) and then after the beep, the border color changes from black to red. If I press ctrl-oa-esc to get to the CDA menu, it changes back to black, until I press ctrl-reset or reboot, at which time it goes to red. In the control panel, everything looks fine, and any changes I make there take effect until I reset, when again the border color gets incremented. Going through the self-test does get everything back to normal, for awhile at least. I don't think it's a virus, because it seems to come up after anything: 16 bit, 8 bit, ProDOS 8, GS/OS, and even Zork's OS, on a 5.25". I don't think it's my battery or the battery RAM, because nothing else in the control panel gets changed, and the RAM checks out OK with the self-test. Any suggestions? Henry --- Henry Throop Internet: throoph@jacobs.cs.orst.edu