Эмуляторы других платформ в Орионе - программные и аппаратные

[zx_]

Строго говоря, аппаратный эмулятор Спектрума-48 на Орионе был. Т.е. на дополнительных корпусах микросхем. Было два варианта - караваевский, реализованный в ТашкентскомТурбо-2 (Турбо-3 и Турбо4 уже были без него), и Чистяковский (а может он только рассказывал о нем). Но это было реально усложнение - как еще пол-ориона прикрутить, поэтому не пошло в народ.

Для ZX Card эмуляцию Спектрума неплохо бы приделать,
по примеру Вектора 06С
у Вектора есть ZX адаптер и к нему программа эмулятор, которую написал -дописал софорумник ivagor
http://zx-pk.ru/threads/18798-emulya...030#post569030

давно хотел попросить ivagor , адаптировать эмулятор спека для ориона с ZX -Card

было бы здорова

[Advertiser]

[Error404]

мое от 2012года:

Ну, примерно так я и думал:
Жаль конечно, что это не программное решение, которое можно было бы сдернуть, а именно программно-аппаратный эмулятор (аппаратный в существенной мере). На Орионе тоже похожее было, и тоже примерно в дюжине дополнительных микросхем. Но не прижилось как-то, у меня даже доков не осталось.

Там тупо аппаратно эмулируется полспектрума в плате адаптера Z80 (вторая половина - программно на NMI), плюс спектрумовский экран аппаратно реализуется.

У меня есть другая задумка: программный эмулятор спека где экран целиком 25раз в секунду перекодируется по NMI (доработок минимум), а порт клавиатуры перекодируется при помощи дополнительной ОЗУ на 256 байт читающейся по порту FE, а заполняемая матрично по NMI с реальной Орионовской клавы (точно так же клавиатура будет и в эмулятор MSX подсовываться когда созреет плата на 9958, просто по другим портам).
но для этого нужен проц на 8/10 МГц, т.к. эти перекодировщики отъедят до половины ресурса. А такие частоты есть только на ПРО.

[ivagor]

У меня есть другая задумка: программный эмулятор спека где экран целиком 25раз в секунду перекодируется по NMI (доработок минимум), а порт клавиатуры перекодируется при помощи дополнительной ОЗУ на 256 байт читающейся по порту FE, а заполняемая матрично по NMI с реальной Орионовской клавы (точно так же клавиатура будет и в эмулятор MSX подсовываться когда созреет плата на 9958, просто по другим портам).

Имхо вариант Фролова для вектора универсальнее и не такой требовательный к ресурсам (все же переброска экрана требует больше времени, чем опрос клавиатуры) - ч/б экран спека эмулируем аппаратно перепутыванием адресных линий, и NMI по обращению к портам (по крайней мере к части портов). Насчет экрана по сравнению с вектором есть шероховатости - на орионе он был бы не на всю ширину, а с левого или правого края (для 512 точек), да и по вертикали не по центру (т.к. нет аппаратного скролла), но зато "даром" и 50 раз в секунду. Эмулировать цвет на орионе лучше и быстрее, чем на векторе, можно при опросе клавиатуры по NMI (как у Фролова)

[Error404]

Имхо вариант Фролова для вектора универсальнее и не такой требовательный к ресурсам (все же переброска экрана требует больше времени, чем опрос клавиатуры) - ч/б экран спека эмулируем аппаратно перепутыванием адресных линий, и NMI по обращению к портам (по крайней мере к части портов). Насчет экрана по сравнению с вектором есть шероховатости - на орионе он был бы не на всю ширину, а с левого или правого края (для 512 точек), да и по вертикали не по центру (т.к. нет аппаратного скролла), но зато "даром" и 50 раз в секунду. Эмулировать цвет на орионе лучше и быстрее, чем на векторе, можно при опросе клавиатуры по NMI (как у Фролова)

Такой вопрос: эмулируется ли доработанным Вектором режим Спектрума-128?

[ivagor]

эмулируется ли доработанным Вектором режим Спектрума-128?

