Доброго времени суток! Занялся написанием часов/будильника на PIC16F630..
Так вот, при занятых 258 словах памяти программ контроллера всё хорошо, ведет себя как и положено, но стоит только дабавить любую команду в начало исходника, то он начинает отображать не то что надо, в зависимости от места постановки лишнего слова..
Может есть какая-то особенность или секрет, которого я не знаю?

Пишу на ассемблере в MPLAB IDE v8.70
Прошиваю через PICkit 2 Programmer

Если нужно, могу выложить исходник..

P.S. Замена контроллера не помогла..

тебе совет,то выкладывай. Форуму ни чего не нужно.

Вот исходник с 259-й командой NOP в блоке инициализации
Собрано на макетной плате: PIC16F630, сдвиговый регистр 74HC595, 4-х разрядный 7-ми сегментный индикатор FYQ-2541AS
Схему соединения сейчас нарисую..

И не мудрено. Вы очень вольно обращаетесь с таблицами. И не учитываете, что команда ADDWF PCL не выполняет перенос в старший байт адреса, при переполнении в младшем.
У меня для контроля в таких случаях всегда стоял предохранитель:

Компилируй и пиши дальше. Объяснять лень. Читай про PCL и PCH

Да, в этом и была причина.. В источниках, откуда я черпал свои знания (интернет статьи, частично даташиты) такого нюанса не видел..

Благодарю за разъяснение!

В даташите этому 2-3 странице посвящено, и насколько помню даже со стрелочками куда какие биты переносятся показано. Даташиты надо изучать, а не хрень самописную всякую. Если программа не сильно объемная, то можно сделать так: в мплабе (если там пишете) ставим
Таблица должны быть в самом конце программы.

Не буду комментировать Ваш наезд на ТС - человек учится, но отмечу, что последнее Ваше утверждение - спорное.

Однако в случае с PICами это утверждение весьма спорно.
Сработает только в случае, если у применяемого МК только одна страница памяти программ.
Ежли мы имеем дело с МК имеющим более 1 страницы памяти программ, то повылазят дополнительные "подарки" от неучтенного содержимого PCLATH даже при обработке простейших подпрограмм (не говоря уже о таблицах).

Добавлю: вообще не правильное. И приложенный код тоже.

Эм... прошу изъяснений.

Таблица вообще может быть где угодно, хоть кусками в разных местах.
Весь это пустопорожний разговор от желания упростить расчет перехода через addwf PCL, f.
Универсальный расчет перехода включает в себя вычисление ЗНАЧЕНИЯ для PCL с переносом (переполнения) в PCLATH и лишь затем записью в сам PCL. Это слегка длиннее, но абсолютно универсально.

По выложенному тексту таблица должна находиться в первой странице т.е. в начале программы и заканчиваться не далее 0xFF.
Если хотите располагать таблицу в любом месте, то как описал КРАМ.
Поиграйте с текстом в MPLAB.

МММ...
Поговорим о "среднемладших"... Исходим из следующего:
В большинстве случаев таблица нужна для быстрого преобазования данных и редко превышает 256 байт.
Общий объём памяти программ превышает 1 страницу...
Возможна работа активных аппаратных перрываний...
Поскольку при вызове подпрограммы преобразования по CALL TABLE содержимое PCLATH.4:PCLATH.3 уже автоматически сбрасывается в PCH, то загрузка старшего байта адреса указателя таблицы должна быть выполнена перед вызовом CALL TABLE, а не в самом теле обработчика.
Для удобства работы начальную точку желательно размещать на границе областей (0x0000/0xNN00).
Следует учесть, что ADDWF PCL,1 при W=0xFF даст "бесконечный цикл"... (если не учитывать перенос в старший разряд при "примитиве" минимальной реализации алгоритма обращения к PCL)
Таким образом вводится еще одно ограничение на входные параметры при вызове обработчика.
В обработчике прерываний обязательным пунктом будет хранение в программном блоке временных регистров содержимого PCLATH и его последующее восстановление по завершению обработчика прерываний.
Пример с дополнительной предобработкой содержимого PCLATH в теле обработчика необходим лишь в случае произвольной точки вхождения в обработчик таблиц в любой точке адресного пространства памяти программ.
В большинстве практических применений достаточно предварительное указание старшего байта адреса таблицы, не забывая при том, что исходное (до CALL TABLE) содержимое PCLATH после выполнения RETLW X будет искажено (если не добавить еще один промежуточный регистр временного хранения).
Кстати PIC16F630 такие страсти-ужасти практически не угрожают - диапазон адресов не затрагивает PCLATH.4:PCLATH.3 (0x000-0x3FF) да еще при весьма "льготном" режиме доступа ко второму банку РПД.
Единственно надо следить за PCLATH.2:PCLATH.1:PCLATH.0, но и это не обязательно, если таблица на границе 256 байтовой области, либо значение в W не превышает 127.
Т.е. для 630-го это будет:

REG EQU 0x20
;==========
ORG 0
CALL TABLE
NOP
;=================
ORG 220H ; РАСПОЛОЖЕНИЕ В ЛЮБОм
; месте памяти программ при разрешенном
; диапазоне значений в W от 0 до 127 (0x00-0x7F)
TABLE
ADDWF PCL,F ;
TABL RETLW B'11000000' ;
RETLW B'10011111' ;
; ...
END

Если же необходимо использовать страничный механизм, то прийдется сделать такое:

movlw high TABLE
movwf PCLATH
CALL TABLE
_____
TABLE
movlw low TABLE
addwf reg,w
btfsc STATUS,C
incf PCLATH,f
movwf PCL
ну и далее кучка retlw
а вот как насчет 0xFF в REG... и дополнительного хранения/восстановления PCLATH - кому надобно - додумывайте.

BOB51 Не поленись в MPLAB прогнать этот код.

Да у Микрочипа есть апнота по этому злодейству... поиском её...

Верно... Зевнул - любая запись весь PCLATH загружает, а старшей двойки там не будет.
зато второй пример к месту

Импровизация не возбраняется. Главное не упускать из виду основную суть.

Благодарю всех участников данного обсуждения, особо otest за помощь в разрушении "стереотипа ADDWF PCL,f"/подсказку решений относительно особенностей работы с PCL/PCLATH для режимов таблица данных/вычисляемый переход (таблица векторов)!