Орион-128: Разное

Вид для печати

Показывать 40 сообщений этой темы на одной странице

26.04.2017, 18:52
barsik

Вложений: 1

Странслировал M1 Z80 версии 1.07 для РК-клавиатуры. Код оптимизировать дальше невозможно, это предельная версия (и для сжатия фонта использован самый эффективный алгоритм).

После оптимизации кода, удалось выиграть ~150 ячеек. Эти ячейки были потрачены на:

- исключена директива R. ORDOS автоматически грузится по сбросу
- чтобы блокировать загрузку ORDOS держите клавишу <CC> при нажатии на сброс
- исправлен алгоритм ввода п/п-ммы F803 (теперь срабатывает по нажатию)
- оптимизирована п/п-мма F81B (работает быстрее и меньше байтов)
- заменена неудобная процедуры ввода команд (использован CCP из М3)
- заменена процедура вывода символов (выводится 9 линий знакоместа)
- заменена подпрограмма FLASH (курсор большой)
- введена индикация включённого регистра клавиатуры формой курсора
- введена индикация регистра клавиатуры высотой тона подзвучки
- полностью заменена директива 'M' на упрощенную директиву 'M' монитора-3
- полностью заменена директива 'D' на упрощенную директиву 'D' монитора-3
- введена подпрограмма BEEP F83F (и константа CBEEP F3E7 влияет на частоту)
- убран вектор подпрограммы CONOUT (это незачем, если CONIN не векторизована)
- введён вектор подпрограммы BEEP F83F, точно также как это в М2
- убрана п/п-мма CLICK и теперь подзвучка клавиатуры использует BEEP

Проверил только в эмуляторе, где невозможно проверить МГ-подпрограммы и звуки. По-прежнему не получил сведений о проверке ранее выложенных версий в реале. Просьба ко всем, кто имеет Z80 и прошиватель ПЗУ РФ2, проверить эту и другие версии. Интересует правильность звуков и работа МГ-подпрограмм. Помните, что с М1 работает только NC$ и NC4$ из 1991 года. VC$ 1994 года с М1 успешно глюкается. Прилагаю какой-то NC$ (у них версии не обозначены), который нормально работает с М1.

Теперь займусь оптимизацией версии для КР580. Это мне важно потому, что часть кода одновременно будет использована для ПЗУ другого компьютера на КР580 с экраном 256*256. Позже "расковыряю" и оптимизирую и версию М2-РК для КР580.

- - - Добавлено - - -

Вложение с дампами ПЗУ удалено, как устаревшее. Ищи в последующих постах
26.04.2017, 21:35
Stampmaker

Цитата:

Сообщение от tol123

Ну тогда ждемс!

будем пока без ay.

очень советую собрать этот хороший и полезный девайс.
а AY в нём появится нескоро, очень нескоро, если вообще появится.
только учтите, что РАМ7 поддержан только в DSDOS.
29.04.2017, 09:42
barsik

Вложений: 1

Ну вот наконец и версии ПЗУ М1 для КР580. Для КР580 оптимизировать чужой код на порядок тяжелее, и это удалось с трудом. Выкладываю версию для РК-клавиатуры и версию для MS-клавиатуры. Они разные (по перечню улучшений, что в каждую удалось уместить).

Версия 1.20 для РК-клавиатуры и КР580. Это первая и, скорее всего, последняя версия для КР580 и РК-клавиатуры. Код оптимизирован до физического предела (25 часов оптимизации). Для сжатия фонта использован самый эффективный алгоритм (для КР580, для Z80 есть и лучше), но из-за этого фонт другой (тот что использую сам). Номер версии сразу 1.20, чтобы оставить номера для последующих версий на Z80, которые начались с 1.01, причём для РК и MS клавиатур нумерация своя (т.е версии 1.XY-MS и 1.XY-RK, это совершенно непохожие версии, сделанные в разное время и не имеющие ничего общего).

За счёт оптимизации кода КР580 удалось сделать следующее:

- исключена директива R. Теперь ORDOS автоматически грузится по сбросу
- чтобы блокировать загрузку ORDOS, держите клавишу <CC> при нажатии на сброс
- исправлен алгоритм ввода п/п-ммы F803 (теперь срабатывает по нажатию)
- оптимизирована п/п-мма F81B (работает быстрее и меньше байтов)
- теперь доступен для ввода символ подчёркивания (<СС> + пробел)
- заменена неудобная процедуры ввода команд (использован CCP из М3)
- заменена подпрограмма FLASH (курсор большой)
- введена индикация включённого регистра клавиатуры формой курсора
- полностью заменена директива 'M' на упрощенную директиву 'M' монитора-3
- полностью заменена директива 'D' на упрощенную директиву 'D' монитора-3
- введена подпрограмма F83F (чтобы был хоть какой-то звук, использован CLICK)
- убран вектор подпрограммы CONOUT (это незачем, если CONIN не векторизована)
- убран вектор пустой и совершенно бесполезной подпрограммы F821
- удалена подпрограмма SVBYTE, зато её вход векторизован, также как в М2
- директива 'O' сохранена, но работает только после загрузки драйвера SVBYTE
- в качестве драйвера SVBYTE годятся старые драйвера SVBYTE 1992 года
- удалена директива 'C', этот ROM-BIOS рабочий (а не для отладки цвета)
- как ненужные удалены директивы 'R' и 'Z'

Версия 1.00/MS-7007 для КР580. Нумерация с 1.00, т.к других версий М1 для MS-клавиатур я не встречал. Всё-же удалось уместить весь фонт в ПЗУ, оверлейность или удаление п/п SVBYTE не потребовалась. Это достигнуто тем, что директивы D и M оставлены примитивными, как в оригинале, а также выкинута директива C, которая низачем не нужна. В данной версии ORDOS автоматически не грузится, это пока оставлено как в оригинале, для запуска ORDOS надо исполнить директиву R. Скоро странслирую версию 1.01-MS КР580 с автозагрузкой ORDOS, так что ещё одна версия точно будет.

- исправлен алгоритм ввода п/п-ммы F803 (теперь срабатывает по нажатию)
- п/п-мма F81B работает быстрее (т.к сам драйвер MS из РАДИО 12.1991 быстрее)
- заменена подпрограмма FLASH (курсор большой)
- введена индикация включённого регистра клавиатуры формой курсора
- введена подпрограмма F83F (чтобы был хоть какой-то звук, использован CLICK)
- убран вектор подпрограммы CONOUT (это незачем, если CONIN не векторизована)
- убран вектор пустой и бесполезной подпрограммы F821
- удалена директива 'C', этот ROM-BIOS рабочий (а не для отладки цвета)
- как ненужная удалена директива 'Z' (т.к уже программы 1991 портят CCP ORDOS)
- а если всё-же нужен рестарт ORDOS без загрузки, не проблема ввести G BFFD <ВК>

Подробнее об этих 2-х ПЗУ читайте в сопроводительных файлах.

Кроме того, т.к было "отковыряно" еще более 20 ячеек, то перетранслированы и все версии для Z80 (правда в основном эти байты истрачены на вывод номера версии в титре, титр ПЗУ в ORDOS не виден, надо держать <СС> при сбросе). Номера версий не менялись, потому просьба удалить все предыдушие версии, чтобы избежать путаницы. Кроме того, чуть изменено ПЗУ М3 V3.13-MS из 1992 (увеличена константа автоповтора).

Дизассемблировал NC$. Т.к тот дизассемблированный исходник, что "болтается" в архивных дистрибутивах вообще никуда не годится (то же самое можно увидеть и в любом отладчике). Вообще с помощью дизассемблера МИКРОН очень трудно дизассемблировать программы с самомодификацией кода, а данная программа NC$ просто "бъёт все рекорды" по само-модифицируемости (модификация кода считается извращённым стилем программирования и не поощряется, среди фирменных программ это не встречается, но для нас это вполне оправдано, т.к экономит код).

Исходник нужен, чтобы увидеть, как выполняется опрос клавиш. Нет никакой задержки, поэтому если в ROM-BIOS использована более грамотная подпрограмма опроса клавиатуры F81B, в которой этот опрос выполняется в 2-3 раза быстрее, то ввод становится "очень нервным". Чем быстрее опрос клавиш, тем больше времени остаётся в играх на движение спрайтов и музыку. Также и в текстовых программах это ускоряет вывод текста (т.к профессиональные текстовые программы и во время вывода непрерывно проверяют клавиатуру). Поэтому быстрый опрос клавиатуры важен.

Самый быстрый (почти мгновенный) опрос клавиш получается при аппаратной клавиатуре, где CPU остаётся только забирать готовый ASCII-код. А т.к в ОРИОНЕ предусмотрена загрузка драйвера любой клавиатуры, то ориентация на тормознутость одного конкретного ПЗУ - это ошибка.

Теперь есть возможность оптимизировать NC$ и сделать так, чтобы можно было пользоваться не только при любом ПЗУ, но даже и при аппаратной клавиатуре.

Ни одна из версий ПЗУ не проверена в реале (у меня нет возможности прошивать, точнее чистить, ПЗУ), да и нет, ни MS-7007 клавиатуры, ни адаптера магнитофона, ни самого магнитофона. В проверке прежде всего нуждаются звуки и ввод с магнитофона.

PS: Если кому-то нужна директива 'C', которая бесполезная, т.к не делает ничего, кроме как заполнения плоскости цвета заданным кодом (раскрашивает экран), то могу странслировать эти 10 байтов в виде ORDOS-программы (будет как бы внешняя команда ДОС, во многих ДОС команды внешние, например, в RK-DOS большая часть команд - внешние).
29.04.2017, 16:08
barsik

Сделал версию М1 КР580 и для MS-клавиатуры (на это ушло всего 3 часа). Причём удалось обойтись, как без загрузки оверлеев из ROM-диска, так и без переноса в драйвер подпрограммы SVBYTE. Чтобы сократить число вложений, просто перевложил файл вложения в предыдущем посте, соответственно отредактировав текст.

По-прежнему нужна проверка в реале. Ну или хотя бы на разных эмуляторах, где есть MS-клавиатура, вывод звуков и работает МГ-ввод из WAV-файлов. Если на каком-то эмуляторе не работает, то скорее всего там не эмулирована команда CP (HL) попадающая в ППА (на моём эмуляторе тоже так было вначале, пока я не понял в чём дело).

Могу в базовый М1 для РК-клавиатуры (т.е без улучшений п/п-рамм) встроить в директиву I автонастройку на скорость МГ-ленты, а также директиву R - ввод в формате ORDOS (тогда не нужен будет CH4$). Могу то же самое сделать и для М2, т.е встроить в него автонастройку на скорость.

Есть также возможность сделать 2-х ПЗУ-шечный ROM-BIOS ОРИОНА (на КР580). Суть в том, чтобы как на СПЕЦИАЛИСТЕ получить резидентный драйвер шрифта 8*8. С М3 это тяжело, т.к там нет свободных ячеек, а М2 я немного уже "уплющил" и получил ~230 свободных ячеек !!! (на Z80 будет ещё больше). С учетом установки вторым этажом второй ПЗУ РФ2, этого хватит на цветной (но не оконный) драйвер 8*8.

Можно истратить эти ячейкии иначе. Например, можно встроить драйвер связи с IBM PC по проводной линии (как чере ВВ51, так и без неё, если IBM PC имеет параллельный порт принтера). Суть в том, чтобы п/п-ммы LDBYTE и SVBYTE работали бы не с МГ-лентой, а с проводной линией. Тогда все древние МГ-программы будут работать также, только скорость обмена (с линией вместо магнитофона) будет в 5-15 раз выше.
29.04.2017, 21:01
barsik

Вложений: 2

Сегодня день мониторов ОРИОНА для КР580. Исправил МОНИТОР-2. При этом за счёт более эффективного программирования одновременно освободил в нём 282 ячейки при полном сохранении функционала.

Также сделал М2 для MS-7007. Это то же самое, что и вариант М2 Дм.Тупицына из 1992, но с другими драйверами клавиатуры и экрана. Здесь свободно только 178 ячеек так как MS-драйвер на 104 байта длиннее.

Есть у кого-нибудь более эффективный алгоритм компрессии фонта ? Есть три моих алгоритма, но самый эффективный алгоритм требует Z80. Может этим кто-нибудь занимался. Жалко если не удастся довести число свободных ячеек до 300 (это можно сделать ухудшив качество, но не хотелось бы).

Попробуйте новые версии М2. Поставьте сначала старый М2 и повводите в ORDOS-е или в редакторе символы. Затем поставьте этот М2 и сравните удобство ввода текста.

Заодно разобрался в отличиях М1 и М2. Теперь могу сделать так, чтобы VC$ и другие ORDOS-программы работали с Монитором-1. Да, так и не дождался того, что кто-нибудь выложит МОНИТОР-4. Если бы его выложили, то я бы уже сегодня "заковырял" бы и его.

Разобрался как вводит с МГ-ленты МОНИТОР-2. Это сделано не в соответствии с РК86 и даже просто некорректно. А именно нет синхронизации по второму синхробайту, что идёт после двух ИЛИ ТРЁХ нулевых байтов перед КС. Число нулевых байтов и пауза между блоком и КС может быть любой. Кстати, с поиском синхробайта п/п-мма даже короче (экономится 6 байтов). М2 сразу после конца блока вводит и просто пропускает 3 байта (2 нулевых байта и байт E6). Таким образом не только не проверяется, что это пилотон (т.е два именно нулевых байта), но и байт E6 вообще не проверяется (нет поиска синхробайта, как на всех РК-клонах и МИКРО-80). Все 3 байта игнорируются и значение имеют только два последующих байта КС.

Это неправильно, т.к недопускает никакой паузы между блоком данных и блоком контрольной суммы. В РК86 и МИКРО-80 может выводиться 1 и более нулевых байтов перед синхробайтом и КС. А в ОРИОНЕ только 2, причем это могут быть даже не нулевые байты, а любые. И синхробайт не влияет и может быть любой. Таким образом ОРИОН может вводить любую чушь, лишь бы КС в нужном месте совпала. Но на других ЭВМ с РК-форматом это не так. Так же читается и формат ORDOS (т.к это стандартная п/п-мма LD_MAS ввод массива).

Вообще в МГ-подпрограммах М2 с удивлением нашёл ~30 NOP-ов непонятного назначения (в М1 NOP-ов не было). Возможно это была попытка добиться того, чтобы константа ввода точно соответствовала РК86. В М3 никаких NOP-ов нет, подпрограммы вдвое короче, а надёжность выше.

С удивлением узнал, что подпрограммы LDBYTE и SVBYTE в М2 вообще не векторизованы. Векторизация введена только в М3. Ещё один минус для М2. Т.е М2 не годится для загрузки драйвера проводной линии, т.е замены МГ-подпрограмм на аналоги, не использующие магнитофона. Когда-то я загрузив драйвер, так обменивался со СПЕЦИАЛИСТОМ и СИНКЛЕР-ом со скоростью 8 кб в секунду (что даже не снилось ВВ51).

Возможно используя полученный листинг сделаю настоящий М2, т.е ПЗУ с которым уже можно будет работать в CP/M, если конечно мне кто-нибудь сообщит какие коды VT52 надо в это ПЗУ встроить. Если выкинуть МГ-подпрограммы, то в этом ПЗУ будет свободно ~350 ячеек.

Т.к "обнаружил" в ПЗУ М1 еще 10 свободных ячеек, то все выложеные ранее версии М1 для Z80 и КР580 придётся перетранслировать (просьба удалить все ранее выложенные версии ПЗУ). Глупо не использовать все свободные ячейки.

Подскажите кто-нибудь, как избавляться от VC$. Если я его запускаю, то потом мне никак не удаётся от него отделаться. Выход не помогает, а кнопка СБРОС разрушает ОЗУ и пользоваться ей не рекомендуется. Поэтому клавиатурное прерывание М3 по УС+СС+С, что делает JMP F800, очень выручало. Но в М2 этого нет, и я как без рук. В NC$ для запрета автовозврата достаточно было удалить файл автостартёра EXT$. Но здесь он невидимый и потому я не знаю как его удалить.

- - - Добавлено - - -

Добавил М3 MS-7007 для КР580. Процессор Z80 позволяет эффективно сокращать объём программы для КР580, поэтому при Z80 нет проблем разместить на 104 байта более крупный MS-драйвер в коде М3. Однако при КР580 это представляет существенную трудность, т.к М3.1-РК КР580 уже изначально написан весьма грамотно. Отчего в нём невозможно освободить даже несколько байтов, а сжать код на 104 байта - это просто непосильная задача. Однако и это мне удалось сделать. Вот версия М3 КР580 для MS-7007.

- - - Добавлено - - -

Добавил М3 КР580 V3.151. По сравнению с версией 3.150 сохранена п/п SVBYTE и звук сделан по EI/DI (ранее ошибочно звук был оставлен по OUT FF, как для Z80) .
30.04.2017, 18:10
ABRAMKA0

Вложений: 1

Цитата:

Сообщение от barsik

Да, так и не дождался того, что кто-нибудь выложит МОНИТОР-4. Если бы его выложили, то я бы уже сегодня "заковырял" бы и его.

Ловите,Владимир Иванович.Я уж и не помню,где я его нарыл,записан в РФ5 еще в 2002 году,но не помню как он работал.А вот с мониторами 1-2-3 помню в ОРДОСЕ проблем не было.Вложение 60834
P.S. для того,чтобы вставить файл в сообщение,я его переименовал в .txt,перед использованием замените расширение файла на .bin
P.S.S А все же,Владимир Иванович,вы не любите ОРДОС "как люблю ее я",а пытаетесь NC для неё переделать?Ну честно,почему?
30.04.2017, 20:00
barsik

Это не МОНИТОР-4. Это монитор-3 версий 3.0 или 3.1, т.е ещё КР580, кем-то переделанный, а точнее изуродованный. Он может работать как монитор-2, но как М3 уже работать не может, изуродован, не может вводить HEX-числа. Но команды G и I сохранены. Дизассемблировал за 15 минут, знакомый код, расставил имена, как у меня в исходниках, чтобы легко ориентироваться, и стал искать что добавлено.

Нашёл в коде загрузчик дисковода с адресацией ОРИОСОФТ (F710). Надо бы проверить в реале, а проще в эмуляторе B2M, т.к он поддерживает НГМД. В МОНИТОР-4 должны быть вместо МГ-подпрограмм дисководные подпрограммы. Может быть это какая-то ранняя версия М4. Ничего концептуально нового, обычный ROM-BIOS на базе М3 с загрузчиком дисковода и загрузкой ORDOS. Добавлена новая стандартная подпрограмма в конец таблички входов на F842. Там всего 4 команды:

Код:

DI OUT (F9),A LD (F3D5),A RET

Изменения делал человек незнакомый с ROM-BIOS-ами. Ячейка F3D5 это важная ячейка - относящаяся к параметрам окна. А её используют для хранения номера банки. Сдвинут вход WARM BOOT F86C, даже стандартный вход в CCP F8B6 не сохранён. Не говоря уже о внутренних точках М3. В общем это не может называться М4. Это не новая разработка, это компоновка из чужих кусков. И это делается за 10 минут.

Понятно почему взят М3. Ведь в нём код п/п-рамм оптимизирован и соответственно, если выкинуть сам монитор, то места хватает и для собственных дополнений. Позднее я закончу дизассемблирование этого М4. Только для того чтобы узнать, что значит строка "R/F/H ?", что выводится если отключить ROM-диск. Вообще-то, если нет ДОК-файла, это однозначно свидетельствует о несерьёзности автора.

NC$ я дизассемблировал, чтобы посмотреть и возможно переделаю его в NC4. VC$ не работает с магнитофоном, потому он и не интересен. А NC$ уже весной 1991 один человек (в Ленинграде) переделал так, чтобы работало на 4 банки, причём это был файл 4К, содержащий в себе и модификацию ORDOS 2.0, чтобы она работала на 4 банки (для этого надо НЕ много изменений). В 1991 этот файл грузился с МГ, т.е CCP вообще не было. Но этого хватало, т.к CCP ORDOS малофункционально и NC его вполне заменяет. Т.к этого NC$ на 4 банки не сохранилось, то раз уж дизассемблировал, то не сложно переделать. Может у кого-то сохранился такой NC$ на 4 банки? Он был широко распространён до появления VC$, который появился года на полтора позднее. В каталогах торговцев программами это видно.

А вообще-то было же несколько ORDOS-нортонов (кроме авторского). Это даже не считая нортона А.Вакуленко и нортонов В.Воронина. Где они все выложены? Ради интереса хочу написать свой нортон для ORDOS. Даже два. Один без драйвера, а второй с оконным драйвером. Для этого много труда не надо, т.к подпрограммы есть, а "глюкало" писать не понадобится, это делает оконный драйвер.

- - - Добавлено - - -

Добавил в свой предыдущий пост вложение M3.151 для КР580 (с трудом удалось уместить SVBYTE, исправлен звук, он в версии 3.150 ошибочно оставался ещё для Z80), а также те экстенты М3, что работают при КР580.
02.05.2017, 00:49
barsik

Выиграл ещё 16 байтов за счёт уплотнения фонта. Теперь в МОНИТОРЕ-2 у меня уже есть 298 свободных ячеек и не хватает всего 2-х байтов до круглой цифры. В эти 300 байтов можно вставить много чего. 16-ти байтов хватает, чтобы вернуть титры в выложенные ранее ПЗУ M3 КР580 (М3.13.5-MS и 3.151-РК). В ближайшее время их перетранслирую.

Имея 300 (а при Z80 и более) байтов для расширения возможности ROM-BIOS, могу сделать универсальный ROM-BIOS ОРИОНА. В котором будут драйверы трех типов клавиатур. Базовой, с матрицей РК86, альтернативной, с матрицей MS-7007, а также аппаратной промышленной (типа КОНСУЛ, 15ВВВ-97, клавиатуры ИРИШИ, и от АГАТА/Apple-II). Также можно сделать ПЗУ поддерживающее две клавиатуры: обычную от РК86 и IBM-клавиатуру подключенную по способу IBM PC (т.е через его же контроллер 4042).

К сожалению, игры нагло напрямую лезут сквозь ППА в матрицу кнопок, поэтому с аппаратными клавиатурами они не работают. Но системные программы, не использующие наглого влезания в ППА клавиатуры, с аппаратной клавиатурой всё-же использовать можно. Хотя в большинстве моих драйверов для подмены кодов курсорных клавиш программа, получив код курсорной клавиши, читает ППА клавиатуры, чтобы узнать получен код с клавишей CONTROL или без неё, что даёт информацию о том, надо ли подменять нестандартные коды курсорных клавиш ОРИОНА на коды курсорных клавиш принятые в CP/M. Но свои драйверы, я легко исправлю, чтобы работали и с аппаратной клавиатурой, в которой есть сигнал CONTROL (сигнализирующий о том, что клавиша нажата). Такой сигнал легко вывести из любой аппаратной клавиатуры.

Чтобы при аппаратной клавиатуре работали игры, теоретически, есть возможность использовать идею прерывания, используемую в DEC-машинах. Там мощные DEC-процессоры имеют расширенную систему команд (что-то типа FPU поддержки расширенной арифметики). Но, как ни странно, программы рассчитанные на эти процессоры могут работать и на самых древних процессорах. Это достигается, тем, что встретив "неродную" команду, процессор выполняет стандартное прерывание TRAP, по которому вылетает в загруженный программный эмулятор расширенной системы команд. Таким образом новая программа работает, хотя и медленно, т.к программная эмуляция тормозит. Если бы разработчики КР580 догадались ввести переход на FFFD при "встрече" неверного кода команды (12 недокументированных команд КР580), то программы Z80 работали бы и на КР580.

Если ввести в ОРИОН аппаратное прерывание (при КР580, оно увы, м.быть только на 38H, или же требуется куча трудов по установке контроллера прерываний), то при попытке процессора залезть в ППА клавиатуры, будет происходить прерывание, в котором эмулируется поведение матрицы клавиш. Это довольно сложная процедура и она займет все 300 свободных байт (если вообще уместится).

Возможно использовать эти ячейки и иначе. ~300 байтов хватит, что ввести в М2, например, поддержку ВИ53, по типу ИРИШИ - музыкальный язык. При этом для вывода музыки, на консоль выкидывается строка с искейп-кодом, после которого все последующие байты интерпретируются не как символы для терминала, а как команды вывода нот в разных каналах ВИ53. В ИРИШЕ используют только один канал, т.е одноголосие. Да и то сделано с ошибкой, так что практической пользы от этого нет, даже простейшую мелодию не сделать (но попищать и произвести какафонию можно).

Но чтобы получить трехголосную музыку, надо иметь в звуке атаку и затухание, т.е необходима регулировка громкости звука по каналам. Хотя бы по одному каналу для основной мелодии. Когда-то я пробовал использовать для регулировки громкости ИД14 (это 2 дешифратора в одном корпусе). Тогда на адреса подаётся вес уровня громкости, на чип-селект сигнал, а на выходы ИД14 подключены резисторы, так что образуется делитель, что даёт 4 градации уровня громкости для двух каналов. Расход деталей для регулировки громкостей всего 1 корпус, но при этом плохо, что выходной сигнал не синусоида, и к тому же с несбалансированным средним уровнем.

Средний уровень 0 получается с операционником. Операционник включён как повторитель так, что при 1 на входе он инвертирует, т.е по 1 даёт минус входного сигнала, а при 0 не инвертирует и даёт плюс входного сигнала. Так что получается из 1 выходит положительная полуволна, а из нулей отрицательная полуволна (относительно земли), отчего средний уровень сигнала нулевой. Т.о сдвоенный операционник позволяют на ВИ53 производить классическую музыку. Расход деталей в 2 корпуса вполне оправдан (даёт 2 канала с регулировкой громкости). Чтобы получить лучший тембр, нужен КМОП аналоговый мультиплексор, который коротит сигнал на землю разными емкостями. С резистором (лучше дросселем) образуется частотный фильтр. Для каждого диапазона частот включается своя ёмкость. Благодаря чему на выходе не меандр, а почти синусоида. Т.о всего за счёт расхода 3-х корпусов, качество трехголосной музыки резко возрастает.

Есть возможность ввести в М2 КОИ-8. Тогда в ПЗУ несжатыми размещаются маленькие русские буквы (что знимают всего 256 байт) и немного изменяется драйвер.
03.05.2017, 16:30
barsik

Выкладываю обновлённые версии ПЗУ М1, М2, М3 для КР580 для всех клавиатур с максимальным числом свободных ячеек. Они очень нуждаются в проверке (особенно версии для MS). Все выложенные ранее версии КР580 имеют недостатки и их следует удалить.

М2 для КР580 в данной выкладке имеет 297 свободных ячеек. Мне удалось достичь и 305 свободных ячеек. Однако при этом изображение самого символа оказывается центрованным, как в М3. А в М2 символ придвинут кверху знакоместа и на это ориентируется VC$, рисуя горизонтальные линии не по центру знакоместа. Поэтому, чтобы всё было как в оригинале М2 пришлось потратить ячейки.

Пока отлаживал MS-мониторы в эмуляторе, рассчитанном на РК-клавиатуру, придумал как с ПЗУ рассчитанном на MS-клавиатуру, пользоваться клавиатурой от РК. Для этого первоначально составил таблицу соответствия клавиш РК клавиатуры клавишам MS-клавиатуры. Эта же таблица позволяет играть в игры, где прямой программный опрос MS-матрицы (если такие игры есть). Но для владельцев MS полезно составить обратную программу, чтобы играть в игры для РК-клавиатуры на MS-клавиатуре.

А потом для удобства векторизовал F81B (как сделано в М3 для Z80) и написал драйвер EXT$, который подменяет одни коды другими и в ORDOS грузится автоматически. Таким образом кое-как получил возможность пользоваться программами при ПЗУ для MS. По крайней мере запускать программы можно. К сожалению, в матрице MS-7007 больше линий и число кнопок больше, чем 64. Поэтому коды некоторых клавиш никак не ввести (можно сделать, чтобы, по крайней мере, можно было вводить все буквы, заменив некоторые редко используемые символы, типа '% * / ^ ~' на недоступные буквы).

Привожу список соответствия клавиш. Слева - то, что хотелось бы ввести, а справа - на что надо нажать. Как видите, не все коды нужных клавиш можно ввести, имея ROM-BIOS для MS, а клавиатуру для РК. Но пользоваться всеми программами, кроме текстовых редакторов, этого хватает. Список, возможно, не полный и даже, возможно, неточный (т.к не из реала). Во вложении программка позволяющую узнать коды. Она ещё понадобится при подключении корветовской клавиатуры вместо MS-7007. Для выхода удерживайте 5 секунд любую клавишу.

Код:

. Соответствие клавиш с ROM-BIOS для MS-клавиатуры при матрице РК86 A...D M Y...B F1...CTP,ВК !...2 B...@ N...- Z...Y F2...F2 =...F4 C..." O...F [...0 F3...влево "...3 D...9 P ]...1 F4...вверх :...F5 E...7 Q ^...I F5...вправо %...5 F R...E ПС...F2 вниз...F2,U $...вниз G...> S...K HOME..| вверх...] #...4 H...X T...M CTP...) вправ...W &...6 H..влево U...+,: забой..T влево..H )...CTP I...G V...Q 4...R пробел...O /...F3 K...< W 5...Z ВК...пробел >...W L...8 X...N 6...ESC R/L...R/L Символы, что не ввести: . , _ 0 1 2 3 7 8 9 + - * ? F M P Q W
03.05.2017, 17:00
Error404

Да уж, раскладки символов на матрицу и близко не похожие.
Меня всегда интересовало: при том что печатное поле пишмашки на всех клавиатурах одинаковое, с чем глубокий смысл в каждом клоне каждый раз рассыпАть символы по матрице как Киса "Сеятель" Воробьянинов ассигнации на базаре - случайным образом (ну как минимум - неочевидным). Чтобы потом дважды героически преодолевать трудности: один раз разводя печатку/пленку для кнопок и второй раз перекодируя ни к чему топологически не привязанные сканкоды в символы?
04.05.2017, 16:23
barsik

Вложений: 1

Дизассемблировал в полноценный исходник М4. Теперь могу сказать из чего и как он получен и что из себя представляет.

Итак, получено это не из М3.1 для КР580, а из моего ПЗУ М3 Z80 из 1994, версий до 3.605. Т.к в версии 3.605 уже форма курсора меняется в зависимости от регистра клавиатуры, а здесь курсор большой, но неизменной формы (а версии М3 из 1992 от А.Новгородова вообще имеют маленький курсор как в М2).

Что сделано в этом ПЗУ? Добавлена новая входная точка F3C0. Там стоит переход на WARM BOOT F86C. Автор понял, что ещё один JMP ниже F3C3 умещается, но истратил его на ерунду, т.к стандартный вход WARM BOOT в советских компьютерах это F86C. Ячейка F3C1 в M3 это TMPSP (в М2 TMPSP это F3DF, что в M3 вектор AINT). Чтобы освободить ячейки F3C0, F3C1, F3C2 для ненужного входа WARM BOOT, автор поставил TMPSP на F3E1,что в М2 и М3 резервный адрес COUTC (для непонятных целей введённый в М2).

Естественно, при обратном переводе с Z80 на КР580 произведена замена JR команд на JP, убраны DJNZ, команды BIT и сдвиги регистров изменены на сдвиги в аккумуляре. Однако в п/п-мме ролика экрана, использовались команды LDI, поэтому эта часть заменена на п/п-мму ролика из М3.0 для КР580.

