OrionExt, я уже понял, что утекло. Вопрос был: где и как?
Припоминаю, что ещё в доинтернетную эпоху писал на писи под ДОСом утилиты обмена с Орионом по RS-232, вероятно какие-то файлы попали на писюк в тестовых целях... а может даже бэкапил что-то тогда. Но это всё была 100% оффлайн техника. Впрочем, ладно, это уже не важно
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
Denn, ну как откуда. С твоего сайта и качал модемом в начале нулевых. Ох, давно это было. Это ведь не твой двойник сайт сделал и исходники выложил
Электроника КР-02, MSX YIS-503IIR, Орион-128, Ленинград-2, Pentagon-128k, MSX2 YIS-503IIIR, MSX-EXT, ...
Зарождение промышленного шпионажа или еще раз о защите информации:-).
http://orion-128.narod.ru/
как бы не отсюда ноги растут
barsik, спасибо за интерес к теме и вопросы.
Упрёк голословный, на основании чего сделан вывод - не понятно. Оформление темы в хронологическом стиле - да, не очень информативно, особенно для "вновь входящих" и привыкших получать информацию в максимально "пережёванном" виде, но те, кто "в теме", знают где что искать.Сообщение от barsik
Всё ПО имеет либо встроенную справку (выводится при запуске программы без параметров, либо с ключом "/?" или "/H"), либо отдельным текстовым файлом "*.H" или "*.HLP", либо по горячей клавише "H" в самой программе.
Информация для пользователя ОС есть на форуме (в первых постах), а также одним файлом в формате "*.doc".
Инфо для восьмибитных программистов (а таковые вообще есть в природе?) представлена в виде тех же "вордовских" файлов с подробным описанием API, распределением памяти, кодировки символов, кодов ошибок и т.п..
Более структурировано, в меру возможностей, пытаюсь оформить документацию тут - https://vk.com/dsdos_orion
Если будет время, то планирую сделать сайт, но это слишком масштабно.. пока не до этого.
Здесь всё исключительно на Орионе, а не на писи! Писюк в качестве хранилища и обменника был "прикручен сбоку" совсем недавно, но его роль лишь в логистике контейнеров с информацией (т.е. это своеобразный роутер для Ориона), не более того.
Я против смешивания 8-битки и писи, это совершенно разные миры.
One more time... Орион - это Орион, это прекрасный 8-битный мир, и он никому ничего не должен. Сабжевая ОС была написана исключительно на самом Орионе, его штатными средствами, и предназначена для работы на этом самом Орионе, с упором на максимальный комфорт и раскрытие возможностей платформы.
Для любителей "поковырять" орионовские файлы с помощью американских технологий (зачем?) был написан соответствующий инструмент -
http://zx-pk.ru/threads/21984-dsdos-...l=1#post883707
Вопрос преобразования кодировок он также решает.
DSDOS разрабатывалась и развивается по одному простому принципу - реальной насущной необходимости какого-либо функционала. Моей личной необходимости. Также по мере возможности воплощаются некоторые хотелки пользователей.
В своё время одних заглавных букв Монитора стало мало, понадобился "нижний регистр" и псевдографика. Нужно - сделали! Информации "как правильно" (или как "кому-то надо") не было, поэтому сделали как логично, исходя из данной ситуации. А логично было исходя из особенностей родной РК'шной клавиатуры прибывать константу к "сырому" коду F81Bh и получить соответствующую русскую букву. Аналогично с регистром букв - тоже воздействие константой на базовый код процедуры Монитора. Других стандартов не было, значит сделали свой. Задача для Ориона решена: имеем два языка, два регистра и псевдографику; текстовый редактор это всё поддерживает, можно ваять тексты и программы.
То, что не удобно на писи - ну, извиняйте, не для того роза цвела, как говорится.
Забавно
П.С. у меня под MSDOS в образовательных целях была написана утилита конвертации туда-обратно, в ДОСовскую 866-ю и в виндовую 1251. Практически не пользовался ни разу.
Двухбайтовый перевод строки это какая-то заморочка исключительно писишных файлов или какой-то писишной обработки, на Орионе такое расточительство ОЗУ не используется, у меня файлов с 0D0Ah нет.
Формат текстовых файлов на Орионе всегда был такой:
Коды символов: 20..7Eh (в DSDOS пошире - 20..FEh);
Разделитель строк - 0Dh;
Признак конца файла - FFh (как я понимаю, наследие Микрона);
Коды 00..0Ch и 0E..1Fh - не используются и считаются ошибкой формата.
Именно это и сделано в DSDOS. Выводом полностью можно рулить через п/п вывода сообщения. Включая управление режимом цвета, с недавней версии.
Только не "американскими" искейп-кодами, а экономными и прицельными последовательностями кодов, которые решают насущные задачи.
Никому ничего не должны. К счастью (да, именно так - к счастью!), на момент зачатия ОС мой мозг не был отягощён знаниями американских технологий, "как правильно" и прочими "уставами" и догматами, которые, как известно, являются не чем иным, как запретом мыслить. Повторюсь, всё создавалось по мере необходимости, исходя из имеющихся реалий.
Так вот, изначально DSDOS базировалась на ПЗУ Монитора в качестве базовой системы ввода-вывода, и представляла из себя только функционал работы с файлами, который и был "неправильно" (в "американском" смысле) назван BIOS'ом: базовая система ввода-вывода ФАЙЛОВ. Не "дисковая система", а ввод-вывод файлов - более широкое понятие, т.к. изначально предполагалась файловая организация обмена данными между программами, а сами файлы не только в виде физических дисков (ленты, дискет и т.п.), а также в виде RAM-дисков, виртуального "диска", буфера обмена и т.д.. Т.е. ОС состояла из файловой системы (BIOS) и процессора консольных команд (CCP, здесь название случайно совпало с американским
Позже меня окончательно утомил дико тормозной 6-битный вывод символов, и я сделал надстройку над Монитором, которая позволяла использовать полноценное знакоместо 8х8 с вменяемой скоростью вывода. В процессе работы стало понятно, что "надстройка" (модуль консольного ввода-вывода, CONIO) бесповоротно переходит в статус "перманентно" и от API Монитора с его "прелестными" 64 символами в строке я отказываюсь.
Касательно включения чего-то в ROM-BIOS. Упор был на идеологию минимального вмешательства. Т.е. функционал базового Ориона не должен страдать, а ОС это "надстройка", дающая дополнительный функционал, для комфортной работы. Родной (RK86/ORDOS) софт Ориона должен "видеть" нативную среду (базовый М2 и API ORDOS). Иначе это уже не Орион, имхо.
Кому полезно? Мне - нет
Драйвер завязан на функционал DSDOS (ввод-вывод символов, организация оконного режима вывода, операции с файлами). Вплоть до обращения к системным переменным ОС и её буферу каталога файлов.
Писать нечто универсальное (и дико тормозное, разумеется) задачи не стояло.
Так сделайте.
Флаг Вам в руки.
В свою очередь, считаю мышь совершенно излишней на 8-битке. Но, если кто-то придумает ей применение и адекватно это реализует, то почему бы и нет.
Опять же, есть маленькая проблемка.. изначально у Ориона нет мыши. Чтобы заставить пользователя её "прикрутить" (а предварительно приобрести), нужно сделать что-то такое.. уж точно не банальную возможность "тыкать в файлы в нортоне", а что-то более мотивирующее.
Нет! Это как раз важно!
GUI на Орионе ради преклонения перед американскими технологиями, в ущерб производительности и вообще мимо какого-либо здравого смысла? Бесперспективняк.
ЕМНИП, это был 1998-ой год. Из оф. инфы по Ориону было описание ORDOS и SPDOS. Всё. На волне хайпа я поддался всеобщему соблазну американских технологий и пытался программировать на Си под MSDOS (на чужом лаптопе). Самодельная реализация RS-232 с помощью двух ног порта ВВ55 и мозгового штурма. Протокол RS-232 я расковырял выводя прилетающую с писюка инфу на экран Ориона. Далее придумал как выводить ОРДОС-файл, стало быть нужно было придумать формат его хранения на писи. Так родился формат ORI. Степень его "нестандартности" лично мне оценить сложно, т.к. других формат не было (слова "интернет" я не знал, в ФИДО была гробовая тишина на тему Ориона). Тут скорее принцип: кто первый, того и тапки. А о каких-либо стандартах говорить смешно, ибо писюк в мире Ориона это резиновая баба.
П.С. сигнатура нужна для исключения подлога: подсовывания левых файлов с переименованным расширением в ".ORI". Степень ненужности данного функционала каждый оценивает по-своему.
Это не удобнее, а это "мне так привычнее". Почувствуйте разницу
Тут я ничего не понял %)
Орионовский файл на писи это просто контейнер. Какие паритеты и КС, зачем они? Чтобы больше тормозил файлообмен?
Даты файлов изначально в DSDOS не было, но потом в ней возникла насущная необходимость, и даже место в заголовке нашлось, причём не влияя на родную структуру ORDOS. Было сделано и активно используется.
В целом принцип понятен.. как в том анекдоте, по любому вопросу есть два мнения: моё и неправильное.
И тут тоже понятно. Не как в американских технологиях, значит неправильно. Не как я привык, значит неудобно.
Я делал с нуля, поэтому изначально делал как мне реально удобнее и интуитивно понятнее. Стрелки гоняют курсор согласно соответствующим направлениям - это, имхо, логично. Табуляция тоже гоняет курсор между панелями (для совместимости с писишными привычками), но мне удобнее пользоваться стрелками.
Для перемещения в начало конец списка на экране удобнее использовать соответствующие клавиши ([Home]/[End]), а для перемещения в самое начало и в самый конец всего списка их комбинации с Ctrl. Просто, быстро, логично, интуитивно.
Имхо, конечно.
Вопросы "резиновой бабы" (эмуляции) меня мало интересуют, гораздо увлекательнее работать на реальной железке. Для этого и создана DSDOS и ПО под неё.
Для написания же статей (снятия скриншотов) я использую прекрасный эмулятор от камрада b2m, там виртуальный дисковод моя ОС видит и всё работает "из коробки", никаких специальных телодвижений для этого не требуется.
Нажимаем иконку дискеты, выбираем ODI-образ и DSDOS прекрасно видит эту "дискету" (пиши-читает файлы).
Другие эмуляторы не пробовал в виду отсутствия таковой нужды. Полагаю, что если в эмуле реализована одна из известных версий КНГМД для Ориона, то она также без проблем будет работать с моей ОС.
Концепт ОС предполагает изначальную поддержку всех актуальных носителей, т.е. соответствующие драйвера уже включены в ядро. Также есть возможность проинсталлировать свой драйвер, в т.ч. "поверх" родного. Вариативность вполне достаточная, имхо.
Скрытый текст
[свернуть]
- - - Добавлено - - -
Stampmaker, исходники я не выкладывал на сайте.
Последний раз редактировалось Denn; 06.02.2018 в 15:21.
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
По поводу контрольных сумм (КС) для файлов поделюсь мнением: они имели бы право на существование, если бы файл был чем-то константным. Но представьте такое: некий процесс (или несколько процессов) постоянно пишут в файлы (элементарно логи в /var ), причем они не новые файлы создают, а правят (или дописывают) существующие. И что же, ОС при этом после каждой записи (а их, напомню, архимного и архичасто) должна пересчитать КС всего файла (а если файлы большие, например всё те же логи в /var ?) и внести изменения в заголовок файла? Очевидно что такая система не жизнеспособна, и даже с небольшими файлами - будет работать сама на себя. А для ПЗУ (где файлы не меняются) КС тоже вряд ли имеет смысл, т.к. носитель не испортится (99,999%) и файлы не правятся. КС могла бы иметь место на единице хранения - блоке файловой системы, кратно корой происходит каждая единичная запись данных, но Ордос до таких категорий не доросла.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
КС файла у меня реализована при файлообмене с виртуальным диском, т.к. там есть реальная нужда в этом (могут иметь место помехи передачи в железке). Но там КС упрощённая (XOR всех байтов тела файла), она вычисляется на лету (не увеличивает общую скорость обмена) и передаётся только между хостами, в заголовке файлов не хранится.
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
А что тут представлять? Простенькие конверторы проще всего писать именно на бейсике. Получается быстрее, чем на Си или ассемблере. Беру заготовку, где уже есть загрузка файла и запись результата в файл. Остаётся потратить пару минут на написание всего нескольких строк на бейсике, что и делают конверсию. И даже не требуется бейсик программу компилировать.Забавно. Пытаюсь представить масштабы нужды...
Фраза как раз характеризует именно Ваше отношение, не моё. Явное нежелание даже хоть что-то обсуждать.
Напрасно Вы восприняли мой пост как "наезд". Я не критиковал, а высказал личное мнение, причём всего на пару моментов, о том что реально неудобно, но что при желании поправить совсем несложно.
Я понимаю, что при программировании интереснее написать своё, чем заимствовать. Но речь о базовых вещах, здесь изобретать велосипеды незачем.
А я использую прекрасный эмулятор EMU80, где в меню выбора есть ОРИОН с DSDOS, но дисковода нет.
А вот это совсем неправильно, т.к расширение ODI используется уже более 10 лет и этот формат общепризнан и поддержан эмуляторами и утилитами, как формат CP/M Ориона и Корвета.
Обозвав так же формат дискет SPDOS, Вы ввели никому ненужную путаницу. Здесь как раз и необходимо было вводить новое расширение. Фантазии не хватило на собственное расширения для образов дискет SPDOS? Не знаю как в эмуляторе от b2m, но в EMU80 можно для каждой конфигурации задать используемый тип файлов с образами дисков.
Вообще-то диск подключённый по линии называется сетевым. Понятно, что при передаче всегда используются КС. Речь шла о ORDOS-файлах, чтобы обнаруживать дохлоту в реале.
При файлообмене без разницы какие два байта пересылать, два нуля или два байта КС. И всё как раз наоборот, - не имея готовой КС, при файлообмене КС придётся считать, что и затормозит, хотя и несущественно.
Байт паритета это упрощённый аналог КС, но однобайтовый (знаю ЭВМ в которых в МГ-подпрограммах для контроля пересылается именно байт паритета блока, а не два байта КС). Предложил я это лишь для того, чтобы уместить в 4 байта три вещи: КС, расширение ORDOS-имени и дату файла.
Речь идёт о средстве позволяющем выявлять дохлоту в архивных файлах. А не для выявления ошибок в объектных кодах прямо в процессе трансляции исходников программ в ORDOS-файл ассемблером. Причём и такой ситуации даже нет, т.к ассемблер ORDOS производный от МИКРОНА пишет не побайтово, а массивом.
Нелепый довод. Удивлён читая такое от Вас, т.к Вы знакомы с тем как программы работают с файлами. Во всех ДОС, кроме ORDOS, файл сначала открывают, а в конце работы закрывают, после чего никаких изменений с содержимым файла не происходит. Что за идиот стал бы перезаписывать КС при каждой очередной записи в файл, достаточно это сделать один раз при закрытии файла.
Но сейчас ORDOS дорабатывать поздно, т.к в реале ей никто, кроме Denn-а не пользуется. Я включил функцию подстановки КС в ORD-файл в нортоны и всё, проблема решена. Не увидел такого решения у Denn-а, и его использование лишних байтов в ORDOS-метке не совпадает с моим, потому и предложил обсудить это. Но когда сталкиваешься с таким отношением, то в другой раз не захочется что-то обсуждать.
Насчёт жизнеспособности. Имею исходники 6-ти разных DOS (совершенно разных концепций), которые используют эл.диск в качестве носителя. И все они используют для контроля целостности файлов контрольные суммы и работе программ с последовательным и произвольным доступом это нисколько не мешает.
К тому же речь шла именно о ORDOS-файлах, т.е об ORDOS, а не о какой-то иной более нормальной DOS в которой файлы имеют настолько большие размеры, что считать КС всего файла очень долго.
Я исхожу из реальной практики. В конце 80-тых пару лет пользовался платой внешнего эл.диска на РУ7-мых, для чего одним грамотным програмистом была написана RAMDOS (не путать с RAMDOS РК86 Д.Лукьянова из ж.РАДИО). Там файлы имели КС. Потому, хотя файлы иногда дохли, но дохлые файлы не плодились.
А в ORDOS дохлые файлы просто разводились. Не только из-за помех по питанию, падения утюгов на плату и проникающего гамма-излучения. При разработке ПО всегда происходят улёты. В.Воронин (Алёна) специально разработал апп.защиту квазидисков ORDOS от записи. Как только я познакомился с ORDOS, то на основе предыдущего опыта сразу же сказал, что это большая дурь не иметь КС файлов. Так что ORDOS - единственная в мире DOS, где нет КС.
Разработчики мыши для БК-010 и Корвета так не считали. Эта мышь называется "манипулятор ММ 8031". Выдаёт результат в параллельном коде (с двух реверсивных счётчиков) и подключается просто и всего через один порт ППА.Флаг Вам в руки. В свою очередь считаю мышь совершенно излишней на 8-битке
Глупости. Весь мир сделал свой выбор.
Теперь ясно, что Вы не Стивен Джобс, который увидев мышь сразу понял удобство графического интерфейса.
Речь о однозадачной ОС. Точнее даже не о ОС, а лишь об оболочке для любой ОС для управления файлами. Что-то типа 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 программирование графики существенно усложняется.
Последний раз редактировалось barsik; 08.02.2018 в 05:36.
Вы бываете слишком категоричны. То порт никому не нужен, то ORDOS никем не используется... Ну я вот тоже пользуюсь и тем, и другим. И вполне разделяю точку зрения Denna.
Это наверное все уже видели, смотреть там особенно не на что. См. во вложении этого поста.
Про файлы комментировать не буду, рассуждения продиктованы опытом, а у меня опыт другой (во многом с машин откуда и UZIX, где в порядке вещей с большой частотой открывать-закрывать файлы чтобы изменить в них только несколько байт, т.к. работа с файлами ведется не только пользователем, но и ядром и сервисами ОС для её собственных нужд).
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
