до меня доперло, чем основано неперекрашивание нескольких пикселей в начале при смене цвета во время отрисовки картинки.
мне кажется всему виной обработка процедур в момент возникновения прерывания.
дело в том что каждая команда занимает определенное колличество циклов. а так, как прерывание происходит во время исполнения какой либо команды, проц сначала доделывает операцию, а потом только сбрасывается на прерывание, что занимает некоторое время и является причиной недоперекрашивания.
все гениальное просто 
и тут уж никуда не деться
HBlank, согласно внутренним счетчикам VDP, занимает столько времени, сколько нужно на отрисовку 2 пикслелей на экране. Согласно документации, это эквивалентно 36 циклам M68K. (Я это называю по памяти, так что могу немного наврать в цифрах).
Насчет "процессор сначала заканчивает обработку инструкции, а потом переключается на прерывание" - я тоже так думаю, хотя это только моя догадка, так как я не сильно разбираюсь в механизме обработки прерывания. Если оно так, действительно пара циклов может теряться. Однако крайне мало инструкций процессора занимают больше 10 циклов, и думаю, большая редкость застать длинную инструкцию в самом начале ее выполнения.
В то же время, обработка самого прерывания тоже должна занять пару циклов процессора. Нужно сохранить в стеке значение PC (Program Counter - оффсет текущей инструкции), на котором произошло прерывание, а также значение SR (Status Register). Кстати, именно из-за того, что в стеке настраивается состояние SR, для возврата из прерывания нужна специальная инструкция RTE, а не обычный RTS.
Но вряд ли может случиться так, что все эти операции по времени займут больше, чем само прерывание. Вот тот эффект про который ты говоришь, ты заметил в Канслвании. Но видел ли ты его когда-нибудь в Сониках? Я не видел, если только мельком в Соник 3 (в AIZ 2).
Где-то на первой странице этого топика я высказывал мысль, что дело в медленном коде. Думаю, так и есть. Код прерывания не оптимален, понатыкан всякими бранчами, отнимающими время процессора, а может сам перенос цветов в CRAM сделан медленно (например, если перебрасывать по 2 байта, да еще и в цикле, потери времени будут огромны). Ну а если код еще написан на Си...
Вобщем, из-за всего этого палитра не успевает переброситься вовремя, и уже начинается отображение новой строки с еще старой палитрой.
