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

[alx32]

Я заказывал на Али Gm16C550 GoldStar по $1,47, но сейчас товар не доступен...

[Advertiser]

[Denn]

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

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

"могу предложить только PC16550DN/NOPB (Texas Instruments) ... 870 руб./шт."

Это что-то уж совсем за гранью добра и зла ((

Можно в тутошнюю барахолку кинуть объяву "куплю 16C550", думаю местные продаваны с удовольствием подтянутся

[Stampmaker]

Предлагаю на рассмотрение форумчан (а может кто-то и изготовит) замену ROM-диску - Super ROM-диск - сокращённо SROM-диск. Устройство представляет из себя параллельно соединённые ПЗУ и СОЗУ, переключаемые джамперами. Т.к. DSDOS поддерживает ROM-диск объёмом до 1МБ, то в данном диске есть возможность поставить ПЗУ как на 64КБ, так и на 1МБ. СОЗУ набирается с шагом 128КБ, т.е. минимальный объем СОЗУ данного диска составляет 128КБ.

Зачем всё это нужно?
Думаю, некоторые пользователи Ориона сталкивались с вопросом об оперативном изменении содержимого ROM-диска, а затем, возможно, и с возвратом к предыдущему его состоянию. Для этого надо было стирать ПЗУ, записывать его на другом компьютере. По окончании эксперимента заново стирать и записывать. Теперь же этого делать не нужно. Вместо ПЗУ теперь работает СОЗУ. Из него компьютер стартует ОС, при необходимости СОЗУ "перепрошивается" самим же Орионом на другую сборку и продолжает работать, как ни в чём не бывало. Изначально, конечно же, ПЗУ всё-таки придётся прошить, чтобы можно было загрузиться. Но затем, используя специальную утилиту, мы можем "перезаписать" свой ROM-диск на любую другую сборку DSDOS текущей или даже новой версии, чем в ПЗУ, не вынимая ПЗУ! И в случае краха ОСи в СОЗУ (села батарея или ещё что-то), мы безболезненно грузимся из ПЗУ и спокойно заливаем нужную нам сборку обратно в СОЗУ. Из личного опыта могу сказать, что используя данный диск уже более трёх месяцев, информация из СОЗУ ни разу не пропала и экспериментировать с компьютером в плане ROM-диска стало гораздо легче.

Фото SROM-диска. В данном варианте плата дополнена переходником для телевизора и разъёмом PS/2. В обычном виде этого не будет (см. окончание поста).


В данном случае установлено 256КБ, чего, в общем, пока что достаточно. Остальные СОЗУ напаиваются бутербродом, все выводы, за исключением 30-ых, соединяются параллельно. Выводы 30 напаянных микросхем соединяются с выходами D5 1533АП15.



Как работать с диском?
! ВНИМАНИЕ !
Неаккуратное пользование утилитой может привести к выходу из строя либо порт ВВ55 либо ПЗУ.
Будьте внимательны!
Читайте все сообщения утилиты до конца и не торопитесь!
И ещё.
Разработчики схемы и ПО не несут никакой ответственности за повреждённые ваши данные или оборудование. Всё, что вы делаете, вы делаете на свой страх и риск. И не говорите потом, что вас не предупреждали.

Изначально предполагается, что у пользователя установлена DSDOS версии не ниже 3.8

Пример работы.
В зависимости от того, какое ПЗУ используется, 64КБ или 1МБ, джампер J9 ставится в соответсвующее положение.
Джампер J1 ставим в режим ROM, джампер J2 в любое и грузимся из ПЗУ.


Допустим, мы хотим обновить ранее установленную ОС 3.83 до версии 3.84 из виртуального диска.


В ORI-сервере выбираем папку с нужной сборкой.


В командной строке DSDOS набираем:
G: [BK]
G> SROM$ G: /S [BK] если на текущем ROM-диске отсутствует утилита SROM$

либо
A> SROM$ G: /S [BK], при условии, если утилита SROM$ находится на ROM-диске, а нужная сборка на виртуальном диске G:.

и внимательно следуя инструкциям программы, записываем сборку ОС в СОЗУ.


Переводим диск в режим записи, установив J1 в RAM, а J2 в Write.


Жмём [ВК] и ждём окончания работы.


Работа выполнена.
Теперь переводим диск в режим чтения, установив J2 в Read.



Это теперь рабочее состояние диска: J1=RAM, J2=Read и его больше трогать не нужно.

По окончании работы утилиты выполняем холодный рестарт ОС командой Q [BK].



Всё. У нас теперь в SROM-диске нужная нам сборка DSDOS и программы.


Схема SROM-диска.


Для работы SROM-диска необходимо провести небольшую доработку основной платы - пробросить на разъем ROM-диска всего 2 провода. На работе иного существующего железа, а также старого ROM-диска это никак не сказывается.

Итак, от DD53 ВВ55 порта клавиатуры вывод 15 соединить с контактом B9 разъема ROM-диска, а вывод 16 соединить с контактом B10.
По желанию можно также контакт С30 (инверсный сброс) системного разъема Х2 соединить с контактом А9 разъема ROM-диска, но так как триггер ТМ8 всегда обнуляется программно, то этот сигнал можно не пробрасывать, а просто соединить вывод 1 триггера ТМ8 через резистор 1кОм с линией +5В.

Схему и печатную плату, выполненные в PCAD 2004, можно скачать здесь.

P.S.
Как принято говорить, собранное из исправных деталей устройство начинает работать сразу и никакие наладки не требуются.

[Denn]

Очередной миниотчёт о проделанной работе и небольшой анонс ближайших планов.

Наконец-то удалось добраться до "метровых" RAM-дисков и сделать их программную поддержку. Сперва это был RAM-диск в Гибридном ЭД™ (информация в соотв. теме), а теперь сделана аналогичная программная поддержка альтернативной "быстрой" реализации в виде отдельного ВУ, включаемого в системный разъём ПРК "Орион-128". Жаргонное название - "RAM7", т.к. девайс размещается в области портов расширения (F7xx), соответственно RAM-диск в ЭД получил название RAM5 (от локализации в F5xx).
О "RAM7" расскажу подробнее. Пилотный вариант разработан с использованием доступных микросхем СОЗУ UT621024 и некоторого кол-ва ЛЭ простой логики. В ближайшее время Сергей (а-ка Stampmaker) обещал опубликовать схему, плату и некоторые подробности изготовления, у него этот девайс собран и успешно применяется в работе.

Итак, несколько слов о ТТХ RAM-диска. Физический объём 1 Мб (1024 Кб). Кластерная организация хранения, в связи с этим реальный объём для хранения файлов составляет 1016 Кб (8 Кб "съедают" каталог + FAT). Хранение данных при обесточивании ПРК осуществляется от батарейки CR2032 (3V). Защита данных от случайного повреждения двухуровневая: супервайзор + специальный механизм активации режима записи в СОЗУ. Для ускорения доступа использован аппаратный инкремент адреса при операциях чтения/записи. Непосредственно чтение/запись осуществляются простыми командами LDA/STA (или более быстрыми аналогами MOV rg,M / MOV M,rg).
RAM-диск инсталлируется при загрузке ОС и доступен, как диск E:. При первом запуске требуется инициализация (форматирование), которые на данный момент осуществляются с помощью специальной утилиты RAMD7$, впоследствии данный функционал будет интегрирован в имеющуюся стандартную утилиту FORMAT$ (вызов: FORMAT$ E: [/F] | [/V] | [/Q]).
В будущем концептуально предполагается скорее всего обязательное наличие в системе RAM-диска (любой реализации: ЭД или RAM7), который будет использоваться аналогично жёсткому диску на писи (хранение конфигурационных файлов ОС и прикладного ПО, файлов данных).

Следующим этапом развития предполагается создание единой платы т.н. DS-Card™, на которой будут размещены все необходимые устройства, а именно: быстрый порт COM2, быстрый RAM-диск, возможно RTC (i2c), быстрый SDHC, AY и ЦАП (2х12 бит, с активным ЦФ).
С целью уменьшения габаритов придётся "наступить на горло религии" и заменить рассыпуху на МК, а платы разбить на две (под концепт мат/платы рев.512, на которой штатно имеются два системных разъёма):

DS-Card I "mini":
- COM2 (16C550)
- COM3 (опционально);
- RAM7 (на двух СОЗУ по 512 Кб);
- i2c RTC (опционально).
Коммутация на МК.

DS-Card II "mini":
- AY;
- ЦАП (2х12 бит, 2хDAC, активный ЦФ, фильтрация питания аналоговой части, линейный выход);
- "быстрый" SDHC;
- "быстрый" IDE (опционально).
Коммутация на МК.


Возможно, пилотным будет "бюджетный" вариант DS-Card на почти "религиозных" компонентах, со следующей "разблюдовкой":

DS-Card I "Sail":
- COM1 ("разогнанная" ВВ51А, 38400 Бод или MSM82C51A-2, 115200 Бод);
- COM2 (16C550, 115200 Бод);
- RAM7 (на 8 шт. СОЗУ 128 Кб).
Коммутация на рассыпухе.

DS-Card II "Sail":
- AY;
- Ковокс (2х12 бит, пассивный на резисторах, без ЦФ);
- "медленный" IDE на ВВ55+ЛН1 (опционально)
Коммутация на рассыпухе.

Благодаря использованию труъ-рассыпухи и "религиозных" компонентов, размеры плат бюджетного варианта будут соответствующие, что и отражено в названии

Процесс компоновки и разработки плат ещё в процессе, если есть желающие присоединиться, то, как говорится вэлкам (пишите в ЛС).

[Stampmaker]

Представляю схему диска RAM7 объёмом 1МБ.


Расположен по адресам F7F0H...F7F3H
F7F0 - регистр данных;
F7F1 и F7F2 - регистры адреса;
F7F3 - регистр номера банка (0...15) и разрешения записи на диск.

Диск имеет две особенности:
1) Не теряет данные при выключении питания;
2) Имеет защиту от произвольной записи при сбоях в системе.

Как работает схема описывать не буду, она проста как ROM-диск и всё в ней ясно.

Если кто испытывает затруднения с приобретением супервайзера DS1210, то вот его замена.
Цифры в кружках - это соответствующие ножки микросхемы DS1210. Некоторые отсутствуют потому, что они попросту не нужны.


Что касается платы, то в пилотном варианте совместно с диском на ней собраны и последовательные порты, которые были описаны ранее в этой же теме и подключаются непосредственно к USB. Заинтересованные могут скачать рисунок платы формата PCAD 2004 и программу теста формата *.ORI здесь.

Фото платы.


Немного о сборке.
Под микросхемы СОЗУ отведено два посадочных места. Остальные шесть напаиваются бутербродом.
Можно было сразу всё напаять, но я напаивал по частям и гонял тест диска. В итоге всё нормально.


Также на основной плате необходимо выполнить небольшую доработку.
Т.к. устройство требует сигнал прямого сброса, то на контакт В20 системного разъёма #F7 необходимо его подать с 12 ноги процессора.

[OldSpeccer]

Stampmaker,
ИМХО конечно, но в схеме SROM-диска я бы выбросил лишний 20-ногий, и не самый подножный буфер,
руля инверсными чипселектами памяти прямо с инверсных выводов ИД7, а проинвертировал бы единственный
выход супервайзера. Разве так не логичнее?

