TS-Conf на ReVerSE-U16

[dsp]

Bomber не запускался из за того что (как я понял) рассчитан на частоту вертикальной развертки ~ 49 Hz. Я устанавливал всегда 60 Hz, поэтому DMA не попадало в интервал между прерываниями. Для 49 Hz – запускается. Запускал и на частоте 60 Hz (правда при 60 Hz наблюдается мерцание экрана.) путем запрещения прерывания во время работы DMA. В первом варианте хардверно отключал сигнал прерывания для Z80
t80se модуль: INT_n => cpu0_int_n_TS or dram_req,

Во втором варианте программно запрещал прерывания (DI) для RST 8, потом перед возвратом разрешал снова (zxevo.rom)
org #0000
begin
di
jp main_start

org #0008
jp RST_8

org #0070
RST_8
di
ld bc,#27AF
chk
in (c)
jp p, exit
jr chk
exit
ei
ret

org #0080
main_start

[TS-Labs]

Bomber не запускался из за того что (как я понял) рассчитан на частоту вертикальной развертки ~ 49 Hz.

Да, в нем есть кадровые прерывания, которые на лету переключают режимы. Требует 320 строк в кадре.
На 60фпс - плохая идея его запускать )))

[dsp]

Согласен ))),
но зачем я это все делал - программа не запускалась и у меня была цель убедиться, что проблема не в tv80-arbiter. Хотя может проще было у тебя вначале спросить на счет 60фпс.

[TS-Labs]

Надо было )
Вообще на 60 фпс никакие спектрумские софты нормально работать не будут.
Я думаю единственное решение это делать фреймбуфер, т.е. система работает в 49фпс, данные кладутся в память, а на экран рисуются 60фпс. Но естественно надо писать в буффер не то что в видеопамяти и бордере, а то, что должен рисовать "луч" монитора в этот момент - нужна точная эмуляция луча. Это кстати несложно в ХДЛ. Минусы метода - будут tearing эффекты на экране. Но можно выбрать кратный 2х режим - 97фпс.

[dsp]

Фреймбуфер - я так понимаю, что надо памяти больше 60 kB для этого (как насчет готового устройства GBS-8200).
TS-Labs, у меня вопрос по поводу gfxovr(video_top) провода. Вроде как нет источника сигнала: // wire gfxovr = vconf[3]; - так и должно быть?

[TS-Labs]

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

[MVV]

Фреймбуфер - я так понимаю, что надо памяти больше 60 kB для этого (как насчет готового устройства GBS-8200).

Тогда уже лучше стандартный 640х480@60Hz 256-16777215 цветов с палитрой и производный от него /2 320х240 и не городить велосипед. Пусть то что было, останется таким-же и на том-же железе.

[TS-Labs]

Для буфера достаточно 4 бит, если обычный спек или 8 если ТСконфа. Хотя если в растре дергать палитру то 8 не хватит, надо 16.

[dnik75]

В принципе можно поиграться с разрешением 720x576@50p Hz или 50i Hz. Большая часть мониторов и практически все телеки c hdmi поддерживают их. clock вроде как можно варьировать.
Например http://joco.homeserver.hu/zxpipi/

[MVV]

Другого варианта, чтобы работали спец эффекты вроде как и нет. Jozsef пишет http://joco.homeserver.hu/zxpipi/, что изменил pixel clock = 28MHz (7MHz x 4). Пересчитав частоты, сокращение строк до 624 проблем с работой HDMI телевизоров не вызвало. Придется втискивать, особенно пентагоновский.
Native formats:
Detailed timing #1....... 720x576p at 50Hz (16:9)
Modeline............... "720x576" 27,000 720 732 796 864 576 581 586 625 -hsync -vsync

Ну это как дань совместимости, а как быть с новым графическим режимом?

[TS-Labs]

Новый в смысле совсем новый? На ТСХБ я тестировал 1280х1024 на ВГА мониторе, 108МГц пиксель. Понятно, что если я его использую, придется настрогать видеопроцессор для рисования окон, примитивов, битмапов. Но даже так такой режим непросто обработать по бандвизу памятей. Ну и поскольку я фанат 16:9, то скорее всего 1280х720.

[MVV]

