User Tag List

Показано с 1 по 10 из 18

Тема: ОРИОН-128: Монитор М3 и ROM-BIOS F800

Древовидный режим

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #6

    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,581
    Спасибо Благодарностей отдано 
    64
    Спасибо Благодарностей получено 
    112
    Поблагодарили
    97 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Denn Посмотреть сообщение
    А что не так с сохранением значения RamTOP в системной переменной? "Так" - это как?
    План вполне конкретный и очевидный, имхо. Т.к. ОЗУ для программ пользователя и всяких драйверов в общем-то одно - нулевая страница, то для защиты этих самых драйверов нужен механизм. Собственно он и был придуман: простой и логичный.
    Просто эти механизмы должны быть Ордосе (или другой ОС). Не монитора это дело - знать про то как я буду использовать ОЗУ, которым он сам ну никак не управляет. Соответственно ОС отличающийся от Ордоса (с другой концепцией, хотя и работающей через что-то мониторовское), помощи от этих п.п. никакой, только трата байтов в ценных 2к Монитора. Ну это тоже самое как например Монитор будет "иметь свое оригинальное представление" о том как мне под Юзиксом размещать процессы, ну не его же это дело.

    Собственно, подход "стека", уровней "нарезки" ПО от простого к сложному, от физики/аппаратуры к математическим абстракциям (как например вируализация памяти) - основа разработки всех ОС. Я это подсмотрел еще в детстве (ДВК с ее RT11) в школьном классе с БК-хами, задолго до Ориона, и наблюдаю до сих пор во всех промышленных и бытовых ОС, что имел дело. Когда возникает "смесь" процедур с разных уровней в некоем блоке, это вызывает дискомфорт (приспособиться можно, но зачем?).

    Цитата Сообщение от Denn Посмотреть сообщение
    С Монитором Ориона-ПРО есть одно, но большое счастье - он в природе один единственный! Слава богу, что руки рационализаторов до него не добрались. Хоть тут какая-то стабильность, и при написании софта можно быть уверенным, что не всплывёт какой-то "сюрприз" при обращении к стандартной п/п из-за того, что у пользователя экзотический Монитор.
    Я так понимаю, что он сделан на базе какого-то М3. Так что не удивительно.
    Не, он оригинальный, совместимости с M3 там еще меньше чем с М2. RAMTop они выпилили думаю потому, что набрались практики, изучили "соседние" ОС и пришли к аналогичному выводу о нелогичности этой подпрограммы, при этом искали канлдидатуру на выпиливание (хотя правильно было бы оствить как есть для совместимости, а новое дописывать после "штатных" п\п).
    В M3 кстати не стали писать отсебятину вместо RAMTOP как в ПРО, точка входа есть на своем месте, просто там для экономии места и хоть какой-то совместимости get_RAMTOP возвращает константу, а set_RAMTOP ничего не делает, что дает возможность это обойти при известной ловкости (проверить через get_RAMTOP записалось ли новое значение при set_RAMTOP) - если знать что такое бывает.



    Цитата Сообщение от Denn Посмотреть сообщение
    Я плевался трижды!

    1). Пресловутый RamTOP, причём ладно бы подменили на что-то безобидное, так нет, поставли запись чего-то в произвольную страницу ОЗУ!

    2). Опрос клавиатуры F81Bh работает по-другому. Другие времянки реакции, соответственно при реализации на базе этой п/п своего ввода, курсор мигает по-другому. Зачем?! Потом из-за перехвата невозможно пользоваться комбинацией УС+НР+F4... "Спасибо".

    3). Область непереключаемого ОЗУ: F300..F3FFh. М2 использовал некоторые документированные участки под системные переменные и стек. М3 "решил" оккупировать другие участки, оптом. "Фича" недокументированная, разумеется. ПО, которое использует это бесценное непереключаемое ОЗУ, вдруг "внезапно" портит мониторный опрос клавиатуры!

    Конечно всё решаемо (жопочасами с дизассемблером наперевес), но "за что?" и ради чего, спрашивается...
    Да, я тоже на это же самое наступил. Что говорит о том, что любой прогер боль-менее лезущий в системное, на это наткнется, т.к. опять же хромает идеология построения системного ПО (Монитора).
    Причем что забавно - эта п.п. записи байта из-за того что page_in + page_out кодируются в одном байте (по нибблам) позволяет адресовать через нее максимум 512кб ОЗУ (я могу понять когда аппаратно что-то не реализовано, но когда на ровном месте таки урезки по части ПО, мне не понятно - обычно наооборот "на будущее" оставляют для входных параметров подпрограмм резерв по битам/адресам/страницам).

    И я долго искал как в Режиме-128 опросить отдельно статус CTRL и/или SHITF. В доке есть несколько вариантов через разные новые п.п, в коде - нет ни одного (те п.п. есть, но дико сырые или урезанные). Может конечно плохо искал, но то что описано даже прошагал в эмуляторе (насколько терпения хватило).
    Последний раз редактировалось Error404; 08.12.2016 в 12:27.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Орион-128: BASIC
    от ivagor в разделе Орион
    Ответов: 34
    Последнее: 05.12.2025, 05:31
  2. Ответов: 506
    Последнее: 15.09.2023, 02:34
  3. Service rom + 128 basic rom
    от VELESOFT в разделе Оси
    Ответов: 1
    Последнее: 24.03.2013, 04:48
  4. ОРИОН 128-продам
    от Nordic в разделе Барахолка (архив)
    Ответов: 23
    Последнее: 23.03.2009, 07:54
  5. Орион-128
    от AlexBel в разделе Барахолка (архив)
    Ответов: 1
    Последнее: 25.09.2007, 20:40

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •