Скажу честно. Прикольная система. Но расширения от слова нуль - тут.
Вид для печати
Скажу честно. Прикольная система. Но расширения от слова нуль - тут.
Καλημέρα για όλα!
Делюсь новой "поделкой". Заначка этого ПО датирована у меня в исходниках аж 1999-ым годом, тогда была написана основная часть движка, но к сожалению в силу жизненных обстоятельств проект был заброшен. Сейчас возникла насущная необходимость и проект был воскрешён и доведён до боевого образца, в связи с чем и решил его опубликовать.
Итак, речь идёт о компиляторе языка ассемблера. Доселе я пользовался замечательным ассемблером из пакета "Микрон" (а точнее усовершенствованным вариантом - АССЕМБЛЕР «М&S»), адаптированным под Орион-128+ORDOS (а впоследствии и под DSDOS), но его возможности были исчерпаны и возникла потребность в бόльшем функционале. Основной проблемой микроновского ассемблера является ограничение на размер компилируемого кода и всего 6 значащих символов у меток/констант. Также не хватает условной компиляции и некоторых других "плюшек", без которых конечно обойтись можно, но порой тоскливо.
Сразу оговорюсь, что при разработке нового ассемблера (далее - "DSDOS ASSM" или просто "DASM") я руководствовался исключительно своими потребностями, без особой оглядки на моду, "вражеские" стандарты и прочие условности. Идеология как и у всего проекта DSDOS: максимальная скорость работы, максимальный комфорт использования, минимальный занимаемый объём, никакой глобализации - только решение насущных задач в рамках платформы Ориона.
В основу положен функционал микроновского ассемблера, о котором можно почитать тут, в связи с этим в описании буду стараться не пересказывать функционал Микрона, а расскажу о нововведениях и отличиях.
Основные ТТХ:
■ синтаксис команд: Intel_8080 style (MOV, STA, LHLD и т.д.);
■ поддержка некоторых команд МП Z80 (альт.регистры, короткие переходы, циклы, операции с отдельными битами регистров*);
■ максимальное кол-во значимых символов меток/констант - 14;
■ поддержка латинских и русских букв (регистрочувств.), а также символов псевдографики в именах меток/констант;
■ регистронезависимое написание команд, операторов и операндов (MOV A,B | mov a,b | MoV a,B | etc.);
■ логические операции над константами ("И", "ИЛИ", "НЕ", "ИСКЛЮЧАЮЩЕЕ ИЛИ");
■ поддержка двоичной, восьмеричной, десятичной и шестнадцатеричной с/с.
■ ускоренная обработка таблицы меток (методом деления пополам);
■ размер буфера выходного кода до 28 Кб**
■ буфер меток/констант до 1700 шт.**
■ условная компиляция кода;
■ мультифайловая компиляция (разбиение исходного кода на несколько файлов);
■ динамическое подключение текста при компиляции;
■ динамическое подключение бинарных данных (ресурсов) из файлов;
■ заполнение массива константой;
■ множественные ORG;
* в настоящей версии (v2.7) реализована поддержка команд переключения наборов регистров на альтернативные (EXX и EXA), остальные будут добавляться по мере реальной необходимости.
** в настоящей версии буфер таблицы меток и выходного кода единый, расположен в дополнительной странице ОЗУ, в адресном пр-ве 8000..EFFFh, в ТТХ указаны предельные значения каждого параметра, при компиляции реального кода одновременно они недостижимы, и фактические значения будут меньше. В планах добавление возможности работы с расширенным ОЗУ (с потерей квазидиска), в таком варианте буферы таблицы меток и выходного кода будут расположены в разных страницах, и предельные значения будут фиксированные: до 3840 меток и до 60 Кб выходного кода независимо!
Мультифайловая компиляция (файл проекта)
При написании больших программ (около 8 Кб и более) всплывает страничное ограничение Ориона, т.к. тело ассемблера, исходный текст программы, таблица меток и выходной код физически расположены в одной странице ОЗУ и на всё про всё отведено 48 Кб. Для обхода ограничения выбрана стратегия "размазывания" исходного текста программы на несколько файлов (далее - модулей) и размещение таблицы меток с выходным кодом в дополнительной (системной) странице ОЗУ #1. Текстовый редактор Gemini-EDIT в ОС DSDOS позволяет одновременно работать с восемью текстовыми файлами, т.о. работа с "размазанным" исходником не представляет трудностей, при этом ассемблер обрабатывает модули по очереди, загружая в ОЗУ только один (текущий).
Список модулей в порядке их обработки перечислен в специальном файле проекта "*.PR" или "*.P", имя которого указывается в качестве параметра при вызове DASM.
Пример файла проекта MYPRG.PR:
Файлы модулей должны находиться на том же диске, где файл проекта.Код:; Исходник программы MYPRG (из двух частей)
PART1.AS ; часть I
PART2.AS ; часть II
Файл "*.PR" может содержать следующую информацию:
- имя файла модуля;
- комментарий;
- пустая строка.
Имя файла модуля указывается в формате ОС DSDOS, задание имени диска не поддерживается. Одна строка может содержать только описание одного модуля. Информация после имени файла через пробел игнорируется, что можно использовать в качестве комментария.
Строка с комментарием должна начинаться с символа ";". Пробелы в начале строк, а также пустые строки игнорируются при обработке.
Команды компилятора и операторы языка ассемблера в файле проекта не поддерживаются!
Содержимое файла проекта используется на всех стадиях компиляции, т.о. оно постоянно находится в основной странице ОЗУ и "отъедает" часть буфера текущего модуля.
На каждом проходе компилятор подгружает очередной модуль согласно списку из файла проекта и обрабатывает его, при это на экран выводится имя файла подгруженного модуля.
С точки зрения программиста, разбиение исходного текста на модули никак не влияет на процесс его обработки. Виртуально компилятор воспринимает весь текст целиком.
Т.о. если встречается команда условной компиляции в одном модуле, то её действие также распространяется на последующие. Однако действие команды принудительного окончания обработки (END) распространяется только на текущий модуль!
Компилятор определяет алгоритм работы по расширению рабочего файла, указанного при вызове DASM. Если расширение ".PR" или ".P", то рабочий файл интерпретируется, как файл проекта, в таком случае компилятор ищет в нём файлы модулей. В противном случае рабочий файл интерпретируется, как монофайловый исходник (обычно с расширением ".AS" или ".A") и DASM непосредственно приступает к его компиляции. При загрузке файлов производится проверка формата, и если файл не является текстовым, то работа компилятора прерывается с сообщением: "Ошибка формата".
Рабочий диск задаётся при указании имени рабочего файла при вызове DASM. На этом диске также размещается файл выходного кода, имя которого по-умолчанию формируется компилятором автоматически по следующему принципу: часть имени исходного файла модуля или проекта до точки расширения (но не более семи символов), плюс символ исполняемого файла - "$".
Имя файла выходного кода может быть задано программистом в исходном коде - с помощью команды FILE (см. далее).
Буферизация данных
В процессе работы компилятор создаёт в буферном ОЗУ следующие данные: таблицу меток/констант и выходной код программы. При успешном завершении компиляции выходной код сохраняется в файл.
Буфер расположен в дополнительной странице ОЗУ, в адресном пр-ве 8000..EFFFh. На первом проходе компиляции создаётся таблица меток, а на втором, сразу после таблицы, - выходной код.
Есть две ключевые точки при заполнении буфера:
1) Превышение порога BFFFh
2) Превышение порога EFFFh
В первом случае данные попадают в область атрибутов цвета C000..EFFFh, и чтобы на экране не было мусора, DASM автоматически переключает режим отображения на монохромный.
Во втором случае достигнута верхняя граница буфера и процесс компиляции прерывается, с выводом соответствующего сообщения об ошибке. Синтетический тест показал, что при данном размере буфера возможна компиляция выходного кода размером до 20 Кб. Предельное значение может варьироваться в зависимости от содержимого реального кода программы и количества используемых меток/констант.
На время использования буфера, на квазидиске во временном файле "~DASM" сохраняется содержимое области драйверов B000..BFFFh ОС DSDOS, по окончании компиляции оно восстанавливается (временный файл удаляется).
Все вышеописанные процессы с буферизацией актуальны для текущей версии, не использующей расширенное ОЗУ квазидиска.
Системы счисления (с/с)
DASM поддерживает следующие с/с:
1) Двоичная (bin)
2) Восьмеричная (oct)
3) Десятичная (dec)
4) Шестнадцатеричная (hex)
Двоичные числовые константы обозначаются символом "b" (или "%") после всех разрядов числа. Допустимые цифры "0" и "1". Незначащие нули в начале можно опускать. Максимальное количество разрядов - 16.
Пример:
Восьмеричные числовые константы обозначаются символом "o" после всех разрядов числа. Допустимы цифры "0..7". Незначащие нули в начале можно опускать. Максимальное количество разрядов - 6.Код:MVI A,1111b ; [A] = 0Fh
LXI H,1111000010101110% ; [HL] = F0AEh
Пример:
Десятичные числовые константы записываются в привычном виде и не требуют спец. символов после цифр. Допустимы цифры "0..9". Незначащие нули в начале можно опускать. Максимальное количество разрядов - 5.Код:MVI A,17o ; [A] = 0Fh
LXI H,177777o ; [HL] = FFFFh
Пример:
Шестнадцатеричные числовые константы обозначаются символом "h" после всех разрядов числа. Допустимы цифры "0..9" и буквы "A..F" (или "a..f"). Незначащие нули в начале можно опускать. Если число начинается с буквы, то перед ней обязательно требуется указывать незначащий ноль, в противном случае компилятор интерпретирует значение, как метку. Максимальное количество значащих разрядов - 4.Код:MVI A,15 ; [A]=0Fh
LXI H,32768 ; [HL] = 8000h
Пример:
Регистр символа признака с/с также не имеет значения.Код:MVI A,0Fh ; [A]=15
LXI H,0F800h ; [HL] = F800h
Выражения
В качестве числовых значений операндов возможно использование выражений с применением числовых/символьных констант, меток и следующих математических и логических операций:
1) Сложение "+"
2) Вычитание "-"
3) Умножение "*"
4) Деление "/"
5) Побитовая инверсия - "~" *
6) Логическое И - "&"
7) Логическое ИЛИ - "|"
8) Логическое ИСКЛЮЧАЮЩЕЕ ИЛИ - "#"
* в случае слов действует только на младший байт (для исключения ложной ошибки "Значение вне диапазона" при использовании с однобайтовыми операндами), для полной инверсии слова можно использовать конструкцию "Var # FFFFh"
Вычисление производится последовательно слева-направо, без приоритетов. Знак инверсии ставится перед числом/константой/меткой, остальные - между ними. При взятии значения с инверсией, сначала применяется инверсия, а затем выполняет операция.
При вычислении все значения представлены в виде слов, т.о. результат всегда находится в диапазоне 0..65535. Если при выполнении операции происходит переполнение или "уход в минус", то выводится ошибка: "Переполнение", при этом результат вычисления остаётся корректный (с учётом отбрасывания битов за пределами слова). Например, "65535 + 2" вызовет ошибку переполнения, а в результат запишется значение "1". Аналогично, "0 - 1 = FFFFh" .
В случае однобайтовых операндов компилятор проверяет, чтобы значение выражения было в диапазоне 0..255, и при превышении верхней границы выводит ошибку: "Значение вне диапазона". При этом в выходной код записывается значение младшего байта слова результата.
Например:
При попытке деления на ноль компилятор выводит соответствующую ошибку, при этом дальнейшая обработка выражения прерывается, в выходной код записывается результат, посчитанный до момента обнаружения ошибки.Код:VAR:EQU 0A8FFh
MVI A,VAR ; здесь компилятор выдаст ошибку-предупреждение, а регистру [A] будет присвоено значение FFh
Скрытый текст
Некоторые примеры выражений:
Код:MVI B,1111b + ~0Fh ; регистру [A] будет присвоено значение FFh
VAR1:EQU 0F800h
VAR2:EQU 0F8FEh
VAR3:EQU VAR2 - VAR1 ; VAR3 = FEh (F8FEh - F800h)
MVI A,VAR2-VAR1 ; ошибки выхода за границы байта не будет, регистру [A] будет присвоено значение FEh (F8FEh - F800h)
VAR4:EQU VAR1 # 800h ; F800h xor 800h = F000h
LXI H,VAR4 | 2FFh + ~VAR3 ; VAR3 or 2FFh = F2FFh, инверсия от VAR3 = 01h, [HL] = F2FFh + 01h = F300h
VAR5:EQU 'a' ; VAR5 = 61h
MVI C,VAR5 & 5Fh ; регистру [C] будет присвоено значение 'A' (41h)
MVI A,'b' & 5Fh ; регистру [A] будет присвоено значение 'B' (42h)
CALL VAR4 | VAR5 ; вызов п/п по адресу F061h (F000h or 61h)
DCR B
JNZ $ - ~VAR3 ; условный переход к предыдущей команде (DCR B)
VAR6:EQU $+1 ; VAR6 = адресу операнда следующей команды (MVI A,0)
MVI A,0
LXI D,VAR6 / 20o ; [DE] = VAR6/16
VAR7:EQU 'A' * 'B' # 0FFFFh ; VAR7 = инверсия от (41h * 42h) = EF3Dh
[свернуть]
Команды ассемблера
DASM поддерживает два вида команд: внешние и внутренние. Внешние задаются через параметры командной строки, внутренние - в исходном тексте программы.
Режим трансляции
Команда имеет два варианта: внешний и внутренний.
Внешняя - ключ "/n", внутреняя - MODE n
где n - номер режима (1, 2 или 3)
Приоритет внутренним командам, причём их может быть в тексте исходника несколько, режим меняется динамически на каждом проходе по факту обработки очередной команды MODE. По-умолчанию компилятор использует режим №1.
В режиме №1 компилятор при обнаружении ошибки, выводит на экран причинную строку исходника, под ней текстовое описание ошибки и приостанавливает обработку, продолжение - по нажатию любой клавиши. В планах сделать возможность перехода в текстовый редактор к строке с данной ошибкой.
По окончании компиляции выводится следующая информация:
- кол-во ошибок;
- кол-во меток/констант;
- адреса блока выходного кода и его длина;
- имя и номер рабочей страницы ОЗУ выходного файла.
При выходе в ОС, блокируется возврат в оболочку ОС DSDOS, чтобы можно было проанализировать результат работы.
Режим №2 аналогичен предыдущему, в результаты добавлена распечатка таблицы меток/констант.
Режим №3 аналогичен режиму №1, но при обнаружении ошибок обработка не приостанавливается, и блокировка возврата в оболочку - только при наличии ошибок.
Притормозить вывод сообщений компилятора и распечатку таблицы меток/констант можно нажатием и удержанием любой клавиши, кроме [Esc] - она прерывает компиляцию с выходом в ОС.
Во время компиляции на экран в развлекательных целях выводится символьная анимация процесса =)
Система команд
Внутренняя команда. Синтаксис: CPU type
где type=0 - только команды МП i8080, type=1 - разрешена обработка доп. команд МП Z80.
В режиме "0" разрешена компиляция только команд МП i8080 (КР580ВМ80), доп. команды Z80 вызовут ошибку и процесс компиляции будет прерван. Команда полезна для самоконтроля программиста в случаях написания кода под платформу на МП i8080. По-умолчанию DASM использует режим "0".
Дополнительные команды Z80:
EXX - переключение набора РОН на альтернативный;
EXA - переключение набора регистров PSW на альтернативный (аналог EX AF,AF' в синтаксисе Zilog)
В планах добавление: JR <offs>, JR(cond) <offs>, BIT r,n, SET r,n, LDIR и других.
Имя и номер рабочей страницы ОЗУ выходного файла
Внутренняя команда. Синтаксис: FILE filename [, page]
где filename - имя файла (от 1 до 8 символов)
page - номер рабочей страницы ОЗУ (0 или 1).
Имя файла указывается в формате ОС DSDOS. Указание диска не допускается, файл всегда сохраняется на рабочий диск, где размещеных файлы исходного кода программы.
Номер рабочей страницы ОЗУ необязательный параметр, по-умолчанию его значение = 0.
Рабочая страница ОЗУ выходного файла
Внутренняя команда. Синтаксис: PAGE page
page - номер рабочей страницы ОЗУ (0 или 1).
Задаёт номер рабочей страницы ОЗУ выходного кода (без задания имени файла). Её действие полностью аналогично применению параметра "page" в предыдущей команде.
Вставка (включение) текста в исходник
Внутренняя команда. Синтаксис: INCL filename
где filename - имя файла (от 1 до 8 символов)
Имя файла указывается в формате ОС DSDOS. Указание диска не допускается, включаемый файл должен присутствовать на рабочем диске, где размещен(ы) файл(ы) исходного кода программы.
Команда вставляет в текущую позицию текст из файла, т.о. он обрабатывается в составе основного текста программы.
Отсутствие включаемого файла на диске прервёт компиляцию.
Вставка текста требует наличия соответствующего кол-ва свободной памяти в ОЗУ буфера исходника. При нехватке памяти компиляция будет прервана с ошибкой "Недостаточно ОЗУ".
Вставка блока данных
Внутренняя команда. Синтаксис: DATA filename
где filename - имя файла (от 1 до 8 символов)
Имя файла указывается в формате ОС DSDOS. Указание диска не допускается, включаемый файл должен присутствовать на рабочем диске, где размещен(ы) файл(ы) исходного кода программы.
Команда вставляет в выходной код по текущему адресу данные из файла. Счётчик адресов увеличивается на длину файла.
Отсутствие включаемого файла на диске прервёт компиляцию.
При нехватке памяти в буфере выходного кода компиляция будет прервана с ошибкой "Недостаточно ОЗУ".
Установка счётчика адресов
Внутренняя команда. Синтаксис: ORG addr
где addr - физический адрес (0000..FFFFh, допускается использование выражений).
Команда инициализирует текущий счётчик адресов.
Отличительной особенностью DASM является документированная возможность многократного применения команды в тексте программы!
Первая встретившаяся компилятору команда ORG также определяет адрес посадки выходного файла. Последующие влияют только на адресацию внутри идущего за ними кода. По-умолчанию ORG=0.
Применение нескольких команд ORG позволяет делать вставки кода, предназначенного для работы в других областях памяти.
При вставке такого "внешнего" кода посреди основного, необходимо предварительно сохранять в переменной текущее значение счётчика адресов, а после окончания "внешнего" кода восстанавливать с помощью повторной команды ORG, в качестве параметра которой указывать сохранённый адрес плюс длину "внешнего" кода.
Пример:
Код:ORG 0
; ...ОСНОВНОЙ БЛОК
EXT_CUT: ; адрес окончания (прерывания) основного блока
ORG 0F300h ; ORG "внешнего" блока = F300h
EXT_BEGN: ; адрес начала "внешнего" блока
; ...код "внешнего" блока
EXT_END: ; адрес конца "внешнего" блока
ORG EXT_END - EXT_BEGN + EXT_CUT ; восстановление счётчика адресов основного блока
; ...ПРОДОЛЖЕНИЕ КОДА ОСНОВНОГО БЛОКА
Условная компиляция
В процессе работы DASM отслеживает состояние т.н. флага компиляции. Если флаг сброшен, то обработка кода не выполняется, компилятор в этом режиме воспринимает только команды условной компиляции и команду окончания текста END. Если флаг установлен, то компиляция выполняется в обычном режиме. По-умолчанию флаг компиляции всегда установлен, для его модификации в DASM есть три команды: IF, ELSE и ENDF, действие каждой из которых распространяется до появления следующей.
Задание условия
Внутренняя команда. Синтаксис: IF cond
где cond - значение условия (0 или 1, допустимы любые значения от 0 до 65535).
При cond=0 флаг компиляции сбрасывается (обработка команд выключена), при cond>0 флаг устанавливается (обработка команд включена).
Условие может быть представлено выражением.
Инверсия условия
Внутренняя команда. Синтаксис: ELSE
Изменяет значение флага компиляции на противоположное.
Отмена условия
Внутренняя команда. Синтаксис: ENDF
Устанавливает флаг компиляции, обработка команд включается.
Скрытый текст
Пример:
Код:Тип_платформы:EQU 0 ; 0 - "Орион-128", 1 - "Орион-ПРО"
PT_KBRD_128:EQU 0F400h
PT_KBRD_PRO:EQU 1Ah
; ...
IF Тип_платформы
IN PT_KBRD_PRO
ELSE
LDA PT_KBRD_128
ENDF
ANI 40h
JZ IsCTRL
; ...
[свернуть]
Генерация массивов
Массив одинаковых байтов
Внутренняя команда. Синтаксис: DDB byte, count
где byte - однобайтовая константа* (0..255)
count - количество повторений (1..65535**)
* может быть задана выражением;
** указан теоретический предел, реальное максимальное значение определяется размером буфера выходного кода и размером скомпилированного кода, предшествующего команде.
Команда является как бы комбинацией стандартных DB byte и DS count, она вставляет массив из count-элементов, заполненный константой byte.
Массив одинаковых слов
Внутренняя команда. Синтаксис: DDW word, count
где word - двухбайтовая константа* (0..65535)
count - количество повторений (1..32767**)
* может быть задана выражением;
** указан теоретический предел, реальное максимальное значение определяется размером буфера выходного кода и размером скомпилированного кода, предшествующего команде.
Команда является как бы комбинацией стандартных DW word и DS count, она вставляет массив из count-элементов, заполненный константой word.
Скрытый текст
Пример кода, написанного с использованием нововведений DASM:
Код:; Классика жанра - "Хэллоу Ворлд!"
; (C) 2017 CoolHacker, 27.10.2017
MODE 2
CPU 0
FILE HELLO$, 0
ORG 0
JMP Старт
INCL BIOS.H
INCL CONIO.H
Старт:
LXI H,MSG_HelloWorld
CALL ShowMSG
JMP EscSHELL
MSG_HelloWorld:DB 13
DDB '<', 10
DB ' Хэллоу, Ворлд! '
DDB '>', 10
DB 0
END
[свернуть]
__________________________________________________ __________________________________________________ ____________
Ссылка для скачивания - http://denn.ru/8bit/orion/soft/dasm/ASSM$.ori
► Новый ассемблер будет включён в сборки ОС DSDOS v3.87 (coming soon...) вместо ассемблера «М&S».
Скриншоты интерфейса из эмулятора:
https://pp.userapi.com/c837428/v8374...cf8DCT0h7M.jpg
* мультифайловая компиляция
https://pp.userapi.com/c837428/v8374...xKGp-zuY9g.jpg
* показ ошибки и распечатка таблицы меток
Продолжение тут - http://zx-pk.ru/threads/21984-dsdos-...l=1#post936060
Если была бы шапка с ссылками или хотя бы историей обновлений в первой сообщении этой темы, было бы проще ориентироваться или возможно это привлекло других орионщиков. Я например прочитав там, что данная ось работает только с КНГМД издальше и не интересовался. О том что новые версии работают и с другими контроллерами узнал из параллельной ветки.Цитата:
Сообщение от Denn
Sancho45, замечание справедливое. Я давно уже думал о том, что начало темы не отражает текущей ситуации, а информация слишком "размазана" по портянкам. С другой стороны вся инфа взаимосвязана и исторически последовательна, поэтому грохать интро не хотелось бы.
Были мысли каким-то образом "похоронить" эту тему и завести новую, но наверное это не очень хорошо...
Правильнее будет сделать подробную страничку на стороннем ресурсе, а здесь в заглавном посте дать ссылку. Пока актуальная информация коллекционируется тут - vk.com/dsdos_orion.
По КНГМД скорее наоборот: в будущих версиях планирую уйти от штатной поддержки дискет, т.к. сейчас актуальнее НЖМД и SDHC, а код обслуживания дискет занимает место, которого катастрофически не хватает.
Вот это тоже относится к предыдущему замечанию. Недостаток информации. Есть и расширения, и возможность подмены модулей ОС, установка своих драйверов, взаимодействие модулей и т.д..Цитата:
Сообщение от OrionExt
как вариант использовать подключаемый драйверЦитата:
Сообщение от Denn
Именно так.Цитата:
Сообщение от Stampmaker
Программирование на Ассемблере DSDOS
Для существенного упрощения процесса написания программ на ассемблере в среде ОС DSDOS, предлагается библиотечная модель организации кода, в которой программный интерфейс ОС и наборы некоторых функциональных узлов оформлены в виде т.н. библиотек, подключаемых к программе с помощью инструкции INCL <file>. Т.о. основной код программы не загромождается лишней информацией, а для обращения к ресурсам ОС и подпрограммам библиотек используются осмысленные имена констант, переменных и меток. Назначение подпрограмм библиотек и список их входных/выходных параметров можно в любой момент посмотреть в самих файлах библиотек, открыв их в редакторе.
Предлагается следующая организация структуры DSDOS-программы:
1. Блок описания (назначение, номер версии, информация об авторе, дата создания/изменения и т.п.);
2. Блок настройки компилятора (режим трансляции, имя и адрес посадки файла выходного кода);
3. Стартовый блок (контроль платформы, среды и версии ОС DSDOS, если требуется);
4. Блок программного интерфейса ОС и подключаемых библиотек;
5. Основной код программы.
В случае многофайлового проекта п.1 можно вынести непосредственно в файл проекта *.PR, пп.2-4 в файл заголовочного модуля, а п.5 в модуль(и) основного кода.
В будущем планируется разработка т.н. AssmBuilder™ - среды разработки, в которой создание кода будет частично автоматизировано, а именно выбор модели организации кода, подключение необходимых библиотек, генерация нужного количества файлов-модулей, контроль версий и т.п. будет выполняться автоматически на этапе создания проекта, на основании выбора опций.
А пока среда для разработки DSDOS-программ оформлена в виде набора файлов библиотек, стартового шаблона будущей программы согласно вышеописанному концепту и пакетного файла для генерации необходимой среды на диске Ориона.
Пакет разработки можно скачать по ссылке - http://denn.ru/8bit/orion/soft/dasm/dsdos_sdk.rar или в OriNET - \OriNET\[DSDOS]\API\
Архив содержит следующий набор файлов (в формате *.ORI):
DSDOS.L - базовая библиотека с описанием точек входа ресурсов ОС DSDOS, используется всеми остальными модулями;
BIOS.L - интерфейс модуля BIOS (версия ОС, установка расширений BIOS);
CONIO.L - интерфейс базовых подпрограмм модуля консольного ввода-вывода;
KBRD.L - интерфейс доп. подпрограмм обслуживания клавиатуры модуля консольного ввода-вывода;
CURSOR.L - интерфейс подпрограмм управления курсором модуля консольного ввода-вывода;
TXTSCR.L - интерфейс дополнительных подпрограмм модуля консольного ввода-вывода (выбор экрана, оконный режим, работа с цветом и др.);
EXTDRV.L - интерфейс установки расширений модуля консольного ввода-вывода;
BOOT.L - интерфейс настройки среды при загрузке ОС (тест аппаратной части, установка доступа дисков и др.);
RAMTOP.L - интерфейс управления/контроля верхней границы ОЗУ пользователя;
CCP.L - интерфейс командного процессора;
ERRORS.L - интерфейс обработки ошибок ОС;
SHELL.L - интерфейс управления оболочкой ОС;
CLBRD.L - интерфейс работы с буфером обмена;
RTC.L - интерфейс контроля системной даты и времени (установка, запрос, синхронизация с сервером, преобразование форматов);
RS232.L - интерфейс работы с последовательными портами и ORI-сервером;
FILE.L - интерфейс подпрограмм работы с файлами и дисками;
DIR.L - интерфейс подпрограмм работы с каталогом;
ROMD.L - интерфейс подпрограмм обслуживания ROM-диска;
FDD.L - интерфейс подпрограмм обслуживания КНГМД;
CMDL.L - библиотека обработки параметров командной строки;
!MKWORK% - пакетный файл для генерации среды разработки на квазидиске ПРК Орион;
!NEW.AS - шаблон новой программы.
Содержимое архива необходимо развернуть в папку на виртуальном диске (или на дискете), открыть диск на Орионе и запустить файл !MKWORK%. В результате, на диске "B:" будет создана среда разработки: файлы библиотек, файл шаблона новой программы и конфигурационный файл для редактора Gemini-EDIT со списком необходимых открытых файлов. Далее остаётся только запустить редактор (по клавише "ЗБ" из оболочки), в котором откроется файл шаблона и можно начинать писать свою программу.
Скрытый текст
Содержимое файла шаблона новой программы:
В блоке подключения файлов указан полный базовый список библиотек, включение большинства которых закомментировано. Дело в том, что включение библиотек увеличивает выходной код программы, в связи с этим в реальной программе имеет смысл подключать только необходимые.Код:; *** Шаблон программы для ОС DSDOS ***
; © 2017 <Автор> /Регион/
; Версия: 1.0a
; Создано: 08.11.2017
; Изменено: 15.11.2017
; *** Настройки компилятора ***
MODE 3 ; режим трансляции (1..3)
FILE NEWPROG$ ; имя выходного файла
ORG 0 ; а/п программы
; *** Стартовый модуль (обязательный) ***
; настройка проверки аппаратной части:
HW_TYPE:EQU 0; 0 - без проверки платформы, 1 - требуется Орион-128, 2 - требуется Орион-ПРО
HW_RAM:EQU 0; 0 - без проверки объёма ОЗУ, 1 - 64 кб, 2 - 128 кб, 4 - 256 кб, 8 - 512 кб требуется;
; настройка проверки версии ОС:
OS_VERSION:EQU 38h; 0 - без проверки, иначе - требуемый номер версии (BCD)
INCL START.L ; размещается в самом начале кода!
; *** Интерфейс п/п ОС DSDOS ***
INCL DSDOS.L
; версия ОС, модуль расширения BIOS
;INCL BIOS.L
; консольный ввод-вывод
INCL CONIO.L
;INCL KBRD.L
;INCL CURSOR.L
;INCL TXTSCR.L
;INCL EXTDRV.L
; загрузка ОС, среда, оболочка
;INCL BOOT.L
;INCL RAMTOP.L
;INCL CCP.L
;INCL ERRORS.L
;INCL SHELL.L
; буфер обмена
;INCL CLBRD.L
; дата/время
;INCL RTC.L
; последовательный порт, ORI-сервер
;INCL RS232.L
; файловая система, диски
;INCL FILE.L
;INCL DIR.L
;INCL ROMD.L
;INCL FDD.L
; *** Библиотеки ***
;INCL CMDL.L
; *** Основной код программы ***
START:
RET
END
[свернуть]
Со временем список библиотек будет расширяться, а архив по вышеуказанной ссылке обновляться.
Стартовый блок
Важно:
- код стартового блока должен располагаться в самом начале программы (включение модуля START.L), на него будет передано управление операционной системой при запуске программы!
- основной код программы должен начинаться с метки "START", на неё в случае успешного запуска передаётся управление из модуля стартового блока!
Для настройки параметров стартового модуля требуется обязательная инициализация следующих переменных:
HW_TYPE - контроль платформы: 0 - не выполнять, требуется: 1 - Орион-128, 2 - Орион-ПРО;
HW_RAM - контроль объёма ОЗУ: 0 - не выполнять, требуется: 1 - 64 кб, 2 - 128 кб, 4 - 256 кб, 8 - 512 кб;
OS_VERSION - контроль версии ОС: 0 - не выполнять, иначе - требуемый номер версии (в двоично-десятичном виде, например 38h = версия не ниже 3.8).
Стартовый блок осуществляет проверку на запуск программы в среде ОС DSDOS, и в случае отсутствия таковой выводит средствами Монитора ПРК "Орион" сообщение "ПО для ОС DSDOS", по нажатию любой клавиши передаётся управление по адресу F800h.
В случае активации контроля платформы, выполняется проверка с помощью соответствующей функции ОС. При несоответствии выводится сообщение "Требуется ОРИОН-xxx" (вместо "xxx" тип требуемой платформы) и производится выход в ОС.
При активации контроля объёма ОЗУ, выполняется соответствующая проверка (через API DSDOS), и если объём имеющегося ОЗУ ПРК меньше требуемого, то выводится сообщение "Требуется xxx Кб ОЗУ" (вместо "xxx" требуемый объём ОЗУ) и производится выход в ОС.
В случае активации проверки версии ОС, таковая выполняется по принципу "больше или равна указанной". Если текущая версия ОС ниже требуемой, то осуществляется выход в ОС с сообщением "Требуется ОС vX.X".
Если какой-либо контроль неактивирован (параметр равен 0), то в финальную программу не включается соответствующий фрагмент кода проверки.
Имена меток системных библиотек
DASM поддерживает регистрозависимое, а также русскоязычное написание имён меток, т.о. программист может творчески подойти к процессу. Чтобы выделить подпрограммы, переменные и константы системных библиотек, их имена пишутся только заглавными буквами, разделение смысловых конструкций с помощью символа нижнего подчёркивания "_".
Имена системных констант начинаются с конструкции "DEF_...", имена системных переменных с "VAR_...", имена системных подпрограмм по принципу "ОБЪЕКТ_ДЕЙСТВИЕ" (например, FILE_LOAD). Последнее (касательно имён п/п) не является строгим правилом, имена п/п установки параметров начинаются с действия "SET_...", п/п запроса параметров "GET_..." (например, SET_DISK, GET_CURS_POS).
Пример программы (обработка параметров командной строки)
В качестве примера рассмотрим программу, которая анализирует командную строку, и если находит там параметры или ключи, то выводит их на экран в порядке обнаружения (слева-направо). Для упрощения задачи программиста используется готовая библиотека CMDL.L, которая включена в пакет разработки.
Скрытый текст
Код программы:
Код:; *** Пример обработки командной строки ***
; (C) 2017 Соловьев Д.Н. /Санкт-Петербург/
; 15.11.2017
; *** Настройки компилятора ***
MODE 3
FILE CMDTEST$
ORG 0
; Стартовый модуль (обязательный)
; настройка проверки аппаратной части:
HW_RAM:EQU 0
HW_TYPE:EQU 0
; настройка проверки версии ОС:
OS_VERSION:EQU 38h; требуемый номер версии
INCL START.L
; *** Интерфейс п/п ОС DSDOS ***
INCL DSDOS.L
INCL SHELL.L
INCL CONIO.L
; *** Библиотеки ***
INCL CMDL.L
; *** Переменные ***
VAR_COUNT:DB 0; кол-во параметров +1
; *** Основной код программы ***
START:
; получение кол-ва параметров ком.строки
CALL GET_CMDL_COUNT
RZ
MOV A,B
INR A
STA VAR_COUNT
MainLOOP:
; цикл получения и вывода значений параметров
LDA VAR_COUNT
SUB B
ADI '0'
STA VAR_NUMBER
CALL SHOW_MSG
DB 13,'Параметр #'
VAR_NUMBER:DB 'x = ',0
; анализ очередного параметра командной строки
CALL GET_CMDL_ITEM
RC
JZ PrintKEY
PrintITEM:
; вывод значения параметра
LDAX D
CPI ' '+1
JC NextITEM
MOV C,A
CALL PRINT_C
INX D
JMP PrintITEM
PrintKEY:
; вывод значения ключа "/x" или "-x"
MVI C,'■'
CALL PRINT_C
MOV C,A
CALL PRINT_C
NextITEM:
; проверка на окончание
DCR B
JNZ MainLOOP
JMP SHELL_OFF
END
[свернуть]
ОС при успешном запуске программы передаёт ей в регистровой паре [DE] адрес указателя на содержимое командной строки, следующее сразу за именем программы. Если параметры отсутствуют, то по адресу в [DE] будет байт признака окончания строки 00h (в ОС считается признаком конца любой байт со значением меньше 20h). Если пользователь при запуске программы ввёл доп. параметры, то они разделяются символом пробела, а ключи (специальные параметры, указывающие на режим работы программы) начинаются с символа "/" или "-".
При старте с помощью подпрограммы GET_CMDL_COUNT библиотеки CMDL.L мы сначала определяем количество доп. параметров командной строки. Если установлен флаг нуля (<Z>=1), то это означает, что доп. параметры отсутствуют, и мы командой RZ выходим в ОС. В противном случае в регистре [B] у нас содержится общее количество доп. параметров, введённых пользователем, которое мы инкрементируем и сохраняем в переменную VAR_COUNT для последующего вычисления номера очередного обрабатываемого параметра.
Далее идёт главный цикл обработки параметров. Сначала с помощью подпрограммы SHOW_MSG библиотеки CONIO.L выводится сообщение: "Параметр №xx". Затем с помощью подпрограммы GET_CMDL_ITEM запрашиваем очередной параметр командной строки и в зависимости от его типа (ключ или нет) производим посимвольный вывод содержимого параметра (с помощью подпрограммы PRINT_C библиотеки CONIO.L) до символа пробела или окончания строки. Подпрограмма GET_CMDL_ITEM использует указатель в регистровой паре [DE], содержимое которой портить нельзя!
После уменьшаем счётчик количества параметров (в регистре [B]), делаем проверку на окончание и переходим на начало цикла.
В конце обработки всех параметров выходим в ОС через подпрограмму отключения автовозврата в оболочку SHELL_OFF библиотеки SHELL.L. Вызов последней необходим для того, чтобы была возможность увидеть результаты работы программы в случае присутствия доп. параметров в командной строке.
[пост редактируется...]
Обещанная "предновогодняя" сборка ОС DSDOS v3.87 для обеих платформ: Орион-128 и Орион-ПРО.
Почти год не выкладывал обновления, за это время накопилось некоторое количество изменений. Вот краткий список:
► новый интерфейс загрузчика;
► упразднена возможность загрузки ОС с дискеты;
► добавлен автодетект RAM-дисков (ЭД™ или RAM7) и подгрузка соответствующих драйверов;
► поддержка RTC на базе БИС КР512ВИ1;
► автосинхронизация даты и времени с ORI-сервером при загрузке ОС;
► регистрация платформы на ORI-сервере (требуется сервер v3.12 и выше!);
► отображение даты и времени в оболочке SHELL (при наличии в системе RTC);
► некоторые доработки модуля ввода-вывода (CONIO);
► полная русификация краткой справки по командам ОС (в CCP);
► в версии утилиты FORMAT$ для ПРК "Орион-128" добавлено форматирование диска "E:";
► оптимизация кода всех модулей ОС, ещё большее ускорение вывода символов на экран;
► программная блокировка возврата в оболочку;
► в оболочке добавлена команда быстрого возврата в текстовый редактор, независимо от содержимого панелей;
► также добавлена команда просмотра/редактирования файлов в hex-виде (утилита HEXEDIT$);
► переработан код текстового редактора Gemini-EDIT, ускорены алгоритмы обработки фрагментов текста и поиска/замены;
► изменения некоторых горячих клавиш в текстовом редакторе, добавление новых комбинаций;
► в настройках текстового редактора по-умолчанию настроен шаблон рабочих файлов "*.AS" вместо "*.TXT";
► в сборку включён новый Ассемблер DSDOS вместо "M&S";
► в сборках "Программист" включены библиотеки API DSDOS, портов ввода-вывода и шаблон исходного кода новой программы под DSDOS;
► традиционная оптимизация кода системных утилит, вывод справки с отменой возврата в оболочку;
► в сборки добавлена утилита обслуживания мини-программатора популярных ПЗУ Winbond 27C512 (публикация будет чуть позже).
Из печального: очень хотел, но, увы, физически не успел сделать поддержку HDD и SDHC. С другой стороны, есть чем заняться в следующем году :)
Загрузчик (BOOT)
Вывод информации переведён на API DSDOS, с соответствующими скоростью и красотой :)
https://pp.userapi.com/c834104/v8341...-y5g9htbBQ.jpg
Вывод информации загрузчика становится возможным после загрузки модулей ОС, до этого момента в левом верхнем углу экрана штатными средствами ПЗУ Монитора выводятся точки - каждая соответствует одному успешно загруженному модулю. Также средствами монитора выводится сообщения об ошибке, если таковая случится в процессе загрузки модуля.
По-прежнему, во время загрузки ОС производится автодетект аппаратуры, при этом на экран выводится соответствующая информация.
Для ПРК "Орион-128" дополнительно теперь определяется наличие RAM-диска (ЭД™ или быстрый RAM7), подгружается соответствующий драйвер и активируется диск "E:".
В случае обнаружения соединения с ORI-сервером производится синхронизация текущей даты, а в случае наличия в системе RTC - синхронизация их показаний даты и времени с сервером.
Загрузка ОС по-прежнему очень быстрая, поэтому если требуется поизучать выводимую загрузчиком информацию, то нужно нажать и удерживать любую символьную клавишу.
Поддержка RTC
Для обеих платформ теперь поддерживаются аппаратные часы реального времени на отечественной БИС КР512ВИ1.
Для ПРК "Орион-128" RTC должна находиться по адресам F7Bxh, для "Орион-ПРО" по адресам 5xh.
Утилита DATE$ теперь записывает информацию о текущей дате в RTC. Для работы с показаниями времени добавлена отдельная утилита TIME$. После первого запуска RTC (или после фатального провала питания) требуется инициализация с помощью утилиты TIME$, которая программирует RTC определённым образом в формате ОС DSDOS (24-часовой формат, без автоперевода зимнее-летнее, двоичный формат хранения, а также сигнатура DSDOS в CMOS).
В оболочке ОС (SHELL), справа в строке команд/статуса всегда отображаются дата и время (если RTC присутствует и корректно инициализирована).
https://pp.userapi.com/c841337/v8413...bqZAvI1Wqc.jpg
Программно RTC доступны через соответствующие функции API DSDOS.
Оптимизация кода
Периодически находятся лазейки для ускорения алгоритмов и уменьшения объёма кода. Всё это крайне актуально на фоне слабых ресурсов ПРК. Повышается комфорт работы (ускоряется отклик системы). Уменьшение объёма кода позволяет добавлять новый функционал.
На этот раз удалось скомбинировать вывод символа с помощью стековых операций с пропуском "лишних" переключений банков ОЗУ, что дало небольшой, но всё же ощутимый прирост скорости.
В текстовом редакторе оптимизация коснулась самых часто используемых во время редактирования алгоритмов стяжки/раздвижки текста, тестирования всего файла на ошибки и поиска/замены фрагмента.
В драйверах RAM-дисков (ЭД™ и RAM7) ощутимо ускорена запись файлов за счёт отказа от пересохранения всего каталога, по факту записывается только один заголовок причинного файла (16 байт).
Изменения в модуле ввода-вывода
В подпрограмме ввода символа (01h или INPUT_KEY в библиотеке CONIO.L) добавились выходные параметры - регистры флагов предустановлены в зависимости от того, были нажаты или нет, часто используемые клавиши: [Enter], [Esc] или [F4]. Это упрощает код обработки в ПО.
Дополнены управляющие коды подпрограммы вывода символа (00h или PRINT_C в библиотеке CONIO.L). Добавлен код табуляции (смещение к ближайшей позиции, кратной восьми). Добавлен код вывода символа из набора курсоров: 1Ch+<код>, где "код" = 00..1Fh; на экран выводится соответствующий курсор как обычный символ (не XOR-наложением).
Добавлен код включения/выключения цветного вывода символов: 1Eh+<код>, где код = 00h (монохромный) или 01h (цветной). Скорректирована отработка управляющего кода 18h из крайнего правого угла, теперь курсор переходит в левый верхний угол экрана (ранее был возврат каретки).
Добавлена новая п/п ввода hex-байта (06h или INPUT_BYTE_HEX в библиотеке CONIO.L).
Управление признаком возврата в оболочку (SHELL)
При запуске программ из оболочки по [Enter], выставляется признак возврата в оболочку при выходе из программы. Это удобно. Но! Бывают ситуации, когда требуется вдумчиво изучить информацию, которую программа вывела на экран в процессе работы и осуществила выход в ОС. Ранее для этого был только механизм удержания [Shift], что иногда не удобно.
Теперь введена возможность программно управлять признаком возврата в оболочку. Например, большинство утилит, будучи запущеные без параметров, выводят на экран справку. В настоящей сборке все утилиты в этом режиме отключают возврат в оболочку.
Программно контроль признака возврата доступен через библиотеку SHELL.L.
В API DSDOS также появилась возможность получить код последней системной ошибки (п/п GET_LAST_ERROR в библиотеке ERRORS.L).
Новый Ассемблер DSDOS
Предлагает более удобный интерфейс, более богатый функционал и позволяет использовать библиотечную модель программирования. Поддерживает мультифайловую компиляцию и позволяет писать ПО большого объёма.
Подробно описан в предыдущем посте.
Текстовый редактор Gemini-EDIT v5.5
Является основным инструментом при написании ПО на ПРК "Орион". В связи с активным использованием "вражеской" клавиатуры PS/2 и навыкам от IBM-совместимых ПК, были адаптированы комбинации горячих клавиш. В основном изменения коснулись ухода от некоторых сочетаний вида [АР2]-затем-<буква> в пользу сочетаний [Ctrl]+<буква>, а также дублирование вариантов сочетаний для работы с буфером обмена (Ctrl+[Ins], Shift+[Ins], Shift+[Del], Ctrl+[C], Ctrl+[V]).
Более подробно см. встроенную справку редактора.
Также для повышения комфорта при программировании на Орионе, сделан быстрый возврат в редактор (клавиша [Забой] в оболочке) и шаблон рабочих файлов редактора по-умолчанию - "*.AS". Возможно расширение шаблона к виду "*.A", в таком случае в каталог также будут включены файлы с расширением ".A".
Команда вызова внешней программы из редактора (ранее Ctrl+[G], теперь Ctrl+[P]) ассоциирована с клавишей [P] - (P)roject. В случае компиляции ассемблером файлов проекта, удобно пользоваться именно этой функцией редактора, т.к. при обычном вызове ассемблера всегда подставляется текущий текстовый файл, что в случае редактирования AS-модуля приведёт к неверной обработке. С помощью [Esc]-затем-[P] нужно прописать вызов Ассемблера, а в качестве параметра указать имя файла проекта "*.PR", т.о. независимо от текущего редактируемого файла, компилироваться всегда будет весь проект. Последующие вызовы можно уже делать через [Ctrl]+[P], ввод параметров при этом не потребуется (они хранятся в настройках редактора).
Сочетания [Esc]-затем-[G] и [Ctrl]+[G] изменены на работу с псевдографикой.
Утилита FORMAT$ для ПРК "Орион-128"
Добавлен функционал форматирования RAM-диска "E:". Утилита автоматически определяет тип RAM-диска (ЭД™ или RAM7) и применяет соответствующий алгоритм инициализации.
▼▼▼ Ссылки для скачивания различных вариантов сборок ▼▼▼
Внимание! Архивы были обновлены 28.12.2017 !
Для ПРК ОРИОН-128/512:
ПЗУ ROM-диска объёмом 64 Кб
ПЗУ ROM-диска объёмом 128 Кб
ПЗУ ROM-диска объёмом 256 Кб
ПЗУ ROM-диска объёмом 512 Кб
Поддержка RAM5 (RAM-диск 1024 Кб в составе ЭД™ 1x1, порт #F50xh) и RAM7 (быстрый RAM-диск 1024 Кб в виде платы расширения, порт #F7Fxh) теперь автоматическая, никаких отдельных сборок для каждого варианта не требуется!
Для ПК ОРИОН-ПРО:
"Стандарт", ПЗУ ROM-диска объёмом 64 Кб
"Стандарт", ПЗУ ROM-диска объёмом 256 Кб
"Геймер", ПЗУ ROM-диска объёмом 64 Кб
"Геймер", ПЗУ ROM-диска объёмом 256 Кб
"Программист", ПЗУ ROM-диска объёмом 64 Кб
"Программист", ПЗУ ROM-диска объёмом 256 Кб
Внутри архивов под объёмы 256 Кб находится два варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска, и соотв. кол-вом файлов по 64 Кб (файлы romdiskN.bin) для старого варианта (в составе мультикарты).
:v2_dizzy_punk:Цитата:
Сообщение от Sancho45
Публикую обещанное - программатор ПЗУ с электрическим стиранием: Winbond W27C512.
Уши этого устройства растут из варианта более универсального программатора УФ-стираемых ПЗУ (27x256, 27x512, 27C040, 27C080) для Орион-128. Практический опыт показал, что ПЗУ Winbond W27C512 самые удобные, и надобность в возможности прошивки УФ-стираемых ПЗУ, в общем-то, отпала. Для работы с W27C512 требуется меньше вариантов напряжений и минимум коммутации, в результате схема была ощутимо упрощена.
А поскольку W27C512 поддерживает мгновенное электрическое стирание, то было и упрощено ПО, обслуживающее программатор: не требуется отдельно выполнять проверку на чистоту и стирание, они выполняются автоматически перед прошивкой.
Исключительно с целью развлечения проект выполнен на совершенно "нефеньшуйной" элементной базе - SMD.
Фото программатора в сборе:
https://forum-img.guitarplayer.ru/2024/02/11/60Y6s.png
альт.ссылка на изображение
https://forum-img.guitarplayer.ru/2024/02/11/60o8I.png
альт.ссылка на изображение
Конструкция рассчитана на применение углового разъёма, т.о. программатор вставляется под углом 90 градусов к плате ПРК "Орион-128":
https://forum-img.guitarplayer.ru/2024/02/11/60qcU.png
альт.ссылка на изображение
Форм-фактор устройства в виде "затычки на параллельный порт" выбран не случайно. Дело в том, что применение соединительного кабеля (шлейфа) вызывает большое количество проблем со стабильностью работы устройства, требуется довольно сложная помехозащищённая конструкция кабеля. В общем, повторяемость устройства в выносном варианте (с применением шлейфа) была бы сомнительная.
Устройство изначально разработано для ПРК "Орион-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-биток.
Запуск утилиты без параметров традиционно выводит справку:
https://forum-img.guitarplayer.ru/2024/02/11/60rh6.png
альт.ссылка на изображение
Конструкция программатора такова, что питание и управляющие сигналы на ПЗУ подаются только во время выполнения операции, после завершения которой на всех выводах устанавливается нулевой потенциал, т.о. возможна безопасная смена микросхемы. Перед выполнением операций, стирающих информацию в ПЗУ, сначала выводится предупреждающий транспарант, требующий подтверждения действия (кроме режима "W"!).
Полный образ для прошивки ПЗУ W27C512 занимает 64 Кб, в один файл он не помещается, а также не помещается в ОЗУ пользователя (48 Кб). Вопрос решён традиционно разбивкой образа на два файла (по 32 Кб каждый), которые по очереди загружаются в ОЗУ во время работы программатора. Формат файлов образа: <Имя>+<Расширение>. Имя - произвольные символы, допустимые в именах файлов ОС DSDOS, максимальное кол-во = 6. Расширение - два символа вида <#N>, где N - порядковый номер файла образа (0, 1). У обоих файлов образа <Имя> должно быть одинаковое, различие только в номере параметра <Расширение>! При указании имени файла образа в параметрах запуска утилиты, расширение указывать не нужно, его утилита формирует автоматически при поиске требуемого файла.
Режимы работы программатора задаются ключами. Режимы проверки чистоты ПЗУ и стирания не требуют указания имени файла образа - вводится только ключ. В остальных режимах указывается имя файла образа и ключ, порядок следования параметров произвольный.
В ходе выполнения операций на экран выводится индикатор прогресса. В операциях с файлами - в два прохода, соответственно.
Итак, собственно режимы работы программатора.
Проверка чистоты микросхемы [ключ /C]:
https://forum-img.guitarplayer.ru/2024/02/11/605Xg.png
альт.ссылка на изображение
ПЗУ считается чистым, если во всех ячейках записано FFh. В противном случае выводится кол-во нестёртых ячеек.
Данный режим является наследием от ПО для программирования УФ-стираемых ПЗУ, большого практического смысла применительно к W27C512 в нём нет.
Ещё один режим, доставшийся от универсальной версии программатора - стирание [ключ /E]:
https://forum-img.guitarplayer.ru/2024/02/11/60pHv.png
альт.ссылка на изображение
Позволяет мгновенно (за 200 мс) стереть всю информацию в W27C512. Полезен скорее для отладки программатора.
Программирование [ключ /P]:
https://forum-img.guitarplayer.ru/2024/02/11/60EKp.png
альт.ссылка на изображение
Оба файла образа должны находиться на указанном устройстве (традиционно, без явного указания диска, поиск файлов осуществляется на рабочем диске ОС - "B:"), размер файлов должен быть 32768 байт. Возможна прошивка только одного файла (т.е. только первых 32 Кб ПЗУ), если второй файл образа отсутствует.
Перед началом программирования всегда выполняется стирание микросхемы!
Программирование каждого файла состоит из двух фаз: прошивка и проверка/допрошивка. Каждая фаза отображается своими символами, заполняющими индикатор прогресса.
Если во время проверки обнаруживаются несоответствия ячеек, то, согласно алгоритму производителя, выполняется до 10 попыток допрошить проблеммные ячейки.
В финале, если все ячейки запрограммированы успешно, выводится соотвествующее сообщение:
https://forum-img.guitarplayer.ru/2024/02/11/60dej.png
альт.ссылка на изображение
Альтернативный режим программирования [ключ /W]:
https://forum-img.guitarplayer.ru/2024/02/11/60gIC.png
альт.ссылка на изображение
Отличие в отсутствии запроса подтверждения действия. Для ускорения работы продвинутых пользователей :)
Проверка [ключ /V]:
https://forum-img.guitarplayer.ru/2024/02/11/60t9r.png
альт.ссылка на изображение
Сравнение содержимого ПЗУ с образом. В режимах программирования выполняется автоматически.
Чтение [ключ /R]:
https://forum-img.guitarplayer.ru/2024/02/11/60G8u.png
альт.ссылка на изображение
Чтение содержимого ПЗУ с сохранением в файлы образа на диск.
PS по вопросам изготовления печатной платы обращаться к Сергею
Драйвер расширения ExtDRV
Дальнейшее развитие ОС DSDOS привело к расширению функционала модуля консольного ввода-вывода CONIO с помощью драйвера ExtDRV.
Дополнительные процедуры позволяют организовать диалог с помощью оконного интерфейса, а также содержат готовые компоненты навигации по дискам/файлам и операций с ними.
Драйвер расширения интегрируется в ОС и его функционал доступен через API DSDOS (call BIOS, пул номеров подпрограмм: 50..61h).
Для работы требуется ОС DSDOS версии 3.87 и выше. Начиная с версии 3.88 драйвер будет интегрирован в сборки ОС, а на предыдущей версии возможна его установка с помощью утилиты EXTINST$:
https://forum-img.guitarplayer.ru/2024/02/11/60IcH.png
альт.ссылка на изображение
Статус и версию установленного драйвера ExtDRV можно посмотреть утилитой SYSTEM$:
https://forum-img.guitarplayer.ru/2024/02/11/60NnY.png
альт.ссылка на изображение
Концепт
Каждый элемент интерфейса представляется в виде т.н. окна, прямоугольной области символьного экрана, заключённой в рамку (или без неё). Рабочая область окна представляет собой уменьшенную версию символьного экрана, в котором действует стандартный функционал консольного ввода-вывода ОС DSDOS:
https://forum-img.guitarplayer.ru/2024/02/11/60SXF.png
альт.ссылка на изображение
Драйвер поддерживает работу с двумя типами окон:
1) Простое;
2) Сохраняемое.
Простое окно строится только в экранной области, при этом содержимое экрана на его месте теряется безвозвратно. При построении окна второго типа, драйвер предварительно сохраняет содержимое экрана под ним во временный файл на квазидиске, т.о. реализуется возможность "закрыть окно", с полным восстановлением информации под ним на экране. Механизм открытия/закрытия сохраняемых окон реализован по принципу стэка (LIFO). Каждое открытое окно второго типа создаёт свой временный файл на квазидиске, при закрытии окон соответствующие временные файлы удаляются. Максимальное количество открытых сохраняемых окон (теоретический программный предел - 255) ограничено их размерами, режимами открытия и свободным местом на квазидиске.
Сохранение и восстановление содержимого экрана под окнами реализованы с помощью ускоренных алгоритмов с использованием инструкций POP/PUSH, что позволило добиться приемлемой скорости на классическом Орионе-128 с процессором КР580ВМ80А (такт 2,5 МГц).
Окна обоих типов могут быть открыты в одном из двух режимов:
1). Монохромный;
2). Цветной.
В первом варианте окно строится только на переднем плане экранной области, атрибуты цвета остаются без изменений. При этом у сохраняемого окна во временный файл также записываются только данные переднего плана, что по сравнению с цветным режимом занимает в 2 раза меньше места на квазидиске. Во втором варианте окно окрашивается в заданный программистом цвет, и сохраняются атрибуты цвета под окном. Также устанавливается соответствующий режим отображения символов.
Вид рамки задаётся отдельной процедурой конфигурации драйвера, и действует на все последующие открываемые окна. Есть также глобальная настройка "рамка по-умолчанию", этот вид рамки устанавливается при вызове процедуры конфигурации с кодом рамки FFh, данный функционал позволяет пользователю на уровне системы настраивать вид рамок окон в программах по своему вкусу. Доступны следующие виды рамок:
00h – без рамки*;
01h – одиночная «┌─»;
02h – двойная «╔═»;
03h – жирная «██»;
04h – сетка «▓▓»;
05h – орнамент «■■»;
06h – шахматная «https://upload.wikimedia.org/wikiped...Spectrum89.svg»;
20h..FDh – пользовательская**.
_____________________________
* вся площадь окна доступна для консольного ввода-вывода, в остальных случаях рабочая область окна: (Ширина - 2) х (Высота - 2);
** рамка рисуется символом с соответствующим ASCII-кодом.
https://forum-img.guitarplayer.ru/2024/02/11/604rS.png
альт.ссылка на изображение
Работа с драйвером (информация по программированию)
Программный интерфейс драйвера описан в библиотеке 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):
https://forum-img.guitarplayer.ru/2024/02/11/60BLR.png
альт.ссылка на изображение
https://forum-img.guitarplayer.ru/2024/02/11/60HKV.png
альт.ссылка на изображение
В рег. паре [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) – расширенное меню сохранения файла, с открытием/закрытием окна;
Первые две процедуры универсальные, подходят для организации диалогов любых операций с файлами, не имеют никакой привязки к окнам, структура меню строится от текущих координат курсора, всё оформление диалога выполняет программист непосредственно перед вызовом процедуры.
В сокращённом варианте минимум входных параметров, список файлов представлен только их именами:
https://forum-img.guitarplayer.ru/2024/02/11/60Tz2.png
альт.ссылка на изображение
B расширенном задаётся режим отображения полей файлов в списке (вывести/скрыть: адрес посадки, длину hex/dec, атрибут защиты, страницу ОЗУ и дату):
https://forum-img.guitarplayer.ru/2024/02/11/60xNJ.png
альт.ссылка на изображение
Процедуры 5Eh и 5Fh являются готовыми компонентами открытия и сохранения файла, соответственно. Они самостоятельно открывают своё отдельное сохраняемое окно, положение и размеры которого автоматически подбираются так, чтобы оно было расположено в центре экрана ПРК:
https://forum-img.guitarplayer.ru/2024/02/11/60C9m.png
альт.ссылка на изображение
По завершении выбора файла, окно диалога автоматически закрывается, содержимое экрана под ним восстанавливается и в программу пользователя возвращается дескриптор выбранного файла (в BIOS'е установлен текущим выбранный диск и имя файла).
В процедуре сохранения файла есть возможность выбрать имя файла из уже имеющихся в списке (запись «поверх») или ввести новое (соотв. поддиалог вызывается клавишей пробела):
https://forum-img.guitarplayer.ru/2024/02/11/60hJc.png
альт.ссылка на изображение
В случае записи «поверх», процедура самостоятельно удаляет одноимённый файл на диске!
https://forum-img.guitarplayer.ru/2024/02/11/60ncy.png
альт.ссылка на изображение
Непосредственно команды чтения/записи файлов и обработки статуса их исполнения программист выполняет самостоятельно, процедуры драйвера организуют только все необходимые подготовительные работы.
Во всех процедурах с файлами в рег. паре [HL] передаётся указатель на ASCII-строку (признак конца – 00h) шаблона(ов) для отбора файлов, отображаемых в списке. Если шаблонов несколько, то они разделяются пробелами. Например:
При [HL]=0000h отбор игнорируется и выводится полный список файлов.Код:DB '.AS .TXT',0
Кол-во файлов, видимых на экране (в окне) задаётся при вызове соответствующей процедуры. Если полный список длиннее, то реализуются скроллинг и листание страниц, а также переходы в начало/конец списка по 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$, в архиве также прилагается её исходный код.
https://forum-img.guitarplayer.ru/2024/02/11/60vnh.png
альт.ссылка на изображение
__________________________________________________ __________________________________________________ _
Ссылка для скачивания - архив в формате *.ORI
Denn, пилит свою ОСЬ (лет так 17 точно). Уважуха. Когда уже много задачность появиться на Орионе;)
- - - Добавлено - - -
Чоть навеело. Помню, исходники оси от Denn по модему качал.
Всё конечно замечательно описано, а почему не в отдельной теме даже если учесть что ПО под Орион. Программатор не укладывается в название темы: DSDOS для ПРК "Орион".
На 8-битке смысла нет. На классическом Орионе - тем более. Это если в привычном "писишном" смысле.Цитата:
Сообщение от OrionExt
Виртуальная "многозадачность" в концепции DSDOS есть, она реализуется с помощью сохранения текущего состояния программ в конфигурационных файлах, т.о. запуск программы можно рассматривать как переключение к данной задаче. Оболочка ОС в качестве "переключателя". Также есть механизм call-вызова программы из программы. Имхо, для Ориона этого вполне достаточно.
Использовать писи для хранения файлов Ориона, емнип, я начал в конце 2015-го года, до этого жил на дискетах, т.е. полностью в 8-битном домене. Но и после 2015-го исходники публично не выкладывал. Соответственно, вопрос: откуда?Цитата:
Сообщение от OrionExt
- - - Добавлено - - -
Наверное, справедливое замечание.Цитата:
Сообщение от fifan
Но с другой стороны, если я выложу сабж в разделе про железо (а по специфике форума оно как бы автоматом подразумевается для спектрума), то будет странно. Как известно, железка без ПО смысла не имеет, а ПО обслуживающее данный программатор есть только под Орион, и только под DSDOS.. получается, что есть смысл публиковать там, где обитает народ, интересующийся DSDOS. По-моему так (С)
https://cs6.livemaster.ru/storage/4e...f7e778d4vi.jpg
Я не говорил переместить в другой раздел, а оставить в Орионе, но под новым заголовком.Цитата:
Сообщение от Denn
fifan, предлагаю этот вопрос оставить на усмотрение модератора.
П.С. если я буду по каждой своей железке и софтинке генерить новые темы, то наоборот предполагаю появлении армии недовольных ("оно всё равно работает только под твоей осью, нафига оно в общем разделе?").. палка о двух концах, однако.
Это мягко говоря, преувеличение. С документацией плохо. Если просто из любопытства почитать тему, то да, есть что почитать и посмотреть - "много букаф", интересные фото и скриншоты.Цитата:
Сообщение от fifan
Но нет документации для программиста в нормальном виде. Да и для пользователя документации нет, это значит, что надо читать всю эту тему, запоминать информацию. Даже 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 начинает работать с другим типом носителя (флоп, винт, флэш).
Denn, значит пора создавать твой раздел, с карточными играми и куртизанками!
Ну, вы барин задачу ставите:D Поскрипел мозгами, пошуршал по дискам.Цитата:
Сообщение от Denn
А это чье? Не мое:)
Код: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 ' '
[свернуть]
OrionExt, я уже понял, что утекло. Вопрос был: где и как?
Припоминаю, что ещё в доинтернетную эпоху писал на писи под ДОСом утилиты обмена с Орионом по RS-232, вероятно какие-то файлы попали на писюк в тестовых целях... а может даже бэкапил что-то тогда. Но это всё была 100% оффлайн техника. Впрочем, ладно, это уже не важно :)
Denn, ну как откуда. С твоего сайта и качал модемом в начале нулевых. Ох, давно это было. Это ведь не твой двойник сайт сделал и исходники выложил:)
Зарождение промышленного шпионажа или еще раз о защите информации:-).
http://orion-128.narod.ru/
как бы не отсюда ноги растут
barsik, спасибо за интерес к теме и вопросы.
Упрёк голословный, на основании чего сделан вывод - не понятно. Оформление темы в хронологическом стиле - да, не очень информативно, особенно для "вновь входящих" и привыкших получать информацию в максимально "пережёванном" виде, но те, кто "в теме", знают где что искать.Цитата:
Сообщение от barsik
Всё ПО имеет либо встроенную справку (выводится при запуске программы без параметров, либо с ключом "/?" или "/H"), либо отдельным текстовым файлом "*.H" или "*.HLP", либо по горячей клавише "H" в самой программе.
Информация для пользователя ОС есть на форуме (в первых постах), а также одним файлом в формате "*.doc".
Инфо для восьмибитных программистов (а таковые вообще есть в природе?) представлена в виде тех же "вордовских" файлов с подробным описанием API, распределением памяти, кодировки символов, кодов ошибок и т.п..
Более структурировано, в меру возможностей, пытаюсь оформить документацию тут - https://vk.com/dsdos_orion
Если будет время, то планирую сделать сайт, но это слишком масштабно.. пока не до этого.
Здесь всё исключительно на Орионе, а не на писи! Писюк в качестве хранилища и обменника был "прикручен сбоку" совсем недавно, но его роль лишь в логистике контейнеров с информацией (т.е. это своеобразный роутер для Ориона), не более того.Цитата:
Сообщение от barsik
Я против смешивания 8-битки и писи, это совершенно разные миры.
One more time... Орион - это Орион, это прекрасный 8-битный мир, и он никому ничего не должен. Сабжевая ОС была написана исключительно на самом Орионе, его штатными средствами, и предназначена для работы на этом самом Орионе, с упором на максимальный комфорт и раскрытие возможностей платформы.Цитата:
Сообщение от barsik
Для любителей "поковырять" орионовские файлы с помощью американских технологий (зачем?) был написан соответствующий инструмент -
http://zx-pk.ru/threads/21984-dsdos-...l=1#post883707
Вопрос преобразования кодировок он также решает.
DSDOS разрабатывалась и развивается по одному простому принципу - реальной насущной необходимости какого-либо функционала. Моей личной необходимости. Также по мере возможности воплощаются некоторые хотелки пользователей.Цитата:
Сообщение от barsik
В своё время одних заглавных букв Монитора стало мало, понадобился "нижний регистр" и псевдографика. Нужно - сделали! Информации "как правильно" (или как "кому-то надо") не было, поэтому сделали как логично, исходя из данной ситуации. А логично было исходя из особенностей родной РК'шной клавиатуры прибывать константу к "сырому" коду F81Bh и получить соответствующую русскую букву. Аналогично с регистром букв - тоже воздействие константой на базовый код процедуры Монитора. Других стандартов не было, значит сделали свой. Задача для Ориона решена: имеем два языка, два регистра и псевдографику; текстовый редактор это всё поддерживает, можно ваять тексты и программы.
То, что не удобно на писи - ну, извиняйте, не для того роза цвела, как говорится.
Забавно :) Пытаюсь представить масштабы нужды...Цитата:
Сообщение от barsik
П.С. у меня под MSDOS в образовательных целях была написана утилита конвертации туда-обратно, в ДОСовскую 866-ю и в виндовую 1251. Практически не пользовался ни разу.
Двухбайтовый перевод строки это какая-то заморочка исключительно писишных файлов или какой-то писишной обработки, на Орионе такое расточительство ОЗУ не используется, у меня файлов с 0D0Ah нет.Цитата:
Сообщение от barsik
Формат текстовых файлов на Орионе всегда был такой:
Коды символов: 20..7Eh (в DSDOS пошире - 20..FEh);
Разделитель строк - 0Dh;
Признак конца файла - FFh (как я понимаю, наследие Микрона);
Коды 00..0Ch и 0E..1Fh - не используются и считаются ошибкой формата.
Именно это и сделано в DSDOS. Выводом полностью можно рулить через п/п вывода сообщения. Включая управление режимом цвета, с недавней версии.Цитата:
Сообщение от barsik
Только не "американскими" искейп-кодами, а экономными и прицельными последовательностями кодов, которые решают насущные задачи.
Никому ничего не должны. К счастью (да, именно так - к счастью!), на момент зачатия ОС мой мозг не был отягощён знаниями американских технологий, "как правильно" и прочими "уставами" и догматами, которые, как известно, являются не чем иным, как запретом мыслить. Повторюсь, всё создавалось по мере необходимости, исходя из имеющихся реалий.Цитата:
Сообщение от barsik
Так вот, изначально DSDOS базировалась на ПЗУ Монитора в качестве базовой системы ввода-вывода, и представляла из себя только функционал работы с файлами, который и был "неправильно" (в "американском" смысле) назван BIOS'ом: базовая система ввода-вывода ФАЙЛОВ. Не "дисковая система", а ввод-вывод файлов - более широкое понятие, т.к. изначально предполагалась файловая организация обмена данными между программами, а сами файлы не только в виде физических дисков (ленты, дискет и т.п.), а также в виде RAM-дисков, виртуального "диска", буфера обмена и т.д.. Т.е. ОС состояла из файловой системы (BIOS) и процессора консольных команд (CCP, здесь название случайно совпало с американским :)).
Позже меня окончательно утомил дико тормозной 6-битный вывод символов, и я сделал надстройку над Монитором, которая позволяла использовать полноценное знакоместо 8х8 с вменяемой скоростью вывода. В процессе работы стало понятно, что "надстройка" (модуль консольного ввода-вывода, CONIO) бесповоротно переходит в статус "перманентно" и от API Монитора с его "прелестными" 64 символами в строке я отказываюсь.
Касательно включения чего-то в ROM-BIOS. Упор был на идеологию минимального вмешательства. Т.е. функционал базового Ориона не должен страдать, а ОС это "надстройка", дающая дополнительный функционал, для комфортной работы. Родной (RK86/ORDOS) софт Ориона должен "видеть" нативную среду (базовый М2 и API ORDOS). Иначе это уже не Орион, имхо.
Кому полезно? Мне - нет :)Цитата:
Сообщение от barsik
Драйвер завязан на функционал DSDOS (ввод-вывод символов, организация оконного режима вывода, операции с файлами). Вплоть до обращения к системным переменным ОС и её буферу каталога файлов.
Писать нечто универсальное (и дико тормозное, разумеется) задачи не стояло.
Так сделайте.Цитата:
Сообщение от barsik
Флаг Вам в руки.Цитата:
Сообщение от barsik
В свою очередь, считаю мышь совершенно излишней на 8-битке. Но, если кто-то придумает ей применение и адекватно это реализует, то почему бы и нет.
Опять же, есть маленькая проблемка.. изначально у Ориона нет мыши. Чтобы заставить пользователя её "прикрутить" (а предварительно приобрести), нужно сделать что-то такое.. уж точно не банальную возможность "тыкать в файлы в нортоне", а что-то более мотивирующее.
Нет! Это как раз важно!Цитата:
Сообщение от barsik
GUI на Орионе ради преклонения перед американскими технологиями, в ущерб производительности и вообще мимо какого-либо здравого смысла? Бесперспективняк.
ЕМНИП, это был 1998-ой год. Из оф. инфы по Ориону было описание ORDOS и SPDOS. Всё. На волне хайпа я поддался всеобщему соблазну американских технологий и пытался программировать на Си под MSDOS (на чужом лаптопе). Самодельная реализация RS-232 с помощью двух ног порта ВВ55 и мозгового штурма. Протокол RS-232 я расковырял выводя прилетающую с писюка инфу на экран Ориона. Далее придумал как выводить ОРДОС-файл, стало быть нужно было придумать формат его хранения на писи. Так родился формат ORI. Степень его "нестандартности" лично мне оценить сложно, т.к. других формат не было (слова "интернет" я не знал, в ФИДО была гробовая тишина на тему Ориона). Тут скорее принцип: кто первый, того и тапки. А о каких-либо стандартах говорить смешно, ибо писюк в мире Ориона это резиновая баба.Цитата:
Сообщение от barsik
П.С. сигнатура нужна для исключения подлога: подсовывания левых файлов с переименованным расширением в ".ORI". Степень ненужности данного функционала каждый оценивает по-своему.
Это не удобнее, а это "мне так привычнее". Почувствуйте разницу ;)Цитата:
Сообщение от barsik
Тут я ничего не понял %)Цитата:
Сообщение от barsik
Орионовский файл на писи это просто контейнер. Какие паритеты и КС, зачем они? Чтобы больше тормозил файлообмен?
Даты файлов изначально в DSDOS не было, но потом в ней возникла насущная необходимость, и даже место в заголовке нашлось, причём не влияя на родную структуру ORDOS. Было сделано и активно используется.
Цитата:
Сообщение от barsik
Цитата:
Сообщение от barsik
В целом принцип понятен.. как в том анекдоте, по любому вопросу есть два мнения: моё и неправильное.Цитата:
Сообщение от barsik
И тут тоже понятно. Не как в американских технологиях, значит неправильно. Не как я привык, значит неудобно.Цитата:
Сообщение от barsik
Я делал с нуля, поэтому изначально делал как мне реально удобнее и интуитивно понятнее. Стрелки гоняют курсор согласно соответствующим направлениям - это, имхо, логично. Табуляция тоже гоняет курсор между панелями (для совместимости с писишными привычками), но мне удобнее пользоваться стрелками.
Для перемещения в начало конец списка на экране удобнее использовать соответствующие клавиши ([Home]/[End]), а для перемещения в самое начало и в самый конец всего списка их комбинации с Ctrl. Просто, быстро, логично, интуитивно.Цитата:
Сообщение от barsik
Имхо, конечно.
Вопросы "резиновой бабы" (эмуляции) меня мало интересуют, гораздо увлекательнее работать на реальной железке. Для этого и создана DSDOS и ПО под неё.Цитата:
Сообщение от barsik
Для написания же статей (снятия скриншотов) я использую прекрасный эмулятор от камрада b2m, там виртуальный дисковод моя ОС видит и всё работает "из коробки", никаких специальных телодвижений для этого не требуется.
Нажимаем иконку дискеты, выбираем ODI-образ и DSDOS прекрасно видит эту "дискету" (пиши-читает файлы).
Другие эмуляторы не пробовал в виду отсутствия таковой нужды. Полагаю, что если в эмуле реализована одна из известных версий КНГМД для Ориона, то она также без проблем будет работать с моей ОС.
Концепт ОС предполагает изначальную поддержку всех актуальных носителей, т.е. соответствующие драйвера уже включены в ядро. Также есть возможность проинсталлировать свой драйвер, в т.ч. "поверх" родного. Вариативность вполне достаточная, имхо.Цитата:
Сообщение от barsik
Скрытый текст
- - - Добавлено - - -
Stampmaker, исходники я не выкладывал на сайте.Цитата:
Сообщение от Stampmaker
По поводу контрольных сумм (КС) для файлов поделюсь мнением: они имели бы право на существование, если бы файл был чем-то константным. Но представьте такое: некий процесс (или несколько процессов) постоянно пишут в файлы (элементарно логи в /var ), причем они не новые файлы создают, а правят (или дописывают) существующие. И что же, ОС при этом после каждой записи (а их, напомню, архимного и архичасто) должна пересчитать КС всего файла (а если файлы большие, например всё те же логи в /var ?) и внести изменения в заголовок файла? Очевидно что такая система не жизнеспособна, и даже с небольшими файлами - будет работать сама на себя. А для ПЗУ (где файлы не меняются) КС тоже вряд ли имеет смысл, т.к. носитель не испортится (99,999%) и файлы не правятся. КС могла бы иметь место на единице хранения - блоке файловой системы, кратно корой происходит каждая единичная запись данных, но Ордос до таких категорий не доросла.
КС файла у меня реализована при файлообмене с виртуальным диском, т.к. там есть реальная нужда в этом (могут иметь место помехи передачи в железке). Но там КС упрощённая (XOR всех байтов тела файла), она вычисляется на лету (не увеличивает общую скорость обмена) и передаётся только между хостами, в заголовке файлов не хранится.
А что тут представлять? Простенькие конверторы проще всего писать именно на бейсике. Получается быстрее, чем на Си или ассемблере. Беру заготовку, где уже есть загрузка файла и запись результата в файл. Остаётся потратить пару минут на написание всего нескольких строк на бейсике, что и делают конверсию. И даже не требуется бейсик программу компилировать.Цитата:
Сообщение от Denn
Фраза как раз характеризует именно Ваше отношение, не моё. Явное нежелание даже хоть что-то обсуждать.Цитата:
Сообщение от Denn
Напрасно Вы восприняли мой пост как "наезд". Я не критиковал, а высказал личное мнение, причём всего на пару моментов, о том что реально неудобно, но что при желании поправить совсем несложно.
Я понимаю, что при программировании интереснее написать своё, чем заимствовать. Но речь о базовых вещах, здесь изобретать велосипеды незачем.
А я использую прекрасный эмулятор EMU80, где в меню выбора есть ОРИОН с DSDOS, но дисковода нет.Цитата:
Сообщение от Denn
А вот это совсем неправильно, т.к расширение ODI используется уже более 10 лет и этот формат общепризнан и поддержан эмуляторами и утилитами, как формат CP/M Ориона и Корвета.Цитата:
Сообщение от Denn
Обозвав так же формат дискет SPDOS, Вы ввели никому ненужную путаницу. Здесь как раз и необходимо было вводить новое расширение. Фантазии не хватило на собственное расширения для образов дискет SPDOS? Не знаю как в эмуляторе от b2m, но в EMU80 можно для каждой конфигурации задать используемый тип файлов с образами дисков.
Вообще-то диск подключённый по линии называется сетевым. Понятно, что при передаче всегда используются КС. Речь шла о ORDOS-файлах, чтобы обнаруживать дохлоту в реале.Цитата:
Сообщение от Denn
При файлообмене без разницы какие два байта пересылать, два нуля или два байта КС. И всё как раз наоборот, - не имея готовой КС, при файлообмене КС придётся считать, что и затормозит, хотя и несущественно.Цитата:
Сообщение от Denn
Байт паритета это упрощённый аналог КС, но однобайтовый (знаю ЭВМ в которых в МГ-подпрограммах для контроля пересылается именно байт паритета блока, а не два байта КС). Предложил я это лишь для того, чтобы уместить в 4 байта три вещи: КС, расширение ORDOS-имени и дату файла.
Речь идёт о средстве позволяющем выявлять дохлоту в архивных файлах. А не для выявления ошибок в объектных кодах прямо в процессе трансляции исходников программ в ORDOS-файл ассемблером. Причём и такой ситуации даже нет, т.к ассемблер ORDOS производный от МИКРОНА пишет не побайтово, а массивом.Цитата:
Сообщение от error404
Нелепый довод. Удивлён читая такое от Вас, т.к Вы знакомы с тем как программы работают с файлами. Во всех ДОС, кроме ORDOS, файл сначала открывают, а в конце работы закрывают, после чего никаких изменений с содержимым файла не происходит. Что за идиот стал бы перезаписывать КС при каждой очередной записи в файл, достаточно это сделать один раз при закрытии файла.
Но сейчас ORDOS дорабатывать поздно, т.к в реале ей никто, кроме Denn-а не пользуется. Я включил функцию подстановки КС в ORD-файл в нортоны и всё, проблема решена. Не увидел такого решения у Denn-а, и его использование лишних байтов в ORDOS-метке не совпадает с моим, потому и предложил обсудить это. Но когда сталкиваешься с таким отношением, то в другой раз не захочется что-то обсуждать.
Насчёт жизнеспособности. Имею исходники 6-ти разных DOS (совершенно разных концепций), которые используют эл.диск в качестве носителя. И все они используют для контроля целостности файлов контрольные суммы и работе программ с последовательным и произвольным доступом это нисколько не мешает.
К тому же речь шла именно о ORDOS-файлах, т.е об ORDOS, а не о какой-то иной более нормальной DOS в которой файлы имеют настолько большие размеры, что считать КС всего файла очень долго.
Я исхожу из реальной практики. В конце 80-тых пару лет пользовался платой внешнего эл.диска на РУ7-мых, для чего одним грамотным програмистом была написана RAMDOS (не путать с RAMDOS РК86 Д.Лукьянова из ж.РАДИО). Там файлы имели КС. Потому, хотя файлы иногда дохли, но дохлые файлы не плодились.
А в ORDOS дохлые файлы просто разводились. Не только из-за помех по питанию, падения утюгов на плату и проникающего гамма-излучения. При разработке ПО всегда происходят улёты. В.Воронин (Алёна) специально разработал апп.защиту квазидисков ORDOS от записи. Как только я познакомился с ORDOS, то на основе предыдущего опыта сразу же сказал, что это большая дурь не иметь КС файлов. Так что ORDOS - единственная в мире DOS, где нет КС.
Разработчики мыши для БК-010 и Корвета так не считали. Эта мышь называется "манипулятор ММ 8031". Выдаёт результат в параллельном коде (с двух реверсивных счётчиков) и подключается просто и всего через один порт ППА.Цитата:
Сообщение от Denn
Глупости. Весь мир сделал свой выбор.Цитата:
Сообщение от Denn
Теперь ясно, что Вы не Стивен Джобс, который увидев мышь сразу понял удобство графического интерфейса.
Речь о однозадачной ОС. Точнее даже не о ОС, а лишь об оболочке для любой ОС для управления файлами. Что-то типа Finder для MAC-128, только на 2 порядка проще. Понятно, что суть будет совсем иная. Но сначала надо получить хотя бы внешний интерфейс, а далее можно улучшать идеологию. Естественно и графика поначалу получится некрасивой, но при желании всё можно довести до шедевра.
Имея свой нортон с окнами для какой-либо DOS, берём оттуда готовые исполнительные части команд (COPY, MOVE, RENAME...) и заменяем табличный интерфейс нортона на графический. Имея готовый графический интерфейс, это сделать совсем несложно.
Кстати, графические оболочки Apple-II Desktop, MouseDesk и Quark Catalyst прекрасно работали на 8-ми разрядных Apple-IIе и Apple-IIс с тактом CPU в 1 МГЦ и ОЗУ в 128 кб. Ресурсов 8-ми разрядки достаточно, чтобы вывести на экран пиктограммы и синхронно с движением мыши двигать по экрану стрелку-указатель. Хотя горизонтальное разрешение, чтобы улучшить графику, желательно поднять до 448*256.
Не понимаю Вашего страха перед GUI. Кстати, написание GUI это самая интересная задача, что осталась в системном программировании для ОРИОНА и СПЕЦИАЛИСТА.
Какой ущерб производительности? Какая разница перемещать балку подсветки в нортоне курсорными клавишами или перемещать стрелку-указатель мышью в GUI.
Чтобы избавиться от страха написать GUI-интерфейс, подумайте о том, какие минимальные функции нужны для GUI. Тогда Вам станет ясно, что это не намного сложнее, чем написать нортон и уж точно проще, чем макро-ассемблер.
Для простейшего GUI нужны функции:
1. Открытие окна
2. Изменение размера окна
3. Перемещение окна
4. Перекладывание нижележащего окна наверх
5. Вывод пиктограммы и её перемещение мышью
6. Перемещение по экрану стрелки-указателя синхронно с движением мыши
7. По нажатию кнопки мыши проверка на попадание в заданные окна
8. Обслуживание окна выпадающего вертикального меню
Здесь относительно сложно сделать только пункт 4. Позиции 6,7,8 у меня уже есть (написал ещё в 90-тые годы). К сожалению, для Z80. БОльшая сложность нарисовать пиктограммы. Поэтому и искал Windows для ОРИОНА, что входила в дистрибутив CP/M-48K от ОРИОНСОФТ в 1993. Но так и не нашёл.
Сейчас у меня много незаконченных проектов (причём по железу), но чуть позднее, надеюсь поиметь мышь и заняться программированием GUI для СПЕЦИАЛИСТА (с ОЗУ 256 кб), хотя для КР580 программирование графики существенно усложняется.
Вы бываете слишком категоричны. То порт никому не нужен, то ORDOS никем не используется... Ну я вот тоже пользуюсь и тем, и другим. И вполне разделяю точку зрения Denna.Цитата:
Сообщение от barsik
Это наверное все уже видели, смотреть там особенно не на что. См. во вложении этого поста.Цитата:
Сообщение от barsik
Про файлы комментировать не буду, рассуждения продиктованы опытом, а у меня опыт другой (во многом с машин откуда и UZIX, где в порядке вещей с большой частотой открывать-закрывать файлы чтобы изменить в них только несколько байт, т.к. работа с файлами ведется не только пользователем, но и ядром и сервисами ОС для её собственных нужд).
Что значит "ОРИОН с DSDOS"? В смысле, подкинут образ ROM-диска со сборкой DSDOS ?Цитата:
Сообщение от barsik
Ну, подкиньте тогда стандартный КНГМД (как он там официально называется, плата которого в комплекте плат "Орион-128 рев.512" ?).
ODI - это виртуальный образ дискеты объёмом 800 Кб (Прим.: копия секторов, без служебной разметки треков).Цитата:
Сообщение от barsik
В чём неправильность? Что эмулятор b2m его поддерживает и/или что DSDOS с ним работает "из коробки" ?
Полагаю, что b2m сделал его поддержку, т.к. он известный, популярный и, в общем-то, наверное единственный в своём роде для данной задачи.
А в DSDOS просто есть поддержка работы с ГМД подходящей организации.
Зачем? Какое своё расширение? Устройство 800кб-дискет, равно как и формата ODI, не зависит от ОС, это просто хранилище (файл ODI - соответствующий контейнер).Цитата:
Сообщение от barsik
Под форматом SPDOS имеется в виду логическая организация данных на диске (DIR & FAT). Вопросы авторства формата - к М.Короткину, я так понимаю формат придумал он. По крайней мере в описании никаких упоминаний о заимствовании нет.
Вопросами эмуляторов не владею, тут лучше обратиться к знающим людям.Цитата:
Сообщение от barsik
У меня почему-то язык не поворачивается называть RS-232 линк "сетью". Имхо, сеть - это нечто большее, чем соединение двух абонентов.Цитата:
Сообщение от barsik
В данном случае как раз считаю, что было бы неграмотно (в "американском смысле") называть хранилище на писи "сетевым диском".
Он может и становится "сетевым" в случае расшаривания с помощью утилиты Google-Drive, но это частный случай использования, и сетевая функция уже виртуальная.
Для обнаружения дохлоты в реале лучше пользоваться осциллографом ;)Цитата:
Сообщение от barsik
У меня за 17 лет "дохлоты" носителей не встречалось. Битые дискеты попадались конечно, но там без программной КС проблема обнаруживается. Сбоев квазидиска не было ни разу.
Считаю неразумным вводить тормоза файлообмена в угоду перманентного контроля неисправности аппаратуры.
Считать КС придётся по любому, на каком этапе - без разницы. И это медленно. Лучше собрать нормальное неглючащее железо и работать на комфортной скорости, имхо.Цитата:
Сообщение от barsik
файл может быть не закрыт (зависли, вышли из программы некорректно и т.п.), получается что КС будет неверная.Цитата:
Сообщение от barsik
Потом, неполадка (требующая контроля КС) может случиться в любое время, в т.ч. когда файл открыт.. и её нужно контролировать и обрабатывать, иначе смысл затеи теряется.
Вы живёте в своём мире (увы, американском), и считаете, что остальные мыслят и делают всё также. Ну, или по крайней мере должны также.Цитата:
Сообщение от barsik
Есть люди, которые до сих пор работают на Орионе в М1 и загружают ПО с магнитофона.
А есть те, кто программирует на калькуляторах. Кто-то прошивает РФ2 с помощью тумблеров.
Мир многогранен.
Для американского ПО существуют соответствующие американские компьютеры, и там оно всё адекватно. У русских, как известно, свой путь :)
Серьёзно?Цитата:
Сообщение от barsik
Если бы на писи была КС, и при добавлении данных в файл выполнялся её пересчёт и контроль, то обработка видео в реальном времени была бы невозможна. Даже при нынешних гигагерцах и гигабайтах в секунду.
Я рад за них. Их концепт пошёл в народ? Идею "ММ 8031" все бросились копировать? Написано ПО, которое вкусное и без этой их мыши ничего подобного не сделать?Цитата:
Сообщение от barsik
За мир сделали выбор те, кто диктует правила (у кого есть власть/деньги). Тайд стирает лучше других порошков, это знают все правильные домохозяйки ;)Цитата:
Сообщение от barsik
Джобс не в курсе про Орион-128, его возможности (ресурсы) и выполняемые задачи.Цитата:
Сообщение от barsik
Самый удобный интерфейс для человека - голосовой (а ещё лучше силой мысли прямо в мозг). Сейчас к этому мир идёт.
Только всё должно быть адекватно. Если вывод "Hello World" заберёт все ресурсы ПК, то нет смысла в такой концепции ПО.
А я - да, не Джобс уж точно. Слава богу.
Простой вопрос - ЗАЧЕМ? Демосцена на Орионе? :)Цитата:
Сообщение от barsik
Вероятно у нас разное понимание термина. Под GUI я понимаю ГРАФИЧЕСКИЙ интерфейс пользователя. Не символьный. Т.е. элементы интерфейса представлены графикой. Достаточно взять ТТХ Ориона и калькулятор, и станет понятна бессмысленность затеи.Цитата:
Сообщение от barsik
У меня оболочка ОС выводит на экран по 25 файлов в каждой панели, итого 50 файлов появляются на экране почти мгновенно. Надеюсь размер вашей пиктограммы не 8х8 и она не монохромная ? Вот и прикиньте отрисовку хотя бы половины (или даже четверти) этого кол-ва пиктограмм на Орионе-128. А заодно посчитайте объём памяти, требующийся для хранения этих пиктограмм и смысл такой затеи для запуска М128 и прочих бэйсиков.
С объёмом ОЗУ 128кб и ROM-диском на 64кб такая ОС просто не взлетит, вероятно придётся грузиться с дискеты, а это даже не смешно.
Разница в объёме кода "прослойки" (ОС) и необходимости "махать паяльником".Цитата:
Сообщение от barsik
Если отбросить мотив "шоб было крутакак на американском компе", то для чего оно надо?
Простая посекторная копия диска, как-бы, не имеет формата, ну кроме, может быть, порядка следования секторов в файле. Но он в подавляющем большинстве случаев одинаковый и логичный. То есть, какой-то специальной поддержки именно орионовских дисков в эмуляторе нет.Цитата:
Сообщение от Denn
Чтобы отличать одни образы от других, используется расширение файла. Для меня известным и популярным становится то, что я в достаточном количестве нахожу в интернете. Для Ориона-128 это были файлы с расширением .odi и именно это расширение я указал в конфигах для выбора файлов-образов.
Ну там на практике (то есть в большинстве утилит, которые я встречал) для подобных форматов используется след. негласные соглашения:Цитата:
Сообщение от b2m
- сектора упорядочиваются по значению в ID-маркере сектора сектора (если возможно), а не по физическому расположению,
- для двусторонних дисков: стороны хранятся не раздельно, а чередуясь для каждого цилиндра (цилиндр_0 сторона_0, цилиндр_0 сторона_1, цилиндр_1 сторона_0, цилиндр_1 сторона_1,...).
И все.
Это название пункта в меню выбора платфомы в эмуляторе. Значит автор эмулятора включил конфиг под такое железо и ПО. И посчитал ненужным включать туда дисковод. Видимо это было давно, когда DSDOS ещё не поддерживала обычный КНГМД, а позднее Вы поленились послать автору эмулятора образы дискет в формате SPDOS.Цитата:
Сообщение от Denn
Насчёт смысла, - это свойственная Вам депрессия. Зачем Вы постоянно всё депресуете? Нужна, наоборот, моральная поддержка. А зачем этот сайт читают и пишут? Это такое хобби. И оно лучше, чем клеить кораблики внутри бутылок.Цитата:
Сообщение от Denn
С чего Вы взяли, что большой объём памяти тратится на пиктограммы. Типов иконок, допустим 8. Типоразмеров иконок, для начала два: 24*32 и 16*24. Итого расход на пиктограммы всего ~1 кб. А вот на окна действительно уходит много памяти, но 2-х банок хватит. Кстати, я ориентируюсь на больше, чем 2 банки, мне нужен RAM-диск, а лишь DOS+GUI занимают 2 банки.
Не взлетит, - это непонятный жаргон. Что Вы этим утверждаете? Что будет работать неудовлетворительно или вообще не будет работать? На Apple-IIe хватило 128 кб и тормозного флопа на 140 кб. ROM-диска там вообще не было.Цитата:
Сообщение от Denn
Чего "несмешного" в загрузке с дискеты? DOS грузится с дискеты или ROM-диска, а DOS стартует Desktop оболочку. Всё, естественно, работает из ОЗУ. Весь код для работы с графикой в банке где экран, а код DOS и TPA в другой банке. Тип DOS вообще не важен. Это может быть DOS объёмом в 12 кб или RKDOS в 4 кб и даже ORDOS объёмом в 2 кб.
Не сомневаюсь, что получится тормознуто, но вовсе не из-за графики, а из-за небайтовых шрифтов. Придётся использовать шрифты 5*9, 6*9 и 7*9, и кстати, драйверы придётся переделать, чтобы символы можно было помещать в любое место экрана, а не только в позиции знакомест. Вот тогда и понадобится Z80 на такте 4.5 МГЦ (пиксель клок 9 МГЦ, экран 448*256).
В графическом интерфейсе в окне можно выводить и список файлов, так что интерфейс Нортона можно считать окном GUI со списком. Размеры иконок масштабируются пользователем, так что нужны картинки всех размеров от 8*12 до 32*48.Цитата:
Сообщение от Denn
Из этого вопроса и потому, что Вы считаете, что возможностей ОРИОНА для GUI не хватит, думаю что Вы не пользовались GUI на Apple-II или на Apple MAC-128 из 1984 года. У меня они есть оба в реале и я Apple GUI пользовался.
В GUI на слабых машинах применяют монохром, хотя особенности цвета Специалиста позволяют оцветить без торможения. В цветных Amiga и Atari - GUI тоже монохромный. GEM от DR для EGA тоже в основном монохромный.
Посмотрите вид графического интерфейса на Apple-IIe работающем на CPU с тактом в 1 МГЦ, ОЗУ 128 кб и экраном 560*192. Интерфейс монохромного MAC выглядит похоже (только белый и графика лучше, т.к там растр 512*342).
Скрытый текст
Вы прекрасно знаете, что в DOS работающих с носителем с помощью БИС контрольные суммы есть у физических секторов. И даже в DOS, где сам процессор заменяет БИС, контрольные суммы всегда используют. А для CD и DVD даже используются исправляющие контрольные коды.Цитата:
Сообщение от Denn
... ужас от Ваших доводов. Если файл открытый на запись не закрыт, то его каталоговая запись неверна и волноваться надо уже не о том, что КС не совпала, а о том, что содержимое файла не то. Но речь-то об ORDOS, где нет даже такого.Цитата:
Сообщение от Denn
Понятно, что КС разумнее иметь у секторов, т.к это единица обмена, но речь-то о ORDOS, где нет ни секторов, ни контрольных сумм. Потому и совершенно очевидно решение исправления ситуации, - иметь КС на целый файл, тем более, что файлы маленькие. Иметь КС удобно, т.к это даёт гарантию, что файл не повреждён.
Создаётся впечатление, что Вам не важно на что и как возражать, лишь бы возражать. Я лишь предложил с пользой использовать свободные 4 байта в метке ORD-файла. Точнее предложил даже не использовать, т.к и так давно это использую, а ввести единообразие, стандартизовать. А это вызвало обструкцию и неприятие. И смехотворные доводы.
А речь шла не только о КС и дате файлов. Очевидно, что глупо было отводить на имя всего 8 символов, а для программ всего 7, оставляя в то же время 4 байта в ORDOS-метке неиспользованными. И если в самой ORDOS с этим большим неудобством смирились, то при конверсии в ORD-формат нормальных файлов из других DOS теряется расширение.
Я эту ситуация давно исправил. Двумя способами. Просто подстановкой 3-х символов CP/M-расширения в позиции 13,14 и 15. А байт с оффсетом 12, как флаг что есть продолжение имени, ставится равным 7E (символ '~'). Второй способ, расходует лишь 7 битов, оставляя 3 байта для КС и даты, - тогда 12-й байт это токен, который кодирует стандартное расширение. В тех DOS, что я использую, загрузчики понимают оба эти формата ORDOS-метки.
Кстати, в SPDOS разумно было бы ввести нормальные имена файлов, т.е, как Вы это называете - сделать "как принято в Америке", а не в ORDOS.
Ладно, проехали и забыли. Исходил из того, что Вы программируете для ОРИОНА и сделал неверные выводы. Убедился, что Вам на всё наплевать.
Согласен. Учту.Цитата:
Сообщение от VituZz
Исходил из того, что не встречал ранее людей, кто применил третий ППА. На платах ташкентского Турбо-10 МГЦ и принтер и ROM-диск обслуживает один порт F500. Зачем тогда нужен третий ППА? Он только излишне грузит шину и снижает надёжность при турбировании по схеме Турбо-200%. Гораздо разумнее на этом месте было бы поставить ВИ53. Но он и вручную удобно ставится на это место.
А какую конкретно точку зрения Denn-а Вы разделяете? Я уловил у него только одну точку зрения, что GUI для 8-ми разрядки - это чушь собачья, а мировой опыт не в счёт, т.к это изобрели мерзкие американцы.Цитата:
Сообщение от VituZz
"Орион" хорош тем, что это своего рода радиолюбительский конструктор. Авторы дали основу, пусть и небезупречную (это нам теперь хорошо рассуждать апостериори, а тогда - они сделали, а мы - нет!). Каждый, разумеется, видит свой путь усовершенствования ЛК. Кто-то хочет более быстрый процессор, больше памяти, CP/M с существующим обширным ПО. А кто-то считает, что смысл существования такого компьютера в том, что можно быстро набросать примитивную программу, легко подключить какое-то своё железо и поработать с ним, как сейчас в стиле Ардуино. У меня на железном "Орионе" есть и расширенная память, и контроллер дисковода, и ROM-диск, и ещё всяких железных разностей, но я давно уже понял, что для моих целей вполне достаточно 128 кБ ОЗУ, текстового экрана с символами 6х8, ROM-диска на 64 кБ и дискеты для оперативного сохранения результатов своей работы. Дисковод, возможно, в будущем заменю на CF.Цитата:
Сообщение от barsik
Поэтому третий порт у меня постоянно используется, проблем с нагрузкой на шину пока не замечал. Правда, ПЗУ с "Монитором" у меня включена через буфер, но это я делал только лишь для динамического питания РФ2, поскольку справочник утверждает, что при таком питании инфа в ней хранится дольше.
Принцип разумной достаточности.Цитата:
Сообщение от barsik
Строго говоря, мировой опыт насчитывает куда как более обширную историю и разнообразие CLI (и при наличии и поддержки бизнес-графики на тех платформах в том числе), чем GUI. И поныне весь сегмент средней и высшей стоимости выч.техники и ПО это прежде всего CLI (даже Windows пришлось допиливать до приличной CLI когда Билл решил влезть на этот сегмент рынка IT).Цитата:
Сообщение от barsik
Массовое же внедрение GUI имело под собой вполне конкретную бизнес-задачу: в товарных количествах привлечь бытовых хомяков в сферу продаж вычислительной техники (что стало возможно при удешевлении техники на волне повышения степени интеграции). Что мы пожинаем и по сию пору: представьте насколько лучше была бы социальная жизнь не будь этих б-гомерзких смартфонов с социальными сетями, вытеснившими живое общение.
Поскольку мы не те хомяки (их на орионовщине почти не было, это все же не Спектрум), то GUI сделать конечно можно - если очень хочется для получения собственного удовольствия, но говорить что оно нам принесет что-то недостающее - это вряд ли. Хотя посмотреть будет очень интересно из соображений что удастся выжать из этой идеи. Оно конечно реализуемо (сделали же SymbOS), но количество затраченных человеко-часов конечно будет запредельное, поэтому и не хочется за это браться.
Windows производства Орион-Софт уже посмотрели по моей ссылке?
Как неоднократно упоминал ранее, вопросы эмуляции меня мало заботят, т.к. предпочитаю реальное железо.Цитата:
Сообщение от barsik
Я не "ленился", а просто не интересовался данным вопросом.
Каждый занимается своим делом. Тот, кто развивает эмуляторы, сам ищет востребованные фишки и воплощает их в своих детищах.
По поводу форматов уже отвечал ранее.Цитата:
Сообщение от barsik
Дискета - это наследие от старых времён, сейчас я ими не пользуюсь. Поддержка их в DSDOS сохранилась.
Вы натолкнули меня на идею включать в комплект поставки сборки ОС набор ПО, не поместившегося в 64К-вариант ROM-диска, в виде образа дискеты!
Это мысль! спасибо ;)
Призыв к здравому смыслу вгоняет вас в депрессию? По каким причинам?Цитата:
Сообщение от barsik
GUI на Орионе бесперспективен в практическом смысле, так что тут я не готов поддерживать.Цитата:
Сообщение от barsik
На счёт корабликов согласен :)Цитата:
Сообщение от barsik
Вы же не планируете их хранить в JPG, ведь так? /-)Цитата:
Сообщение от barsik
Зачем они тогда нужны? Что принципиально меняет использование восьми иконок для конечного пользователя?Цитата:
Сообщение от barsik
Без подколов, просто хочу докопаться до истины. Может я чего-то не понимаю в компьютерах...
Надеюсь всем понятно, что ПРК Орион не для домохозяек, мягко говоря. Зачем 8-битному юзеру запуск М128 или PENX'а через иконку?
Масштаб работы по возделыванию GUI этого стоит?
Это 96 и 48 байт на картинку, соответственно.Цитата:
Сообщение от barsik
К примеру, это 14 шт. пиктограмм займут объём, который занимает весь код ORDOS. Код их обслуживания.. наверное чуть больше М128$ или даже М256$.
При этом для пользователя функционально ничего не изменится. А вот ОЗУ пользователя станет меньше, места в ROM-диске тоже.
В чём профит?
Может лучше сделать прикладное ПО, собственно для которого ПК и предназначен?Цитата:
Сообщение от barsik
А в ОС заложить возможность предоставить максимум комфорта пользователю при минимуме отжора ресурсов.
Это местный жаргон на форуме. "Не получится".Цитата:
Сообщение от barsik
Не влезет в стандартный (классический) Орион.Цитата:
Сообщение от barsik
Точнее так, влезти может и влезет, а вот ресурсов для ПО не останется. И вместо комфорта получим ограничения и раздражающие тормоза.
Я рад за Яблочников. Понятие "хватило" весьма относительное.Цитата:
Сообщение от barsik
Зато я чётко представляю чего хватает и чего не хватает для Ориона, и для комфортной работы на нём. Работы, а не демомэйкерства.
Без слёз смотреть загрузку ОС и подгрузку её модулей с дискеты во время работы невозможно.Цитата:
Сообщение от barsik
Слава богу, в Орионе изначально придуман классный концепт загрузки ПО (как минимум, системного) из ROM-диска.
Но родной ROM-диск это 64 Кб, точнее даже 62 Кб... приходится крутиться и вертеться, и уж точно без графики.
А программы пользователя можно не запускать, ибо уже негде :)Цитата:
Сообщение от barsik
Если кроме шуток, то ОЗУ пользователя (яснопонятный русскоязычный термин, использованный в оф. лит-ре авторами Ориона, в отличие от TPA "оттуда")
в идеале должно максимально стремиться к целой банке (64 Кб), имхо. К сожалению, в Орионе оно фактически ограничено 48 Кб из-за экранной области, лежащей в общем адресном пространстве ОЗУ пользователя. Но хотя бы все эти 48 Кб предоставить прикладному ПО. Для ОС и её нужд фактически остаётся вторая страница, и то не полная, а "зазоры" между областями атрибутов цвета экранных областей.
Можно, конечно, пойти путём размещения ОС и её причиндалов в 3-ей банке, но тогда либо сильно урезаем квазидиск, либо лишаемся его вообще, а это очень серьёзная полезняшка, от которой лично я не готов отказываться.
Забудьте про честный графический вывод символов на Орионе. Просто забудьте. Серьёзно.Цитата:
Сообщение от barsik
П.С. кстати, мир перешёл на векторные шрифты. Сотни мух не могут ошибаться, ведь так? ;)
Натянем на Орион? Чем не челендж? ;)
Если вы ещё не поняли (читая форум), то все аппаратные доработки Ориона будут делать полтора человека - вы и может кто-то ещё (начнёт, но не доделает).Цитата:
Сообщение от barsik
Вопрос "зачем?" я уже задавал.Цитата:
Сообщение от barsik
Масштабировать будете высшей математикой или туполинейным набором картинок всех размеров? Объём кода и ж/ч vs. реальная необходимость этой красоты?
Не пользовался. Из 8-биток мне интересен только Орион.Цитата:
Сообщение от barsik
Монохромная графика уныла и невыразительна, на мой взгляд. Впрочем, талантливый художник возможно предложил бы красивые решения и в таком формате, но пока таковых не встречал.Цитата:
Сообщение от barsik
Здесь Орион. Как есть. Доработки никто делать не будет. Никто. Потомучто.Цитата:
Сообщение от barsik
Так это ж нерусские платформы. С нерусскими идеями, задачами, мышлением. Оно уже всё придумано и воплощено.Цитата:
Сообщение от barsik
На запорожец наверное можно поставить фары от форда, но какой смысл?
По-своему занятно. Но лично мне такое не нужно на Орионе, т.к. чётко понимаю ресурсы Ориона и задачи для него.Цитата:
Сообщение от barsik
Я мысленно созрел на символьно-клавиатурный оконный интерфейс для некоторого ПО, но графика и мышь точно нет.
Мимо обсуждаемого вопроса. Мы говорили про подсчёт КС средствами ОС и хранение её в заголовке файла.Цитата:
Сообщение от barsik
В данном топике речь про DSDOS, а не про ORDOS.Цитата:
Сообщение от barsik
Польза программной КС очень сомнительна. Польза даты очевидная. И дата была введена в DSDOS задолго до поддержки аппаратных RTC.
Мне за 17 лет реальной работы на Орионе это ни разу не понадобилось. Обычным пользователям тем более не нужно.Цитата:
Сообщение от barsik
Хорошо, допустим я программирую на Орионе, сохраняюсь на квазидиск и после неудачного "мазка" у меня код улетает в космос, по пути оставляя следы в квазидиске. Что в этом случае мне даст ваша КС? То, что файл исходника испорчен, я и так узнаю (текстовый редактор при открытии рабочего файла проверяет на ошибки формата, а ассемблер умеет обнаруживать более "высокоинтеллектуальные" ошибки исходника).
Какой профит от КС? Она же не снимет порчу :)
Стандартизация с какой целью? Ориону глубоко фиолетово в каком виде его файлы хранятся на дисках.Цитата:
Сообщение от barsik
Контейнера *.ORI вполне достаточно для хранения файлов Ориона на писи. За 20 лет у меня не возникла потребность как-то его дорабатывать.
Вы храните свои файлы в ORD, я храню в ORI, а остальные "полтора" человека хранят на дискетах ("половинка" на реальной, а "целый" в ODI), вот и вся реальность :)
За что люблю Орион и его изначальный ORDOS-концепт: достаточный минимализм.Цитата:
Сообщение от barsik
Красивый и лаконичный 16-байтовый заголовок файла, однобуквенные команды ОС.
Для ресурсов Ориона идеально.
Для "многообразия" ПО на Орионе 8(7) символов для имени файла достаточно. По мере необходимости в них же запросто "запихивается" расширение.
Главное без фанатизма и желания натянуть неуместные здесь писишные масштабы и навороты.
Зачем?Цитата:
Сообщение от barsik
Но, судя по второй части предложения, кажется, вы уже начинаете всё сами понимать.
Уловили неверно.Цитата:
Сообщение от barsik
Не "чушь", а на мой взгляд бесполезное изобретение из разряда "круто", неадекватное задачам и ресурсам Ориона.
Мирового опыта у Ориона нет и никогда не будет, ибо это платформа для творчества узкого круга людей с определённым менталитетом, а не для коммерции и "домохозяек".
Американцы не мерзкие, просто у них свой путь.
Как всегда прикольно смотреть на битвы гигантов.
Denn, Давай меньше демотиваци. А то песня про все Орион-ы, которые сгнили (это было не в этом топике), уже не канает.
OrionExt, вот все не сгнившие - http://zx-pk.ru/threads/27165-perepis-naseleniya.html
Плюс-минус, но в общем картина понятна.
Denn, а ты не реагируй на старого форумчанина, профиль которого вообще другая платформа. Чего он на Орионе то забыл?