Chaos Constructions 2009

[svofski]

Да тут вообще звезды в твою сторону поворачиваются. И пикад у тебя и Вектор у тебя и опыт работы с SIMM-ами у тебя. Заметь, что в этой штуке можно заодно и контроллер флопа развести и эмулятор прямо в него воткнуть. Не понимаю, как ты можешь сопротивляться такому соблазну!

[tnt23]

У меня овладевание фпга как-то скрипуче движется

[b2m]

а b2m показывает в общем прилично, но разводит недопустимую асинхронщину из-за чего все мельтешит

Мелькает не из-за "асинхронщины", а потому что правый край растрового эффекта в эмуляторе не попадает между букв, как у тебя. Это ещё вопрос, будет ли он попадать на реальном Векторе. Вопрос о количестве тактов от момента прерывания до появления "луча" на экране (или наоборот) пока открыт.

[svofski]

Это да, вопрос безусловно открыт.. Мы все ждем с замиранием когда Tim0xA прогреет паяльник =)

Количество тактов тут мало чего меняет, в таких пределах это скорее фаза.

Эх, если б растровое прерывание было на произвольную строку, да еще бы процессор был с инструкциями покороче, такого можно было бы навернуть...

[b2m]

Между прочим, если внимательно посмотреть правую границу растрового эффекта, то у тебя она не вылазит за пределы второй буквы (там где они пересекаются), а у меня справа от буквы есть один пиксель эффекта. Однако у меня цвет задаётся для группы из 8 точек, т.е. ширина эффекта у тебя на один пиксель меньше, чем число кратное восьми. Почему?

И это при том, что за один такт выдаются 2 точки (соответственно, за минимальный цикл процессора из 4-х тактов - 8 точек).

[svofski]

Я сам этим вопросом интересуюсь.

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

Поскольку video_palette_wren (ну и value) -- это регистры, запись в них происходит по clk24. В ОЗУ палитры запись произойдет на один клок позже.

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);

Тут интересней paletteram_adr, который в основном равен coloridx и именно от момента перещелкивания coloridx зависит то, куда ж мы запишем реальную цифирь. Тактом раньше -- записали в цвет предыдущего пикселя, тактом позже -- в цвет следующего. Это при том, что отображаться может один и тот же в этот момент.

Для храбрых, 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-ы сдвинуты по фазе "влево" -- это похоже на правду.

К анализу кода приглашаются все желающие, на то он и открытый =)

[Advertiser]

[b2m]

К анализу кода приглашаются все желающие, на то он и открытый =)

Нет уж, спасибки
Мне, как программисту с солидным стажем, будет трудно осмысливать программу, в которой все операторы выполняются одновременно. Я люблю по-тихоньку, шаг за шагом

[Tim0xA]

Мы все ждем с замиранием когда Tim0xA прогреет паяльник

Готовь версию без квазидиска

[svofski]

На сколько хватит твоего терпения, я успею поужинать? =)

[Tim0xA]

Да, я пока проверю, как работает команда INR с флагом AC...