Реинкарнация Вектор ПК-6128ц

[Serg6845]

всё немного усложняется переводом прошивки РЕ3 в логику на ПЛИС...

там переводить-то нечего...
вот тут например http://forum.pk-fpga.ru/download/file.php?id=491 есть файлик RT5.VHD - прямо готовый пример...

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

Я более чем уверен что то из серии GAL16V8 100% сможет заменить РЕ3. Они и по скорости подойдут, и по стоимости не сильно оттопыриваются, и ко всему они многократно программируемые.

скорее всего да. разве что могут вылезти нюансы если нужен открытый коллектор как у РЕ3.

[Advertiser]

[Improver]

Я более чем уверен что то из серии GAL16V8 100% сможет заменить РЕ3

Я тоже уверен, что подойдут, я даже хотел попробовать, но у меня их в наличии нет, поэтому эксперименты с ними отложил на время, а пока решил сделать на том, что есть. И ещё у меня есть смутное сомнение, что для замены РЕ3 хватит одного корпуса GAL16V8, но это уже технические мелочи.

там переводить-то нечего...
вот тут например <...>

Спасибо, поизучаю и попробую повторить.

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

могут вылезти нюансы если нужен открытый коллектор

Там ОК не нужен, это сделано просто из-за РЕ3.

[Improver]

Вот такая временная замена РЕ3 получилась:

Прошивка для EPM3256

Выполнена на базе "ускоренного" варианта, код на VHDL:

library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity RE3 is
	port
	(
	  address: in std_logic_vector(4 downto 0);
		q: out std_logic_vector(7 downto 0);
		ledin: in std_logic;
		led: out std_logic
	);
end RE3;

architecture behaviour of RE3 is
begin
	process(address, ledin)
	begin
		case address is
			when "00000" => q <= "01111110";
			when "00001" => q <= "01111100";
			when "00010" => q <= "01110100";
			when "00011" => q <= "01110000";
			when "00100" => q <= "01010000";
			when "00101" => q <= "11110100";
			when "00110" => q <= "10110001";
			when "00111" => q <= "11110011";
			when "01000" => q <= "01101111";
			when "01001" => q <= "01101101";
			when "01010" => q <= "01100100";
			when "01011" => q <= "01100000";
			when "01100" => q <= "01100000";
			when "01101" => q <= "01100000";
			when "01110" => q <= "01100000";
			when "01111" => q <= "01100010";
			
			when "10000" => q <= "11101111";
			when "10001" => q <= "11101101";
			when "10010" => q <= "11100100";
			when "10011" => q <= "11100000";
			when "10100" => q <= "11100000";
			when "10101" => q <= "11100000";
			when "10110" => q <= "11100001";
			when "10111" => q <= "11100011";
			when "11000" => q <= "01101111";
			when "11001" => q <= "01101101";
			when "11010" => q <= "01100100";
			when "11011" => q <= "01100000";
			when "11100" => q <= "01100000";
			when "11101" => q <= "01100000";
			when "11110" => q <= "01100001";
			when "11111" => q <= "11100011";
	 		when others => null;
		end case;
		led <= ledin;	
	end process;	

end behaviour;

[свернуть]

Пока что проблем с работой нет -- сигналы формируются хорошо (судя по показаниям осциллографа), память тестируется без ошибок, тест техпрогона запускается...

Эксперименты с GAL отложил в связи с их отсутствием у меня в данный момент.

[Improver]

Небольшой предновогодний отчёт о состоянии проекта:

1. Обнаружена и исправлена досадная ошибка -- на микросхемах D54 и D55 (К155РУ2) были перепутаны адресные входы и входы данных. Причём ошибку допустил ещё при восстановлении схемы ПК-6128ц, а в новоделе не перепроверил. Исправил схемы и тут, и там, перерезал и перепаял 16 дорожек на плате -- изображение есть. Только оно почему-то заметно хуже, чем на оригинальном Векторе с той же CXA2075M -- красного цвета почти нет, всё зелёное... Но радует, что строчные и кадровые синхроимпульсы в идеале.

2. Откорректировал циклы по работе графики в прошивке D10 (К155РЕ3, или в заменяющей её сейчас ПЛИС). На реале оказалось, что расстояние между импульсами FR7 и FR6 должно быть в два раза больше, иначе сигнал с триггера D49 отстаёт на пиксель. В настоящий момент первая половина прошивки выглядит так:

