ТЕМА:

цитата:
надо внутри модуля speccy искать грамотное место, где низкий уровень ready должен приостанавливать работу.

Судя по всему сигнал нового контроллера READY необходимо подключить к порту WAIT_n процессора, сейчас он висит на 1 и процессор все время работает.

Да, уже подсоединил ready sdram контроллера к WAIT_n и работоспособность ... сохранилась. Было бы больше ясности, если бы без использования WAIT_n, постоянном clock и новом контроллере sdram были бы хоть какие-то проблемы. Видимо не такое уж SDRAM медленное. Может быть с новым контроллером и отдельное внутреннее ОЗУ ПЛИС под видеобуфер не понадобилось бы. Позже проверю.

Про "растаскивание" speccy на части идею понял - попробую.

Кстати, при соединении сигналов ready и WAIT_n опять пошла помеха. Совет про борьбу с помехами через изменение seed в fitter settings помог - спасибо.

Итак, раз после внесенных исправлений и добавок ZX Spectrum заработал как надо, то может быть заменить архив, распространяемый с сайта? Как свой новый его выкладывать будет неверно. Если уж выкладывать, то в бОльшей степени свой, который я собираюсь делать, прислушавшись к советам о разбиении на блоки, видные в визуальном представлении, но написанные на не графических, "словесных" HDL языках все-таки, наверное. Хочу сделать шину, к которой бы подключались блоки с третьим состоянием и потом заниматься увеличением их количества, расширяя функционал.

Еще есть вопрос про модуль ПЗУ - во что компилирует среда предлагаемый HEX файл? В драгоценные логические блоки или в какой-то механизм, хранящий данные во внутреннем ОЗУ ПЛИС, защищенном от записи? Если первый вариант, то можно ли реализовать второй? Короче, я хочу хранить свои данные в конфигурационном флеше.

А пока должен сказать - очень неудобно каждый раз при замене ПЗУ стирать все db среды, чтобы она "заметила" подмену. Есть ли более официальный способ сообщить среде о замене HEX файла?

1. не удастся сделать шину с третьим состоянием внутри плис. Шину придется разбивать на сигналы работающие на ввод и вывод
+ сигналы управления, как это сделано в Т80 с шиной данных. Возможность работы с третьим состоянием относится только к пинам плис.
2.HEX файл размещается во внутреннем озу плис. При синтезе стандартный компонент (мегафункция) lpm_rom берет данные из HEX файла и помещает их в озу плис. Он (компонент) есть в мегавизарде (схемная реализация) + документация как с ней работать. Соответственно данные HEX файла присутствуют и в sof файле при конфигурации плис и в файле прошивки конфигурационного ПЗУ.
Попробуйте поработать со схемным вариантом этой мегафункции, или с компонентом ROM 1-PORT, там замена файла HEX не вызывает затруднений. В последствие можно перейти на какой нибудь язык, мегавизард генерирует соответствующие файлы реализации .v или .vhd.

1. Эх... Ну просто в эйфории нахожусь в связи с освоением новой для меня технологии - простите новичка :) Т.е. получается у меня с увеличением количества узлов, подключенных к шине, будет расти некий мультиплексор? (как это сейчас сделано внутри speccy)? А как тогда устроен сам этот мультиплексор? Всегда как выбор одного сигналов из двух (раз нельзя выходы соединять)? Или, может быть, если я готов гарантировать невозможность выхода "на передачу" двух выходов одновременно, то все-таки их можно соединять вместе?
2. Понял. Ок. Ну, а все-таки, конфигурационную flash, как некое хранилище можно?

1. Да только через мультиплексор (бус-селектор), есть такой стандартный компонент.
2. Конфигурационное ПЗУ можно использовать как хранилище каких то данных, например boot загрузчика для линукс. Но после конфигурорования плис данные окажутся в озу плис
хотя это не обязательно, можно и просто хранить данные как в ПЗУ

2. Ну а что-то более удобоваримое - когда среды разработки уже нет вообще? Т.е. чтобы готовое устройство пользовалось этой памятью и как-то определяло "в куда" можно писать, а "в куда" нет (чтобы не затереть ту область, в которой хранится конфигурация ПЛИС)? Я понимаю, что теоретически это возможно, но может есть стандартный компонент?

Есть стандартный компонент для чтения из конфигурационного ПЗУ EPCS Serial Controller в SOPS builder или Qsys но он для процессора NIOS, так, чтобы отдельно, для любого софт процессора не встречал...
Можно посмотреть проекты "AMBER" или "Linux на NIOS" или другие где запускают линукс на софт процессоре например или поискать инфу о реконфигурации плис "на лету",там эти вопросы обсуждаются.
На мой взгляд для хранения программ спектрума лучше подключить SD-card или использовать дополнительную флеш ПЗУ с последовательным интерфейсом.

Безусловно, если говорить об устройстве, специализирующемся на эмуляции ретрокомпьютеров, то у него должно быть больше разъемов для периферии, включая разъемы джойстиков, тюльпаны под TV, разъем для SD карт и т.д.. Такие разработки уже существуют (ZX-kitы (Speccy2010), MIST, Aeon Lite и т.д.) Я же стараюсь адаптировать их проекты или разработать что-то свое или на основе проекта с этого сайта, что работало бы строго только на "чистом" марсоходе и шилде разъемов. Единственное вмешательство, без которого у меня не получилось обойтись это еще одна "мама" для стереоджека, для входа от магнитофона, который я прилепил на шилд на двухстороннем скотче и подсоединил к входу АЦП. Кстати, если бы на шилде использовался бы разъем под джеки с четыремя (включая землю) контактами (как у гарнитур у смартфонов, т.е. с микрофонным контактом), то мне бы не пришлось извращаться так. Короче, получается, что в качестве накопителя я имею право использовать только USB разъем под готовый картридер или USB флешку.

Про подсказки о компонентах для работы с конфигурационным флешем - спасибо, буду "копать". Это обязательно пригодится и для полезных вещей. Целая энергонезависимая память уже припаяна - грех не использовать. Например, для пользовательских настроек какой-нить железяки.

Еще вопрос чисто по проекту ZX Spectrum этого сайта - сколько мониторов не перепробовал - все показывали картинку с полем картинки в самом верху и у самого края экрана слева. Т.е. как нарисовано в учебной статье Ewgeny7 - без бордюра слева и сверху. Только после нажатия на автоподстройку мониторы соображали и сдвигали картинку к центру. Кто помнит - синхроимпульс должны все-таки идти в строке перед областью сигнала с картинкой или после? В разных найденных мной материалах по-разному нарисовано. В большинстве сказано, что после, но почему тогда так плохо настраиваются на сигнал все мониторы?

Поискал и почитал еще про телевизионные стандарты - наиболее солидные описания на иллюстрациях показывают, что гасящий и синхроимпульс должны идти ПЕРЕД прямым ходом луча. Понятно, что делать наоборот проще - счетчики адреса графической информации являются по совместительству счетчиками для формирования синхроимпульсов. Цена ошибки тоже невелика, особенно для аналоговых приемников - одна строка сверху. Но для цифровых телевизоров и мониторов это плохо.