ЮТ-88: Реализация на ПЛИС (uХ_Reverse)

[Ewgeny7]

Вот исходники и файлы конфигурации "ЮТ-88" для девборды u10.
Реализован "ЮТ-88" 64кб ОЗУ, Монитор-F, клавиатура PS/2, магнитофонный интерфейс, звук (биппер).
Частота процессора - 1.75 Мгц (практически как в оригинале).
Также прилеплен простой РОМдиск с двумя программами - "BASIC Микро-80" и "Тетрис".
Порядок работы с диском - кнопкой F10 "проецируем" диск на область памяти 0000-3FFF, затем директивой Т монитора копируем кусок диска в ОЗУ, затем кнопкой F11 "выключаем" ромдиск.

Для копирования бейсика делаем:
Т0,1FFF,0

для тетриса:
Т2000,2666,3000

Далее запускаем программы директивой G. (бейсик - G0, тетрис - G3000).

Исходники не "причесывал", ибо нафик нуно. Но там и так относительный порядок

Да, спасибо b2m за сырки К580ВМ80А

[Advertiser]

[b2m]

Прикольно. Я думал что на третьем циклоне будет значительно меньше LE расходоваться. Ан нет, процессор - 887 LE, хотя на втором не намного больше (где-то 905-910 в зависимости от обвязки).

И ещё, всегда неприятно удивляет, что клава расходует столько много LE (253 в данном случае, у меня в b2m не намного меньше). Никто не знает, как можно уменьшить её, кроме как засунуть таблицу перекодировки в M4K блок? А то она больше чем вся остальная обвязка

[Ewgeny7]

как можно уменьшить её

Ну, если только засунуть ее в ПЗУ (как ты и предложил). Только это ограничит нажатия до одной кнопки в один момент времени. Не стоит это экономии ячеек... ПЛИСы для наших целей и так достаточно жирные чтобы не экономить.

---------- Post added at 12:57 ---------- Previous post was at 12:56 ----------

Ан нет, процессор - 887 LE, хотя на втором не намного больше (где-то 905-910 в зависимости от обвязки).

Z80 кушает 2000LE, так что вроде расход оказывается вполне предсказуем.

[vlad]

Никто не знает, как можно уменьшить её, кроме как засунуть таблицу перекодировки в M4K блок?

Уменьшить можно, если её обработку полностью повесить на проц, чем то ведь все равно придется жертвовать, ищите компромисс...

[b2m]

Уменьшить можно, если её обработку полностью повесить на проц, чем то ведь все равно придется жертвовать, ищите компромисс...

Проблема в том, что всякие игрушки обычно работают напрямую с железом, и с клавиатурой тоже. Создание патча на каждую игру - не выход.

[svofski]

Если процессор работает на частоте около 1.75МГц, а его настоящий предел скорее всего около 25-50, у него есть время выполнять задачи, не требующие бешеной скорости, такие, как обработка клавиатуры. Надо только подпатчить процессор, чтобы упростить переключение контекста.

[vlad]

Если процессор работает на частоте около 1.75МГц, а его настоящий предел скорее всего около 25-50, у него есть время выполнять задачи, не требующие бешеной скорости, такие, как обработка клавиатуры. Надо только подпатчить процессор, чтобы упростить переключение контекста.

Оно то так Только с одной стороны, это будет уже не реплика ЮТ-88, а проц не ВМ80, а с другой, делать все это некому и не для кого... Так, что лучше оставить все как есть... Главное, есть начало, а допиливание уже дело времени и желания...

[b2m]

Надо только подпатчить процессор, чтобы упростить переключение контекста.

Второй процессор в том-же адресном пространстве?
Распределение памяти тоже надо патчить.

Но вообще, с клавиатурой бывает не всё так просто. Порт, из которого читается состояние клавиш, должен очень быстро отреагировать на изменение порта, в который пишется маска рядов. Такое возможно, только если заранее подготовить в памяти все возможные соответствия маска->состояние, а порт клавиатуры будет своеобразным доступом к этой памяти. Однако возможны неадекватные реакции программ, когда после нажатия клавиши ещё не вся таблица соответствий скорректирована.

---------- Post added at 16:42 ---------- Previous post was at 16:38 ----------

Оптимальный вариант, это когда матрица реализована на HDL, а перекодировкой и установкой регистров на пересечении строк и столбцов матрицы занимается другой, медленный процессор.

Вот только будет ли выигрыш в количестве ячеек?

[svofski]

Про "проц не ВМ80", он и так не ВМ80 уже по определению. Ничего страшного в таких изменениях нет. Наоборот, в этом весь интерес. Потом, нечто подобное можно было сделать и с железным ВМ80. Уверен, что были какие-нибудь хардверные отладчики, которые подпихивали банки памяти целиком на ходу.

Второй процессор в том-же адресном пространстве?
Распределение памяти тоже надо патчить.

Скорее наоборот, один процессор перекидывать между разными адресными пространствами. В основном нужно менять распределение памяти: в процессоре можно было бы вообще ничего не подкручивать, но проще если у него будет железная поддержка двух контекстов: тогда можно вообще хоть по очереди инструкции исполнять в двух адресных пространствах.

У меня в БК сделано что-то отдаленно похожее: она сама себя вытягивает за волосы: подгружает себе ПЗУ-шки с SD-карты, работает с FAT-ом и загружает BIN-ы с той же SD-"кассеты", при этом для все это происходит прозрачно для основной программы. Но там не нужно было переключать контекст часто. Здесь будет немного другая задача, зато решив ее можно будет еще много чего сделать почти не расходуя лишние ячейки.

Оптимальный вариант, это когда матрица реализована на HDL, а перекодировкой и установкой регистров на пересечении строк и столбцов матрицы занимается другой, медленный процессор.

+1 этому.

[Ewgeny7]

А по-моему эти свистопляски с процессором - просто спорт ради спорта. Городить непонятно что ради 50-100 ячеек... Дело ваше. Мне больше нравится когда симулятор поближе к реалу.

---------- Post added at 12:35 ---------- Previous post was at 12:21 ----------

Привинтил я квазидиск на 256Мб. Добавил в ромдиск СР/М 64 и ОС ЮТ-88. Поигрался в этот глюкодром. СиПиэМка работает, только без дисковода толку от нее негусто. Чисто букаффки на экране посмотреть. ОСь_ЮТ глючная до безобразия, на половине директив виснет. Или это я просто такой кривой бинарник нашел???