Адр.     0 1 2 3  4 5 6 7  8 9 A B  C D E F
D0(RATO) 0 0 0 0  0 0 1 1  1 1 0 0  0 0 0 0
D1(RAS)  0 0 0 0  0 0 0 0  1 0 0 0  0 0 0 1
D2(CAS)  1 1 0 0  1 1 0 0  1 1 1 0  0 0 0 1
D3(MX1)  1 0 0 0  0 0 0 0  1 1 0 0  0 0 0 1
D4(MX2)  1 1 1 1  1 1 1 1  0 0 0 0  0 0 0 0
D5(FR6)  1 1 0 0  1 1 1 1  1 1 1 1  1 1 1 1 -- чтение первой пары регистров
D6(FR7)  1 1 1 1  1 1 0 0  1 1 1 1  1 1 1 1 -- чтение второй пары регистров
D7(FR1)  0 0 0 0  1 1 1 1  0 0 0 0  0 0 0 0
         ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^
               Экран              ОЗУ

3. Запустил "Тест Устройств", он заработал, но выполнить тест памяти не смог -- выдал ошибку на этапе проверки диспетчера памяти. Анализ работы теста показал, что есть ошибки при обращении к памяти в режиме 023h/032h, это когда по адресам 8000h..FFFFh запись выполняется в Банк 3, а чтение из Банка 2 и наоборот. Причина пока не понятна, продолжаю тесты. Возможно всё решится небольшим сдвигом циклов в прошивке D10 (К155РЕ3).

И ещё: в текущем состоянии (пока на плате не распаяно АУ, нет RTC, нет джойстиков...) потребление по питанию составляет 0,46...0,51А, т.е. пока ещё можно запитать от USB.

[Improver]

Исправил работу с памятью, как я и предполагал, всё решилось выставлением циклов в прошивке D10 (К155РЕ3). Теперь первая половина прошивки выглядит так (полная прошивка выложена на гитхаб):

Адр.     0 1 2 3  4 5 6 7  8 9 A B  C D E F
D0(RATO) 0 0 0 0  0 0 0 0  0 1 1 1  1 0 0 0 -- доступ процессора к памяти
D1(RAS)  0 1 0 0  0 0 0 0  0 1 0 0  0 0 0 0
D2(CAS)  0 1 1 1  0 0 1 0  0 1 1 1  0 0 0 0
D3(MX1)  0 1 1 0  0 0 0 0  0 1 1 0  0 0 0 0 -- 0 = адрес по CAS, 1 = адрес по RAS
D4(MX2)  0 1 1 1  1 1 1 1  1 0 0 0  0 0 0 0 -- ОЗУ / Графика
D5(FR6)  1 1 1 1  0 0 1 1  1 1 1 1  1 1 1 1 -- чтение первой пары регистров (по положительному фронту F6M)
D6(FR7)  1 1 1 1  1 1 1 1  0 0 1 1  1 1 1 1 -- чтение второй пары регистров (по положительному фронту F6M)
D7(FR1)  0 0 0 0  0 0 1 1  1 1 0 0  0 0 0 0 -- 13-й бит адреса (графика) + тактовая частота 750кГц
         ^ ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
                 Экран             ОЗУ

F 6МГц   0 1 0 1  0 1 0 1  0 1 0 1  0 1 0 1 -- тактовая частота генератора
SVNC     1 0 0 1  1 0 0 1  1 0 0 1  1 0 0 1 -- тактовая частота процессора

Больше нет ошибок в ОЗУ. Теперь надо разобраться с изображением...

[Improver]

Очередной этап проекта. Как оказалось, с предыдущим вариантом прошивки "эмулятор РЕ3" на EPM3256 стал очень нестабилен -- реагирует искажениями и пропаданием/появлением изображения при касании щупом осцилографа даже к неподключённым пинам, попробовал заменить на GAL16V8. Из-за того, что у РЕ3 и GAL входы-выходы с разных сторон, пришлось поставить "галку" вверх выводами, получилось вот так:



Сигналы стали заметно лучше, но с GAL есть провал в "0" сигнала FR1 при переходе адреса с хх011 на хх100 (возможно из-за небольшого отставания F1.5M), что приводило также к пропаданию изображения. Для исправления сдвинул прошивку на 4 бита влево:

Адр.     0 1 2 3  4 5 6 7  8 9 A B  C D E F -- совпадает с прошивкой ПК-6128ц
D0(RATO) 0 0 0 0  0 1 1 1  1 0 0 0  0 0 0 0 -- доступ процессора к памяти
D1(RAS)  0 0 0 0  0 1 0 0  0 0 0 0  0 1 0 0
D2(CAS)  0 0 1 0  0 1 1 1  0 0 0 0  0 1 1 1
D3(MX1)  0 0 0 0  0 1 1 0  0 0 0 0  0 1 1 0 -- 0 = адрес по CAS, 1 = адрес по RAS
D4(MX2)  1 1 1 1  1 0 0 0  0 0 0 0  0 1 1 1 -- ОЗУ / Графика
D5(FR6)  0 0 1 1  1 1 1 1  1 1 1 1  1 1 1 1 -- чтение первой пары регистров (по положительному фронту F6M)
D6(FR7)  1 1 1 1  0 0 1 1  1 1 1 1  1 1 1 1 -- чтение второй пары регистров (по положительному фронту F6M)
D7(FR1)  0 0 1 1  1 1 1 1  0 0 0 0  0 0 0 0 -- 13-й бит адреса (графика) + тактовая частота 750кГц
         ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^
            Экран          ОЗУ        Экран

При таком варианте все глюки ушли, все тесты отрабатывают, на касания реакции нет. Кроме того могу отметить, что выравнивание картинки по центру экрана практически идеально, временные задержки синхроимпульсов с этой прошивкой выведены до варианта по схеме megov-а (о чём я делал некое исследование ранее).
Полный вариант прошивки, как обычно, обновлён на гитхабе, прошивка для GAL16V8 с исходниками в этом архиве: GAL16V8_RE3.rar

Теперь о грустном... На изображении крайне скверно выводится красный цвет, на больших площадях он просто пропадает, в результате чего в "Тесте техпрогона", например, фон не жёлтый, а зелёный. Причин тут может быть три, как я думаю:
1. Брак одного из чипов К155РУ2 (хотя, ослик отличий в сигналах на выходах РУшек не показывает),
2. Брак чипа CXA2075m -- китайцы вполне могли прислать некондицию,
3. Непропай, или утечки и просадки на линии красного цвета от ЦАП до CXA2075.

И второй неприятный момент: в тесте ЦПУ (и только там) на фоне проявляются вертикальные почти незаметные полосы:



Причина пока непонятна, надо тестировать всё...

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

Скрытый текст

[свернуть]

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

[ivagor]

И второй неприятный момент: в тесте ЦПУ (и только там) на фоне проявляются вертикальные почти незаметные полосы:

А что это за версия теста? Немного отличается и от 1.1 из комплекта 06Ц и от версии для 6128.
Видно, что полосы на стыках байтов, т.е. или первая точка байта запаздывает или последняя точка заканчивается рано. Можно попробовать этот же цвет фона в бейсике - SCREEN0,0,16

2. Брак чипа CXA2075m -- китайцы вполне могли прислать некондицию,
3. Непропай, или утечки и просадки на линии красного цвета от ЦАП до CXA2075.

Для проверки можно попробовать поменять R и G на входе кодера.

[Improver]

А что это за версия теста? Немного отличается и от 1.1 из комплекта 06Ц и от версии для 6128.

Это я просто стал копать Тест устройств, и попутно его немного модернизировал... Но пока он не готов для выкладывания -- ещё не всё доделано.

Видно, что полосы на стыках байтов, т.е. или первая точка байта запаздывает или последняя точка заканчивается рано.

Не, я сейчас кажется догадался в причинах: там отключённые экранные области для теста заполняются кодом "ADD C" == 081h, и они "просвечивают". Кстати, при стартовой картинке, когда всё рисуется с отключённой палитрой, в реале немного проглядывают контуры фигур и текста, этого нет в эмуляторах. Надо будет проверить тест на реальном Векторе -- там тот же эффект наблюдался, насколько я помню.

Для проверки можно попробовать поменять R и G на входе кодера.

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

[ivagor]

Не, я сейчас кажется догадался в причинах: там отключённые экранные области для теста заполняются кодом "ADD C" == 081h, и они "просвечивают". Кстати, при стартовой картинке, когда всё рисуется с отключённой палитрой, в реале немного проглядывают контуры фигур и текста, этого нет в эмуляторах. Надо будет проверить тест на реальном Векторе -- там тот же эффект наблюдался, насколько я помню.

Да, на векторе эффект "просвечивания" был, но намного слабее, чем на фотографии.

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

Тогда это вряд ли кодер.

[ivagor]

Только сейчас обратил внимание, что яркостный сигнал формируется не резисторами, как в оригинальных 06Ц, .02 и 6128, а кодером. Это приведет к отличию при подключении в чб варианте. Кодер делает оттенки серого примерно 0.6G+0.3R+0.1B, а у 06Ц и .02 свои варианты, причем разные. Для 6128 оттенки серого не считали и не определяли по реалу, но есть подозрение, что они тоже не соответствовали стандартной формуле. Короче говоря, реинкарнированный 6128 не покажет те 16 оттенков серого в подобных программах.