Вид для печати
Да тут вообще звезды в твою сторону поворачиваются. И пикад у тебя и Вектор у тебя и опыт работы с SIMM-ами у тебя. Заметь, что в этой штуке можно заодно и контроллер флопа развести и эмулятор прямо в него воткнуть. Не понимаю, как ты можешь сопротивляться такому соблазну!
У меня овладевание фпга как-то скрипуче движется :(
Мелькает не из-за "асинхронщины", а потому что правый край растрового эффекта в эмуляторе не попадает между букв, как у тебя. Это ещё вопрос, будет ли он попадать на реальном Векторе. Вопрос о количестве тактов от момента прерывания до появления "луча" на экране (или наоборот) пока открыт.Цитата:
Сообщение от svofski
Это да, вопрос безусловно открыт.. Мы все ждем с замиранием когда Tim0xA прогреет паяльник =)
Количество тактов тут мало чего меняет, в таких пределах это скорее фаза.
Эх, если б растровое прерывание было на произвольную строку, да еще бы процессор был с инструкциями покороче, такого можно было бы навернуть...
Между прочим, если внимательно посмотреть правую границу растрового эффекта, то у тебя она не вылазит за пределы второй буквы (там где они пересекаются), а у меня справа от буквы есть один пиксель эффекта. Однако у меня цвет задаётся для группы из 8 точек, т.е. ширина эффекта у тебя на один пиксель меньше, чем число кратное восьми. Почему?
И это при том, что за один такт выдаются 2 точки (соответственно, за минимальный цикл процессора из 4-х тактов - 8 точек).
Я сам этим вопросом интересуюсь.
Поскольку video_palette_wren (ну и value) -- это регистры, запись в них происходит по clk24. В ОЗУ палитры запись произойдет на один клок позже.Код:always @(posedge clk24) begin
if (iports_write & ~WR_n & cpu_ce) begin
video_palette_value <= DO;
video_palette_wren <= 1'b1;
end
else
video_palette_wren <= 1'b0;
end
Тут интересней paletteram_adr, который в основном равен coloridx и именно от момента перещелкивания coloridx зависит то, куда ж мы запишем реальную цифирь. Тактом раньше -- записали в цвет предыдущего пикселя, тактом позже -- в цвет следующего. Это при том, что отображаться может один и тот же в этот момент.Код:wire [3:0] paletteram_adr = (retrace/*|video_palette_wren*/) ? video_border_index : coloridx;
palette_ram paletteram(paletteram_adr, video_palette_value, clk24, clk24, video_palette_wren, realcolor2buf);
Для храбрых, coloridx берется из модуля video.v и обновляется примерно вот так:
На спаде клока, что занятно. Сейчас трудно сообразить, но скорее всего это означает, что индекс цвета, то есть адрес палитры, обновляется раньше, чем формируется сигнал записи в ОЗУ палитры.Код:reg [3:0] xcoloridx;
wire [3:0] coloridx_modeless;
always @(negedge clk24) begin
if (mode512) begin
if (ce6)
xcoloridx <= {2'b00, coloridx_modeless[2], coloridx_modeless[3]};
else
xcoloridx <= {2'b00, coloridx_modeless[1], coloridx_modeless[0]};
end
else
xcoloridx <= coloridx_modeless;
end
// coloridx is an output port, address of colour in the palette ram
assign coloridx = border ? border_idx : xcoloridx;
Из всего этого я пока делаю вывод, что ширина отрезка от инструкции out $0c до out $0c короче быть вряд ли способна. А вот то, что она все out-ы сдвинуты по фазе "влево" -- это похоже на правду.
К анализу кода приглашаются все желающие, на то он и открытый =)
Нет уж, спасибки :)Цитата:
Сообщение от svofski
Мне, как программисту с солидным стажем, будет трудно осмысливать программу, в которой все операторы выполняются одновременно. Я люблю по-тихоньку, шаг за шагом :rolleyes:
Готовь версию без квазидиска :)Цитата:
Сообщение от svofski
На сколько хватит твоего терпения, я успею поужинать? =)
Да, я пока проверю, как работает команда INR с флагом AC...