[Denn]

В связи с периодически возникающей необходимостью обмена информацией между IBM-PC и Орионом, пришлось написать программу для конвертации файлов в *.ORI и обратно.

Версию для Windows cкачать можно тут - http://denn.ru/8bit/oriserv/oricnv.zip


Интерфейс конвертера простой и понятный:


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


В левой панели показано содержимое папки с писишными файлами, в правой - содержимое папки с файлами *.ORI. Папки выбираются с помощью соответствующих кнопок над панелями, пути к папкам запоминаются в INI-файле программы. После успешной конвертации, содержимое панели выходного файла автоматически обновляется. Для принудительного обновления над панелями есть кнопки "Обновить".
Конвертируемый файл выделяется мышкой в соответствующей панели, и если его конвертация возможна, то становятся активными кнопки копирования.
Все кнопки снабжены всплывающими подсказками, которые появляются при наведении на них указателя мышки.

Программа имеет два режима конвертации:
1) Прямое копирование;
2) Копирование текста.

В первом режиме побайтовая копия исходного писишного файла оформляется в ORI-контейнер, при этом в заголовке орионовского файла устанавливаются следующие значения:
- имя файла (первые 8 символов исходного имени в верхнем регистре; если исходное имя короче, то дополняется пробелами до 8, согласно формату ORDOS/SPDOS/DSDOS);
- адрес посадки = 0000h;
- длина файла = длине исходного файла;
- атрибуты = 00h;
- номер страницы ОЗУ = 00h;
- дата файла = текущей системной дате на момент конвертации (согласно формату DSDOS).

При обратном преобразовании побайтовая копия "вынимается" из ORI-контейнера и оформляется в виде писишного файла с именем исходного орионовского.

Второй режим хитрее. Дело в том, что текстовые файлы на Орионе устроены несколько иначе, чем таковые на IBM-PC. Во-первых, отличается кодировка русских букв. Во-вторых, разделитель строк на писи состоит из двух байт (0Dh, 0Ah), а на Орионе из одного (0Dh). В-третьих, на Орионе признаком конца текстового файла является байт FFh, на писи такового нет вообще. Второй режим конвертации как раз учитывает все эти три особенности и делает соответствующие преобразования (в т.ч. меняется длина выходного файла!).
Также при копирования текста в ORI-файл, у последнего устанавливается "стандартный" адрес посадки 2000h, для совместимости с текстовыми редакторами. Этому же условию должен удовлетворять конвертируемый *.ORI файл при копировании текста на писи.

При конвертации PC→ORI в первом режиме, в качестве имени выходного файла берутся первые 8 символов исходного писишного файла. Во втором режиме берутся первые пять символов (родное расширение файла отбрасывается) и добавляется расширение ".TX". При обратной конвертации в первом режиме выходной писишный файл получает такое же имя, как у исходного ORI-файла, а во втором режиме в исходном имени точки заменяются на символ нижнего подчёркивания и добавляется расширение ".txt".

Конвертация PC→ORI в первом режиме доступна для любых файлов размером 1..65535 байт (ограничение файловой системы Ориона). Конвертация PC→ORI во втором режиме доступна только для текстовых файлов (определяется по расширению), ограничения по размеру аналогичные, как в первом режиме.

П.С. программа позволяет конвертировать файлы *.BRU в писишные (на правой панели они видны в списке). Обратное преобразование не поддерживается.

[OldSpeccer]

Привет всем, надеюсь выжившие остались!
В продолжение темы, ибо Орион жив.
*В процессе разборки гаражного хлама из-под прочего мусора показалась страшная, позеленевшая, некогда полузапущенная другом, но так и не ожившая плата Ориона.
Всплыла былая любовь - не смог пройти мимо. С удивлением обнаружил, что кое-что даже можно найти, и вполне живые люди совсем недавно еще занимались темой,
за что - отдельный большой респект!
Итак, взялся я за паяло, оскоп и интернет, и вскоре Орион задышал. Оживал он, правда, очень трудно, но в итоге многочисленные глюки были отловлены, и он наконец уверенно зашуршал. Устойчиво и без глюков, настоящий железный Орион
Проц ВМ80 (а надо ли иное?), память 256К на ру5-х, с доп. платой, ром-диск на 29с010, клавиатура на атмеге88, 32" по SCART-у (кстати, а вы знали, что при отображении
в режиме 16:9 пропорции картинки почти идеальны - басик рисует правильный круг!!), сдвиг экрана вниз выполнен. С большим удовольствием констатировал, что Орион - очень приятная 8-битка (как и планировалось), и в немалой степени это заслуга программной среды DSDOS, но и в принципе архитектуры. Ну, и для возможности действительно использования Ориона остался последний шаг - хранение-доступ информации.
И вот тут, казалось бы уже все просто - я таки уперся в стену,и надеюсь на помощь небезразличных форумчан.
Была собрана плата последовательного интерфейса - сначала на связке ВИ53+uPD71051, но она не заработала как положено - интерфейс работал в одну сторону - прием был, а передачи нет. Схема была переделана под фиксированный клок и 38400 - но увы, те же грабли: прием есть - передачи нет. Подозрение пало на мс УсАПП, откопал целую стопку КР580ВВ51 - результат тот же!
После 18-ти попыток найти ошибку-кз-обрыв и перепроверки всего - взялся за даташит на 8251, и обнаружил там упоминание, что передатчик выдает данные на TxD только при 0 на входе /CTS. Соединил этот вывод с землей, и о, чудо - байтики пошли в обе стороны. Отсюда мой первый вопрос к автору(Denn): я видел - вы тестировали также на "железном" Орионе? Вы в эти грабли не упирались? Может у вас RS232-кабель в "железе" - полный, с распаянными RTS/CTS, а эмулятор просто игнорирует эти сигналы? Если не трудно - пожалуйста перепроверьте вопрос! Соединение RTS-CTS(лупбэк) на порту Ориона никакого эффекта не дает, только посадка в 0 входа ВВ51-й.
Второе - несмотря на то, что байты в терминале ходят корректно в обе стороны, тем не менее Орион "не видит" сервера. Запускается сервер версии 2.05 (винда х64, core2duo), порт занимает корректно. Орион при старте обнаруживает порт и пишет наличие виртуального диска 16 с чем то мегабайт, но при попытке любого обращения
DSDOS вываливает ошибку 80 - диск не готов. Проверено с DSDOS 3.81 и 3.83. Заметил, что при попытке обращения к виртуальному диску на TxD нет никакой активности, что вряд ли можно считать нормальным. Уважаемый Denn, если вы еще следите за топиком - нетрудно ли будет глянуть в суть вопроса?

[Hacker VBI]

OldSpeccer, поздравляю!

[Denn]

OldSpeccer, мои поздравления с оживлением суперкомпьютера!

По вопросам.

Для корректной работы ВВ51 интерфейс должен быть полноценным, сигналы RTS/CTS она обрабатывает. Соответственно, получаются два варианта: либо мы "затыкаем" RTS/CTS перемычками (7-8 контакты разъёма DB-9) на каждой стороне и т.о. обманываем протокол, либо делаем честный линкер с перекрёстной передачей сигналов RTS/CTS. В первом случае в сервере (на писи) в настройках порта параметр "Flow Control" ставим в "None", во втором случае - "Hardware".

Соединение RTS-CTS(лупбэк) на порту Ориона никакого эффекта не дает, только посадка в 0 входа ВВ51-й.

Скорее всего где-то аппаратная неисправность. "Лупбэк" (но только с обоих концов!) должен решать вопрос.

В сборках прошивок ОС, в конце есть файлы теста портов СОМ1 и СОМ2, с их помощью можно полноценно протестировать соответствующие порты, в т.ч. и "лупбэком", т.е. замыкаем 2+3 и 7+8 на разъёме СОМ-порта Ориона, в результате чего тест будет печатать задвоенные символы (отправленный и принятый).

В "быстрой" реализации порта (COM2, на 16C550) программно отключена обработка RTS/CTS, т.о. возможно использование "кастрированного" линкера, у которого сигналы RTS/CTS висят в воздухе. При этом в настройках порта сервера "Flow Control" ставим в "None".

Рекомендую по-возможности использовать скорость 115200 Бод, т.к. работа на ней черезвычайно комфортная!
В данный момент я работаю над т.н. "кэшированием" каталогов в ОС DSDOS, что позволит ощутимо ускорить выполнение файловых операций при работе с виртуальным диском, а также с RAM5/RAM7, но всё равно лучше работать на 115200 Бод.

несмотря на то, что байты в терминале ходят корректно в обе стороны, тем не менее Орион "не видит" сервера. Запускается сервер версии 2.05 (винда х64, core2duo), порт занимает корректно.

К сожалению, у меня олд-скул что называется "по жизни", и домашние компы примерно уровня Пентиум-3, разлива 2001-го года Соответственно, Винда там ХР, обычная 32-битная. Проверить работоспособность сервера на новомодных 7-ках, 8-ках и 10-ках и 64-битных версиях у меня возможности нет (( Поэтому не могу гарантировать правильную работу старинной компонеты СОМ-порта на таких системах. Если кто-то исследует вопрос, буду благодарен за обратку.

Лично пробовал USB-реализацию СОМ-порта в виде шнурка-переходника - у меня не "взлетела", работать работало, но периодически были ошибки в передаваемых данных в сторону Ориона (ошибка в старшем бите), подозреваю что проблема в плохом согласовании уровней сигналов (в шнурке скорее всего MAX232, а у меня в Орионе "трэш" на КТ315 ). В итоге для увеличения кол-ва портов в писюке нашёл PCI-карту с двумя СОМ-портами, которая заработала сразу "из коробки", на чём и успокоился.

Орион при старте обнаруживает порт и пишет наличие виртуального диска 16 с чем то мегабайт, но при попытке любого обращения DSDOS вываливает ошибку 80 - диск не готов.

Скорее всего проблема где-то на начальной стадии протокола, т.е. Орион отправил запрос серверу и не получил ответ.
В сервере начиная с версии 2.05 есть возможность подробного логирования ошибок, для этого нужно включить обе галочки "Журнал" и "Подробно". Поскольку протокол всегда двухсторонний, то ошибка на Орионе также приведёт и к ошибке на писи, которую сервер зафиксирует в лог, который можно посмотреть нажав кнопку "Журнал операций". Там будет HEX-код ошибки, по которому я смогу попытаться понять на каком участке алгоритма обмена происходит сбой. Чем меньше код, тем ближе к началу протокола проблема.

Опять же, для начала лучше просто проверить связь Орион<->Писи с помощью тестов, передавая как одиночные символы, так и строки. По ошибкам в строках можно уже примерно предположить характер проблемы.

Заметил, что при попытке обращения к виртуальному диску на TxD нет никакой активности, что вряд ли можно считать нормальным.

Получается, что сервер вообще не видит запросов - в таком случае ошибок он не зафиксирует.
Скорее всего проблема в области RTS/CTS или настройки "Flow Control" на писи.