> On the
> 16F874 part that I am using, I have modified the START definition of
> gpr1 so that the address 0xA0 is never allocated.

Personally, I don't think this change belongs in the linker control file.
I think it is better done explicitly in the source code:

.save0  code   h'7F'
wsave   res    1       ;W save area in bank 0
.save1  code   h'FF'
wsave1  res    1       ;W save area in bank 1

If you ever move the code to another chip that doesn't have RAM here, you
will get a linker error.

> RESET           CODE    H'000'

You need to set PCLATH before the goto.

>                  goto    Main              ; go to beginning of program

> DATABANK   NAME=gpr1     START=0xA1     END=0xFF     //Does 0x20 & 0xA0
> map together?

Argh, no!!!  Each separate region of RAM should have its own DATABANK or
SHAREBANK (SHAREBANK in this case).  You are telling the linker it's OK to
allocate your RAM on top of all the FSRs in bank 1.

> My concern is that the template and code examples are misleading.

What templates and what code examples?

> From
> the responses, I gather that the consensus is emerging that 1) indeed
> the '874 '877 distinction is subtle,

Pretty straight forward, I think.  The difference is clear if you compare
the data space map of the 877/876 on page 13 with the map for the 874/873
on page 14.

I think the reason you got some misleading responses is that some people
(myself included) didn't notice that you were using one of the relatively
unusual PICs that don't have unbanked memory at 70h- 7Fh.  I hadn't
noticed you were using '874 or '873, and didn't remember off the top of my
head that these didn't have the shared RAM anyway.  However, none of that
is the fault of the documentation.  It seems quite clear to me.

> 2) the register support on the
> '874 is too weak and incorrectly documented,

I don't know what "weak" means, but what specifically do you find
incorrect?  I'm looking at "PIC16F87x Data Sheet" (DS3029C).  The register
mapping is spelled out quite clearly on page 14, and appears correct to
me.

> 3) there are some fixes at
> either code writing time or linker time (if using relocatable code).

"Fix" for what?  You haven't shown anything that's broken.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics