Лешадок помпе: плата расширения для Вектора-06ц

[Improver]

А это никак не связано с регенерацией?

Не исключено...

[svofski]

Экранка Black Ice из зала:



- - - Updated - - -

Экранка SkyNet:



Загрузка частей тормозит. Это мой дисковод печатает дебаг инфо за кадром.

[ivagor]

svofski, спасибо за кино! Шадки качают, это радует.
Пара вопросов по black ice.
1. "Какого цвета платье". Цвет букв в районе 1:10, когда YES HYPER JUMP видится мне как бело-голубой. В эмуляторах желто-зеленый. Это такие жесткие особенности цветопередачи связки монитор+камера(или телефон или не знаю)? Еще цвет летящих на зрителя точек сначала должен быть желто-красный (потом, с тех же 1:10 - белый), но толком рассмотреть окраску точек на записи с реала затруднительно, это я даже не докапываюсь, просто не могу разглядеть.
2. В районе 0:35-0:36 по экрану пробегает нечто вроде "помехи" - это именно помеха в тот момент, или повторяющаяся особенность?

[svofski]

"Какого цвета платье"

Все цвета обычные, ничего странного в них нет. Проблема в съемке.

В районе 0:35-0:36 по экрану пробегает нечто вроде "помехи" - это именно помеха в тот момент, или повторяющаяся особенность?

Не, это просто разбег кадровой монитора и камеры. Я вообще удивлен, что это фактически видно только в одном месте, нету никаких полос итд.

Из артефактов, присущих реалу. Если присмотреться, есть иногда какие-то едва заметные сдергивания, как будто запись в экран разбегается с лучом, где-то в районе презентации всеми любимой фотографии. Ну и теплые ламповые пульсации геометрии всей картинки в целом в зависимости от содержимого экрана. Кроме того известные вертикальные полосы записи в РУ2 в Black Ice, но на них специально показывать никому уже не надо, они просто есть.

А так вообще объективно ничего удивительного я не увидел. Просто приятное ощущение от того, что вот оригинальное железо и на нем такие крутые штуки вытворяли.

Настроить камеру так, чтобы по всем параметрам получилось сделать видео с экрана так, как оно видится мне, причем при всех вариантах мерцаний, преобладания яркого фона и темного фона итд для меня задача оказалась непростой. Может быть надо снимать в дневное время, когда общее освещение яркое и без выраженных бликов, тогда проще достичь какого-то разумного баланса. Из курьезов: пришлось нарочно расфокусировать объектив, чтобы муар был не такой страшный. И все равно в SkyNet получилось плохо. Кроме того мой фотоаппарат не умеет плоский профиль, так что на коррекцию в постобработке нельзя рассчитывать. В общем делать экранки это какая-то пока для меня неизведанная наука

Надо приделывать хоть какой-то плохонький интерфейс пользователя. А то сейчас мне чтобы сменить дискету надо обновлять прошивку.

[svofski]

Из сегодняшних ужасов. Вот это работает 100%, выдерживает даже пересборку с нуля без сигналтапа:

always @* begin: _cpu_datain
    casez(di_select) 
    6'b1?????:   cpu_di <= boot_vec; // boot vector
    6'b?????1:   cpu_di <= sdram_do; // do not move this line
    6'b010000:   cpu_di <= lowmem_do;
    6'b001000:   cpu_di <= bufmem_do;
    6'b000100:   cpu_di <= ram_do;
    6'b000010:   cpu_di <= display_idata;
    default:    cpu_di <= ioports_do;
    endcase
end

Вот это нет:

always @* begin: _cpu_datain
    casez(di_select) 
    6'b1?????:   cpu_di <= boot_vec; // boot vector
    6'b010000:   cpu_di <= lowmem_do;
    6'b001000:   cpu_di <= bufmem_do;
    6'b000100:   cpu_di <= ram_do;
    6'b000010:   cpu_di <= display_idata;
    6'b?????1:   cpu_di <= sdram_do; // fml im ded x_x
    default:    cpu_di <= ioports_do;
    endcase
end

- - - Updated - - -

Да, важный момент, я немного несправедлив к Квартусу, потому что это приоритетный шифратор. То есть по учебнику casez специально для этого предназначен, а я его заставляю работать. sdram_do имеет приоритет над остальными выборками (почему - отдельная история, сейчас неважно). А раз приоритет, будь добр подвинуть строчкой повыше!

[b2m]

Вот это нет:

always @* begin: _cpu_datain
    casez(di_select) 
    6'b1?????:   cpu_di <= boot_vec; // boot vector
    6'b010000:   cpu_di <= lowmem_do;
    6'b001000:   cpu_di <= bufmem_do;
    6'b000100:   cpu_di <= ram_do;
    6'b000010:   cpu_di <= display_idata;
    6'b?????1:   cpu_di <= sdram_do; // fml im ded x_x
    default:    cpu_di <= ioports_do;
    endcase
end

Какой-то неправильный шифратор. Что у тебя выбирается при 6'b1хххх1? Почему последняя строка не 6'b000001? Почему после еденицы нолики, а не вопросы (в средних строках)?

[Advertiser]

[svofski]

b2m, приятно, когда твой код читают, даже если за него приходится краснеть.

Эта конструкция транслируется в приоритетный шифратор. В случае, когда есть неоднозначность, приоритет у того, что написано выше. При 6'b1xxxx1 выберется boot_vec. Последняя строка в процитированном тобой фрагменте срабатывает только если 6'b000001, а в случае например 6'b000101 перекидывается на ram_do.

Такая ситуация вообще не должна возникать. А почему вообще так получилось: селекторы обязаны быть (и были раньше) one-hot. Но ядро 6502, которое я использую, при чтении выдает следующий PC на шину адреса на следующем клоке независимо от RDY. От этого мой старый механизм простого выделения селекторов перекосило, и ван-хотом он быть временно перестал. А это хака, чтобы посмотреть как работает чтение-запись в принципе. Ее обязательно надо изжить, но не правя этот шифратор, а переделав селекторы.

[b2m]

а в случае например 6'b000101 перекидывается на ram_do.

Фигушки. ram_do выбирается лишь в одном варианте 6'b000100, конкретно этот вариант попадает лишь под маску 6'b?????1.

Вопросы генерируют множество вариантов, где вместо вопросов либо нули, либо еденицы. На мой взгляд, это лишь сокращённая запись.

Но в одном ты прав - casez может иметь несколько совпадений (если они были сгенерированы вопросами) и в конечном итоге будет действовать тот, что стоит выше.

- - - Добавлено - - -

Проблема там скорее всего в наличии строчки default, которую можно считать вариантом 6'b??????, стоящим на последнем месте.

- - - Добавлено - - -

А может и не на последнем, а вообще случайном. Кто этот кактус знает...

[svofski]

Фигушки. ram_do выбирается лишь в одном варианте 6'b000100, конкретно этот вариант попадает лишь под маску 6'b?????1.

Здравый смысл с тобой согласен. У меня же результат менялся от сборки к сборке. Уверен, что выборка приходилась на ram_do, хотя повторить это уже не захочу. Вывод тем не менее простой: не надо делать такие шифраторы вообще. Раньше по-моему Квартус выдавал хотя бы предупреждения какие-то на этот счет. Сейчас ему тихо сводит моск, а ты сиди и гадай, где слажал.

[andreil]

Здравый смысл с тобой согласен. У меня же результат менялся от сборки к сборке. Уверен, что выборка приходилась на ram_do, хотя повторить это уже не захочу. Вывод тем не менее простой: не надо делать такие шифраторы вообще. Раньше по-моему Квартус выдавал хотя бы предупреждения какие-то на этот счет. Сейчас ему тихо сводит моск, а ты сиди и гадай, где слажал.

Скорее всего в этом виноваты глитчи схемы
То есть какая-то часть в этой сборке отработала быстрее и выдала вектор, а в другой сборке - уже другая.
Входные сигналы на шифратор подай через регистр - и скорее всего проблема исчезнет. Ну и с фронтами поиграться стоит - я у себя сделал тактирование счётчика по положительному фронту, а занесение данных со счётчиков в регистр - по отрицательному. Без регистров была гонка состояний (т.е. "глитч") и работала только каждая третья-четвёртая сборка. Сейчас всё работает стабильно.