DSDOS для ПРК "Орион-128"

[Denn]

Публикую обещанное - программатор ПЗУ с электрическим стиранием: Winbond W27C512.

Уши этого устройства растут из варианта более универсального программатора УФ-стираемых ПЗУ (27x256, 27x512, 27C040, 27C080) для Орион-128. Практический опыт показал, что ПЗУ Winbond W27C512 самые удобные, и надобность в возможности прошивки УФ-стираемых ПЗУ, в общем-то, отпала. Для работы с W27C512 требуется меньше вариантов напряжений и минимум коммутации, в результате схема была ощутимо упрощена.
А поскольку W27C512 поддерживает мгновенное электрическое стирание, то было и упрощено ПО, обслуживающее программатор: не требуется отдельно выполнять проверку на чистоту и стирание, они выполняются автоматически перед прошивкой.
Исключительно с целью развлечения проект выполнен на совершенно "нефеньшуйной" элементной базе - SMD.

Фото программатора в сборе:


альт.ссылка на изображение


альт.ссылка на изображение

Конструкция рассчитана на применение углового разъёма, т.о. программатор вставляется под углом 90 градусов к плате ПРК "Орион-128":


альт.ссылка на изображение


Форм-фактор устройства в виде "затычки на параллельный порт" выбран не случайно. Дело в том, что применение соединительного кабеля (шлейфа) вызывает большое количество проблем со стабильностью работы устройства, требуется довольно сложная помехозащищённая конструкция кабеля. В общем, повторяемость устройства в выносном варианте (с применением шлейфа) была бы сомнительная.
Устройство изначально разработано для ПРК "Орион-128" (под порт пользователя #F600), но его также возможно использовать фактически на любой 8-битке, имеющей свободный порт ВВ55. В частности у меня в данный момент устройство подключено к мультикарте ПРК "Орион-ПРО" (к порту #20, через переходник) и успешно используется в работе.


Принципиальная электрическая схема программатора - (ссылка)

*Отдельное спасибо Сергею (aka Stampmaker) за помощь в разработке и изготовлении печатной платы и красивый чертёж схемы!


Внешнее питание не требуется, основное питание (+5в) конструкция берёт непосредственно из разёма порта, а необходимые для режимов записи/стирания напряжения (+12в и +14в) получаются при помощи step-up преобразования. Благодаря использованию высокочастотного (1,6 МГц) преобразователя LM27313XMF, возможно применение очень компактных компонентов обвеса (дросселя и конденсаторов), а также абсолютно бесшумная работа (никаких писков, свистов).

Ссылки на ключевые компоненты Step-Up преобразователя:

Преобразователь LM27313XMF

Дроссель CM453232-100KL, 10 мкГн

Керамические LowESR чип-конденсаторы 10мкФ X7R 25В

Для привнесения в конструкцию "немного ламповости", коммутация адресной линии и напряжения +14в в режиме стирания выполнена на малогабаритном реле с двумя группами переключающих контактов. На самом деле была попытка сделать этот узел на транзисторных ключах, но там выходило то ли 6, то ли 8 шт ПТ + их обвязка... в общем, реле однозначно победило.
Кстати, щёлканье реле весьма сексуально, и тихими зимними вечерами очень доставляет А ещё больше доставляет его цена в ЧиД - https://www.chipdip.ru/product/1-1462037-8-im03ts )) Но это уже совсем другая история...

В качестве микросхемы регистра защёлки адреса можно применить отечественную ИМС ЭКФ1533ИР23.

Важно! Элементы: R3, R4, R5 и R7 определяют точность напряжений программирования (+12в) и стирания (+14в), желательно применение компонетов с допуском не хуже 1%.


Программная поддержка представлена утилитой WBPROG$ (для каждой из платформ своя версия, включены в соответствующие сборки DSDOS v3.87). В будущем также планируется реализация в виде плагина к оболочке SHELL. При наличии интереса, возможно будут написаны варианты ПО и для других 8-биток.

Запуск утилиты без параметров традиционно выводит справку:


альт.ссылка на изображение

Конструкция программатора такова, что питание и управляющие сигналы на ПЗУ подаются только во время выполнения операции, после завершения которой на всех выводах устанавливается нулевой потенциал, т.о. возможна безопасная смена микросхемы. Перед выполнением операций, стирающих информацию в ПЗУ, сначала выводится предупреждающий транспарант, требующий подтверждения действия (кроме режима "W"!).

Полный образ для прошивки ПЗУ W27C512 занимает 64 Кб, в один файл он не помещается, а также не помещается в ОЗУ пользователя (48 Кб). Вопрос решён традиционно разбивкой образа на два файла (по 32 Кб каждый), которые по очереди загружаются в ОЗУ во время работы программатора. Формат файлов образа: <Имя>+<Расширение>. Имя - произвольные символы, допустимые в именах файлов ОС DSDOS, максимальное кол-во = 6. Расширение - два символа вида <#N>, где N - порядковый номер файла образа (0, 1). У обоих файлов образа <Имя> должно быть одинаковое, различие только в номере параметра <Расширение>! При указании имени файла образа в параметрах запуска утилиты, расширение указывать не нужно, его утилита формирует автоматически при поиске требуемого файла.

Режимы работы программатора задаются ключами. Режимы проверки чистоты ПЗУ и стирания не требуют указания имени файла образа - вводится только ключ. В остальных режимах указывается имя файла образа и ключ, порядок следования параметров произвольный.
В ходе выполнения операций на экран выводится индикатор прогресса. В операциях с файлами - в два прохода, соответственно.
Итак, собственно режимы работы программатора.


Проверка чистоты микросхемы [ключ /C]:


альт.ссылка на изображение

ПЗУ считается чистым, если во всех ячейках записано FFh. В противном случае выводится кол-во нестёртых ячеек.
Данный режим является наследием от ПО для программирования УФ-стираемых ПЗУ, большого практического смысла применительно к W27C512 в нём нет.


Ещё один режим, доставшийся от универсальной версии программатора - стирание [ключ /E]:


альт.ссылка на изображение

Позволяет мгновенно (за 200 мс) стереть всю информацию в W27C512. Полезен скорее для отладки программатора.


Программирование [ключ /P]:


альт.ссылка на изображение

Оба файла образа должны находиться на указанном устройстве (традиционно, без явного указания диска, поиск файлов осуществляется на рабочем диске ОС - "B:"), размер файлов должен быть 32768 байт. Возможна прошивка только одного файла (т.е. только первых 32 Кб ПЗУ), если второй файл образа отсутствует.
Перед началом программирования всегда выполняется стирание микросхемы!
Программирование каждого файла состоит из двух фаз: прошивка и проверка/допрошивка. Каждая фаза отображается своими символами, заполняющими индикатор прогресса.
Если во время проверки обнаруживаются несоответствия ячеек, то, согласно алгоритму производителя, выполняется до 10 попыток допрошить проблеммные ячейки.

В финале, если все ячейки запрограммированы успешно, выводится соотвествующее сообщение:


альт.ссылка на изображение


Альтернативный режим программирования [ключ /W]:


альт.ссылка на изображение

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


Проверка [ключ /V]:


альт.ссылка на изображение

Сравнение содержимого ПЗУ с образом. В режимах программирования выполняется автоматически.


Чтение [ключ /R]:


альт.ссылка на изображение

Чтение содержимого ПЗУ с сохранением в файлы образа на диск.


PS по вопросам изготовления печатной платы обращаться к Сергею

[Denn]

Драйвер расширения ExtDRV

Дальнейшее развитие ОС DSDOS привело к расширению функционала модуля консольного ввода-вывода CONIO с помощью драйвера ExtDRV.
Дополнительные процедуры позволяют организовать диалог с помощью оконного интерфейса, а также содержат готовые компоненты навигации по дискам/файлам и операций с ними.
Драйвер расширения интегрируется в ОС и его функционал доступен через API DSDOS (call BIOS, пул номеров подпрограмм: 50..61h).
Для работы требуется ОС DSDOS версии 3.87 и выше. Начиная с версии 3.88 драйвер будет интегрирован в сборки ОС, а на предыдущей версии возможна его установка с помощью утилиты EXTINST$:


альт.ссылка на изображение


Статус и версию установленного драйвера ExtDRV можно посмотреть утилитой SYSTEM$:


альт.ссылка на изображение


Концепт

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


альт.ссылка на изображение


Драйвер поддерживает работу с двумя типами окон:

1) Простое;
2) Сохраняемое.