В подпрограмме вывода символов в М2 и М3 до 1994 как рабочая используется ячейка OSTAT F3DD. Но в моих М3-Z80 эта ячейка не используется, вместо неё используется IXL половинка индекного регистра. Это было сделано не ради освобождения ячейки F3DD, а потому что так достигается экономия объёма кода. Естественно, при обратном переходе на КР580 пришлось изыскивать свободную ячейку. Но автор М4 не изучал разные ПЗУ для КР580 и не знал, что ячейка OSTAT F3DD именно для этих целей и служит. Поэтому он ввёл ещё одну служебную ячейку OSTAT F3F2, выполняющую ту же самую функцию, что в М1 M2 M3 КР580 выполняет ячейка OSTAT F3DD (которая в М4, естественно, свободна).

Даже если бы не было полной идентичости кода с M3 Z80, это однозначно свидетельствует, что получено из ПЗУ для Z80. Об этом же свидетельствует использование новгородовской п/п-ммы XF81B, которая совершенно другая, чем п/п-раммы В.Сугоняко и В.Ивинских. К чести автора следует сказать, что он не просто заимствовал, а изучил код и сумел изменить константу в п/п-мме ввода с клавиатуры.

Выкинуты все МГ-подпрограммы. Выкинута проверка и автостарт M3-EXT. Выкинут CCP М3 (п/п-мма ввода строки и конверсия HEX-текстов в их значения). Директивы I и G, как ни странно остались, но делают теперь совсем иное (не запуск с указанного адреса и не ввод с магнитофона). Их надо нажимать при сбросе.

Внесены некоторые изменения в стандартные входы. О смещениях стандартной входной точки WBOOT я уже упоминал. П/п-ммы F81B F80F F812 оставлены векторизованными, как в М3-Z80 (что чревато проблемами с программами идиотов, что в качестве обычных ячеек хранения используют ячейки F3F0...F3FF, предназначенные для ROM-BIOS). Вместо READ RAMTOP F830 вставлена своя новая подпрограмма XXXXXX непонятного назначения. (меняет байты в банках). Вместо запроса RAMTOP теперь стоит подпрограмма INILOCK (инициализация рабочих ячеек). Это именно то, чего не хватало в М2 и М3, т.к позволяет без проблем отгружать драйвера. В моих ПЗУ это тоже есть, но входная точка не тратится (точка за 3 байта до F86C). Введена новая стандартная входная точка F842. Эта п/п-мма служит для того, чтобы задать номер банки куда будет просходить возврат из п/п-рамм RDRAM и WRRAM (чтения из записи байта в банки). Это позволяет использовать п/п-ммы F836/39 из любой банки, а не только из нулевой. Но лучше это достигается дублированием содержимого портов F8, F9, FA, FB в адресах F3F8, F3F9, F3FA, F3FB.

Что введено? Если ROM-диск есть, то происходит выход в ORDOS. Если ROM-диска нет, то выводится промпт "? R/F/H" ?". По нажатию на R грузится ORDOS с ROM-диска, по F стартует загрузчик дисковода от ОРИОНСОФТ (адреса F710/F714 и другой оффсет байта в BOOT-секторе с номером банки ДОС). Если же нажать H, то происходит загрузка с винчестера, который установлен по адресу F750...F75F. Так как винчестер был не сильно распространён, то несложно вычислить автора этого ПЗУ М4.

Долго "трахался", чтобы получить полноценный исходник, хотя это ПЗУ не стоило и минуты моего труда. За час можно наштамповать таких десяток, причём лучшего качества, засунув в них загрузчики чего угодно. Чтобы мой труд не пропадал впустую, я исправлю в этом ПЗУ явные ненужности и несоответствия стандартам М2 и выкину загрузчик винчестера стоящего по адресу F750, а также все добавленные нестандартные подпрограммы неизвестного назначения (это не "горит", так что сделаю такое ПЗУ позднее). Можете изучить исходник и выяснить самостоятельно зачем введены новые подпрограммы и что они полезного дают.
04.05.2017, 16:40
Denn

Вопрос из зала: какую задачу решает М4 ? Тобишь, что в его функционале принципиально новое относительно букета версий М3 ?
Увеличение major-номера версии как-то обязывает как минимум к околореволюционным новшествам.
04.05.2017, 17:26
barsik

Цитата:

Сообщение от Denn

какую задачу решает М4 ?

Вопрос не по адресу. Я только дизассемблировал с целью изучения. Сделал М4 не я.

Кстати, есть М4 В.Воронина, который сделан, как минимум, на 5 лет раньше. Ну а задачу М4 решает, как было написано в рекламе - переход от использования магнитофона к использованию дисковода. Правда такая реклама в 2000 году опоздала лет на 10. И ту же самую задачу, запихнуть загрузчик НГМД в ROM-BIOS, решил и А.Новгородв в начале 1992 года, сделав ПЗУ 3.30-D и 3.50-D (D означает дисковод). Только он лишь добавлял, ничего не выкидывая, сохраняя CCP M3.

В.Воронин делая свой М4, как мне кажется, хотел ввести возможность иметь стандартные подпрограммы (или упр.коды, уж не помню) для рисования на экране одинарных и двойных рамочек. Ну а как новые ПЗУ ещё называть? M1 M2 M3 заняты и у каждого из них своя концепция.

А нумерации никогда не хватает. Сначала в 1991-92 считали десятыми (т.е по 0.10 на версию). Дошли до 3.70 (эти версии делал не я). Когда я сам стал делать версии в 1993-95, то я стал считать сотыми 3.601, 3.602... 3.701... Но и этого не хватило, тогда нумерация была продолжена после 3.13, но до 3.2. Т.е - 3.140, 3.141, 3.142...3.146, 3.150...3.153. Я странслировал сотни версий, в основном уже после 1995-96, потому они не распространены.

Вообще-то мне сообщили, что в М4 есть п/п-мы чтения и записи сектора, что действительно имело бы смысл, т.к позволяет поднять уровень BDOS. А просто загрузчик НГМД - это действительно ничего нового.

Должен заметить, что разработка новой версии ROM-BIOS на основе имеющегося исходника, это по сути не серьёзная работа программиста. Работу сделали В.Сугоняко и В.Ивинских в 1991. А всё позднее - это лишь перетасовка кодов, по сути ничего не меняя. Т.е мелкие улучшения вызванные тем, что появилось место, куда что-то можно "впихнуть" и возможно сделать что-то чуть-чуть лучше (например, заткнуть писк по сбросу ВИ53, включить нужным образом окно в Z80CARD-II, заменить в фонте русские большие буквы на маленькие английские и т.п).

Цитата:

Сообщение от Denn

Увеличение major-номера версии как-то обязывает как минимум к околореволюционным новшествам

Согласен и в курсе, как фирмы нумеруют версии.

Я всегда хотел сделать ОРИОНУ приличный ROM-BIOS, засунув туда и драйверы шрифтов 6,7 и 8 и минимальную поддержку графики (перемещение по экрану указателя от мыши с возвратом позиции по нажатию её кнопки), а также дисководные п/п-ммы. У меня есть 2-х ПЗУ-шечный ROM-BIOS (4К вторая РФ2, две банки в окне F800...FFFF) содержащий подпрограммы дисковода (РК-КНГМД), что позволяло с'экономить 2 кб для подъёма уровня TPA DOS в банке 0, где ОЗУ совсем мало и потому это было полезно.
04.05.2017, 17:52
Denn

Цитата:

Сообщение от barsik

Ну а задачу М4 решает, как было написано в рекламе - переход от использования магнитофона к использованию дисковода.

Так это уже всё было в М3. И дисковод, и даже HDD.

Вообще говоря, глубокого смысла во впихивании всего этого в тесное ПЗУ Монитора нет, т.к. в концепте Ориона заложен ROM-диск и автостарт ПО из него.

- - - Добавлено - - -

Цитата:

Сообщение от barsik

Я всегда хотел сделать ОРИОНУ приличный ROM-BIOS, засунув туда и драйверы шрифтов 6,7 и 8 и минимальную поддержку графики (перемещение по экрану указателя от мыши с возвратом позиции по нажатию её кнопки), а также дисководные п/п-ммы.

В нативных 2 Кб нереально.
04.05.2017, 18:28
barsik

Цитата:

Сообщение от Denn

Цитата:

Сообщение от barsik

Я всегда хотел сделать ОРИОНУ приличный ROM-BIOS...

В нативных 2 Кб нереально

Ясное дело. Речь шла о так называемом XBIOS. Тогда, в 1993-94, ОРИОНСОФТ обещала сделать оверлейный ROM-BIOS для обычного ОРИОНА, что должен был быть подверсией мощного ROM-BIOS ОРИОН-ПРО. Он должен был хранить часть кода в ROM-диске. И это было реализуемо. Просто делать не стали. Поболтали в рекламе и забыли.

А я реально поставил в ОРИОН ПЗУ 27256 и даже двумя способами, каждый из которых поддержал программно. Первый вариант, это когда большое ПЗУ прокачивается кусками по 2К в окне F800...FFFF. Какой байт выкинули в порт FC, такой 2-х килобайтовый кусок и "виден" в окне F800.

Второй вариант уже использовал так называемое "теневое ПЗУ" в окне 0...7FFF. Причем ПЗУ F800...FFFF тоже бралось из этого 27256 (старшие 2К). Это теневое ПЗУ всё-время было как-бы в тени ОЗУ и не читалось. Но при его включении появлялось, и оттуда XBIOS работал с экраном. Это существовало с 1995, но спроса уже не было. Причём, была версия и для ОЗУ, грузящаяся из ROM-диска в банку 0 на адреса 0...7FFF (что годилось только для ДОС в банке 1). И там были графические подпрограммы (для перемещения курсоров мыши) и даже графический язык. Вот потому-то на всех моих ОРИОНАХ стоит вторая панелька на 28 ног, куда впоследствии оказалось удобно ставить 62256.

Впоследствии, когда ОРИОН успешно помер, всё это было мной выкинуто и остался только драйвер D8, на котором я и делал нортоны для всех DOS. Хотя драйвер D7 тоже приятный. Ради него я даже в 1998 сделал экран 448 (64 символа 7*10) и этот режим 448 даже поддерживался в моих эмуляторах до 2000 года. Это из-за того, что 10 МГЦ я не мог иметь, а 8.5-9 МГЦ мог (не было Z80H). А при таком пиксель-клоке растр в 480 точек уже не влезает в экран, а 448 как-раз влезает.

Почему в новоделах ОРИОНА не поставили такое теневое ПЗУ? Это самая разумная доработка и нужна в первую очередь для фанатов ORDOS и для других DOS в банке 0 (т.к для DOS в других банках драйвер шрифта может работать и из ОЗУ). Если когда-нибудь, где-нибудь будет ОРИОН с большим ПЗУ, с удовольствием странслирую для него ROM-BIOS.
05.05.2017, 13:46
Stampmaker

Цитата:

Сообщение от barsik

Если ROM-диска нет, то выводится промпт "? R/F/H" ?". По нажатию на R грузится ORDOS с ROM-диска

это как такое возможно? :v2_dizzy_stupid:
05.05.2017, 14:15
Denn

Цитата:

Сообщение от Stampmaker

это как такое возможно? :v2_dizzy_stupid:

Автоматика ROM-диск не обнаружила, но шанс есть... :)
05.05.2017, 14:28
barsik

Цитата:

Сообщение от Stampmaker

Цитата:

Сообщение от basik

Если ROM-диска нет, то выводится промпт "? R/F/H" ?". По нажатию на R грузится ORDOS с ROM-диска

это как такое возможно?

Всё так и есть. Сами смотрите в листинге. Когда мы нажали СБРОС и вывалились в запрос каманды R/F/H, то пока длится CONIN у нас достаточно времени, чтобы подключить ROM-диск и только потом нажать <R>. ROM-диск в М3 определяется по наличию байта C3 в ROM-диске по адресу 7FD, а в М2 с затратой большего числа байтов (чтением двух первых байтов ROM-диска и если они не равны, значит ROM-диск есть).

Если же при сбросе удерживать клавишу <G> или <I>, то игнорируя наличие ROM-диска будет загрузка с винта или из флопа. Причём при последующих нажатиях на кнопку СБРОС ничего уже удерживать не надо, т.к первое нажатие запомнится в последней ячейке ОЗУ F3FF и автоматически будет происходить загрузка из того-же устройства.

Код:

. CALL XF81B INC A LD HL,0F3FFH JP Z,NOPRES LD (HL),A NOPRES: LD A,(HL) CP 'G' JP Z,DIR_F CP 'I' JP Z,DIR_H ORDOS: LD DE,0BFFFH ; загрузка ORDOS c ROM-диска и старт LD HL,7FDH LD (DOPPPA+1),HL LD A,(DOPPPA) CP 0C3H JP NZ,NOROMD ; если в ROM-диске на 7FD не байт C3 LD L,E L30: LD (DOPPPA+1),HL LD A,(DOPPPA) LD (DE),A DEC DE DEC HL LD A,H OR A JP P,L30 JP 0BFFDH ; ────────────────────────────────────────────── TITR: defb 1FH,'?' defb 13,10,'R/F/H ?',0 NOROMD: LD HL,TITR CALL MSSG CALL MCONIN CP 'R' JP Z,ORDOS CP 'H' JP Z,DIR_H CP 'F' JP NZ,NOROMD DIR_F: LD A,0D0H ; команда ПРИНУДИТЕЛЬНОЕ ПРЕРЫВАНИЕ CALL EXECW . . . . . . . .
05.05.2017, 14:30
Denn

На самом деле, как выяснилось, если код загрузчика в ПЗУ ROM-диска начинается с двух одинаковых байтов, то автостарт не произойдёт.
И такая ситуация вполне возможна.
Например, мы стандартно делаем вначале переход на стартовый код: JMP START
При этом физически метка START будет иметь адрес B8C3h. В итоге в кодах будет так: C3 C3 B8...
Вот и напоролись (( Автоматика не выполнит автозапуск такого загрузчика. Придётся мануально.
05.05.2017, 14:45
barsik

Вложений: 1

Цитата:

Сообщение от Denn

Автоматика M2 не выполнит автозапуск такого загрузчика

Такое бывает только с монитором-2. Смотрите мой предыдущий пост. Вот потому-то монитор-3 по всем позициям всегда лучше.

Есть проблема из-за М2. Дело в том, что в М1 и М2 по-дурацки сделан вывод символов. Там сначала выводится 8 линий из фонта, а затем два нуля. Это приводит к тому, что символ не по центру знакоместа, а придвинут кверху. Поэтому балка подсветки инверсией получается некрасивой и рисовать рамки псевдографикой нельзя (оттого их при М2 всегда рисуют внаглую). В М3.0 и 3.1 сделано также но, в M3.11 и последующих М3 сделано не так. Там сначала выводится ноль, затем фонт 6*8 и затем снова ноль. От этого символ выводится по центру знакоместа. При этом число выводимых линий сокращено до 9, отчего шрифт в балке подсветски оказывается сцентрованным. Если выводить только стандартный фонт или загружать свой фонт, но весь, то никаких проблем не возникает.

Однако, нашлись идиоты, что стали подгружать только часть фонта. От этого подгруженный фонт оказывается смещённым на линию. Кроме того, из-за в ATLAS$ в бегущей строке искажаются буквы (естественно, есть кракнутый ATLAS$ где это исправлено).

Такая же проблема с KEYALT$, т.к он тоже загружает только часть фонта, а не весь (исправление таких программ, это исправление одного байта). Естественно, KEYALT$ тоже имеется исправленный.

Вопрос с позицией символа в знакоместе (т.е делать по центру или смещённым, как в М2) сейчас актуален. Т.к я не знаю как лучше сделать в перетранслированных версиях М1 М2 М3 для КР580 и Z80.

Кстати, интересный вопрос, кто написал KEYALT$ - авторы ОРИОНА в 1992, или омские луксиане в 1993? До 1994 никакого KEYALT$ не было, смотрите дистрибутивы. Омские луксиане прислали мне KEYALT$ в 1994 и сообщили, что они его авторы. И я всегда так и считал, пока не нашел недавно док-файлы, где указано, что это разработка авторов ОРИОНА, причём 1992 года. Или это разные KEYALT-ы. Но почему оверлей имеет тоже самое имя FT01?
05.05.2017, 15:05
Denn

Цитата:

Сообщение от barsik

Вот потому-то монитор-3 по всем позициям всегда лучше.

Цитата:

ROM-диск в М3 определяется по наличию байта C3 в ROM-диске по адресу 7FD

И чем это "лучше"?

Допустим я хочу поставить свой загрузчик, который не ОРДОС, а что-то своё. Зачем мне в 07FDh лепить С3h ?

Как раз наоборот, алгоритм проверки первых двух байтов на различия весьма удачный. В случае отсутствия ПЗУ мы читаем "00 00", в случае пустой ПЗУ - "FF FF", в случае физического отсутствия порта ROM-диска читаем два одинаковых байта "мусора", и только в случае осмысленных данных производим загрузку. Т.е. фактически корректно обрабатываем все реальные ситуации.

- - - Добавлено - - -

Цитата:

Сообщение от barsik

...и риссовать рамки псевдографикой нельзя (оттого их при М2 всегда рисуют внаглую).

В Мониторе изначально нет псевдографики в принципе. Да и рисовать графику (в т.ч. рамки) с помощью тормозного 6-пиксельного драйвера - это издевательство над трудящимися :)
В любом случае отрисовку графики делают мимо п/п Монитора.
05.05.2017, 15:47
barsik

Цитата:

Сообщение от Denn

В любом случае отрисовку графики делают мимо п/п Монитора

Правильнее сказать мимо стандартных входов ROM-BIOS. Так делают только авторы ОРИОНА и их последователи, не понимающие, что п/п-ммы ПЗУ слишком убогие и не могут выполнять роль основного драйвера. Что вызвано фатальной ошибкой разработчиков, не понявших, что нужно ПЗУ более 2К, чтобы иметь хороший ROM-BIOS, что в значительной степени определяет качество машины.

На вектора ПЗУ загружаются драйверы разных шрифтов. И в них нет разрыва в 2 линии в графике фонта (почти как в РК86, но там это хоть имеет аппаратные причины, здесь же просто глупость). И в фонтах даже самых мизерных драйверов 4*8 и 5*10, и то есть псевдографика и она сплошная.

Кстати даже с фонтом с шагом в 8 байтов и знакоместе с высотой в 10 линий, выводится сплошная графика по вертикали. Используется принцип как в IBM PC в VGA, когда включён аппаратный фонт 9*14, а реальный фонт имеет размер 8*14. Тогда адаптер VGA повторяет в 9-й колонке содержимое 8-й колонки. Т.к в буквах 8-я колонка это межбуквенный интервал, то на буквы и цифры это не влияет, но псевдографику сохраняет сплошной. Точно также и здесь, только не по горизонтали, а по вертикали (не знаю понял ли кто-то, но не в этом суть).

В нормальных цветных оконных драйверах, когда открывается окно, рамочки там всегда чертятся псевдографикой. И так это на всех компьютерах в мире. И в моих драйверах есть функция окрытия окна, которая выполняется так. Сначала меняются оконные параметры. Затем содержимое нового окна сливается в буфер (буфер работает по принципу: последний зашёл первый вышел, что даёт возможность открывать море перекрывающихся окон и всё восстанавливать, причём в цвете). Затем окно очищается, раскрашивается, рисуется двойная рамка, на которой пишется заголовок окна. И всё это делает только один искейп-код (закрывает окно также один ESC-код), отчего писать программы при наличии оконного драйвера совсем просто. Не надо "шариться" по экрану отсчитывая адреса и рисуя там что-то внаглую (а для имитации закрытия единственного возможного окна, перерисовывая весь экран). И программа, например НОРТОН написанная для шрифта 6*10 годится и при других шрифтах и даже для машины с текстовым адаптером. Вот так устроены грамотные программы.

Вот стандартные ячейки оконности введённые в мониторе-2. Именно их используют все оконные драйверы, начиная с исторически первого драйвера для ОРИОНА В.Ивинских. К сожалению, те кто писал другие драйверы (кроме меня) никогда не дизассемблировали ROM-BIOS ОРИОНА, а авторы ОРИОНА, придумав это, до использования окон так и не добрались, что странно. ПЗУ оконность поддерживает, но программы не используют (возможно ушёл тот, кто это придумал). Именно оконностью, М2 кардинально отличается от М1.

Код:

. HISCRN EQU 0F3CFH ; НАЧАЛЬНЫЙ АДРЕС ОКНА (high byte) WDTSCR EQU 0F3D0H ; ШИРИНА ОКНА В БАЙТАХ FRSTLN EQU 0F3D4H ; N ПЕРВОЙ СТРОКИ ОКНА SCHIGH EQU 0F3D5H ; КОЛИЧЕСТВО СТРОК ОКНА

А если кому-то не хватает скорости, есть Z80. Да и при наличии желания легко турбировать КР580 в ОРИОНЕ до 3 МГЦ, причём при исправлении плющености экрана ОРИОНА. Как раз ставлю сейчас КР580 в ОРИОН (была собранная резервированная плата ОРИОНА, где всё запаяно ещё в 1994, она предназначалось для установки 8088, да так руки и не дошли), чтобы реализовать именно такую доработку ОРИОНА.

Цитата:

Сообщение от Denn

Допустим я хочу поставить свой загрузчик, который не ОРДОС, а что-то своё. Зачем мне в 07FDh лепить С3h ?

Несостоятельный довод. ПЗУ F800 устроено так, что по сбросу читает из ROM-диска именно 2К и делает JMP на BFFD. Т.е у Вас только 3 байта. Какую иную команду кроме JMP, вы можете туда поставить, чтобы не потерять управление? Так что на 7FD в ROM-диске всегда стоит C3. К монитору-3, Вы не подкопаетесь. Нет ничего в М2, что там было бы сделано лучше, чем в М3, т.к его делал грамотный программист.

Цитата:

Сообщение от barsik

Хотелось бы улучшить качество ROM-BIOS ОРИОНА

К сожалению, фатальные аппаратные ошибки при разработке ОРИОНА, не позволяют как-то существенно улучшить качество ROM-BIOS. В имеющиеся 2 кб ПЗУ, освободив в нём ~300 ячеек ничего путного не уместить. Хотелось бы иметь 12 кб, ну хотя-бы 8 кб. Но увы.

Что-то улучшить без аппаратных доработок нельзя. Самый простой и лобовой вариант, это напайка второго этажа РФ2, дающая дополнительные 2 кб. Конечно и это позволило бы как-то улучшить драйвер вывода, но не кардинально. Есть и ещё вариант, для бедных. Это "открытие" под-ПЗУ-шечного ОЗУ. Тогда ПЗУ отключается и становится нечитаемым, а вместо этого оказывается недоступное ранее ОЗУ текущей банки. При Z80 это не проблема, а при КР580 надо иметь какой-то порт управления (т.к системные регистры F800, F900, FA00, FB00 отключаются).

То, что под-ПЗУ-шечное ОЗУ по адресам F800, F8F8, F900, F9F9, FA00, FAFA портится при работе программ, не проблема (это легко учесть программно или даже сделать доработку по защите от записи). Расход деталей в варианте 1: РФ2, ТМ9, ЛА3. А в варианте для бедных - 2-3 корпуса логики (сам это я делал лишь на Z80, а на КР580 пока такой схемы нет).

Задаю вопрос. Есть ли у оставшихся пользователей ОРИОНА интерес к резкому улучшению ROM-BIOS ОРИОНА, что неминуемо требует расширения ПЗУ? Качественный ROM-BIOS резко упрощает разработку программ, при таком же резком повышении их качества и делает возможным даже новичкам в программировании делать красивые графические программы.

Есть ещё один вариант улучшения ROM-BIOS для программ в банке 0 (т.е для ORDOS и CPM-48К). Это придуманная прямо сейчас, идея оверлейного ROM-BIOS с размещением оверлеев, т.е драйверов экрана в банке 1. Никто этого ранее не делал, но это ненамного сложнее и немного тормознее. Это хорошая идея и она мне пригодится для ДОС в банке 0, т.к там мне фатально нехватает места для драйверов (~10 кб) и кода ДОС (~10 кб).

Ой... раз уж речь о аппаратных доработках, чуть не забыл ! Свою давнюю идею "перекорёживателя ОРИОНА", что вполне решает проблему ROM-BIOS. Суть работы перекорёживателя в том, что он перемещает плоскость графики в банку 1. Когда экран включён с C000 то всё как и ранее. Но если экран с 8000, то в банке 0 всё ОЗУ доступно программам, а в банке 1 на 8000 - плоскость цвета, а на 0000 - плоскость графики. Понятно, что при этом квазидиску B - кранты. Зато CPM-48К в банке 0 может работать на все 60К. ROM-BIOS грузится с ROM-диска. А ORDOS я могу переделать так, что диск B будет читаться из банки 2, а не 1 и так далее. Так что фантаты ORDOS не пострадают. Расход деталей 3 дешёвых TTL-корпуса.
05.05.2017, 17:23
Denn

Цитата:

Сообщение от barsik

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

Актуально на машинах с быстрым (аппаратным) выводом символов. Но не на Орионе.

Цитата:

Сообщение от barsik

А если кому-то не хватает скорости, есть Z80. Да и при наличии желания легко турбировать КР580 в ОРИОНЕ до 3 МГЦ

На 10 МГц Ориона-ПРО 6-битный вывод символов тормозной.

Цитата:

Сообщение от barsik

Несостоятельный довод. ПЗУ F800 устроено так, что по сбросу читает из ROM-диска именно 2К и делает JMP на BFFD

Да, действительно, я уже забыл про эту "фишку" с запуском через "верхушку".
05.05.2017, 18:32
Error404

Цитата:

Сообщение от barsik

Задаю вопрос. Есть ли у оставшихся пользователей ОРИОНА интерес к резкому улучшению ROM-BIOS ОРИОНА, что неминуемо требует расширения ПЗУ? Качественный ROM-BIOS резко упрощает разработку программ, при таком же резком повышении их качества и делает возможным даже новичкам в программировании делать красивые графические программы.

Отвечая только за себе - не особенно интересно. Т.к. всегда чего-то не хватит, и надо будет расширять какие-нибудь функции присадкой на вектора ROM-bios. А раз так, то не лучше ли сразу иметь загружаемый в ОЗУ драйвер, который как минимум не нуждается в перепрошивке ПЗУ при его модификации. Собственно поэтому всегда использовал только минимальное ПЗУ с загрузчиком, остальное грузил с носителя.

Есть небольшая ниша для расширенного ROM-биос в моих нуждах - если надумаю делать версию UZIX стартующую "на голом Орионе", а не из под CP/M, и тогда можно использовать подпрограммы из ROM. Но опять же, консольного ввода и вывода хватит уже того что был в М3, а 80х25 там все равно не будет (т.к. это надо использовать экраны в начале ОЗУ). Оконные функции тоже врядли нужны - Uzix или CP/M про них не в курсе и не используют, а приложение должно работать через ядро ОС (и поэтому содержать оконный код в себе) чтобы быть совместимым кросс-платформенно.

Хорошая иллюстрация - ОрионПРО, где всяких функций в РОМ-БИОС имеется предостаточно, но ими не пользуется никто.
05.05.2017, 18:51
barsik

Цитата:

Сообщение от error404

Цитата:

Сообщение от barsik

Есть ли у оставшихся пользователей ОРИОНА интерес к резкому улучшению ROM-BIOS ОРИОНА?

Отвечая только за себе - не особенно интересно

Вам не интересно, потому что Вы не фанат ORDOS и не используете других ДОС в банке 0. А в системах, что работают не в банке 0, проблем с качественным и удобным драйвером нет, для загрузки драйверов есть целая банка 0 (за вычетом экрана).

А пользователям ORDOS и других ДОС в банке 0 всё это недоступно, отчего они и вынуждены пользоваться только "родным" убогим драйвером из ROM-BIOS, который вообще ничего не умеет, кроме как выводить символы КОИ-7 с вертикальным разрывом в 2 линии, отчего не может рисовать даже псевдографику (не говоря уж о том, чтобы открывать-закрывать окна и двигать спрайты). Благодаря убогости ROM-BIOS, ОРИОН с точки зрения программирования для банки 0, фактически низведён до цветного РК86 с сменяемым шрифтом.

А программ для ОРИОН-ПРО с использованием его возможностей не писали потому что программисты для ОРИОНА просто не "пережили" переход на ОРИОН-ПРО. Все программисты ненавидят возиться с железом (т.к программирование намного интереснее). Поэтому все знакомые мне программисты предпочли уйти с ОРИОНА, чем "трахаться" много лет с его сборкой и настройкой. Да и настроить ОРИОН-ПРО из тысяч сумели единицы.

Цитата:

Сообщение от error404

не лучше ли сразу иметь загружаемый в ОЗУ драйвер, который как минимум не нуждается в перепрошивке ПЗУ при его модификации

В этом-то и проблема. Куда в ORDOS или другой ДОС для банки 0 загрузить драйвер 12 кб являющийся расширением ROM-BIOS? Ведь в этой же самой банке экран, ДОС в 12 кб и если сюда мы загружаем оконный драйвер в 12 кб, то за вычетом кода программы у нас остаётся под дисковый буфер (нортона или редактора) ОЗУ с "гулькин нос", а ведь надо ещё найти место для большого буфера сохранения окон (для комфорта надо примерно 20 кб).

Кроме того драйвер в той же банке, где сама ДОС невозможен вот почему. Понятно, что разместить в ОЗУ банки 0 драйвер в 32К, содержащий драйвера всех шрифтов, графические подпрограммы и функции ROM-BIOS для работы с винтом, флопоми SD-картой не получится. Значит, остаётся иметь отдельные драйвера для каждого шрифта, а графику и поддержку винта и флопа откинем (пусть программист мучается и пишет это сам).

Итак, имеются драйвера всех шрифтов с размером от 2 кб до 12 кб. Если ДОС грузить на 12 кб ниже экрана, то в зарезервированное место мы сможем загрузить любой драйвер. Но уровень TPA фатально упадёт на 12К. Причём при загрузке драйвера в 2К, 10 кб в резервированном месте будут пропадать впустую. Если же я смогу переместить все драйверы в ROM-BIOS, то получу максимально высокий уровень TPA. А в концепции ORDOS вообще драйвера в 12 кб не предусмотрены.

Так что Ваш довод несостоятелен. Для ДОС ОРИОНА в банке 0 необходим хороший ROM-BIOS, иначе кроме программ уровня VC$ ничего сделать нельзя.

Интересно, хоть в каком-то новоделе ОРИОНА догадались поставить побольше ПЗУ?
05.05.2017, 20:40
Error404

Цитата:

Сообщение от barsik

Интересно, хоть в каком-то новоделе ОРИОНА догадались поставить побольше ПЗУ?

Так в Орионе ПРО и есть. Там целых два ПЗУ, в двух окнах памяти, первое 8к, второе - до двух мегабайт (я использую одномегабайтную 27c080).
05.05.2017, 21:02
OrionExt

barsik, мое мнение. Для меня достаточно М1 для наладки, М2 для работы. Я бы и М3 не использовал, если бы к нему небыли привязаны некоторые программы. Объем ПЗУ слишком мал для серьезных и объемных подпрограмм и драйверов. Пусть такие, как есть и остаются.

А вот подумать над расширяемым БИОС-ом стоит. Вот, допустим, прикрутили новую железку. Написали одну программу для этой железки. И все. А был бы с этой железкой БИОС глядишь, кто ни будь еще эту железку использовал в своем софте. Хотя бы ради спортивного интереса.

Как то уныло переписывать драйвер ВГ93 сотый раз:(

- - - Добавлено - - -

Как я тут писал, монитор кроме как для бутлоадера по сегодняшним меркам и не на что не годится.
05.05.2017, 21:40
Denn

М2 достаточно для загрузки с ROM-диска, а более и не нужно, ибо в первую очередь мониторный 6-битный вывод неюзабелен, имхо. К тому же с М2 работает всё классическое РК86/ОРДОС-наследие.
Все программные расширения прекрасно вычитываются из ром-диска и как правило запихиваются во вторую страницу, и хранить их в виде БИОС-ПЗУ практического смысла нет.

Максимум чего полезного можно было бы сотворить с монитором - это сделать "унисекс" поддержку клавиатур, имхо.
05.05.2017, 22:37
OrionExt

Цитата:

Сообщение от Denn

Максимум чего полезного можно было бы сотворить с монитором - это сделать "унисекс" поддержку клавиатур, имхо.

Вот интересно как "унисексить" клавы с 2048 байтами;)

- - - Добавлено - - -

МС клава - очень редкая. Еще от Корвета в то время подключали. Я вот бы от MSX клаву подключил бы. Клава весом 1/3 от всего компа – вечная!
05.05.2017, 22:38
barsik

Цитата:

Сообщение от error404

Цитата:

Сообщение от barsik

Интересно, хоть в каком-то новоделе ОРИОНА догадались поставить побольше ПЗУ?

Так в Орионе ПРО и есть. Там целых два ПЗУ, в двух окнах памяти

Заметим, что ОРИОН-ПРО это не заслуга никого из присутствующих и отнюдь не новодел. Точнее новодел 1993 года, хотя одновременно и долгострой до 1998. Значит во всех платах новоделов ОРИОН-128 так и оставили 2 кб. Это ошибка. Ну хотя-бы второе ПЗУ РФ2 могли бы предусмотреть.

Что фанаты ORDOS перевелись? А что DS-DOS тоже не имеет драйверов и обходится, как и VC$ подпрограммами из ПЗУ? Кажется только А.Вакуленко и ещё тульские аделаидчики поняли, что шрифт 8*8 лучще, чем 6*8 и использовали драйвер. Оттого у них и получились нормальные программы. А те, кто ориентировался на убогий драйвер из ПЗУ смогли сделать только неинтересные программы в интерфейсе РК86.

Мне казалось, что каждый программист заинтересован в хорошем ROM-BIOS. Но вероятнее, просто никто не хочет больше программировать для ОРИОНА, оттого всем и плевать. Печально.

А мне не плевать. Так что, сделаю себе ROM-BIOS в расширенном ПЗУ, включаемом в окне 0...7FFF. Железо у меня уже сделано, правда не ПЗУ, а ОЗУ 0...7FFF на 62256, включаемом битом D7 порта FC. Осталось чуть переделать схему и странслировать туда для начала просто драйвер D8, размером в 11 кб. Собственно роль такого ПЗУ может играть и ОЗУ банки 1. И если подумать о схеме, как это сделать, то получится что-то очень похожее на Z80CARD-I из 1991, где тоже в области 0...7FFF можно было включить другое ОЗУ. Эта концепция и предполагалась для решения проблемы драйверов. А Z80CARD-II решала иную проблему.

Но я попробую и другую идею, пришедшую в голову сегодня, что не требует аппаратных изменений. Это сделать тормозной драйвер работающий в банке 1. Если драйвер в банке 0 кидал в область F000...F3FF подпрограммы раскраски, то теперь придётся иметь на F000 подпрограммы вывода графики, хотя фонт остаётся в банке 1. Такой драйвер будет тормознее, но не более чем на 20%. Интересно только на сколько разбухнет Z80 код в 10-12 кб, если его перевести на КР580. По счастью я не увлекаюсь индексными регистрами, поэтому перевод на КР580 возможен, хотя как показал опыт это довольно утомительное дело.

Кстати, была ещё одна идея аппаратной доработки, хоть и менее победительная, чем "перекорёживатель". Это иметь бит, который меняет экранные плоскости местами (инверсия на ЛП5 выборки банки при попадании в экран), что позволяло бы работать с обоими плоскостями как из банки 0, так и из банки 1 без использования некоммутируемого ОЗУ F000.

Цитата:

Сообщение от OrionExt

МС-7007 клава - очень редкая

Не согласен. Их сделали тысячи, очевидно для наборов для сборки РК86 РК-03 (они также стояли и в других промышленных ЭВМ). И оказалось сделали много лишних. Они целый год в 1991 продавались в магазине "Юный техник" и довольно недорого. Я купил 3 штуки. И пользовался ими на ОРИОНЕ до 1996. Когда понял, что эргономика у них хреновая. Слишком маленький ход клавиш и нет фиксации при нажатии. Но всё же это было лучшее, что было в 1991, т.к альтернативой была РК-клавиатура на кнопках МП16.

Цитата:

Сообщение от OrionExt

Ещё клавиатуру КОРВЕТА подключали

Да. С.Корокин сделал такое ПЗУ М2 и пропагандировал это в 1993. Я тоже возможно так сделаю, т.к имею неиспользуемую герконовую клавиатуру от КОРВЕТА.

Цитата:

Сообщение от OrionExt

Я вот бы от MSX клаву подключил бы

И какая же в ней матрица? А вот я пытался подключить дохлую IBM PC клавиатуру к ОРИОНУ. Но как понял, токопроводящая резина слишком высокоомна для ВВ55.

Цитата:

Сообщение от OrionExt

Как то уныло переписывать драйвер ВГ93 в сотый раз

Вооюще-то это не проблема. Я транслировал CP/M явно больше тысячи раз и даже не вникал, как эти подпрограммы работают. У меня есть include-файл FLOP.INC (есть также файл RKFLOP.INC и VINT.INC). И я в него не заглядывал с 1991 года (а зачем, если работает). Так что какая трудность в "переписывании" кода ВГ93? Какой INCLUDE модуль вместе с ДОС транслируется, такое железо в ДОС и получается. Так что у меня есть аналоги всех ДОС ОРИОНА для винта и для РК-КНГМД.

Для подъёма уровня TPA, в ROM-BIOS полезно, как и в IBM PC иметь подпрограммы чтения и записи сектора и подпрограмму форматирования дорожки. Для РК-КНГМД я так и делал и эти две п/п-ммы умешались в моё второе ПЗУ РФ2. Правда это было мне невыгодно, т.к у меня было много форматов (разное число секторов на треке для 3-х типов дисков и дисководов и ещё CP/M и РК-ДОС) и ПЗУ для этого использовать стало невыгодно, так что сейчас я храню во втором РФ2 просто кусок фонта (весь фонт 8*10 имеет размер в A00 и в РФ2 не влезает), что увеличивает TPA на те же 2К.

Цитата:

Сообщение от OrionExt

Вот интересно как "унисексить" клавы с 2048 байтами

Если имеется ввиду уместить драйвер MS и драйвер РК в одно ПЗУ, то раньше это действительно было абсолютно невозможно, но недавно я освободил в ПЗУ М2 ~300 байтов и теперь всё-же возможны кое-какие варианты.

Драйвер РК-клавиатуры 318 байтов. Драйвер MS-7007 422 байта, а есть лишь менее 300. Однако, часть кода одного драйвера есть и в другом, так что реально надо смотреть и пробовать. Может быть что-то и получится. Но придётся выкинуть МГ-подпрограммы и вообще всё, что возможно.

Желательна процедура автоматической настройки на тип клавиатуры. Надо придумать какой-то признак, чтобы ПЗУ могло узнавать какой драйвер подключать.
06.05.2017, 00:25
OrionExt

Цитата:

Сообщение от barsik

Что фанаты ORDOS перевелись?

Ордос хороша для минимальных задач. А дальше каждый пошел своим путем.

Цитата:

Как то уныло переписывать драйвер ВГ93 сотый раз

- - - Добавлено - - -

Я не Denn:v2_dizzy_tired2:

MC в силу технологий уже сгнил.

MSX - клац.

- - - Добавлено - - -

Была бы еще доступней MSX (если бы головой думали). А так 5кг веса. Два компа через тонкую пленку. Штук 5 кнопок в хлам. На шасси (пластмасса) срезаны направляющие (клавиатуры).

- - - Добавлено - - -

Пеепцц, barsik, вы зависли во времени (форума и его странных часов). Тут длинные сообщения …

- - - Добавлено - - -

У меня 23.. у вас 00…
06.05.2017, 14:13
OrionExt

Цитата:

Сообщение от barsik

Я транслировал CP/M явно больше тысячи раз и даже не вникал, как эти подпрограммы работают.

Это тупик.

Вот правильное решение.

Код:

;--- MAIN ROUTINES ------------------------------------------------------------ ;### FDCOUT -> write sectors ;### FDCINP -> read sectors ;### FDCACT -> read and init media (only hardware and partion data, no filesystem)

Остальной аппаратно-зависимый код реализуется в БИОС-е.
06.05.2017, 16:04
barsik

OrionExt, не могли бы Вы изъясняться яснее. Смысл Вашего последнего поста непонятен.

Цитата:

Сообщение от OrionExt

Остальной аппаратно-зависимый код реализуется в BIOS-е

О каком BIOS-е идёт речь. Есть только ROM-BIOS ОРИОНА размером в 2 кб.

Только что, моё предложение расширить ПЗУ ОРИОНА не встретило понимания и с возмущением было отвергнуто прогрессивной общественнотью. Как я уже писал, на моих личных ОРИОН-ах ПЗУ чуть побольше (целых 4 кб), но и этого явно недостаточно. Т.к для ОРИОНА существуют, как минимум, 3 типа старых приводов, - это КНГМД на ВГ93 по схеме КОРВЕТА (это не считая экзотов типа SP-DOS), РК-КНГМД с несколькими кварцами (т.е с форматами до 880 кб) и винчестер (причём известны, как минимум, 3 или 4 варианта подключения IDE-винчестера к ОРИОНУ), а также несколько новых приводов (например, устройства на базе micro-SD).
06.05.2017, 17:37
OrionExt

Цитата:

Сообщение от barsik

О каком BIOS-е идёт речь. Есть только ROM-BIOS ОРИОНА размером в 2 кб.

ROM-BIOS ОРИОНА – это слишком громкое название. BIOS-а в Орионе никогда не было. А был Монитор, который успешно справлялся с возложенными на него задачами. Поэтому цепляться за него не имеет особого смысла и расширять на 2 Кбайта. Тут нужен именно расширяемый БИОС. Чтобы каждый мог добавить в него то, что ему надо (драйвер клавиатуры, дисплея, дисковода, часов, rs232 и т.д.). Вот как это сделать я пока слабо понимаю.
06.05.2017, 19:00
barsik

Цитата:

Сообщение от OrionExt

ROM-BIOS ОРИОНА – это слишком громкое название

Точное название. Название монитор справедливо только для М1 или М3. В М2 нет ни одной команды, а значит это только ROM-BIOS.

Цитата:

Сообщение от OrionExt

BIOS-а в Орионе никогда не было

Вероятно имелось ввиду, что хорошего ROM-BIOS у ОРИОНА никогда не было.

Цитата:

Сообщение от OrionExt

не имеет особого смысла и расширять на 2 Кбайта

Расширение ПЗУ до 4 кб было сделано в 1991 в составе платки Z80CARD-I. Изначально было ясно, что 2 кб слишком мало, а это был аппаратно самый простой и дешёвый вариант. С тех пор лишняя панелька и не снималась, т.к это оказалось очень полезно.

Цитата:

Сообщение от OrionExt

нужен именно расширяемый БИОС

Именно это и непонятно. Поясните о чём идёт речь. Как ROM-BIOS может быть расширяемым. Он же ROM - Read Only Memory, т.е не может меняться. И вообще, как Вы сможете что-то расширять, не расширяя одновременно ПЗУ?

И поясните главное. Для чего и для каких программ расширять ROM-BIOS. Потому-что, если это надо для ДОС в банках 1 или 2, то это один ROM-BIOS, а для банки 0, совсем другой. Причём для ДОС в других банках кроме нулевой, можно обойтись и без ПЗУ, используя ОЗУ банки 0, и называть это следует не ROM-BIOS, а драйвер с набором подпрограмм (которым полагалось бы быть в ПЗУ). ROM-BIOS это то, что в ПЗУ и для ДОС в банке 0 необходимо именно это. Если Вы ведёте речь о ДОС в других банках кроме нулевой, то здесь нет вопроса и обсуждать нечего.

Я нуждаюсь в ROM-BIOS который даёт большие возможности для программ в банке 0, но не отнимает в банке 0 ОЗУ отведённое для программ. И я вижу, что решить эту задачу можно только с помощью ПЗУ. Хотя и для ДОС в других банках ROM-BIOS полезен, т.к слишком хлопотно грузить эквивалентный драйвер в банку 0. Это значит, что каждая программа должна иметь механизм его загрузки и проверки.
06.05.2017, 20:07
OrionExt

Цитата:

Сообщение от barsik

Именно это и непонятно. Поясните о чём идёт речь. Как ROM-BIOS может быть расширяемым.

С каждой картой расширения идет свой BIOS. По аналогии как это сделано в MSX или PC-XT.
06.05.2017, 20:57
barsik

Цитата:

Сообщение от OrionExt

С каждой картой расширения идет свой BIOS. По аналогии как это сделано в MSX или PC-XT

Впервые эту идею применил Стив Возняк в 1976 году для Applle-I (и Apple-II). А авторы МИКРОШИ эту идею позаимствовали.

Чтобы иметь возможность включать ПЗУ в адресном пространстве на внешний разъём (слот) должен выводиться сигнал MEMDI (Memory disable), а на ОРИОНЕ это не предусмотрено.

Что речь идёт о идее встроить ПЗУ в КНГМД для ОРИОНА, как это сделано в КНГМД МИКРОШИ?

В Apple-II и в МИКРОШЕ было специально предусмотрено место, куда включается ПЗУ. В каких адресах может включаться ПЗУ внешней платки на ОРИОНЕ? Место не предусмотрено, значит только на месте ОЗУ или ПЗУ F800. А где именно? Универсальнее всего использовать участок F800...FFFF. Потому что для банки 0 для драйвера удобен адрес сразу ниже C000, а для банки 1 - сразу ниже F000.

Я не вижу в идее перемещения драйвера КНГМД в ПЗУ особой пользы. Это объём кода менее 2 кб, и это не так уж сильно обременяет код ДОС. И главное не даёт никаких решающих преимуществ для программ. Да и конструктивно, проще заменить панельку 24 ноги на панельку 28 ног на самой плате ОРИОНА, чем прикручивать к КНГМД ту же панельку, т.к на плате КНГМД не найти места для неё.

Если уж перемещать код в ПЗУ на плате КНГМД, то почему сразу не всю ДОС целиком, как это в РК-КНГМД для МИКРОШИ? Вот тогда удобство будет выше, - воткнул плату в слот, нажал на сброс и вот ты уже в ДОС. Только надо чуть доработать ПЗУ F800, чтобы при сбросе проверяло, включено ли в адресном пространстве ПЗУ расширения. Впрочем, всё то же самое получается при загрузке ДОС из ROM-диска, что я как раз всегда и использую уже более 20-ти лет.

Но всё это не то. Это не резкое улучшение качества ЭВМ, а просто мелкая и несущественная доработка. Это не решает проблемы ORDOS и других ДОС в банке 0, а именно это проблема. Чем ПЗУ на внешней плате лучше, чем "теневое ПЗУ" 0...7FFF в самом ОРИОНЕ, содержащее ROM-BIOS?

ROM-диск все считают хорошей идеей. А я нет. Намного лучше было бы, если бы в ОРИОНЕ ROM-диск включался бы в адресном пространстве, наподобие картриджа в Денди. Это одновременно заменяет и ROM-диск для хранения файлов и расширение ROM-BIOS. Подумайте сами, насколько качественнее стало бы ПО ОРИОНА, если бы вместо "болтающегося" внешнего ROM-диска в ОРИОНЕ изначально стоял бы просто разъём для установки доп.ПЗУ (да и ППА F500 экономится).
06.05.2017, 21:22
OrionExt

Ну не знаю. А мне такой подход нравится. Платы расширения со своим биос-ом (как пример) позволяют делать контроллеры дисковода на разных микросхемах. И дают возможность заниматься творчеством. А так собрал железку на ВГ93 и все.
06.05.2017, 22:13
Error404

Цитата:

Сообщение от barsik

ROM-диск все считают хорошей идеей. А я нет. Намного лучше было бы, если бы в ОРИОНЕ ROM-диск включался бы в адресном пространстве, наподобие картриджа в Денди. Это одновременно заменяет и ROM-диск для хранения файлов и расширение ROM-BIOS. Подумайте сами, насколько качественнее стало бы ПО ОРИОНА, если бы вместо "болтающегося" внешнего ROM-диска в ОРИОНЕ изначально стоял бы просто разъём для установки доп.ПЗУ (да и ППА F500 экономится).

В Орион-ПРО так и сделано. :)
РОМ-диск объемом до 2Мб (256 страниц по 8кб) в адресном пространстве. Это вторая из ПЗУ (ROM2), в ее начале Авторы разместили Монитор (команд на пятнадцать), Тест железа, конфигуратор, менеджер расширенной памяти (но максимум только лишь 512кб), Ордос, CP/M стартующую из ПЗУ (вот только не умеющую работать с этой ПЗУ - стартует она из ПЗУ и первым делом лезет в дисковод :) ). А дальше в расширении каждый может разместить что угодно (у меня например там своя CP/M но не только сама она как у авторов, но и диск с частоупотребимыми программами к которым она имеет доступ - ROM один из носителей).
А в первой ПЗУ (ROM1, 8к тоже в адресном пространстве) драйверы обоих типов клавиатур, шрифты, оконные подпрограммы, мышь, подпрограммы для доступа к дисководам и жесткому диску).
Вам срочно нужен ОрионПро. :) Я кстати подумываю развернуть агитацию на еще один ограниченный выпуск - кое-какие мелочи в шаблоне поправил и просто детали есть.
07.05.2017, 09:19
barsik

Цитата:

Сообщение от error404

Вам срочно нужен ОРИОН-ПРО

Нет не нужен. Если бы он даже был, я бы его и включать не стал. ОРИОН-ПРО - это не интересно. И ROM-BIOS там не такой, как хотелось бы, хотя его писал В.Пушков.

В качестве ЭВМ с большим ПЗУ у меня есть Супер-Турбо-4 С.Караваева, который уже в 1993 понял, что 2 кб ПЗУ это слишком мало, оттого применил 27256 с возможность программно включать её в адресах 0...7FFF, чтобы можно было расширить ROM-BIOS до 32 кб. Кстати именно такая архитектура работы ROM-BIOS и в западных 8-ми разрядках середины 80-тых, т.е ПЗУ должно быть "теневым" и включаться только на время прогона кода в нём.

У меня на той плате ОРИОНА, что работает (остальные 6 штук дохлые) стоит всего одно ОЗУ 62256, как 32К в банке 4 (т.е общее ОЗУ 241 + 32 кб). Но сейчас думаю, что более разумное использование 62256, это его использование для ROM-BIOS (что к тому же удобнее, чем 27256 на этапе отладки). Тогда, как на IBM PC, где при старте ROM-BIOS из ПЗУ копируется в ОЗУ (в ОЗУ скорость выше), можно грузить ROM-BIOS в 62256 из ROM-диска или откуда-то ещё.

Управление включением "теневого ROM-BIOS" кажется придётся делать по STA FB00 битом D7 (не по OUT FC). Хотелось бы по STA FC00, если этот порт на КР580 возможен. Тут нужен такой порт, что работал бы, как при КР580, так и при Z80 (в т.числе установленными по схеме ОРИОН-СЕРВИС), и не конфликтовал бы ни с какими клонами ОРИОНА. Что можете посоветовать?

Тут вопрос с портами STA FC00, STA FD00, STA FE00. Кажется, из-за упрошённой схемы дешифрации в ОРИОНЕ, при адресации в них произойдёт попадание в порты F800, F900, FA00, а команда OUT FF при КР580 попадает в порт FB00 (при Z80 этого нет, если команды OUT не лезут в память, т.е если нет КП11-тых подменяющих старшие адреса младшими при IN/OUT). Удачно, что при Z80 установленном без КП11, имеются не только порты OUT F8, F9...FF, но сохраняется и базовый порт STA FB00 (у меня он управляет ТУРБО/НЕТУРБО). Важно, что команда STA FB00 работает и при Z80 по схеме ОРИОН-СЕРВИС.

Поэтому, если управлять ROM-BIOS-ом портом OUT FC, то при КР580 это будет запись в адрес FCFC, т.е в порт STA FC00, что, возможно, эквивалентно STA F800, т.е произойдет неприятность. Как же при КР580 управлять включением "теневого ПЗУ" ?

Ведь на ОРИОНЕ с КР580 есть только свободный порт STA FB00, причём лезть в него по OUT FB нельзя, т.к при Z80 это включает что-то другое. Поэтому, видимо, для управления ROM-BIOS-ом придётся использовать порт STA FB00, что неприятно, т.к все мои ДОС придётся перетранслировать (этим портом они включают НЕТУРБО при работе с НГМД).

Никто не хочет проверить, куда в ОРИОНЕ с КР580 и в эмуляторах попадают команды STA FC00... ?

Показывать 40 сообщений этой темы на одной странице

Текущее время: 14:06. Часовой пояс GMT +3.