1 Отредактировано avivanov76 (24-08-2022 21:54)

Тема: Особенности вызова процедур Монитора девятки

Делал тут одну тестовую программку и обнаружил странное: вызываю процедуру Монитора CLREOL (адрес $FCB4), которая должна очищать конец строки, печатая пробелы от текущей позиции курсора, а результата никакого. Не чистит и все тут.

Долго бродил вокруг и около и, наконец, заметил, что указатель BASL (адреса $28, $29), который должен указывать на начало текущей строки экрана, при выбранной 2-й текстовой странице содержит адрес > $3000, то есть указывает на диапазон адресов 6-й текстовой страницы. И что интересно, по этому адресу нашел все свои пропавшие пробелы. А если бы там код программы лежал? Вот был бы прикол.

Стал изучать, как вообще в девяточном Мониторе работает вывод на экран. И оказалось, что Монитор делает вот какую штуку: он перед каждым выводом символа переключает диспетчер памяти, и вывод на экран делает строго через адреса в диапазоне $2000 - $3FFF (первая логическая страница памяти).

Для этого Монитор при выборе текстовой страницы запоминает в ячейке $1E номер страницы памяти, к которой относится текстовая страница. А в момент вызова процедуры печати символа COUT ($FDED) или выполнения косвенного вызова по адресу ($36), Монитор переключает диспетчер памяти, так, чтобы через 1-ю логическую страницу памяти была видна та страница памяти, к которой относится текстовая страница.

Например, если выбрать текстовую страницу 8 командой 8T, то Монитор запомнит номер страницы памяти (2), и при каждом выводе символа на экран будет настраивать диспетчер памяти так, чтобы первой логической странице соответствовала вторая физическая страница (короче, делать запись по адресу $C112). А после вывода символа возвращать все в исходное состояние. Для этого в Мониторе есть две подпрограммы $F84F и $F85A. Первая перенастраивает диспетчер памяти перед выводом символа, вторая восстанавливает исходное состояние.

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

А вот для вспомогательных процедур, типа CLREOL такая настройка не делается, поэтому результат вызова получается странным. В общем, ничего хитрого, но напороться на такое было неожиданно :)

2

Re: Особенности вызова процедур Монитора девятки

Для чего ему эта игра со страницами ?

3

Re: Особенности вызова процедур Монитора девятки

Смысл игры страницами очень простой: Монитор всегда держит адрес текущей строки экрана в указателе $28, $29. Но Монитор не знает, что программа пользователя делает между вызовами процедуры печати символа.

А программа вполне может поменять соответствие логических и физических страниц памяти.
И если в указателе лежит адрес $2800, то этот адрес может указывать и на 1 текстовую страницу и на 5, 9, 13, 17, 21, 25, 29.

Поэтому Монитор всегда принудительно ставит правильное соответствие страниц памяти при выводе символа. А после вывода символа восстанавливает все "как было". Чтобы сюрприз у вызывающей программы не случился.

4 Отредактировано Voldemar0 (26-08-2022 05:57)

Re: Особенности вызова процедур Монитора девятки

не, вопрос не об этом.
Вопрос в том, для чего монитор подтыкает этот банк памяти (вроде бы номер 0), на сегмент номер 1 ?

Т.е. когда прогу запускаешь (xxxG) монитор выстраивает страницы по банки: 0 1 2 3 4 5 6 7.
Он и инициализирует банки в таком порядке на cold reset.
При таком раскладе страница видео 2 должна бы быть на своём адресе $1000.
Но перед выводом символов монитор переключает на сегмент 1 банк 0, получается так:
0 0 2 3 4 5 6 7.
И потом уже пишет в адрес $3000.
Я правильно понял?

Так почему сразу не придерживаться карты 0 1 2 3 4 5 6 7 и не писать в адрес $1000 ?

5

Re: Особенности вызова процедур Монитора девятки

Voldemar0 пишет:

перед выводом символов монитор переключает на сегмент 1 банк 0, получается так:
0 0 2 3 4 5 6 7.
И потом уже пишет в адрес $3000.
Я правильно понял?

Да

Voldemar0 пишет:

Так почему сразу не придерживаться карты 0 1 2 3 4 5 6 7 и не писать в адрес $1000 ?

Этой карты можно придерживаться только для текстовых страниц 0-23. 24-я страница попадает на область устройств ввода-вывода, а страницы 25-31 на ПЗУ. Причем, некоторые операции требуют не только записи в память, но и чтения (прокрутка экрана, например). Поэтому включить ПЗУ на чтение, а ОЗУ на запись нельзя.

И получается, что с такой схемой придется иметь две ветки кода: до 24 страницы использовать исходные назначения страниц, а начиная с 24 страницы переназначать те страницы памяти, которые Монитор не может использовать по прямым адресам.

Но поскольку ПЗУ Монитора всего 2 КБ и лишнего места там нет, то, скорее всего, разработчикам пришлось ужаться и не делать двух веток кода. И переназначать страницы всегда.

Ну а на сегмент 1 они стали подключать текстовые страницы, потому что в сегменте 0 нулевая страница, служебные переменные, стек, короче ее очень нежелательно переключать.

6

Re: Особенности вызова процедур Монитора девятки

Т.е. сисмон девятки любую страницу цепляет на сегмент 1 и, таким образом, может использовать все 64 текстовых страницы?

7

Re: Особенности вызова процедур Монитора девятки

Да.

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

8

Re: Особенности вызова процедур Монитора девятки

Вечно вы чего-то раскопаете :)

9

Re: Особенности вызова процедур Монитора девятки

Это любопытно, потому что, если не ошибаюсь, как раз бейсик и прочий софт девятки этого вроде бы не умеет. Во всяком случае Бейсик не щёлкает диспетчер памяти туда-сюда при выводе текста (точнее, щёлкает на обращения ко входным точкам $4xx... что там было такое, но там перещёлкивания были не ради доступа к видеостраницам).

Но может стоит проверить?