Простое окно строится только в экранной области, при этом содержимое экрана на его месте теряется безвозвратно. При построении окна второго типа, драйвер предварительно сохраняет содержимое экрана под ним во временный файл на квазидиске, т.о. реализуется возможность "закрыть окно", с полным восстановлением информации под ним на экране. Механизм открытия/закрытия сохраняемых окон реализован по принципу стэка (LIFO). Каждое открытое окно второго типа создаёт свой временный файл на квазидиске, при закрытии окон соответствующие временные файлы удаляются. Максимальное количество открытых сохраняемых окон (теоретический программный предел - 255) ограничено их размерами, режимами открытия и свободным местом на квазидиске.
Сохранение и восстановление содержимого экрана под окнами реализованы с помощью ускоренных алгоритмов с использованием инструкций POP/PUSH, что позволило добиться приемлемой скорости на классическом Орионе-128 с процессором КР580ВМ80А (такт 2,5 МГц).

Окна обоих типов могут быть открыты в одном из двух режимов:

1). Монохромный;
2). Цветной.

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

Вид рамки задаётся отдельной процедурой конфигурации драйвера, и действует на все последующие открываемые окна. Есть также глобальная настройка "рамка по-умолчанию", этот вид рамки устанавливается при вызове процедуры конфигурации с кодом рамки FFh, данный функционал позволяет пользователю на уровне системы настраивать вид рамок окон в программах по своему вкусу. Доступны следующие виды рамок:

00h – без рамки*;
01h – одиночная «┌─»;
02h – двойная «╔═»;
03h – жирная «██»;
04h – сетка «▓▓»;
05h – орнамент «■■»;
06h – шахматная «»;
20h..FDh – пользовательская**.
_____________________________
* вся площадь окна доступна для консольного ввода-вывода, в остальных случаях рабочая область окна: (Ширина - 2) х (Высота - 2);
** рамка рисуется символом с соответствующим ASCII-кодом.


альт.ссылка на изображение


Работа с драйвером (информация по программированию)

Программный интерфейс драйвера описан в библиотеке WUI.L (SDK ОС DSDOS).

Первая процедура (EXTDRV_VERSION, код=50h) возвращает номер версии драйвера (традиционно, в BCD-арифметике), а также ID-код (BBh) и рабочую страницу ОЗУ драйвера.


Следующие две процедуры задают/возвращают (SET_TMP_DISK и GET_TMP_DISK, 51h и 52h, соответственно) диск для хранения временных файлов сохраняемых окон (по-умолчанию, это квазидиск «B:»).

Далее следуют процедуры записи/чтения конфигурации драйвера: SET_EXTDRV_CFG и GET_EXTDRV_CFG (53h и 54h). В текущей версии драйвера обслуживают типы рамки: текущий и «по-умолчанию», подробное описание в библиотеке WUI.L.


Следующими идёт группа процедур открытия/закрытия окон (55..59h).

Для открытия окна любого типа требуется указание следующих параметров:

1). Координаты левого верхнего угла (далее - ЛВУ): X (0..45*), Y (0..29*);
2). размеры: ширина (3..48*), высота (3..31*);
3). Цвет (00**..FFh***).
______________________________
* значение параметра в символах;
** значение 00h задаёт "монохромный" режим;
*** значение FFh не меняет текущий режим отображения, в случае цветного режима в качестве цвета берётся цвет родительского окна.

Размеры окна включают символы рамки (при её наличии), рабочая область окна на два символа меньше по каждому направлению.
Минимальный размер окна 3х3 (два символа рамки и один символ рабочей области), в соответствии с этим правилом заданы граничные значения геометрических параметров.
Процедуры открытия окна производят проверку параметров на корректность, в случае выхода окна за границы экрана, построение не производится и возвращается установленный флаг <C>, свидетельствующий об ошибке открытия окна.
В случае работы с сохраняемыми окнами также может иметь место ошибка файловых операций при сохранении/восстановлении содержимого под окном, в этом случае флаг <C> также будет установлен, а рег. [A] будет содержать код ошибки DSDOS. В программе пользователя достаточно отработать ошибку открытия окна, т.к. проблем с закрытием уже открытого быть не должно (за исключением случаев порчи содержимого квазидиска программой пользователя).

Краткий перечень процедур работы с окнами:

55h (WN_OPEN) – открытие простого окна, без сохранения содержимого экрана под ним;
56h (WN_CLOSE) – закрытие простого окна (восстановление параметров предыдущего окна/экрана);
57h (WN_OPEN_SAFE) – открытие сохраняемого окна;
58h (WN_CLOSE_SAFE) – закрытие сохраняемого окна;
59h (WN_CLOSE_AT_N) – закрытие всех сохраняемых окон до окна с номером N.

Подробное описание параметров см. в библиотеке WUI.L (SDK ОС DSDOS). В общем случае, каждая процедура возвращает статус (флаг <C>) и т.н. дескриптор (кординаты ЛВУ, размеры и номер) текущего окна. Размеры соответствуют фактическим размерам рабочей области окна. Номер первого открытого окна = 01h, второго = 02h и т.д.. Главный экран ПРК виртуально является «окном» с номером 00h. Для корректного завершения программы пользователя из произвольного места, требуется вызвать процедуру 59h с параметром N=00h, т.о. будут закрыты все открытые ранее окна. Это актуально только для сохраняемых типов окон. Открытие простого окна не изменяет счётчик окон, т.к. такое окно не участвует в процессе создания временных файлов на диске и восстановление содержимого под ним не требуется.
"Закрытие" простого окна восстанавливает параметры экрана до его открытия. Закрытие сохраняемого окна восстанавливает содержимое экрана под ним и параметры предыдущего окна.


Организация меню выбора представлена двумя процедурами: «Вертикальный список» (WN_MENU_VERT, код=5Ah) и «Горизонтальный список» (WN_MENU_HORIZ, код=5Bh):


альт.ссылка на изображение


альт.ссылка на изображение

В рег. паре [HL] передаётся указатель на структуру меню (строки последовательно, в формате ASCII), в остальных регистрах – параметры и режимы работы (подробности в библиотеке WUI.L).

Пример объявления структуры вертикального меню:

MENU_VERT:
DB ' Пункт #1 '
DB ' Пункт #2 '
DB ' Пункт #3 '

Процедуры не производят открытие нового окна и вывод заголовка, они только организуют само меню. Структура меню создаётся относительно текущих координат курсора, т.о. возможно произвольное расположение меню в текущем окне или на главном экране ПРК.
Для удобства программирования (минимизации кода ) есть режим закрытия последнего сохраняемого окна при выходе из меню, при этом, разумеется, окно должно быть открыто на момент вызова меню.
Меню представляет собой список пунктов, текущий отображается инверсией. Для навигации по пунктам используются стрелки и клавиши [Home]/[End], выбор текущего осуществляется клавишей [Enter]. Также возможен быстрый выбор нажатием цифры [1..9], соответствующей порядковому номеру пункта в списке.


Следующая группа процедур (5C..5Fh) представляет собой готовые компоненты работы с дисками и списками файлов на них, реализующие следующий функционал: выбор диска (из доступных в ОС), выбор каталога (на дисках F, G и H), выбор/открытие файла, сохранение файла.

Краткий перечень процедур:

5Ch (MENU_FOPEN_MIN) – сокращённое меню выбора файла, без открытия/закрытия окна;
5Dh (MENU_FOPEN) – расширенное меню выбора файла, без открытия/закрытия окна;
5Eh (WN_MENU_FOPEN) – расширенное меню открытия файла, с открытием/закрытием окна;
5Fh (WN_MENU_FSAVE) – расширенное меню сохранения файла, с открытием/закрытием окна;

Первые две процедуры универсальные, подходят для организации диалогов любых операций с файлами, не имеют никакой привязки к окнам, структура меню строится от текущих координат курсора, всё оформление диалога выполняет программист непосредственно перед вызовом процедуры.
В сокращённом варианте минимум входных параметров, список файлов представлен только их именами:


альт.ссылка на изображение

B расширенном задаётся режим отображения полей файлов в списке (вывести/скрыть: адрес посадки, длину hex/dec, атрибут защиты, страницу ОЗУ и дату):


альт.ссылка на изображение


Процедуры 5Eh и 5Fh являются готовыми компонентами открытия и сохранения файла, соответственно. Они самостоятельно открывают своё отдельное сохраняемое окно, положение и размеры которого автоматически подбираются так, чтобы оно было расположено в центре экрана ПРК:


альт.ссылка на изображение

По завершении выбора файла, окно диалога автоматически закрывается, содержимое экрана под ним восстанавливается и в программу пользователя возвращается дескриптор выбранного файла (в BIOS'е установлен текущим выбранный диск и имя файла).
В процедуре сохранения файла есть возможность выбрать имя файла из уже имеющихся в списке (запись «поверх») или ввести новое (соотв. поддиалог вызывается клавишей пробела):


альт.ссылка на изображение

В случае записи «поверх», процедура самостоятельно удаляет одноимённый файл на диске!


альт.ссылка на изображение

Непосредственно команды чтения/записи файлов и обработки статуса их исполнения программист выполняет самостоятельно, процедуры драйвера организуют только все необходимые подготовительные работы.
Во всех процедурах с файлами в рег. паре [HL] передаётся указатель на ASCII-строку (признак конца – 00h) шаблона(ов) для отбора файлов, отображаемых в списке. Если шаблонов несколько, то они разделяются пробелами. Например:

DB '.AS .TXT',0

При [HL]=0000h отбор игнорируется и выводится полный список файлов.
Кол-во файлов, видимых на экране (в окне) задаётся при вызове соответствующей процедуры. Если полный список длиннее, то реализуются скроллинг и листание страниц, а также переходы в начало/конец списка по Ctrl+[Home]/[End]. Навигация стрелками, [Home]/[End], [PgUp]/[PgDown], выбор файла – [Enter].
Выбор диска осуществляется нажатием соответствующей буквы [A..H], обновить содержимое текущего диска можно с помощью Ctrl+[R].
В заголовке отображается название действия, текущий диск и, если указан(ы), шаблон(ы) отбора файлов.
Внизу под списком файлов слева выводится номер текущего файла, на котором находится указатель, а справа в квадратных скобках общее количество файлов на диске.
В случае вызова файловых процедур с параметром «диск по-умолчанию» (имя диска = 00h, подробности в библиотеке WUI.L), страница и положение указателя последнего выбранного файла в списке запоминается, и при последующем вызове диалога восстанавливается (если содержимое диска к тому моменту не изменилось).


Заключительные две процедуры 60h и 61h выводят на экран сообщения в окне. Первая (WN_SHOW_ERROR) выводит расшифровку ошибки DSDOS, а вторая (WN_SHOW_MSG) выводит сообщение пользователя. Процедуры самостоятельно открывают и закрывают окно, размещение которого автоматически рассчитывается таким образом, чтобы оно было в центре экрана ПРК. В обоих случаях окно сохраняемого типа, в первом оно фиксированного красного цвета, во втором цвет (или его отсутствие) задаёт программист. Окно с сообщением пользователя имеет три режима:

1) Мигающий курсор после сообщения;
2) Курсор погашен;
3) Второй строкой выводится: [Enter]/[..]/[Esc].

Окно закрывается по нажатию любой клавиши, в программу возвращается её код, а флаги МП установлены как при возврате из процедуры INPUT_KEY модуля CONIO.

