b2m, в сорцах твоей реализации РК на DE1 лежит SDRAM_Controller.v, но он, насколько я понял, не используется. Файлик случайно туда попал или у тебя есть версия РК использующая SDRAM?
Вид для печати
b2m, в сорцах твоей реализации РК на DE1 лежит SDRAM_Controller.v, но он, насколько я понял, не используется. Файлик случайно туда попал или у тебя есть версия РК использующая SDRAM?
Файлик попал случайно, но версия, использующая SDRAM была (временно), и вроде даже работала без сбоев.
Не, не осталось, я прямо в рабочем проекте попробовал, потом убрал. Слишком уж простой контроллер, на чтение/запись уходит много тактов. Для РК не критично, он всё равно 1 такт работает, 24 простаивает. А для реального применения - малопригодно.
ivagor, у меня в амижном проекте SDRAM контроллер вполне работающий
https://code.google.com/p/z3sdram/so...m_controller.v
Выглядит страшновато, но на самом деле он хороший :)
tnt23, спасибо, но для меня это слишком страшновато. b2mу спасибо за случайно забытый контроллер, он у меня даже почти заработал.
Несколько стыдно рассказывать, но я попробую. На данный момент затыка в доступе к SDRAMине по чтению проца и видео.
Если процу не давать читать
.rd(vid_rd),
то изображение нормальное.
Если ему дать читать
.rd(vid_rd ? 1'b1 : cpu_rd&(!addrbus[15])),
то изображение скачет. Тем не менее, можно разобрать, что на директивы монитора реагирует. Например заполнил область значением, потом вывел дамп - все работает как должно.
Ты мой проект что-ли копаешь? Я думал что-то своё мастыришь.
А я, кстати, только первые 16Кб на SDRAM подменял, т.к. в процессе отладки хотелось, что-бы РК-шка работала, а там уже в мониторе смотреть, как SDRAM выглядит. Поэтому у меня таких проблем не было.
Тут надо синхронизацию переделывать, а то процессор 1 раз в примерно 25 тактов обращается, а видео - ровно 1 раз в 24 такта. И эти обращения никак не синхронизированы. Надо скорректировать запросы путём задержки, пока они не попадут в своё "окно". Точнее, достаточно cpu_ce задерживать, если было обращение от видео.
Если еще буду копать, то оставлю нижние 16 Кб в SDRAM, а верхние надо затолкать в ПЛИС, у меня уже сегодня такая мысль появлялась. А до этого думал РК до 16 Кб урезать и все ОЗУ в ПЛИСине.
Так и сделал, вроде работает (директивами монитора пишет и читает, ксоникс немного погонял). Пользуясь случаем, хочу передать большой фак уроду из терасик, который решил ставить на новые DE1 уродские SRAM IS61WV25616EDBLL
---------- Post added at 01:12 ---------- Previous post was at 00:29 ----------
Вопрос про spiton.gam (идет в комплекте с emu) - в emu он показывает заставку, а на DE1 - нет. Это я что-то поломал или так и было? Сама игрушка работает, контрольная сумма при чтении совпала.
---------- Post added at 01:25 ---------- Previous post was at 01:12 ----------
С питоном разобрался. Не знал, что на РК были игрушки, которые меняли адрес экранной области.
Не стреляйте в пианиста, он играет как умеет. :)
Просто времянки надо в проекте учитывать. Ты бы лучше попытался разобраться, как заставить работать SRAM. Времени-то там дофига, процессору вообще по барабану, что память чуть медленнее, он всё равно за 3 цикла (по 25 тактов) читает/пишет. А вот в ВТ57 можно попытаться добавить ещё 1-2 состояния, чтобы запрос на чтение на 1-2 такта дольше был.
Лучше, но сложнее.
---------- Post added at 10:00 ---------- Previous post was at 09:28 ----------
Экспресс-тест по допустимой частоте cpu_ce в текущем состоянии. Только я немного переделал
"Тестировал" в мониторе, заполняя соответственно 4000,40FF и 0,FF значениями 00,55,AA,FF и потом смотрел дамп.Код:reg cpu_ce2;
wire cpu_ce = cpu_ce2;
always @(posedge clk50mhz) begin
//internal ram (cpu and video) works fine with cpu_cnt!=3
//sdram (cpu) works fine with cpu_cnt!=9
if(cpu_cnt!=9) begin cpu_cnt <= cpu_cnt + 11'd1; cpu_ce2<=0; end
else begin cpu_cnt<=0; cpu_ce2<=1; end
startup <= reset|(startup&~addrbus[15]);
end
---------- Post added at 11:43 ---------- Previous post was at 10:00 ----------
Вроде и SRAM нормально заработал, по крайней мере монитором, ксониксом и супер питоном проверку проходит. Взял все тот же контроллер SDRAM (очень вдохновляющий пример, b2m - еще раз спасибо) и сократил до двух состояний (читал про такое на форуме минимига, но не мог нормально сделать)
1. первый такт выставляем адрес и управляющие сигналы
2. второй такт - еще и читаем или пишем.
Только это вариант с раздельным доступом, переделанный из SDRAM, т.е. SRAM по адресам 0-3FFF и обращается к ней только проц.
Надо бы еще наверно что-то вроде теста ОЗУ наваять, но очень похоже, что все работает.
А если взять мой проект, и просто перенести 4000-7FFF внутрь ПЛИС, то ведь тоже должно работать? Тогда ведь к SRAM будет только процессор обращаться, а он делает это достаточно долго.
Я вот думаю, если HOLD/HLDA номально реализовать, в том числе и в процессоре, то должно работать даже с памятью, которая хоть в 10 раз медленнее. Т.е. проблема не в железе, а в исходниках проекта. Другое дело, что мой проект не единственный, который рассчитывает на быструю SRAM. Ты пробовал запускать Вектор,БК,Корвет,MSX?
Я так и сделал :) Как раз это позволило мне спокойно организовать работу с SDRAM а потом со SRAM по адресам 0000-3FFF. Меня только одно смущает - неужели я так невнятно пишу, что даже ты не понял :)
Твой проект как раз в том ряду, который полагается на простой доступ к SRAM и не работает на новых DE1 с той самой "новой" SRAM (формальные отличия во времянках небольшие, сам я думаю, что основная проблема в том, что она с ECC). Проблемы с этой сраминой не только у меня, читал про это и на буржуинских форумах. Не работают вектор (я долго доставал svofski на эту тему), БК, спектрум, Б2М. Вернее степень неработоспособности разная - что-то вобще не работает, что-то частично работает. MSX завелся с полоборота, т.к. использует SDRAM.
Т.е. РК - это второй ретрокомп, который у меня заработал (но только после доработки напильником).
Про это я ничего сейчас не могу сказать. Четкий доступ к моей SRAMине, как я уже написал, получился после разделения обращения на 2 этапа - в первом такте выставляем адрес и управляющие сигналы, во втором читаем или пишем. Т.е. проблема, конечно, не в скорости, а в том, что нужно все делать аккуратно.
Я имел ввиду: не трогать ту часть, которая работает с SRAM (ты, как я понял, дополнительный контроллер для SRAM сделал). Только добавить новое устройство по адресам 4000-7FFF вместо SRAM.
Чтение по-любому обычно так и делается. А вот при записи надо бы откладывать сигнал активации записи на второй такт и снимать его в третьем, т.к. SRAM тут асинхронный, и если сигнал записи прийдёт раньше чем изменится шина адреса, то запись произойдёт не туда, куда надо.
Другой вариант: попробуй ничего не менять, кроме одного - простробировать сигнал записи глобальным клоком:
SRAM_WE_N будет полклока в длинну (надеюсь его хватит), и будет активироваться через полклока после того, как всё остальное начнёт меняться.Код:assign SRAM_WE_N = vid_rd|cpu_wr_n|addrbus[15]|hlda|clk50mhz;
А, так я тоже делал. Оно частично работает, но все равно сбоит.
Так почему же практически везде не так? Читал, что в последних версиях минимига так стало, а еще где?
Сначала я сделал доступ к SRAM в три такта
1. выставляем адрес, WE_N и OE_N =1
2. и 3. как уже написал выше.
Так заработало, но раз заработало и с двумя (без п.1.), я пока с двумя и оставлю. Может при 100 МГц или более пришлось бы в 3 такта.
К сожалению это не сработало, как и много других "простых" вариантов, которые я пробовал с v06cc и rk
---------- Post added at 21:14 ---------- Previous post was at 20:53 ----------
Кстати, еще могу немного сказать на эту тему. В v06cc отключал видео, оставляя доступ только проца - не заработало. Контролировал по наличию звука и миганию светодиода (полученные с использованием неодобренного svofski вудуизма почти рабочие версии v06cc кое-что могут запускать и с видео и со звуком).
В смысле и без ОЗУ внутри ПЛИС? Наверняка будет, только пока непонятно, кто ее первым сделает :) Сегодня я без DE1, надумал многаидей, завтра может хоть что-то заработает. Правда у меня SDRAM сейчас не на первом месте.
По поводу исходников - в соответствии с моими нулевыми знаниями и мои вставки в исходники b2m или очевидные или непотребные. Тем не менее, если неожиданно "полный SDRAM" заработает, то я, наверно, ключевой фрагмент прямо сюда запощу, или ссылку на него.
Тогда такой вариант уже есть, но при модификации исходника b2m мозг я практически не использовал:
1. С помощью визарда создал блок двухпортового ОЗУ в ПЛИСине. Прописал обращение в головном файле по адресам 4000-7FFF. Один порт - читает видеоконтроллер, второй - читает и пишет проц. Уже можно запустить и проверить работу директив монитора.
2. Прописал обращение к контроллеру SDRAM, забытому b2mом, по адресам 0000-3FFF. Доступ имеет только проц. Это несколько уменьшает совместимость, т.к. есть программы, которые меняют адрес ВидеоОЗУ в первую половину. Но вроде их мало.
Про "полный SDRAM" напишу, если получится. Если b2m или кто-то еще сделает раньше - с интересом посмотрю.
-10TLI, это я по памяти
У меня тоже 10нс.
но у тебя наверно 61LV25616AL
Угу.
zebest, поздравляю!
Побаловался СпиналТапом, основные моменты стали понятны, но запустить стабильный SDRAM only так и не смог.
Также спиналтап помог увидеть, что доступ к SRAM (в проекте SRAM+internal RAM) у меня реально не 2 такта, а группами по несколько доступов по 2 такта, т.к. сигналы чтения и записи от процессора длинные. Этот странный вариант работает хорошо.
Попытался организовать другой контроллер, который читал или писал бы один раз на каждое обращение проца. По спиналтапу все ОК, а стабильной работы не получается.
Как я уже писал (а потом стер) - пошел по пути наименьшего сопротивления и переделал SDRAM_Controller.v в SRAM_Controller.v
Убрал рефреш и еще пару состояний, в итоге чтение и запись стали по 4 такта (думаю, это не предел, но пока меньше просто не пробовал).
Теперь работают варианты РК:
1. SRAM [0-3FFF]+internal RAM [4000-7FFF], но он и раньше с моим самопальным "контроллером SRAM" работал.
2. Гораздо более интересный вариант SRAM [0-7FFF]+SDRAM [0-7FFF]. В SRAM пишет процессор, а читает только видео (причем, если надо, и из адресов 0000-3FFF тоже, т.е., например SPITON показывает "картинку" при старте, в отличие от п.1). К SDRAM имеет доступ только процессор. Наверно по такому принципу можно и другие компы под мою хитрую DE1 переделать.
b2m, если не сложно, запусти вот этот тестик. В покореженных мною вариантах между прогонами гаснет экран, а как в твоем оригинальном варианте? В emu экран не гаснет.
Еще познавательный вопрос, не относящийся к реализации в ПЛИС. xonix, приложенный к эмулятору, показывает 30 строк. Если по 10 точек, то это 300 ТВ линий, не многовато ли? Насколько помню, по стандарту не более 288 активных строк.
Пока не смогу, доступа к DE1 нет.
Я не помню точно, но вроде бы по стандарту кадровый СИ должен быть не менее 5%, для 312 линий это 15-16. А тут всего 12, но вполне возможно, что нехватка 3-х линий была не страшна и 99% телевизоров нормально синхронизировали кадры.
---------- Post added at 21:21 ---------- Previous post was at 21:17 ----------
Вроде в интернете пишут - для КСИ 2,5 линии достаточно.
---------- Post added at 21:23 ---------- Previous post was at 21:21 ----------
Верхнее и нижнее поле - минимум 25 линий. Их роль выполняют пустые строки.
У меня DE1 подключена к ТВ/монитору с VGAшным входом, так он не показывал все строки, пока в rk_video.v не поменял 625 на 660. Частота кадров, конечно, немного уменьшилась, но все равно для РК это ни на что не влияет.
Может ли быть активен hlda не во время чтения группы символов для видеоконтроллера?
Если это вопрос по оригинальной схемотехнике 86РК, то скорее всего - нет. hlda активируется по окончании цикла в ответ на присутствие hold, а тот, в свою очередь, генерируется только контроллером ПДП.
Нет, если конечно настроить ВТ57 на чтение или запись по каналу 0 или 1, то hold активируется, но какой в этом смысл?
---------- Post added at 16:06 ---------- Previous post was at 16:05 ----------
А вот нет, фиг вам, drq для других каналов заземлены.
Вопрос был по реализации РК на ПЛИСе.
Т.е., если я правильно понял, в текущей плисовой реализации hlda активизируется только на время чтения группы символов видеоконтроллером.
b2m, вопросы по твоей реализации ВМ80.
Насколько я понял cpu_rd и cpu_wr_n длятся "от ce до ce".
Чтение происходит по заднему фронту cpu_rd?
При записи в каком такте выставляются данные?
Если ce=1, то переходим к следующему такту, иначе просто ждём. Таким образом можно задавать любую частоту процессора при фиксированном системном клоке.
Да, cpu_rd=1 только во втором такте, в третьем такте оно снимается, одновременно фиксируются входные данные.
В первом такте выставляется слово состояния, в циклах записи данные выставляются во втором такте и остаются до следующего первого такта. Одновременно с выдачей данных во втором такте устанавливается cpu_wr_n=0, которое снимается в третьем такте.
Основная проблема: когда видеовывод читает SRAM во втором такте цикла записи, то сигнал записи и адрес меняются одновременно, что приводит к глюкам. Чтение со стороны видеопроцессора должно быть таким:
1. деактивируем сигнал записи от процессора
2. переключаем шину адреса на свою
3. защёлкиваем данные и переключаем шину адреса обратно
4. возвращаем сигнал записи от процессора