Нет. В моем хаке эмулятора Фролова сделал только одну фичу 128го - поддержку AY. Дело как минимум в отсутствии аппаратной поддержки переключения страниц памяти по стандарту спека. Ну и второй экран пришлось бы программно эмулировать. На векторе с 3 МГц это не круто, но на про экран и программно покатит.

Кстати, при любом варианте использования nmi (для экрана или портов) желательно сделать как в эмуляторе спека для энтерпрайза - адрес возврата из nmi сохранять не в озу, а в регистрах, доступных через порты.

[Error404]

Кстати, при любом варианте использования nmi (для экрана или портов) желательно сделать как в эмуляторе спека для энтерпрайза - адрес возврата из nmi сохранять не в озу, а в регистрах, доступных через порты.

Кстати, хорошая мысль - хранить адрес обработчика NMI (тот куда надо перейти с начального 66h ибо там ПЗУ и места нет) во внешнем регистре (в моем случае думаю это можно хранить в той же ОЗУ что и эмулятор матрицы клавиатуры - все ОЗУ обычно более емкие чем 256 байт, там достаточно памяти на что угодно, хоть на целый обработчик NMI ). И регистры процессора туда можно сохранить вместо push/pop.

А вот зачем адрес возврата из nmi сохранять там? Он же на стеке и его гарантированно никто не испортит пока не завершится обработчик NMI?

[b2m]

А вот зачем адрес возврата из nmi сохранять там?

Видимо, на тот самый крайний случай, когда SP случайно указывает на ПЗУ
А вообще, SP может указывать на область памяти, где находится обработчик NMI, и доставать байты из под него будет геморойно.

[Error404]

Видимо, на тот самый крайний случай, когда SP случайно указывает на ПЗУ
А вообще, SP может указывать на область памяти, где находится обработчик NMI, и доставать байты из под него будет геморойно.

И что это нам дает? Придется делать выход за пределы обработчика NMI и уже там сначала выключать ПЗУ с обработчиком NMI, и затем делать RET? А этот доп. обработчик класть в ОЗУ где вероятно полезный код прерванного по NMI приложения? Который тоже сохранять (а где?), и как его восстанавливать если мы пришли сюда сделать RET? Какая-то бесконечная рекурсия.

По-другому, надо делать: обработчик NMI весь держать в той же дополнительной ОЗУ или ПЗУ, включающейся по NMI, и аппаратно ловить выполнение команды RETI (упрощая - RET), по которой аппаратно опрокидывать триггер (отключать NMI-ПЗУ). Тогда на момент чтения со стека адреса возврата все в адресном пространстве уже будет в начальном состоянии.

Или ваще не париться на предмет где там был стек. Мы эмулируем СПЕК (MSX), а значит знаем где у них ПЗУ и где гарантированно не будет стека. Там же и обработчик NMI разместить. Со Cпеком тут все просто, у него с 0000 идет ПЗУ. А где ПЗУ у MSX?

- - - Добавлено - - -

Кстати, метод "переодически ставить стек на ПЗУ" (если там реальное ПЗУ с известным кодом куски которого {например найти их поиском} задействовать под адреса возвратов) можно использовать как защиту от гипервизоров, реализованных на NMI: прерванный такой код вообще нигде не сохранит адрес возврата и не будет понятно куда возвращать управление.

[OrionExt]

А где ПЗУ у MSX?

Интересный вопрос, да где угодно может быть ПЗУ.

Вот один из примеров конфигурации памяти у MSX:

- - - Добавлено - - -

Гарантировано при включении только BIOS будет на своем месте (сброс ВВ55),
а дальше в любой момент времени конфигурация видимой для Z80 памяти может быть какой угодно.

[Error404]

Значит, для нормальной эмуляции MSX нужно ставить аппаратный детектор выполнения команды Z80, которая будет отключать ОЗУ/ПЗУ обработчика NMI. Допустим, это будет детектор однобайтовой команды RET (0C9h).
Господа аппаратчики, как делаются такие вещи? Есть готовые примеры?
Ведь, что-то такое делалось для "расширения Z80" на командах типа "ld e,e" ЕМНИП