Оберон-клуб «ВЄДАsoft»

Эта фича давно назрела. По задумке режим работы программы задаётся в отдельном конфигураторе BasicCfg.h, и такой отдельный конфигуратор можно создать для каждого проекта. Или же воспользоваться конфигурацией по умолчанию. Выглядит он так:
Так сделано для упрятывания режима работы, изоляции этой сущности от, возможно, малоопытного бейсик-программиста. Как было бы лучше? — не знаю. Возможно, надо добавить в интерфейс и явные процедуры InitDI, InitIM0, InitIM2, но тогда придётся добавлять и QuitDI, QuitIM0, QuitIM2, а также PAUSE_DI, PAUSE_IM0, PAUSE_IM2, BEEP_DI, BEEP_IM0, BEEP_IM2 и т.п.

Предлагаю использовать для режима IM 2 процедуру Basic.IM2PROC(proc: PROCEDURE), которую я добавил сегодня. Пример — проигрывание мелодии в фоне (на прерываниях) параллельно с основным циклом исполнения прикладываю. Сама соль в этих строках:

Вместо ProcIM2 могла бы запросто быть процедура PT3x0A.Play, но в самый последний момент выяснилось, что она запрещает прерывания. Поэтому процедура-обработчик прерываний выглядит у нас так:
Трудность в том, что использованный мною плеер PT3x0A должен быть выровнен на границу 256 байт, так что после компиляции код проверяет выровнен ли он, и если нет, то выводит на сколько нужно выровнять. Но думаю решить эту проблему использованием PT3-плеера Сергея Бульбы.

Ну да, с IM 2 не всё так просто. В любом случае, обработчик прерываний нужен централизованный, впрочем, он может быть диспетчером, самолично вызывающим обработчик для опроса событий от мыши, оформленный в виде обычной процедуры.

Напомни, плиз, что это за адрес.

В плеере PT3x0A так :

Проще всего — с помощью Basic.DATA* (примеры есть в примерах к ZXDev).

Позволительно конечно, но лучше в виде отдельной библиотеки. Так будет правильнее: библиотека Basic — для возможностей, реализованных в ZX-Basic'е. Вообще-то и процедуру IM2PROC стоило бы выделить в отдельную библиотеку, но уж больно её реализация привязана к Basic.Init_IM2.

Оказалось, что процедура PT3x0A.Play портит содержимое альтернативных регистров, а процедура Best40.PSCALER из-за этого неправильно работает. Поэтому наш обработчик прерываний, который этого не учитывал, будет выглядеть так:

Вот так всё отлично работает! А вызов RST 0x38 нужен для того, чтобы процедура Basic.PAUSE(Basic.WaitAKey) ждала нажатия кнопки, а без этого просто висло.

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

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

Да, так нельзя.

При разработке для такой платформы как Спектрум трудновасто распределять ресурсы автоматизированно. Такие как прерывания или каналы музыкального сопроцессора. Взять проигрыватель музыки PT3x0A и твой плеер звука. Они ведь подерутся за канал A, нет? И получим какофонию вместо звука. Учесть всё невозможно. Значит будем делать всё это вручную. Обработчик прерываний будет писать сам юзер и пихать туда ну ровно то, что ему нужно. И в нужном ему порядке. И он же решит: сохранять ли альтернативные регистры и вызывать ли RST 0x38. Модули, работающие на прерываниях, будут экспортировать процедуру, которую нужно вызывать каждые 1/50 сек. Пусть эта процедура портит регистры и делает что ей угодно. Об этом будет заботиться обработчик прерываний. Ведь всё равно настоящего событийного (активного) режима работы на Спектруме не добиться. Всё равно придётся дёргать какой-то код для опроса событий от мыши, ведь в Спектруме событие само не вызывает прерываний.

Так что предлагаю отдать обработчик прерываний юзеру. И пусть у него болит голова насчёт расшаривания канала A. Т.е. пусть это будут учитывать используемые им плееры звука и музыки. А если понадобится другая логика, другой порядок обработки событий, юзерский код просто подставит новый обработчик вместо старого тем же самым вызовом Basic.IM2PROC(новый_обработчик).

Идею не совсем понял. Зачем генерировать ассемблерный код, и как именно?

Я вот тоже не понимаю, зачем от человека прятать то, что он должен настроить?
Если уж прячем, то нужно чтобы всё работало само, без настроек.
Если прерывания не нужны, нет ни музыки, ни таймера, ни паузы, ни стандартного опроса клавиатуры, то отключить их совсем. Один байт "DI" и всё.
Если нужен опрос клавиатуры, или пауза, то генерируется "IM 1"
Если-же Некоторое количество модулей хотят сами повисеть на прерываниях, например вызывают:
ZX_Interrupt.StaticReg(MyProc,0(* приоритет *),ZX_Interrupt.NeedPush_AFHL+ZX_Interrupt.NeedPush_BC+ZX_Interrupt.NeedPush_IX);
ZX_Interrupt - модуль отвечающий за спектрумовские прерывания
StaticReg,DynamicReg,UnReg - его функции регистрации обработчика.

Тогда формируется мощьный код, с формирование 257-байтной таблицы. Если вызывается DynamicReg, то по другому, и больше кода.

Может модуль узнать, какие его вызовы есть, и с какими аргументами?

Ну с этим всё просто. Сперва человек пишет как бы на ZX Basic, не парясь режимом прерываний. Потом, узнав что есть режим IM 2, человек задаётся вопросом: как его использовать? И узнаёт это. Для библиотеки Basic этого более чем достаточно, это даже больше, чем есть в ZX Basic. А для более изощрённых применений не используем библиотеку Basic, пишем свою с другой логикой.

Смысл конфигурирования внешним конфигуратором, вынесенным из исходника, открывается когда тебе нужно сгладить различия платформ. Чтобы исходник выглядел одинаково для всех платформ, а отличались только специфические конфигураторы. Так устроена игра Dark Woods. И, возможно, в библиотеке Basic смысл выделять режим прерываний в конфигуратор и сомнителен, поскольку Basic чётко машинно-зависимая, то уж в библиотеке Console его намного больше, потому что этот модуль относительно кроссплатформенный. Если брать Console в качестве хост-модуля (вместо Basic) — выбор режима прерываний не нужен для платформы Windows, но, если в этой же программе используется и музыка, он нужен для ZX.

Пауза может разрешать прерывания, отрабатывать и опять запрещать. Так работает внутренняя процедура Basic_PAUSE_DI.

А если нужен опрос клавиатуры и пауза в режиме IM 2 (для музыки в фоне)?

Вах, дарагой. Не пойму твоего упорства всё время представлять это с такой стороны: “модуль регистрирует обработчик и наслаждается своей автономностью”. Это из мира событийного программирования. Если некоторое количество модулей хотят повисеть на прерывании, пусть экспортируют свою внутреннюю процедуру-обработчик RunMe50Hz. А диспетчер будет сам дёргать эти обработчики. И напишет его сам юзер, не тратя лишних тактов. Так будет намного эффективнее для ZX. Лучше здесь просто не придумаешь. Централизованное сохранение регистров, вызов именно в нужном порядке (например, сначала опрос клавиш, потом музыка). И так будет относительно кроссплатформенно. Ты просто опишешь диспетчер IM 2 в ядре, отличающемся для разных платформ. И это ядро будет маленьким, оно будет только помогать сгладить платформенные различия.

Да, можно сделать как ты предлагаешь. Я сделал как мне на тот момент казалось удобнее (или проще).

Ты хочешь сделать чтобы модуль мыши сам регистрировал обработчик, сам обрабатывал прерывания и всё это было бы достаточно локализованно, чтобы не влиять на работу других модулей? Это возможно, но это малоцелесообразно. Как я уже сказал, в ZX события не вызывают прерываний. Ты хочешь эту активность эмулировать, и пожалуйста, но меньше кода у тебя не будет.

Модуль не может узнавать какие вызовы есть. Он просто может экспортировать наружу разные процедуры (вплоть до асмовых вставок), а уже сама процедура узнаёт какие вызовы есть, но только в рантайме конечно. Создав набор смартлинкуемых процедур можно добиться примерно того же эффекта, только будет не ZX_Interrupt.NeedPush_AFHL+ZX_Interrupt.NeedPush_BC+ZX_Interrupt.NeedPush_IX, а ZX_Interrupt.NeedPush_AFBCHLIX, ZX_Interrupt.NeedPush_AFBCDEHLIXIY и т.д. и т.п. Этого мусора будет там много, но другого способа сделать всё в compile-time я не знаю. И, опять же, всё это имело бы больше смысла если бы модуль для работы с мышью был кроссплатформенным. А так ориентация на Спек железная. Впрочем, я понимаю. Ты хотел бы просто прикрепить задачу к "активности" вызовом отдельной процедуры. И забыть про все проблемы. Но тогда нужна будет очередь вызова и действительно будет много мороки с описанием сохранения регистров. И в compile-time это можно сделать лишь каким-либо сишным препроцессором. Впрочем, надо подумать. Просто мне такое точно не нужно, надеюсь обойтись своим центральным обработчиком и вызовами в стиле RunMe50Hz. Ведь даже кроссплатформенный модуль для работы с мышью (его ZX-реализация) может экспортировать процедуру RunMe50Hz, о которой будет знать только ZX-ядро.

Надеюсь, это было сделано не для того, чтобы на форуме задавалось больше вопросов

Для эффективности ZX, но не для эффективности работы пользователя-программиста. Ему придётся писать банальности. Писать, переписывать, искать ошибки, сомневаться.

Нет. Я приложил картинку в екселе. Модуль мыши экспортирует свою функцию, а пользователь в "Бэкэнд для ZX" Регистрирует его в в модуле прерываний, с нужным приоритетом.
Код бэкэедов должен быть минимальный.
Конфигураторы, я представляю, как нечто чужеродное, сидящее внутри зелёных стрелок. То есть конфигуратор настраивает конкретную библиотеку, для конкретной машины, для конкретного проекта.

А то, что он кросспроектный, недостаточно? А ещё и кроссчеловеческий. Чем удобнее вещь, тем больше народу удачно её используют.

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

Трудность: всё равно потребуется явный вызов IM2Proc.Use* и IM2Proc.Quit, что неприемлемо для кроссплатформености. Всё равно понадобится ядро. Я не считаю это недостатком. Вполне нормальное решение.

Впрочем, для кроссплатформенностых (и даже кроссчеловеческих) применений и унификации можно сделать конфигуратор типа:

Не обвиняй меня, пожалуйста, в закулисно хитром кодинге, нуждающемся в разжёвывании на форуме. Мне вот бы кто тонкости работы с AY рассказал, а то это для меня как китайская грамота. Я библиотеку Basic для игры "Дурак" делал, даже не думая в тот момент, что её будет юзать кто-то ещё. Но это не значит что она плоха, она вполне себе даже ничего, как на мой вкус.

С этим я согласен, но ZX-программисту в любом случае придётся писать банальности, переписывать, искать ошибки, сомневаться. В библиотеках, как и в сборочных скриптах всё не предусмотришь. Если думаешь, что предусмотришь, попробуй предусмотреть, кто бы возражал. Но нет, всегда будут тонкости сопряжения и взаимодействия. Не нужно пытаться предусмотреть всё на свете. Нужно просто прятать излишнюю сложность, позволяя локализовать проблему как можно легче. Асм в Оберон-обёртке позволяет делать это лучше, чем без неё, мне так кажется.

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

А что, пожалуй, можно выбросить настройку режима прерываний из конфигуратора. Basic.IM2PROC может сама создавать таблицу и делать всё по подготовке и активации режима IM 2. Ещё понадобятся какие-нибудь Basic.IM0 и Basic.DI, изменяющие режим прерываний. Трудности возникают с PAUSE и BEEP, в них придётся опрашивать текущий режим и реагировать соотв. образом: в режиме DI перед возвратом включать DI, в режиме IM 0 сохранять IY, в режиме IM 2 возвращаться с разрешённым EI. Просто больше кода будет.