Абсолютно верно. Я думаю надо что-то в таком роде:Сообщение от SMT
Функции 0..#3f - общие для всех эмулей, типа управления скоростью, растактовки, модели памяти, etc
Функции #40..#4f - специфические фичи US
Функции #50..#5f - специфические фичи EMUZWIN
и т.д.
Что-бы было с чего начать, давайтe сделаем функцию №0, управление скоростью эмулятора, где 0..250 - скорость Z80 в процентах от "стандартной", 255 - максимально возможная.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Давайте ED 00 - ED 3F не трогать, а (или наоборот ED C0 - ED FF, но там уже все равно SLT Trap, он вроде как стандарт де-факто)? Тем более что в каком-то древнем эмуле ED 00 - ED 3F они были под завязку. Вообще надо задействовать меньше поменьше "трапов". Номер функции можно передавать например в A, доп. параметры если надо в DC, DE, HL, так же и на выходе если надо что-то получать. Тогда в этом смысле ED FF - проверка наличия фичи, а ED FE - функции (номер в A - можно и те же номера сохранить, и еще запас будет). Так пойдет?
Тогда A=0 - управление скоростью, A=1 - "чтение" скорости в HL (можно было бы за 1 раз сделать, в HL - возвращать предыдущую, но если этого вдруг делать не нужно, лучше эмулятор не дергать, или надо тогда выделять какое-то значение - "оставить скорость" неизменной).
Насчет 254 максимум - маловато будет. Я сегодня как раз гонял RZX-ы, у меня почти все на 1500%, некоторые на 3000%, а отдельные на 5000% бегают. Почему бы и не задавать тогда в HL. Лет через 10 65000% будет нормуль.
Думаю чего не хватает: это определения типа эмуля. Пусть в той же ED FF в HL возвращает две буквы: H='U', L='S', если SMT поддержит и в моем H='E', L='W'. А уже в A - набор флажков по группам поддержанных операций.
Наконец-ТО!!! Давно пора!!!
надо использовать минимум трэпов (то есть один, например, #EDFF) и перепровериться 100 раз (например, у меня раньше были 6-байтная сигнатура 'unreal' в регистрах bc,de,hl), чтобы какой-нить супер-тест недокументированных команд случайно не напоролся на трэп. с другой стороны, кодеры скажут, что неудобно пользоваться очень длинными процедурами обращения в api. сейчас я подумал о таком варианте - сделать 1 функцию, которая проверяет кучу условий (во избежание случайного срабатывания), возвращает тип и версию эмулятора и устанавливает флажок, который позволяет обращаться к EDFF с облегченными параметрами (без перепроверок). флажок сбрасывается при reset или загрузке нового снепшота
один человек хочет, чтобы в его редакторе можно было авто-включить функцию text64, причём в регистрах указать адрес и другие параметры фонта. а потом эта функция появиться в другом эмуле, ес-но, с другим кодом включения. вот будет радости детектить тип эмуля и включать режим по-разному ;-)
Сдались вам эти ED nn команды. Мне больше нравится последовательность которая состоит из документированных команд (чтобы с ассемблерами и отладчиками проблем не было), но с околонулевой вероятностью встречается в реальном коде.
Смысл детектировать эмулятор я вообще не вижу. Да и что должна сделать программа если она хочет включить режим пентагона, но ей это не удается? Ничего!
Поэтому достаточно включить что-то, а если не включилось виноват пользователь, который запретил это в эмуляторе или использует неправильную версию. Я как-то сомневаюсь что даже чтение текущих значенеий понадобится.
2Smt: Вообще- то EDFF - это NOP чистой воды. Так что 100 раз перепроверяться не надо. Если этот трап что-то изменил, то это трап
2Spectre: если что-то делать, то пусть будет на отдельных командах, и не влияет ни на долю микросекунды на скорость выполнения других команд. А мы раньше ничего не делали, и все было хорошо. А пусть теперь будет. Всегда можно опцией/конфигурацией вырубить/врубить.
надо. этот #EDFF может быть среди мусора внутри ксорки. если влияет на регистры, не расксорится же
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
