Если по теме то как-то развитие темы забуксовало - как-то всё не очень понятно что автор задумал - какие-то тайлы вперемешку с блиттером, процессор там что-то двигает в байте прежде чем отправлять в аксель - имхо это не правильно.
Насчёт того как правильно у меня такие соображения:
как тут уже неоднократно проскакивала мысль что нагородить можно кучу любых режимов, но скорее всего они не будут поддержаны - поэтому нужен максимально совместимый режим со стандартным спековским экраном, и вот как это примерно должно быть
1. у акселя своя память и он слушает шину - никаких ДМА и прочей ереси;
2. каждый экран я бы сделал для начала байт на точку с палитрой - итого 49152 байт на экран, самих экранов от 2 до 4;
3. например при записи байта по адресу между 0х4000 .. 0х57FF аксель должен успеть записать в свою видеопамять 8 байт а при записи по адреcам из области атрибутов успеть записать уже 64 байта - также нужно после ресета первые 16 цветов палитры сделать как стандартные цвета спека - это всё для что касается режима совместимости;
4. теперь что касается самих наворотов - проц должен общаться с акселем более высокоуровнево, вот например список основных команд:
0х01 - послать в память акселя спрайт номер такой-то с размером таким то - примерно как в GS - аксель уже сам сообразит где у себя в памяти его разместить
0х02 - отобразить спрайт номер тако-то по координатам таким-то.
0хFF - типо инит - очистить внутреннюю память спрайтов или чтото ещё )
остальные команды добавлять - там точку, линию или print_char аппаратный.

в общем как-то так - игры адаптировать под такое элементарно, или даже на бейсике писать новые )

а то что-то грустно совсем следить за этой темкой ))