В процессе работы некоторых процедур драйвер использует область ОЗУ атрибутов цвета теневого экрана (8000..AFFFh стр.#1) для буферизации данных сохранения экрана под окнами и построения списка файлов по шаблону(ам), а также используются участки непереключаемого ОЗУ F300..F32Fh и F370..F37Fh для кода быстрого переноса экранных данных и формирования имён файлов, это следует учитывать при вызове процедур ExtDRV.


Демо

Для демонстрации возможностей драйвера ExtDRV написана программа EXTDEMO$, в архиве также прилагается её исходный код.


альт.ссылка на изображение

__________________________________________________ __________________________________________________ _

Ссылка для скачивания - архив в формате *.ORI

[OrionExt]

Denn, пилит свою ОСЬ (лет так 17 точно). Уважуха. Когда уже много задачность появиться на Орионе

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

Чоть навеело. Помню, исходники оси от Denn по модему качал.

[fifan]

Всё конечно замечательно описано, а почему не в отдельной теме даже если учесть что ПО под Орион. Программатор не укладывается в название темы: DSDOS для ПРК "Орион".

[Denn]

Когда уже много задачность появиться на Орионе

На 8-битке смысла нет. На классическом Орионе - тем более. Это если в привычном "писишном" смысле.
Виртуальная "многозадачность" в концепции DSDOS есть, она реализуется с помощью сохранения текущего состояния программ в конфигурационных файлах, т.о. запуск программы можно рассматривать как переключение к данной задаче. Оболочка ОС в качестве "переключателя". Также есть механизм call-вызова программы из программы. Имхо, для Ориона этого вполне достаточно.

Помню, исходники оси от Denn по модему качал.

Использовать писи для хранения файлов Ориона, емнип, я начал в конце 2015-го года, до этого жил на дискетах, т.е. полностью в 8-битном домене. Но и после 2015-го исходники публично не выкладывал. Соответственно, вопрос: откуда?

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

Всё конечно замечательно описано, а почему не в отдельной теме даже если учесть что ПО под Орион. Программатор не укладывается в название темы: DSDOS для ПРК "Орион".

Наверное, справедливое замечание.
Но с другой стороны, если я выложу сабж в разделе про железо (а по специфике форума оно как бы автоматом подразумевается для спектрума), то будет странно. Как известно, железка без ПО смысла не имеет, а ПО обслуживающее данный программатор есть только под Орион, и только под DSDOS.. получается, что есть смысл публиковать там, где обитает народ, интересующийся DSDOS. По-моему так (С)

[fifan]

Наверное, справедливое замечание.
Но с другой стороны, если я выложу сабж в разделе про железо (а по специфике форума оно как бы автоматом подразумевается для спектрума), то будет странно. Как известно, железка без ПО смысла не имеет, а ПО обслуживающее данный программатор есть только под Орион, и только под DSDOS.. получается, что есть смысл публиковать там, где обитает народ, интересующийся DSDOS. По-моему так (С)

Я не говорил переместить в другой раздел, а оставить в Орионе, но под новым заголовком.

[Advertiser]

[Denn]

fifan, предлагаю этот вопрос оставить на усмотрение модератора.

П.С. если я буду по каждой своей железке и софтинке генерить новые темы, то наоборот предполагаю появлении армии недовольных ("оно всё равно работает только под твоей осью, нафига оно в общем разделе?").. палка о двух концах, однако.

[barsik]

Всё конечно замечательно описано

Это мягко говоря, преувеличение. С документацией плохо. Если просто из любопытства почитать тему, то да, есть что почитать и посмотреть - "много букаф", интересные фото и скриншоты.

Но нет документации для программиста в нормальном виде. Да и для пользователя документации нет, это значит, что надо читать всю эту тему, запоминать информацию. Даже HELP-ов нет, хотя это совсем не проблема - вывод текстового файла на экран, если нажали <F1> и нужный HLP-файл есть на диске.

Здесь все на PC, потому тексты должны быть сразу доступны на PC, а не в каком-то левом формате, чтобы прочесть который надо истратить море времени и усилий. Зачем применять нестандартную собственную кодировку, для конверсии из которой нет программ. У меня есть программка ORD.EXE 20-ти летней давности для чтения и конверсии текстов ОРИОНА во всех кодировках в формате ORD, но и она не расчитана на такие тексты.

Почему в DSDOS использована не КОИ-8 или КОИ-7 и даже не АЛЬТ-кодировка, а кодировка полученная из КОИ-8, в которой для символов выше C0 отксорен бит D5. Пришлось написать программку на QUICK-бейсике, чтобы конвертировать в нормальный вид, но и это не помогло, т.к в одном файле нормальные разделители 0D,0A, а в других только 0D. Логично было ожидать единообразие.

Обычно экранные процедуры делают искейп-кодами, т.к тогда сохраняется к ним доступ из ЯВУ. Так делали даже в промышленных графических терминалах, например, цветной графический ИЗОТ-1031C. В данной системе нет разделения на DOS-BIOS и DOS-BDOS, один общий BDOS, потому и функции, что должны быть в ROM-BIOS или в загружаемом драйвере включены в BDOS. Экранный драйвер с оконными функциями полезно выделить в отдельный файл (обозвав XBIOS), чтобы его можно было использовать без DSDOS.

А ещё лучше сделать установку теневого ПЗУ (Shadowy ROM) в адресах 0...7FFF и прошить туда этот цветной оконный драйвер, дополнив его процедурами для поддержки мыши и GUI. Причём можно сделать грамотно, чтобы это никого не напрягало и проблем бы не создало. Стандартизуются только интерфейс и функции (а будет это физически реализовано за счёт апп.доработки в теневом ПЗУ или у того, у кого его нет будет отнимать кучу места в ОЗУ ОРИОНА и дико тормозить, - это не важно).

Зачем понадобился формат ORI? Это нестандартный формат, его даже эмуляторы не поддерживают. Не было смысла плодить сущности. Что он даёт относительно формата ORD, кроме никому ненужной сигнатуры? Но ведь и без сигнатуры в 16 байтов, каждому ясно, что если расширение ORD, то это формат ORDOS. У меня все файлы для 4-х разных 8-ми разрядок имеют расширение ORD, потому что это удобнее, чем МГ-производные форматы RKO, RKP, RKR, RKA, RKS, GAM...

Формату ORD не хватало контрольных сумм. Для PC это не актуально, а вот для реального ОРИОНА с эл.диском из излишнего ОЗУ, где у памяти нет 9-го бита паритета для контроля дохлоты, КС намного полезнее, чем дата файлов. Кстати, в других DOS такой проблемы нет, т.к есть КС секторов.

Но как раз 4 байта метки файла в базовом стандарте ORD свободны (занят лишь 1 бит в первом байте, как флаг R/O). Потому 15 битов я сначала резервировал под дату файла, а 2 последних байта использовал, как КС. Но т.к апп.часов у меня в ОРИОНЕ не было, то бит с оффсетом 12 я обычно использовал в качестве токена для расширения файла, что позволяло 128 расширений (COM,BAT,TXT,ASM,TX,AS...) и не мешала ORDOS флагу R/O. А два последних байта ORDOS-метки использовал для КС. В моих оболочках LORD специально есть команда нормализации ORD-файлов (директива <N>), которая подставляет контр.сумму ORD-файла.

В эмуляторе на PC контр.сумма ORD-файла не важна, в то же время дата доступна. Потому разумно этими 4-мя байтами распорядиться так. 1 байт - байт паритета блока (сумма байтов по XOR), в значительной степени это замена КС, 2 байта - дата файла и 7 битов на расширение файла. Давайте подумаем все вместе и введём общепризнанный разумный стандарт на эти 4 байта, - ранее я встречал кучу вариантов их использования и сам использовал по разному.

Логика панелей в нортоне DC$ имеет неудобство, т.е не как общепринято. При нажатии вправо в левой панели указатель не должен сразу перескакивать на соседнюю панель. По первому нажатию клавиши <вправо> указатель должен перескакивать на самую нижнюю строку текущей страницы, а если уже на последней строке страницы (списка файлов), то на последнюю строку последней страницы. И только если указатель стоит на самом нижнем файле в списке, то по нажатию вправо происходит переход в правую панель. Для перехода между панелями служит TAB. А клавиши <влево> и <вправо> в панели служат для перехода к первой и последней строке отображаемой страницы.

Раз DSDOS теперь может работать с нормальным КНГМД, то отчего в дистрибутивах эмуляторов нет поддержки дисковода в DSDOS-конфигах. Обычный нормальный КНГМД многие эмуляторы поддерживают, в отличие от КНГМД для SP-DOS. Почему не попросить авторов эмуляторов доработать конфиг-файл, предназначенный для DSDOS? Это же дописать всего несколько строк. А в саму DOS полезно встроить внешний файл-драйвер, при замене которого DSDOS начинает работать с другим типом носителя (флоп, винт, флэш).

[HardWareMan]

Denn, значит пора создавать твой раздел, с карточными играми и куртизанками!

[OrionExt]

Использовать писи для хранения файлов Ориона, емнип, я начал в конце 2015-го года, до этого жил на дискетах, т.е. полностью в 8-битном домене. Но и после 2015-го исходники публично не выкладывал. Соответственно, вопрос: откуда?

Ну, вы барин задачу ставите Поскрипел мозгами, пошуршал по дискам.

А это чье? Не мое

04.06.2016  13:34    <DIR>          .
04.06.2016  13:34    <DIR>          ..
22.08.2000  10:54            34644 BIOS.TXT
22.08.2000  11:43            13421 BOOT.TXT
22.08.2000  11:43            20044 DSDOS.TXT
22.08.2000  11:44            22255 GRAPH.TXT
22.08.2000  11:42             8040 KERN.TXT
               5 файлов         98404 байт

BOOT.TXT

; Program DSDOS BOOT-loader from ROM-disk
; (C) Solovjov D.N.   /01.09.98/
; Last changes: 11.03.2000

WP:    EQU 1; рабочая страница ОЗУ DSDOS
STACK: EQU 0F3C0H; стек DSDOS
DSDOS: EQU 0F3F0H; старт DSDOS
PDSDOS:EQU  5000H; адр.нач. блока кодов DSDOS
BIOS:  EQU 0F000H; вызов процедур BIOS

M_BOOT:EQU 0A000H; адрес загрузки BOOT-СЕКТОРА
S_BOOT:EQU 0A010H; адрес старта FDD-загрузчика
B_FONT:EQU 0AD00H; знакогенератор ПЗУ "Монитор"

M_SOUR:EQU 0F3FEH; ист-к DOS: 00H-ROM, FFH-FDD
M_IDX: EQU 0F3FFH; признак присутствия DSDOS

PT_CFG:EQU 0F503H
PT_ADR:EQU 0F501H
PT_DAT:EQU 0F500H
ROMDIR:EQU 0800H; ад.нач. ROM DIR

RESET: EQU 0F800H
KEY:   EQU 0F803H
SCN:   EQU 0F81BH
PRC:   EQU 0F809H
MSG:   EQU 0F818H
PRH:   EQU 0F815H
UZG:   EQU 0F82DH
SVBYTE:EQU 0F839H
LDBYTE:EQU 0F836H

BegnZG:EQU 0F3D1H
M_BEEP:EQU 0F3E7H

PORT_2:EQU 0F402H
PtPAGE:EQU 0F9H


ORG 0B800H


JMP START

DB '             '
DB '                '
DB '                '
DB '****************'
DB '** DSDOS V3.5 **'
DB '****************'
DB '                '
DB '(C) SOLOVJOV D.N'
DB '                '
DB '(C) 2000 ST.-PTB'
DB '                '
DB '(C) ORION-128.2 '
DB '                '
DB 'ROM BOOT-LOADER '
DB '                '
DB 'CREAT 11.03.2000'
DB '                '
DB '      '

[свернуть]