DivGMX

[NEO SPECTRUMAN]

Это все хорошо НО!!!
где поддержка самого GMX ???
http://speccy.info/GMX

3Ы: тему не читал

[Advertiser]

[Lethargeek]

Устройство может работать самостоятельно как Спектрум, это так, но основное его предназначение куда более интереснее и универсальней за счет новых конфигураций. Да, может быть подключено не только к Спектруму. Назначение DivGMX я описал в начале этой темы.

У меня по мотивам обсуждения концепций такой вопрос: а каков запас по быстродействию "после Спектрума" и при подключении к реальному Спектруму? То есть, сколько байт своего ОЗУ девайс сможет прочитать или записать (в режиме произвольного доступа) в одном стандартном спектрумовском такте @3,5мгц?

[vlad]

Если теоритически, рассматриваем оригинальный Спектрум на базе DRAM 70..100ns, то где-то 4 байта за такт. С моих соображений для работы с видео буфером на DivGMX, в ПДП нет необходимости, т.к. видео область проицируется сразу на внутреннюю память DivGMX. Доступ к памяти DivGMX при необходимости проще организовать из области ПЗУ.

[Lethargeek]

Если теоритически, рассматриваем оригинальный Спектрум на базе DRAM 70..100ns, то где-то 4 байта за такт. С моих соображений для работы с видео буфером на DivGMX, в ПДП нет необходимости, т.к. видео область проицируется сразу на внутреннюю память DivGMX. Доступ к памяти DivGMX при необходимости проще организовать из области ПЗУ.

Эээ, при чём тут память самого Спектрума и его доступ к памяти DivGMX? Я спросил про достижимую скорость random access между указанными в спецификациях "ПЛИС Altera Cyclone III EP3C5/EP3C10 или Cyclone IV EP4CE6/EP4CE10" и "SDRAM 4/8/16/32MB х 8 bit" в свободное время, остающееся от эмуляции Спектрума (если эмулируется внутри) и поддержки/эмуляции остальных устройств. Не для передачи данных на Спек или от него, а для внутренних нужд гипотетического графического движка.

[vlad]

Ну так бы и спрашивали. Заявленное время от active до active у SDRAM tRC = 66ns. Если Спектрум эмулируется внутри на 3.5MHz, то в запасе еще остается 219ns - 3 случайных доступа к SDRAM (читаем/пишем 3 байта) и это без умного контроллера памяти, который не использует кэш и бурст.

[Lethargeek]

вполне хватит даже для разворачивания 640х480@60Hz 8bpp. Просто это уже давно работает (сделано 3 года назад), и притом на новом проце @42MHz, хз почему это никому не интересно.

Потому что снова получился "неспектрум", поддержать который новым софтом для спектрумиста непосильно, неспортивно, невыгодно (не в деньгах - в количестве потребителей). Лично мне был бы интересен режим 352x288@50Hz 16bpp (+ время на служебные операции) как база для раскраски игр стандартного Спека. Восьмибитность шины, правда, не радует. Хотя, впритык (при 8bpp) может, и потянет что-то в духе упомянутого в "концепциях"

[vlad]

Lethargeek, если что и способно сейчас творчески развиться, так это мульти-платформенная конфигурация ts-conf, остальное всё насколько протухло, что трогать это стало реально крайне опасно даже для программиста или железячника, что тут уже говорить о простом пользователе.
Что мне сейчас интересно, это закончить разработку двухпроцессорной ts-conf и сделать возможным развёртывание на ней операционной системы.

[Lethargeek]

vlad, ts-conf это антиспектрум со своими спрайтами аппаратными; как и прочие не похожие на классику "улучшения", для спектрумиста дела не улучшает, а фактически предлагает новый несовместимый комп с ничтожной пользовательской базой, для которого софт нужно писать с нуля (или адаптировать существующий с приложением аналогичных больших усилий)

[vlad]

Lethargeek, так в этом весь и интерес, иначе зачем вообще что-то делать?

[Lethargeek]

Lethargeek, так в этом весь и интерес,

"весь интерес" для железячника - может быть, но почему-то программистам интересней писать под классику

иначе зачем вообще что-то делать?

почему бы наконец не сделать "что-то" такое, что легко поддерживать спектрумисту?

кстати, вот пример эксперимента в правильном направлении: