That one caught me too. I think this is what you need to turn on 16-bit pointers: #DEVICE *=16 This is from memory since all my PIC stuff is at work, but it should be explained in your readme file. I think there is also something in the back part of the manual in the commonly asked questions section. You can also use the read/write bank commands to access the extra memory directly. Since I was using it as a buffer I decided to do that instead based on my theory that 16-bit addressing eats up valuable program memory. (am I right?) I think I had to be creative to access some of the memory this way though. This is because read bank starts at 120h and 1A0h in banks 2 and 3 instead of 110h 1B0h. I think I fooled the compiler by starting at F0h (effectively -10) instead of zero. Again my code is at work so I can't say for sure. Some simple experiments should confirm this. You'll definitely know if you accidently write over registers by mistake. Jeff At 23:27 -0500 4/3/00, John Hansen wrote: >I'm attempting to write a program for the 16F877 that will require most of >it's 368 bytes of data RAM. I'm using CCS C version 2.674, which is >supposed to support this chip. However, take a look at this output (from >the absolute listing window in MPLAB): > > Filename: C:\PROGRA~1\MPLAB\TNC\KISS.LST > > ROM used: 690 (8%) > Largest free fragment is 2048 > RAM used: 149 (85%) at main() level > 155 (89%) worst case > Stack: 2 locations > >With 149 bytes of RAM used, it seems to think that 85% of the memory is >used up. That would seem to imply that it thinks that there are only 175 >bytes of RAM rather than the advertised 368 bytes. Anybody else run across >this? Is it a bug in CCS? > >John Hansen --- Jeff Davis "Imagination is more important than knowledge. (425) 702-1741 Knowledge is limited. 8323 158th PL NE Imagination encircles the world." Redmond, WA USA 98052 -Albert Einstein-