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

[OrionExt]

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

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

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

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

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

Чет, какая-та мега штука выходит. Не тянуть же весь мапер памяти 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 получается - аэродром какой-то )

[Advertiser]

[OrionExt]

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

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

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

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

2k век

[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....anual-v1-3.pdf