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

[zx_]

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


Для ZX Card эмуляцию Спектрума неплохо бы приделать,
по примеру Вектора 06С
у Вектора есть ZX адаптер и к нему программа эмулятор, которую написал -дописал софорумник ivagor
http://zx-pk.ru/threads/18798-emulyator-quot-zx-spectrum-48-quot-na-quot-vektore-06ts-quot.html?p=569030#post569030

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

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

[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" ЕМНИП

[OrionExt]

Боюсь, что командой RET тут не обойтись.

В MSX чтобы управлять всем этим безобразием существует три группы регистров:
регистр слоев (страниц), регистр вторичных слоев (страниц) и четыре регистра для RAM.

На уровне программы межслотовые переходы осуществляются с помощью подпрограмм,
которые строго стандартизированы. Этих подпрограмм там не несколько штук.

Это должно быть некое программно-аппаратное устройство, которое по приходу
сигнала NMI должно включатся в нулевой странице адресного пространства Z80, а дальше:v2_conf2:

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

Чет, какая-та мега штука выходит. Не тянуть же весь мапер памяти MSX.
А там еще версии программ для картриджей существуют, а у них свои маперы.

[Error404]

Никаких мапперов и страниц - это светит аппаратным переделыванием Ориона в МСХ. Интересуют только игры/программы работающие в 64к. Мы им предоставим V9958 и клавиатуру МСХ (совместимую по портам), на этом всё.
Все остальное из ПО (если заинтересует) - дизасм и переписывание под диспетчеры Ориона.

[ivagor]

Значит, для нормальной эмуляции MSX нужно ставить аппаратный детектор выполнения команды Z80, которая будет отключать ОЗУ/ПЗУ обработчика NMI. Допустим, это будет детектор однобайтовой команды RET (0C9h)
Почему бы не retn? Из за ее двухбайтовости? Если возвращаться по ret, тогда придется немного усложнить обработчик, чтобы корректно вернуть состояние iff1 (но это программная часть, т.ч. не так сложно).

Насчет сохранения адреса возврата nmi в регистрах. Это, конечно, не единственный вариант, но действенный и вместе с тем сравнительно простой. В принципе можно и конфиг памяти переключать по nmi, но тогда в идеале под сохранение адреса нужно подключить свободное озу на 64 Кб (т.к. стек может оказаться где угодно) а потом переключиться на страницу с обработчиком nmi - но все это как то слишком заморочено. Хотя можно и так - подменить адреса при сохранении адреса возврата из nmi, чтобы запулить их в заведомо безопасное место. Надо смотреть, что проще, мне на вскидку кажется, что вариант с регистрами.
Хотя можно вобще не заморачиваться и как в эмуляторе Фролова для вектора оставить естественный ход вещей с сохранением на стеке.

Еще один момент, который желательно предусмотреть (есть в адаптере Фролова) - возможность включения/выключения защиты от записи в область 0000-3FFF.

[Error404]

Почему бы не retn? Из за ее двухбайтовости? Если возвращаться по ret, тогда придется немного усложнить обработчик, чтобы корректно вернуть состояние iff1 (но это программная часть, т.ч. не так сложно).


Да. ловушку на однобайтовую команду поставить гораздо проще (считая в количестве корпусов микросхем). На время работы NMI прерывания будут выключены аппаратно портом 0FBh (т.к. он сбрасывается по приходу /NMI), т.е. di/ei делать не надо и iff восстанавливать соответственно - тоже. Плюс подстрахую это доп вентилем работающем от триггера "мы в NMI", который сбросится финальным RET.



Насчет сохранения адреса возврата nmi в регистрах. Это, конечно, не единственный вариант, но действенный и вместе с тем сравнительно простой.

Я просто понять затрудняюсь - от чего имено он защищает? Прерванная программа же сама свой стек не испортит (где ее прервал приход NMI и где сохранен адрес возврата)?



В принципе можно и конфиг памяти переключать по nmi, но тогда в идеале под сохранение адреса нужно подключить свободное озу на 64 Кб (т.к. стек может оказаться где угодно) а потом переключиться на страницу с обработчиком nmi - но все это как то слишком заморочено. Хотя можно и так - подменить адреса при сохранении адреса возврата из nmi, чтобы запулить их в заведомо безопасное место. Надо смотреть, что проще, мне на вскидку кажется, что вариант с регистрами.
Хотя можно вобще не заморачиваться и как в эмуляторе Фролова для вектора оставить естественный ход вещей с сохранением на стеке.


Делать буду так: по приходу NMI в области 0000...1FFF (где у Ориона-ПРО ROM1) аппаратно будет включаться не ROM1, а ОЗУ на 8к (то же самое ОЗУ, из которого будут выдаваться эмулируемые матрицы кнопок по чтению нужных портов MSX/ZX), где будет лежать обработчик NMI (перекодировщик экрана и вычислитель матрицы клавишь). Аппаратно это реализация будет несложная, т.е. все абсолютно одинаково, только ROM1 включается в это окно по /RES, а RAMNMI туда же по /NMI. Первой командой обработчик NMI сохранит указатель стека уже в свое NMI-шное ОЗУ, в него же поставит новое значение SP, туда же push af, push all, затем все вычисления, pop all; ld a,40h; out (0FBh),a; pop af; ld sp,(1FFEh), RET



Еще один момент, который желательно предусмотреть (есть в адаптере Фролова) - возможность включения/выключения защиты от записи в область 0000-3FFF.

Реализуемо, но стоит ли это еще одной резанины на плате?
А что, бывает такое когда программа Спека пишет в область ПЗУ?

[zx_]

правильно ли я понимаю, будет новая ZX Card ? для удобства эмуляции ?
думаю это очень хорошо, ну и AY заодно можно нав на нее , чтобы два раза не вставать

[Error404]

правильно ли я понимаю, будет новая ZX Card ? для удобства эмуляции ?
думаю это очень хорошо, ну и AY заодно можно нав на нее , чтобы два раза не вставать

все что касается эмулятора на NMI пока что обсуждаем в контексте Ориона-ПРО (т.к. нужны реальные частоты проца более 5 МГц). Если на нем взлетит - сориентируемся по скорости и оценим возможность применения этого на 128.
Видео на V9958 возможно будет для обеих платформ (128/ПРО).
В любом случае, чтобы перерабатывать Z80-CARD-II - пока так далеко мысль у меня не заходила. :)
Алсо, в любом случае (даже если обработчик /NMI разместить на плате Z80-CARD-III), тащить туда же AY не нужно, т.к. Z80-CARD ставится до буферов, а AY (особо в универсальной схеме ZX/MSX) даст существенно количество дополнительных входов по небуферированным ШД/ША процессора (там корпусов будет штук 5 минимум да с сороконогим AY - это уже не CARD, а BOARD получается - аэродром какой-то :) )

[OrionExt]

Вы тут заканчивайте Z80 карту – резать, не 90 годы (резать, паять, провода на плате Ориона):v2_cheer:
Есть системный разъем, там аж 96 контактов(кому мало). Добавляем платки на разъем.

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

И с высотками заканчивайте (3 – этаж и т.д) Z80 карта стала 2 – этажом вынужденно, по другому ни как.
А дальше не надо "сим-сити" строить на плате Ориона:)

Вторыми этажами страдали и коммерческие организации. Но там все понятно. Вот платка стоит 16к озу.
Купи 128к и поставь себе (на уровне чайника).

2k век:v2_dizzy_roll:

[ivagor]

На время работы NMI прерывания будут выключены аппаратно портом 0FBh (т.к. он сбрасывается по приходу /NMI), т.е. di/ei делать не надо и iff восстанавливать соответственно - тоже.
? С приходом nmi z80 и так запретит прерывания. iff1 восстанавливать (из iff2) нужно, ведь до прихода nmi прерывания не обязательно были разрешены. retn сделал бы это автоматом, но, конечно, можно написать аналогичный по функционалу фрагмент заканчивающийся ret


Я просто понять затрудняюсь - от чего имено он защищает? Прерванная программа же сама свой стек не испортит (где ее прервал приход NMI и где сохранен адрес возврата)?
Если nmi по обращению к портам, то проблемы маловероятны (но возможны, например как написал b2m). А вот если nmi по времени, то вполне можно встрять в процесс пересылки чего-нибудь стеком и запортить.


А что, бывает такое когда программа Спека пишет в область ПЗУ?
Насколько помню, само штатное пзу спека может писать куда-то в область 0000-1FFF. Вроде это делает калькулятор (портится 5 байт)

[Error404]

? С приходом nmi z80 и так запретит прерывания. iff1 восстанавливать (из iff2) нужно, ведь до прихода nmi прерывания не обязательно были разрешены. retn сделал бы это автоматом, но, конечно, можно написать аналогичный по функционалу фрагмент заканчивающийся ret


значит, напишем код. В ПРО и так полторы сотни микросхем (два с половиной Ориона-128! при сравнимом функционале), да и дополнительные негде монтировать.



Если nmi по обращению к портам, то проблемы маловероятны (но возможны, например как написал b2m). А вот если nmi по времени, то вполне можно встрять в процесс пересылки чего-нибудь стеком и запортить.


Значит, по /NMI должна включаться ОЗУ 64к и сохраняемый на стеке адрес возврата гарантированно попадет в нее, откуда по его значению и адрес возврата взять можно.
Но и тут до бесконечности можно фантазировать на тему "а если стек стоял на адресах, накрывающих обработчик NMI, тогда он разрушится (если он в этой же ОЗУ) и "улетит" при выполнении, и поэтому обработчик NMI надо хранить в третьей ОЗУ, а лучше - ПЗУ, и все это должно включаться гирляндой на разных циклах ЦПУ" и т.д и т.п.

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



Насколько помню, само штатное пзу спека может писать куда-то в область 0000-1FFF. Вроде это делает калькулятор (портится 5 байт)

Такие фрагменты нужно найти и пофиксить в самом ПЗУ (почему они не пофикшены то, полстолетия спустя?). Ибо нефиг. Либо см. выше про "трюкачей выкинуть и забыть". :)
Вот такое у меня ИМХО.

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

В этом смысле, в эмуляторе Спека с доп. ОЗУ можно вообще не заморачиваться и обработчик NMI вообще хранить в общем пространстве - там где в ОЗУ 0..3FFF будет лежать дамп ПЗУ (уж найдется где там втиснуть пару сотен байт).
Вот с MSX, которой надо выдать все 64к ОЗУ, конечно сложнее, тут надо подумать можно ли обойтись без дополнительного хранилища под обработчик NMI.

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

В принципе, у нас же есть на Орионе-ПРО 2 окна ПЗУ: ROM1 (0..1FFF, одна страница по принципу включена/выключена) и ROM2 (2000..3FFF, куча страниц выбираемых портом - 32-ногая ПЗУ до 1Мб размером, еще и платой расширения можно добить до 2Мб). Предполагалось, что по месту ROM1 стоит ПЗУ 573РФ4 (8к, старшие адреса на плате посажены на +5В), но что нам мешает на этом месте вместо уже недоставаемой 573РФ4 использовать (28)27с512 (64к, собственно они то у меня и закуплены в 28-ногую панельку) и добавить порт страниц ПЗУ в окне ROM1, отцепив адресные ноги от +5 и заведя их на порт?

Все равно нужен порт конфигурации эмулятора (я предлагаю 3FFD - он нигде не используется). Тогда в добавляющиеся страницы ROM1 и какие-нибудь страницы ROM2 (8+8=16к) мы запишем ПЗУ и Спека и МSX, и обработчик /NMI, и все это можно будет программно-аппаратно включать/выключать в области 0..3FFF. Останется вопрос нужна ли нам доп. ОЗУ (кроме как для эмуляции матриц клавиатур, т.е. эмуляции чтения с портов) и в какой момент (и куда) ее нужно включать если таки она нужна для обработчика NMI. Т.е. Спек-48 получается эмулировать вполне красиво (правда, придется в его ПЗУ вписать обработчик NMI), а вот по МСХ пока вопросы.

[OrionExt]

Да, еще на карту эмуляции надо порты джойстика MSX добавить.
Или аппаратно, или программно эмулировать, решайте сами.


И вообще, я склоняюсь только к универсальной карте V9958/9938 для Орион-128/Орион-Про.
Если делать эмуляцию клавиатуры, нужно повышать частоту CPU. Это решение возможно пройдет без правки
только для старых игр 16к/32к рассчитанных на TMS9918. Для новых игр без правки кода не обойтись.
Подправить код программы под железо Ориона - клавиатуру, джойстики, звук, диспетчер памяти(тут не все так просто)
не вижу проблем. Основная проблема адаптации программ заключается в совершенно разных подходах
программирования видео-контроллера.
Да и адаптированные программы можно будет запускать на Орионе-128/Орион-Про без проблем.

Ну если уж идти по сложному пути эмуляции предлагаю ознакомится с картой эмуляции приставки Sega Master для MSX.
https://supersoniqs.com/projects/
https://supersoniqs.files.wordpress.com/2010/08/playsoniq-user-manual-v1-3.pdf

[ivagor]

Вот с MSX, которой надо выдать все 64к ОЗУ, конечно сложнее, тут надо подумать можно ли обойтись без дополнительного хранилища под обработчик NMI
Можно (как в imsx) ограничится игрушками, которые не используют 0000-1FFF, тем более там msx bios.

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

[OrionExt]

ОБРАЩАЮ внимания main board MSX!!! Ни кто не дорабатывает.

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

imsx классная штука. Для простых игр MSX.
и выдавать все 64кб, это самые простые программы(игры) или дос-1 версии или касетные. картриджи не всчет.
Вспоминаю был даже такой советский комп, который эмулировал первый биос мсх. Хотя там чип видео стоял от хт.

Кстати интересный факт. MSX-DOS версии 1.хх (MS-DOS) ничего не хочет знать о памяти выше 64к. так и живет себе. Диспетчеры памяти ей не интересны;) Почему MS-DOS? MSX-DOS-1 написал легендарный программист MS-DOS.