А чего далеко ходить - 720x576p @ 50Hz (280Mbps) он и есть 16:9, только сделать цвет на точку. Производный текстовый от него тоже неплох - 90х36 (символ 8х16). С частотой думать уже ничего не нужно, pixel clock 28MHz. Это даже больше заявленного ранее 640х480 (250Mbps). Ну, а 1280х720 (742Mbps) думаю уже явный перегиб для данной архитектуры TS-Conf и сказано тобой от фонаря, 74.2MHz pixel clock никаким боком . В скобках указано для HDMI. Да и LVDS_E_3R без извратов ограничен на 640Mbps. Если уже рассматривать стандартный режим и 60Hz, то прыгать выше 640х480 неоправданно и ресурсо - накладно .

[TS-Labs]

Ну, я на самом деле не думал про новые разрешения. Так, что да, сказал отфоноря.
720x576p @ 50Hz - это никакой стороной не 16:9, канонично это анаморфик 4:3 (768х576), а не канонично (квадратные пиксели) - 5:4.

[dnik75]

Самое главное 720x576 очень кратен 360x288. В режиме 4:3 вроде лучше смотрится.

[MVV]

Пока TSL занят мечтами о вечном

Варианты:1. Дождаться, когда я портирую конфу на U8. Плюсы: можно будет влет натянуть на U16, кроме того, я хочу не просто портировать влоб, а сразу делать запас для всяческих доработок (мегагерцы, расширенная графика). Минусы метода - долго ждать, хотя процесс идет.2. Помочь в портировании (хотя я помню, что отказался в свое время). Что я бы хотел в плане помощи: перетащить на верилог все модули периферии (которые изначально не на верилоге) - сорри, но на вхдл я хоть и пишу кое-как, но поддерживать сорцы на нем бррр...3. Если особо не стараться, можно просто проэмулировать пентевовскую драму на сдраме. Придется переделать модуль арбитра и рам-контроллера, потому что т80 работает совсем не так, как железный зетник. Минусы: для дальнейшего развития все равно придется делать то, чем я занимаюсь в п.1.

решил столько не ждать, и перенести TS-Conf "в лоб" на U8. Пока то, что есть. Автор сей конфигурации, при желании сделал бы это за пару дней... За основу взял порт от dsp. Стопорнулся на 16bit шине. Для U16 проблем немного, но для U8 придется возвращаться к 8bit. Уж больно костылей в TS-Conf наставлено...

[TS-Labs]

Костыли все проистекают из теплой ламповости железа пентевы, и лучше там не сделать. Unless автор научит как

[TS-Labs]

решил столько не ждать, и перенести TS-Conf "в лоб" на U8

Спасибо!

[MVV]

Проверил работу HDMI 720x576p @ 50Hz. Теперь видео эффекты типа multicolor должны работать.

[dsp]

Добавил небольшое описание с картинками моих костылей в проекте ))), чтобы было проще разобраться всем желающим, надеюсь это поможет и в портировании на 8bit SDRAM.

[dnik75]

Ура!!! Главное процесс идёт

[dsp]

Для SDRAM 8bit (использовал 16bit SDRAM D0-D7, DQMH <= '1'; шина адреса A22 не используется) протестировал в режиме BURST mode. Записываю и считываю 16bit за два раза – младший потом старший Byte. В приведенном примере – все работает (сначала записываю младший байт в D0-7 SDRAM потом старший байт в D0-7 SDRAM). По времени проблем нет.
Использовал этот файл в TWARM проекте. TS- Conf - запускается. Длительность периода чтения/записи в SDARM возросла приблизительно на 10ns в сравнении с SDRAM 16 bit.

[MVV]

Пересобрал для U8. Пока сходу не удалось запустить, пришлось добавил цветные маркеры на бордюр для отслеживания работы загрузчика. Останавливается с зеленым бордюром - нет возврата CALL с драйвера SD. Буду разбирать два варианта - подключение SD и SDRAM. Текущие исходники доступны в репозитарии.

[dsp]

Скачал файл TWARM.vhd для U8. Начал заменять исходный файл на скачанный (по частям). Перешел на одну SD карту(как в U8) - все грузится. Скопирую SDRAM 8Bit модуль и попробую запустить

[TS-Labs]

[dsp]

SDRAM_DQM заземлен в U8
в проекте:
SE4: entity work.sdram
port map (
DQML => open,--SDRAM_DQML,

если я подключаю эту ножку к модулю SDRAM - то работает, если заземляю то красный бордюр. Вроде в U9 SDRAM_DQM подключен к 42 ножке.