Просмотр полной версии : ОРИОН-128: Монитор М3 и ROM-BIOS F800
В Радио 1996-2 была статья "Из опыта работы с "Орионом-128"", там был опубликован драйвер для МС7007 по "Ленинградской" схеме для МОНИТОРа-2, отсканированный текст и оригинал тут: https://yadi.sk/d/jM1-1Z6H32PKUg
Я вроде все вычитал, особенно коды, но бывает и на старуху проруха!
Может кто сделает МОНИТОР-3 под ВМ80 и МС7007? Или какой там самый ходовой МОНИТОР?
Под Z80 и МС7007 всяких МОНИТОРов как грязи, а под ВМ80 только один подкинули :(
Монитор под ВМ80 - это М2 из "Радио". Всё имеющееся Орионовское ПО прекрасно работает с ним. Как я понимаю вариант под клаву MS7007 был на базе него.
Denn, получается что мониторы 3 и выше только под Z80?
Не помню откуда М3 появился, видимо прийдется опять по всем публикациям рыться, и не факт что он публиковался!
Пы.Сы. перечитываю тему с самого начала - столько интересного и полезного нашел уже :) Но почти 170 страниц не просто осилить осмысленно!
Denn, получается что мониторы 3 и выше только под Z80?
Под РК'шную клаву есть для ВМ80, но смысла упираться в М3 не вижу вообще. М2 вполне достаточно. Не работать же в этом Мониторе, в конце концов, это просто набор стандартных подпрограмм, который практически не изменился со времён РК86 :)
П.С. у меня в коллекции есть файл "M41MS.ori" :) Но чесслово даже пробовать его в Орионе желания нет.
Denn, просто я очень отстал, и не понимаю уже в этой суете, что к чему! Как дособираю Ориона - склею монитор и выложу.
А какой это монитор, 1,2,3 ?
Это M3-MS7007 самой древней версии (04.1991) для КР580. В нём вообще нет фонта русских букв. Скиньте мне на личку Ваш E-mail и я пришлю Вам точно такой-же M3 для MS7007 и КР580, но с полным фонтом. Причём с исходником.
МОНИТОРЫ-3 перепутать невозможно. У всех у них без исключения, по адресу 0F842H есть текстовая строка с номером версии.
AF842: defb 'V3.xx'
Программы, которым необходим M3, а это M3-EXT, драйверы и расширители М3 проверяют монитор так :
LD HL,(0F842H)
LD DE,'3' shl 8 + 'V' ; можно LD DE,'3V' но не во всех ассемблерах
XOR A
SBC HL,DE ; для КР580: CALL CMPDH
JP NZ,WRONG_MON
OK:
К сожалению, для КР580 после 1991 никто серъёзных доработок ROM-BIOS не делал. Если для Z80 есть десятки версий (других, чем в Вашем архиве), то для КР580 альтернативных версий почти нет. Могу прислать Вам МОНИТОР-4 (КР580, МС7007, В.Воронин, Новочеркасск, 1996) и МОНИТОР-2/TDA (КР580, МС7007, Дм.Тупицын, 1992). В обоих подключение клавиатур правильное, т.е совместимое с играми для клавиатур РК.
смысла упираться в М3 не вижу вообще
М3 был сделан легендарным программистом В.Ивинских (разработан сказать нельзя, это оптимизация чужого, хотя 30% кода изменено) в январе 1991, одновременно с выходом М2.
В.Ивинских первым в стране адаптировал ВСЕ игры КООП SP-580 для стандартного СПЕЦИАЛИСТА (в т.числе Jet-Set) и сделал кучу системных программ. За пару дней, даже не имея НГМД, адаптировал для КР580 Manic-Miner от ZX-48. 80% игр сезона 1991-92 составляли игры СПЕЦИАЛИСТА, что были адаптированы им для ОРИОНА. Но самое смешное, что для ОРИОНА он делал программы всего 1 месяц, причём даже не имея личного ОРИОНА. Если бы с такой же эффективностью работали остальные программисты ОРИОНА, то сейчас для него было бы 50 тысяч программ.
М3 стал известен раньше, чем был опубликован М2. Монитор М2 мы имели на месяц раньше, чем он был опубликован в ж.РАДИО 01.1991. Т.к М3 делал грамотный программист, то за счет более умелого программирования с'экономлено 150 байт (!) при одновременном улучшении параметров подпрограмм. В освободившееся место встроена подпрограмма ввода строки, CCP резидентного монитора и векторизация). К сожалению, не добавлена п/программа инициализации (это сделано в 1995, когда уже не было смысла).
Что касается версии М3 для МС7007, то она использует совместимую схему включения (что снимает проблему несовместимости с играми для РК-клавиатуры).
МОНИТОРЫ-3 работают по нажатию клавиш, а не по отпусканию (что в М2 - просто идиотизм, это единственный случай в мире, другого такого нет). Процедура сканирования клавиш в М3 - в 3 раза быстрее (а если бы не было диодов, то было бы в 15 раз быстрее, два считывания - и результат).
В М3 есть векторизация клавиатурных подпрограмм. Можно загрузить свой драйвер, любой своей клавиатуры (что я и делал загружая драйвер аппаратной клавиатуры APPLE-II, дающей готовый ASCII-код, т.к моя клавиатура от РК86 была низкого качества на кнопках МП16).
Вывод символов происходит быстрее. Причём выводится символ 6*9, а не 6*8 (отчего маркировка строки инверсией в М2 выглядит глупо, т.к текст не по центру инверсии).
Смысл М3 был в М3-EXT, т.к тогда почти ни у кого еще не было ROM-дисков, а слово ORDOS считалось матерным. Т.е это даёт возможности МОНИТОРА-1, при сохранении подпрограмм ROM-BIOS от МОНИТОРА-2. Причём набор команд монитора может оперативно меняться - команды подгружаются. Например в 1991 были догружаемые команды HELP (выдает справочник по командам М3-EXT) и два мини-дизассемблера (для КР80 и Z80 запускаемые командой точка '.АДРЕС'). А после загрузки RAMDOS для ЭД, команды монитора также меняются - теперь часть команд для ОЗУ работает иначе: D-DIR, W-SAVE, X-EXE...
МОНИТОРЫ-3 для Z80 отличаются тем, что у них большой сплошной курсор, не перепутаешь.
МОНИТОРЫ-3 для Z80 имеют средства для автовозврата по сбросу. Достаточно заменить пару байтов и по сбросу ни в какую ORDOS Вы уже никогда не вернётесь. Будет стартовать тот код, что должен. Например программа "взломщика" или снимок экрана.
COLDST: LD HL, (0F3C1H) ; обслуживание автостарта
LD SP, 0F3BFH
POP BC
PUSH HL
SCF
ADC HL, BC
RET Z
Но главное, во всех МОНИТОРАХ-3 есть вектор INTA 0F3DFH, на который загружаются клавиатурные прерывания. Что позволяет иметь в драйверах управление сочетанием клавиш УС+СС + клавиша (удерживая УС и СС нажать клавишу). Тогда драйвер получается универсальным для МС и РК клавиатур, т.е драйверу не надо лезть в матрицу клавиш, чтобы реализовать управление (не занимая кодов клавиатуры). Драйверу и любой программе не надо знать какой конкретно тип клавиатуры у пользователя. От этого CP/M-драйвер получается универсальным. Сочетание УС+СС при М3 работает как одна доп.клавиша АЛЬТ в PC. Например, часто по УС+СС+K переключаются кодировки в драйверах КОИ-8 -> АЛЬТ -> КОИ-7.
Это даёт как бы кучу дополнительных клавиш, используемых в программах. В некоторых драйверах для банки 2, а впоследствии для ACP/M 1.6x встроен резидентный SHELL. Его работа выглядит так. В абсолютно любой программе (что пользуется для ввода клавиатурой) по нажатию УС+СС + М, в середине экрана открывается окно (объёмом в пол-экрана), включается цвет и Вы оказываетесь в RAM-мониторе с помощью которого можете "шариться" по всем банкам ОЗУ, менять байты. Закончив работу командой 'Q' Вы возвращаетесь в прерванную программу в ту же точку и продолжаете её использовать.
SHELL имеет оверлеи, которые может загрузить сам пользователь. В частности так грузится справочник по входам ROM-BIOS, по функциям BDOS CP/M, таблица ASCII и вообще любые справочные данные, которые Вам оперативно нужны в ходе работы. Шлите Ваш E-mail адрес - скину скрин-шоты, чтобы увидели как это выглядит.
SHELL полезен когда дохнет каталог. Без SHELL - ценному листингу в 100 кило на Вашей дискете при дохлоте каталога - "кранты". Все данные пропали.
Но с SHELL, Вы копируете дисковый буфер 2 Кб, содержащий каталог, ставите новую дискету, ^C, затем 'SAVE 8 DIR.DAT' Затем грузите DU, читаете уцелевшие сектора каталога, пишете их в файл. Из уцелевших секторов и считанного блока в 2К с помощью отладчика компонуете новый каталог. Теперь этот полностью восстановленный каталог можно записать как на обычное место каталога, так и на любой недохлый трек.
Для начала пробуем восстановить каталог на родном месте. Делаем быстрый формат, чтобы отформатировать каталог. Если это получилось, то с помощью DU.COM просто заносим восстановленный каталог туда, где он и был. И копируем нужный файл на хорошую дискету, а эту дискету сразу выбрасываем.
Но если трек каталога сдох насмерть, то и это не беда. C помощью DU.COM можно записать каталог в начало любого ненужного трека (например трек 2 (физически это трек 1 сторона 0). Если у Вас нет варианта CP/M не настраивающего формат дискеты по DPB из BOOT-сектора, то надо откорректировать DPB-диска, что находится в байтах 3...1F BOOT-сектора. Надо изменить число системных треков. При этом придётся пересчитать и контр.сумму (это арифм.сумма байтов DPB плюс 66H). Если у Вас нет калькулятора с HEX-режимом, то вручную складывать HEX-числа Вам будет сложно - но простенькая программка в 10 байт сделает это за миг. После изменения DPB любая CP/M ОРИОНА будет читать каталог уже не с 4-го трека, а со 2-го, где Вы и разместили восстановленный каталог.
Но это не всё. Каталог на новом месте надо откорректировать. Так как номера блоков увеличатся на 2*5/2=5. То есть, во всех экстентах всех файлов надо увеличить номера блоков на 5. Если Вам нужен только один Ваш ценный файл исходника, над которым Вы работали 2 месяца, то достаточно откорректировать только его экстенты с помощью DU.COM. Это делается за 30 секунд труда. После этого Ваш ценный файл можно копировать. Ценные данные спасены.
Все вышеперечисленные работы, при некотором опыте, выполняются не более, чем за 5 минут. Это небольшая цена, чтобы спасти труд 2-х месяцев работы. Впрочем, преимущества М3 может оценить только тот, кто тратил 10 часов, чтобы из кучи фрагментов на диске восстановить погибший исходник (и это не всегда удавалось целиком).
Отрывки реального кода:
TXT: defb 13,10
defb 'SHELL-EXTENT vers 1.02 loaded at B0: B800..C3FF.',10,24H
BADDRV: RST 18H
defb 13,10
defb 'RAM conflict with current DRIVER !',13,10
defb 'Need free RAM B800...CFFF in Bank 0',13,10,0
RET
M80, если строка начинается с цифры или апострофа понимает строку как DEFB,
так что DEFB не обязателен. Т.е ниже это реально транслируемый кусок.
TXHELP: defb 0CH
' * Резидентный SHELL-MONITOR V1.03 (12.1990) *',13,10
' G<адрес> - старт (под)-программы (вып-ся CALL)',13,10
' D<нач.адр>,<кон.адр>,<банк> - дамп памяти ЭВМ',13,10
' M<нач.адрес>,<банк> - модификация ячеек ОЗУ',13,10
' F<нач.адр>,<кон.адр>,<байт> - заполнение ОЗУ',13,10
' T<нач.а>,<кон.а>,<адр.цели>,<банк> - пересылка',13,10
' P<н.а>,<к.а>,<исх.банк>,<пр.банк> копир.банок',13,10
' X<нач.а>,<кон.а>,<байт>,<банк> - поиск байта',13,10
' C<нач.а1>,<кон.а1>,<нач.а2> - сравнение ячеек',13,10
' K<нач.адр>,<кон.адр> - подсчет контрольн.суммы',13,10
' N<нач.адр>,<кон.адр> - подсчет RARITY-байта',13,10
' H<число1>,<число2> - выч. HEX-суммы и разности',13,10
' Y0/1 - цвет SHELL. E<F> - вызов функц.экстента',13,10
' V<мл.нбл:фон,ст.нбл:сим> - цвет в CP/M (или 0)',13,10
' ? - вывод этого HLP текста. Q - возврат в CP/M',0
Текст из одного загружаемого экстента справочника.
' Служебные ячейки ACP/M 1.6X',13,10,10
'RUSLAT 0F30EH а RUSLAT монитора (F3E5) это LOCK',13,10
'C_MODE 0F30FH COLOR FLAG (0-mono, FF-color)',13,10
'STRLEN 0F310H длина строки терминала',13,10
'TKODIR 0F311H кодировка: К7=0, К8=1, АЛЬТ=2',13,10
'DUBLFA 0F312H дубль порта FA',13,10
'DUBLF8 0F313H дубль порта F8',13,10
'IDENT 0F314H номер др-ра. Ст.нибл: шир.симв',13,10
'SYSTIM 0F315H 3 байта инкрементa пo STATUS',13,10 ; RANDOMIZE и программный счёт времени
'@ARDK 0F318H исходная копия яч. F3C7',13,10
'@ACOUT 0F31AH исходная копия яч. F3CD',13,10
'@AINT 0F31CH исходная копия яч. F3DF',13,10
'CHK 0F31EH к.сумма F318...F31D (+1)',13,10
'ACPM_F 0DCB7H опознаватели ACP/M (06,19,92)',0
Резюме. МОНИТОР-3 по качеству и по числу реализованных в нём простейшими средствами идей превосходит МОНИТОР-2 на порядок. Немного утрируя можно утверждать, что по сравнению с М3, М2 - просто "детский лепет".
barsik, спасибо за увлекательный материал. Единственный момент - при чтении очень раздражают подобные вещи:
"что в М2 просто идиотизм"
"отчего маркировка строки инверсией в М2 выглядит глупо"
Эти маркеры указывают на посыл автора: "я - Дартаньян, а вы все...".
Лично я больше, чем уверен, что авторы Ориона делали по-максимуму что могли, на что хватало имеющихся сред разработки и знаний на тот момент.
Резюме. МОНИТОР-3 по качеству и по числу реализованных в нём простейшими средствами идей превосходит МОНИТОР-2 на порядок. Немного утрируя можно утверждать, что по сравнению с М3, М2 - просто "детский лепет".
Из прочитанного я увидел, что некто поставил себе задачу переписать код Монитора "покруче", совместив примитивный командный интерфейс М1 с некоторыми расширенными возможностями стандарных подпрограмм М2, плюс добавив свои "плюшки", посчитав их архиважными. Ну, что ж, похвально. Только Орион придумали другие люди, и у них было своё видение, которое было нацелено не на работу пользователя с Монитором (в архаичном стиле РК86), а концепт был поинтереснее: ROM-диск + ОС, о чём было ясно сказано в статье про М2.
Если посмотреть с точки зрения простого пользователя, то ему вообще без разницы какой Монитор стоит в его Орионе, для него главное чтобы работало игровое и прикладное ПО. Если ПО будет требовать для запуска какой-то нестандартный Монитор, то вряд ли юзер будет пользоваться таким ПО - это и есть правда жизни.
Я хоть и не могу причислить себя к простому юзеру (мне интересно программировать под Орион), но встать на его место вполне способен: так вот, как у пользователя, у меня нужды в мониторе отличном от М2 с 1992-го и до сего года не возникало. Более того, всё орионовское ПО, которое мне попадалось, прекрасно работает с М2, а вот с М3 - увы, есть проблемы совместимости (авторы М3 посчитали ненужными некоторые стандартные подпрограммы и вместо них воткнули свои, с совершенно иным функционалом).
Скиньте мне на личку Ваш E-mail и я пришлю Вам точно такой-же M3 для MS7007 и КР580, но с полным фонтом. Причём с исходником.
Огромное СПАСИБО!!!
Материалы получил, стараюсь все осмыслить. Спасибо за Ваши подробные комментарии - очень помогает , мне ламеру, разобраться в тонкостях!
Пока кое что не ясно - разбираюсь, но материал подан очень подробно, при желании каждый сможет понять!
Орион потихоньку собирается, но пока, если честно, я боюсь внедрять предложенные Вами доработки, хоть и понимаю, что они толковые! И дело тут не в недоверии, а скорее, пока, в моей неготовности сделать все это :(
Error404
08.12.2016, 07:50
Я хоть и не могу причислить себя к простому юзеру (мне интересно программировать под Орион), но встать на его место вполне способен: так вот, как у пользователя, у меня нужды в мониторе отличном от М2 с 1992-го и до сего года не возникало. Более того, всё орионовское ПО, которое мне попадалось, прекрасно работает с М2, а вот с М3 - увы, есть проблемы совместимости (авторы М3 посчитали ненужными некоторые стандартные подпрограммы и вместо них воткнули свои, с совершенно иным функционалом).
Пользователю от Монитора вообще ничего не надо кроме опроса клавиатуры, ИМХО, т.к. при наличии разных типов клавиатур это единственная аппаратно вариативная часть внутри "линейки Орионов-128" (опрос клавы удобнее в M3, кстати, при том что меньше по размеру). Все остальное так или иначе делается не Монитором (уж больно в нем убогие подпрограммы и чаще всего они в ОС следующего уровня заменены на что-то более приличное). RAMTOP - да, заглушили, вообще непонятно зачем он был нужен, такие вещи делаются не так. Толи авторы в момент сочинения этих процедур не имели плана "а как оно будет", то ли имели опыт с какой-то экзотикой (тудно понять какой). А вот где действительно искорежили нужное и стандартное - так это в подпрограммах Ориона-ПРО в режиме совместимости с Орионом-128. Причем какие-то (уже не помню) более нужные вещи поправили (RAMTOP кстати тоже там выпилен). Делал правки в своих драйверах под "это", плевался. А то что "вместо ненужного" добавили - глючное и наполовину заглушено RET-ами.
Пользователю от Монитора вообще ничего не надо кроме опроса клавиатуры
Вот и я почти об том же. На самом деле помимо ввода, от Монитора важен ещё и вывод (F809h и F818h), ну и разумеется самая главная п/п - F800h :)
т.к. при наличии разных типов клавиатур это единственная аппаратно вариативная часть внутри "линейки Орионов-128"
Тем не менее, в играх используют прямой опрос клавы в обход Монитора, ибо требуется скорость и не требуется антидребезг.
опрос клавы удобнее в M3, кстати, при том что меньше по размеру
Как пользователь, я не заметил разницы. А вот перехват комбинаций УС+НР+F4 и т.п. - это для меня была подстава! Причём даже не на уровне F803h, а аж в F81Bh!
Все остальное так или иначе делается не Монитором
Вот именно. В связи с этим вообще не вижу смысла его трогать, все свои навороты прекрасно можно делать в ПО "поверх" п/п Монитора. В т.ч. хитрые загрузчики с нестандартных носителей.
RAMTOP - да, заглушили, вообще непонятно зачем он был нужен, такие вещи делаются не так.
А что не так с сохранением значения RamTOP в системной переменной? "Так" - это как?
Толи авторы в момент сочинения этих процедур не имели плана "а как оно будет", то ли имели опыт с какой-то экзотикой (тудно понять какой).
План вполне конкретный и очевидный, имхо. Т.к. ОЗУ для программ пользователя и всяких драйверов в общем-то одно - нулевая страница, то для защиты этих самых драйверов нужен механизм. Собственно он и был придуман: простой и логичный.
А вот где действительно искорежили нужное и стандартное - так это в подпрограммах Ориона-ПРО в режиме совместимости с Орионом-128. Причем какие-то (уже не помню) более нужные вещи поправили
С Монитором Ориона-ПРО есть одно, но большое счастье - он в природе один единственный! Слава богу, что руки рационализаторов до него не добрались. Хоть тут какая-то стабильность, и при написании софта можно быть уверенным, что не всплывёт какой-то "сюрприз" при обращении к стандартной п/п из-за того, что у пользователя экзотический Монитор.
(RAMTOP кстати тоже там выпилен).
Я так понимаю, что он сделан на базе какого-то М3. Так что не удивительно.
Делал правки в своих драйверах под "это", плевался.
Я плевался трижды!
1). Пресловутый RamTOP, причём ладно бы подменили на что-то безобидное, так нет, поставли запись чего-то в произвольную страницу ОЗУ! Для чего это делать средствами Монитора?..
2). Опрос клавиатуры F81Bh. Совершенно замечательная подпрограмма, ибо инвариантна к текущей странице ОЗУ, т.е. её можно вызывать из любой и она корректно работает! В М1 и М2 работает одинаково, в М3 работает по-другому. Другие времянки реакции, соответственно при реализации на базе этой п/п своего ввода, курсор мигает по-другому. Реакция на РУС/ЛАТ совершенно иная (в чём разница сейчас уже не вспомню, но помню что громко плевался, когда выяснил). Зачем?! Потом из-за перехвата невозможно пользоваться комбинацией УС+НР+F4... "Спасибо".
3). Область непереключаемого ОЗУ: F300..F3FFh. М2 использовал некоторые документированные участки под системные переменные и стек. М3 "решил" оккупировать другие участки, оптом. "Фича" недокументированная, разумеется. ПО, которое использует это бесценное непереключаемое ОЗУ, вдруг "внезапно" портит мониторный опрос клавиатуры! "Здрасьте, давно не виделись!"
Конечно всё решаемо (жопочасами с дизассемблером наперевес), но "за что?" и ради чего, спрашивается...
Error404
08.12.2016, 12:12
А что не так с сохранением значения RamTOP в системной переменной? "Так" - это как?
План вполне конкретный и очевидный, имхо. Т.к. ОЗУ для программ пользователя и всяких драйверов в общем-то одно - нулевая страница, то для защиты этих самых драйверов нужен механизм. Собственно он и был придуман: простой и логичный.
Просто эти механизмы должны быть Ордосе (или другой ОС). Не монитора это дело - знать про то как я буду использовать ОЗУ, которым он сам ну никак не управляет. Соответственно ОС отличающийся от Ордоса (с другой концепцией, хотя и работающей через что-то мониторовское), помощи от этих п.п. никакой, только трата байтов в ценных 2к Монитора. Ну это тоже самое как например Монитор будет "иметь свое оригинальное представление" о том как мне под Юзиксом размещать процессы, ну не его же это дело.
Собственно, подход "стека", уровней "нарезки" ПО от простого к сложному, от физики/аппаратуры к математическим абстракциям (как например вируализация памяти) - основа разработки всех ОС. Я это подсмотрел еще в детстве (ДВК с ее RT11) в школьном классе с БК-хами, задолго до Ориона, и наблюдаю до сих пор во всех промышленных и бытовых ОС, что имел дело. Когда возникает "смесь" процедур с разных уровней в некоем блоке, это вызывает дискомфорт (приспособиться можно, но зачем?).
С Монитором Ориона-ПРО есть одно, но большое счастье - он в природе один единственный! Слава богу, что руки рационализаторов до него не добрались. Хоть тут какая-то стабильность, и при написании софта можно быть уверенным, что не всплывёт какой-то "сюрприз" при обращении к стандартной п/п из-за того, что у пользователя экзотический Монитор.
Я так понимаю, что он сделан на базе какого-то М3. Так что не удивительно.
Не, он оригинальный, совместимости с M3 там еще меньше чем с М2. RAMTop они выпилили думаю потому, что набрались практики, изучили "соседние" ОС и пришли к аналогичному выводу о нелогичности этой подпрограммы, при этом искали канлдидатуру на выпиливание (хотя правильно было бы оствить как есть для совместимости, а новое дописывать после "штатных" п\п).
В M3 кстати не стали писать отсебятину вместо RAMTOP как в ПРО, точка входа есть на своем месте, просто там для экономии места и хоть какой-то совместимости get_RAMTOP возвращает константу, а set_RAMTOP ничего не делает, что дает возможность это обойти при известной ловкости (проверить через get_RAMTOP записалось ли новое значение при set_RAMTOP) - если знать что такое бывает.
Я плевался трижды!
1). Пресловутый RamTOP, причём ладно бы подменили на что-то безобидное, так нет, поставли запись чего-то в произвольную страницу ОЗУ!
2). Опрос клавиатуры F81Bh работает по-другому. Другие времянки реакции, соответственно при реализации на базе этой п/п своего ввода, курсор мигает по-другому. Зачем?! Потом из-за перехвата невозможно пользоваться комбинацией УС+НР+F4... "Спасибо".
3). Область непереключаемого ОЗУ: F300..F3FFh. М2 использовал некоторые документированные участки под системные переменные и стек. М3 "решил" оккупировать другие участки, оптом. "Фича" недокументированная, разумеется. ПО, которое использует это бесценное непереключаемое ОЗУ, вдруг "внезапно" портит мониторный опрос клавиатуры!
Конечно всё решаемо (жопочасами с дизассемблером наперевес), но "за что?" и ради чего, спрашивается...
Да, я тоже на это же самое наступил. :) Что говорит о том, что любой прогер боль-менее лезущий в системное, на это наткнется, т.к. опять же хромает идеология построения системного ПО (Монитора).
Причем что забавно - эта п.п. записи байта из-за того что page_in + page_out кодируются в одном байте (по нибблам) позволяет адресовать через нее максимум 512кб ОЗУ (я могу понять когда аппаратно что-то не реализовано, но когда на ровном месте таки урезки по части ПО, мне не понятно - обычно наооборот "на будущее" оставляют для входных параметров подпрограмм резерв по битам/адресам/страницам).
И я долго искал как в Режиме-128 опросить отдельно статус CTRL и/или SHITF. В доке есть несколько вариантов через разные новые п.п, в коде - нет ни одного (те п.п. есть, но дико сырые или урезанные). :) Может конечно плохо искал, но то что описано даже прошагал в эмуляторе (насколько терпения хватило).
VladimirS
08.12.2016, 12:42
barsik, спасибо за увлекательный материал. Единственный момент - при чтении очень раздражают подобные вещи:
"что в М2 просто идиотизм"
"отчего маркировка строки инверсией в М2 выглядит глупо"
Эти маркеры указывают на посыл автора: "я - Дартаньян, а вы все...".
Лично я больше, чем уверен, что авторы Ориона делали по-максимуму что могли, на что хватало имеющихся сред разработки и знаний на тот момент.
Из прочитанного я увидел, что некто поставил себе задачу переписать код Монитора "покруче", совместив примитивный командный интерфейс М1 с некоторыми расширенными возможностями стандарных подпрограмм М2, плюс добавив свои "плюшки", посчитав их архиважными. Ну, что ж, похвально. Только Орион придумали другие люди, и у них было своё видение, которое было нацелено не на работу пользователя с Монитором (в архаичном стиле РК86), а концепт был поинтереснее: ROM-диск + ОС, о чём было ясно сказано в статье про М2.
Если посмотреть с точки зрения простого пользователя, то ему вообще без разницы какой Монитор стоит в его Орионе, для него главное чтобы работало игровое и прикладное ПО. Если ПО будет требовать для запуска какой-то нестандартный Монитор, то вряд ли юзер будет пользоваться таким ПО - это и есть правда жизни.
Я хоть и не могу причислить себя к простому юзеру (мне интересно программировать под Орион), но встать на его место вполне способен: так вот, как у пользователя, у меня нужды в мониторе отличном от М2 с 1992-го и до сего года не возникало. Более того, всё орионовское ПО, которое мне попадалось, прекрасно работает с М2, а вот с М3 - увы, есть проблемы совместимости (авторы М3 посчитали ненужными некоторые стандартные подпрограммы и вместо них воткнули свои, с совершенно иным функционалом).
"что в М2 просто идиотизм"
"отчего маркировка строки инверсией в М2 выглядит глупо"
{ворчание удалено Error404}
Просто эти механизмы должны быть Ордосе (или другой ОС). Не монитора это дело - знать про то как я буду использовать ОЗУ, которым он сам ну никак не управляет.
Идейно согласен. Но изначально Орион начинался с М1 и работы с стиле РК86. Драйвера уже появились тогда, и конфликты нужно было как-то разруливать.
Кстати, этот самый RamTOP не с РК86/Спеца ли присутствует в Мониторе?
Соответственно ОС отличающийся от Ордоса (с другой концепцией, хотя и работающей через что-то мониторовское), помощи от этих п.п. никакой, только трата байтов в ценных 2к Монитора.
Авторы выбрали концепцию "запихивания" ОС в 2 Кб. При таких жёстких условиях на счету каждый божий байт :) А в Мониторе как раз дофига свободного места... )))
Собственно, подход "стека", уровней "нарезки" ПО от простого к сложному, от физики/аппаратуры к математическим абстракциям (как например вируализация памяти) - основа разработки всех ОС. Я это подсмотрел еще в детстве (ДВК с ее RT11)
Это всё прекрасно, но в случае Ориона избыточно, имхо. Универсализация и глобализация - это здорово, но они требуют ресурсов, а Орион это не писи. Собственно, как и Синклер (там вообще в ПЗУ Бейсик! Лол :))
Тут важно вовремя остановиться с наворотами, чтобы они не убили весь смысл ОС на Орионе.
Разнообразия основного железа (ввод/вывод) не планировалось. "Навески" всякой экзотики всё равно не в BIOS'е поддержаны, а в соотв. ПО пользователя, так что аппаратные абстракции особо и не нужны. Любая универсализация/глобализация отрицательно сказывается на объёме кода и скорости, а это крайне важный момент с ресурсами Ориона, имхо.
Не, он оригинальный.
Ковырял без малого год назад, с тех пор много байт утекло, в голове уже подробности не вспомню... Но помню, что сперва сексился с М3 на О-128, а потом все те же грабли увидел в Мониторе на ПРО'шке, из чего сделал для себя нехитрый вывод.
Кстати, мы говорим об одном и том же Мониторе "ПРО" - который появляется в F800..FFFFh в режиме "Orion-128" ?
хотя правильно было бы оствить как есть для совместимости, а новое дописывать после "штатных" п\п).
Да!
В M3 кстати не стали писать отсебятину вместо RAMTOP как в ПРО, точка входа есть на своем месте, просто там для экономии места и хоть какой-то совместимости get_RAMTOP возвращает константу, а set_RAMTOP ничего не делает, что дает возможность это обойти при известной ловкости (проверить через get_RAMTOP записалось ли новое значение при set_RAMTOP).
Опять же, видимо в разных версиях по-разному. Или у меня уже перепутались Мониторы М3 от О-128 и ПРО'шный...
Причем что забавно - эта п.п. записи байта из-за того что page_in + page_out кодируются в одном байте (по нибблам) позволяет адресовать через нее максимум 512кб ОЗУ (я могу понять когда аппаратно что-то не реализовано, но когда на ровном месте таки урезки по части ПО, мне не понятно - обычно наооборот "на будущее" оставляют для входных параметров подпрограмм резерв по битам/адресам/страницам).
Так вроде более 512 Кб ОЗУ и не планировалось. В любом случае, сабж явно для работы с графикой, а она в 0-ой и 1-ой страницах. А в случае с "ПРО" можно втыкать ОЗУ окнами - там вообще без разницы..
ЗЫ кстати ниббл кодирует 16 страниц, т.е. "метр" ОЗУ ;)
И я долго искал как в Режиме-128 опросить отдельно статус CTRL и/или SHITF. В доке есть несколько вариантов через разные новые п.п, в коде - нет ни одного (те п.п. есть, но дико сырые или урезанные). :) Может конечно плохо искал, но то что описано даже прошагал в эмуляторе (насколько терпения хватило).
На "ПРО" я делаю так:
IN 1AH
ANI 40H
JZ ...нажат CTRL
IN 1AH
ANI 20H
JZ ...нажат SHIFT
На О-128 "IN 1AH" заменить на "LDA 0F402H" (кстати, на ПРО так тоже прокатит, но на целый байт длиннее :)).
Error404
08.12.2016, 13:25
Идейно согласен. Но изначально Орион начинался с М1 и работы с стиле РК86. Драйвера уже появились тогда, и конфликты нужно было как-то разруливать.
Кстати, этот самый RamTOP не с РК86/Спеца ли присутствует в Мониторе?
Не знаю, возможно (скорее РК, по требованию редакции Радио :) ), я под РК86/Спец не программировал, слабо их знаю. А вообще по работам Орион-Софт (авторского коллектива и примкнувших кодеров) заметно что уровень рос, и менялись взгляды на какие-то вещи. Ну это наверное у каждого разработчика так.
На "ПРО" я делаю так:
IN 1AH
ANI 40H
JZ ...нажат CTRL
IN 1AH
ANI 20H
JZ ...нажат SHIFT
На О-128 "IN 1AH" заменить на "LDA 0F402H" (кстати, на ПРО так тоже прокатит).
Да, я в итоге тоже пришел к выводу, что "за неимением гербовой пишем на простой" и оставив попытки сделать через монитор, сделал по портам в версии для ПРО, а для О-128 рассчитываю на наличие М3. Ну если нет его, не заработает часть спецкнопок (чрез комбинации клавишь): досадно но не смертельно.
- - - Добавлено - - -
Попрошу без перехода на личности
Error404
09.12.2016, 13:09
К версиям ROM-BIOS для Z80 3.2...3.5 я отношения вообще не имею, и не считаю их МОНИТОРАМИ-3, т.к они не рассчитаны на подгрузку стандартного M3-EXT и вообще работу в мониторной среде и тем более в ORDOS. Они и были рассчитаны только на пользователей дискетной CP/M и работать с ними в ORDOS и даже просто в RAM-мониторе вообще не предполагалось. К тому же, как указано выше, некоторые из них - "глючные" по клавише <RUSLAT>, хотя в CP/M это никак нельзя было обнаружить. Это обнаруживается только в ORDOS или в "голом CCP".
....
Например, М3.5 содержит встроенный загрузчик дисковода. И она при всём желании не может работать в ORDOS и, соответственно, обслуживать в ORDOS-программах запрос и установку RAMTOP. Поэтому зачем же было сохранять ненужные подпрограммы, тратя на это драгоценные байты?
Именно М3.5ZххD (c загрузчиком с НГМД) за счет того что он позволялся избавиться от Ром-ДИСКА (тогда не было 27с801 и надо было держать плату-лапоть с 8 ПЗУ) и как следствие Ордос, и промежуточных действий между включение питания и загрузкой CP/M, был с восторгом принят владимирскими любителями орионовщины (в количестве "на пике" четырех человек), что учитывая общую слабую распространенность продвинутого ПО - немало. Глюки у нас за несколько лет эксплуатации не проявлялись, никакой другой функционал кроме добавленного в драйвер клавиатуры не требовался (а вот прог.прерыванием CTRL+SHIFT+KEY пользовались активно).
Другие версии Мониторов у меня хранились просто "чтобы были".
Кстати, error404, а зачем Вы заглушили стандартный вход РК86 F86C (WARM BOOT). Вы же видели в исходнике, что, чтобы сохранить этот стандартный для РК86 и ОРИОНА вход в ROM-BIOS 3.5 пришлось "изворачиваться" с лишними JMP-ами. Ясно же, что это было сделано "не сдуру", а так надо. Т.к из многих программ есть выход туда, а с Вашими версиями ROM-BIOS произойдёт улёт.
Если вопрос про версии Мониторов-3 с загрузчиками с IDE/SDcard, то они получены из вышеупомянутого М3.5ZххD (c загрузчиком с НГМД) дизассемблером (так что гениальность кучи джампов один в другой я мог и не понять :) хотя опять же не припоминаю такого - ХЗ) и простой заменой загрузчика (на более сложный и большой, требующий еще большей оптимизации). Удалял ли что-то из "секретных спецджампов" не помню, но если это "что-то" было документировано, причем в Орионовской теме и широко, а не РК-шной (до которой мне и раньше было и сейчас все равно), я его удалять не стал бы 100%.
И потом, они же сразу грузят CP/M откуда никуда улететь невозможно, т.к. никакие программы CP/M в ROM F800 не лезут, и даже авторские хотящие Монитора в подобные "верхние вызовы" не лазили. В-общем глюков не замечал.
Но самый интересный вопрос - почему это М3, если всё что образовывало М3 из ПЗУ выкинуто? Полностью выкинут CCP, подпрограмма ввода строки, п/п-ма конверсии текстовых HEX-цифр в их значения, устранена совместимость с М3-EXT. От М3 остался только эффективный алгоритм распаковки фонта, драйверы вывода символа на экран и ввода с клавиатуры, плюс резидентный обработчик нажатий УС+СС+клавиша. Это скорее М2 с другим кодом самих подпрограмм.
Ну во-первых, выкинуто не мной, и не выкинуто, а "сделано в последней самой свежей версии Монитра, полученной из Питера" (причем сделано без особых объяснений), разница заметна же? :)
Да и ССР там же есть вроде? (с одной командой "грузиться"). Остальное может было не нужно? По той же тривиально причине: нефига тащить в стартовый BIOS (пускай и с CCP) то, что программер должен не лениться делать сам в коде, уж обработку текстовых строк то уж точно.
Я, к сожалению проверить Ваш ROM-BIOS не могу. Сами коды я не могу проверить, т.к по сбросу он пытается что-то считать с каких-то неизвестных устройств. А в итоге вылетает на вход ERROR, вместо того, чтобы загрузить 2 кило из ROM-диска и стартануть их. M3-EXT он не может загрузить, т.к Вы удалили резидентный CCP. Я конечно могу в своем эмуляторе выйти в отладчик и вручную набрать программу теста и стартануть её, но это, сами понимаете, удовольствие ниже среднего.
Т.е просто пока не нашёл Вашей версии ROM-BIOS, которая выходила бы хотя бы в ORDOS. А если есть выход в ORDOS или M3-EXT, то можно стартовать тест из ROM-диска. А изменить исходник ROM-BIOS, чтобы грузилась ORDOS и странслировать, я не могу по причине того, что у Вас колоссально длинные метки. Т.е мне предварительно надо долго редактировать укорачивая метки до нормальной длины. В М80 максимальная длина меток - 6 символов. Чем это Вы такое транслируете?
М80 и транслирую, нормальные там метки, в ограничения пока не упирался. Используемая мной версия есть на Гит. (https://github.com/serge-404/AltairDOS/tree/master/App/bin)
Есть версия Монитора (https://github.com/serge-404/AltairDOS/blob/master/App/source/Monitor3/m37zrkr.zip) на базе опять же M3.5xxxD, c которой и EXT-Z нормально работает (специально не поленился прошагать EXT и компенсировать в Мониторе ранее по треду упоминавшиеся "защитные CALL-ы EXT-Z в никуда в середину тела Монитора" - описаний же нет: в деревни не рассылалось, но как оказалось овчинка выделки не стоит особо - на практике никому EXT пока понадобился), он грузится с RS-232 этой схемы (https://github.com/serge-404/AltairDOS/blob/master/App/source/xmodem/tty_orion.zip) по протоколу X-MODEM (спецом чтобы с PC стандартными средствами типа HyperTerm загружать Орион хоть EXT, хоть что угодно размером в размер ОЗУ нулевой страницы), там всё так же есть CCP (т.к. он никуда и не девался), и он умеет грузить как Ордос, так и любой другой блок любого (ЕМНИП) размера из ROM-диска (описание есть в архиве).
А не кажется-ла вам товарищи, что вы уже порядком загадили флудом конкретную тему, и конкретно про Мониторы для Ориона!?
Было-бы неплохо собрать в одной теме все доступные мониторы с коментариями. А вот все остальное неплохо-бы потереть из темы, или пусть "авторитеты" в флуде киллометровые портянки постят!
Error404
12.12.2016, 21:02
Последние страницы, скатившиеся во флейм, унесены сюда:
http://zx-pk.ru/threads/27178-orion-flejm-quot-bojtsy-vspominayut-minuvshie-dni-quot.html
Захотелось сделать программное определение версии Монитора на "Орион-128". Хочу понять масштабы "зоопарка" актуальных версий и по каким признакам их идентифицировать.
Первое, что приходит на ум - подсчёт контрольной суммы дампа F800..FFFFh (можно даже по упрощёнке - XOR'ингом), но если версий реально много, то получится неслабая таблица к/сумм, а хотелось бы как-то обойтись малой кровью (в смысле малым объёмом кода).
Различать варианты с "мелкозернистыми" изменениями вроде подкрутки констант и вариациями зашифрованных посланий а-ля "здесь был Вася" смысла нет, интересуют принципиальные различия в функционале, от которых зависит работоспособность ПО.
Есть какие-нибудь идеи у знатоков?
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot