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

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

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

10.03.2018, 11:19
Error404

Цитата:

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

Дело в том, что работа с НЖМД организована строго в режиме LBA, который, судя по информации из интернетов, поддерживают только накопители от 512 Мб и выше.

Врут интернетчики, еще когда начинал играть с IDE и с разбора еще были диски мелких размеров, успел пощупать несколько ноутбучных винтов середины прошлого века (2.5" но толстенькие - одни из первых выпущенных такого формфактора, я брал только ноутбучные чтобы было питание только +5В) все они были объемом от 100 до 200 Мб и все поддерживали LBA.

Цитата:

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

Аналогично будет сделана поддержка карт SDHC в ОС DSDOS. В следующей версии ОС поддержка больших накопителей будет включена.

Сразу предлагаю определиться со схемотехникой. КМК лучшим вариантом для Ориона был бы вариант схемы на ИР24(29) - максимальная возможная для Z80 скорость при затратах (в минималке) в полдюжины корпусов дешевой мелкой логики. Предлагаю вариант от PVV из соседней профильной темы. У него получился самый быстродействующий вариант (думаю, по скорости уделает IDE любой схемы) т.к. в моем варианте на ИР24 я сэкономил один корпус за счет выполнения двух IN/OUT (второй для запуска счетчика пакета), а у него запуск регистра автоматизирован и байт с SD читается за один IN/OUT. Единственно, я бы добавил узел предустановки обеспечивающий пакеты не кратные 8 (как в моей схеме), но это уже детали к списку TODO.

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

Цитата:

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

Мини отчёт, вести с полей так сказать.
Вариант подключения по схемотехнике от ОРИОН-ПРО (карта IDE-RTC, как я понимаю - калька с "вражеского" NEMO_IDE).

Планируешь ли добавить вариант для схемы на ВВ55? Вариант от ПРО хотя и побыстрее, но он проблемный (у меня на нем запустилось куда меньшее количество приводов чем на ВВ55), а схема с ВВ55 есть "искаропки" на всех реализациях Ревизии-512, да и ручками паяется за вечер (чего там паять - разъем IDC40 и одна ЛН1).
Тем более что драйвер тоже уже есть (например в варианте для Z80, думаю что тип проца не проблема).

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

В итоге я свой ПРО переделал под схему с ВВ55, прямо на ВВ55 на материнской плате (бывший порт принтера и конфигурации, конфиг DIP теперь у меня читается с АП6 - в версии 3.20 для этого есть слепыши под ВВ55). :)
10.03.2018, 13:42
Denn

Цитата:

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

Сразу предлагаю определиться со схемотехникой. КМК лучшим вариантом для Ориона был бы вариант схемы на ИР24(29) - максимальная возможная для Z80 скорость при затратах (в минималке) в полдюжины корпусов дешевой мелкой логики.

Насчёт ПРО пока не знаю. Если будет готовое работающее и быстрое решение, то вполне можно поддержать его.
На О-128 уже разработана схемотехника аппаратного контроллера SDHC, и даже сделан опытный образец, осталось дело за программной поддержкой (после того, как до конца разберусь с НЖМД, сразу возьмусь за карты). Если контроллер покажет рекордную скорость обмена, тогда имеет смысл ориентироваться на него, имхо. Если чудо не случится, тогда будем ориентироваться на схемотехнически простое решение.

Цитата:

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

Предлагаю вариант от PVV из соседней профильной темы. У него получился самый быстродействующий вариант (думаю, по скорости уделает IDE любой схемы)

Если будет готовая схемотехника для ПРО, то можно попробовать спаять. В любом случае, без железки отлаживать ПО невозможно.

Цитата:

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

Единственно, я бы добавил узел предустановки обеспечивающий пакеты не кратные 8 (как в моей схеме), но это уже детали к списку TODO.

В своём ПО я использую два вида чтения сектора: целосекторное (512 байт) и побайтное. Запись всегда целосекторная. Это связано с особенностью работы НЖМД: он всегда читает целый сектор в свой буфер, а выдавать содержимое буфера хосту может как угодно. Т.о. для экономии времени читается только нужное кол-во данных (N целых секторов "оптом" + некратный хвост). Запись неполного сектора, к сожалению, физически невозможна, поэтому пишем всегда N секторов, с округлением в большую сторону ((
Т.е. требуется возможность чтения кратно одному байту.

Цитата:

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

Планируешь ли добавить вариант для схемы на ВВ55?

Если останется место в финальной версии драйвера (после добавления поддержки подкаталогов), то можно сделать.

Цитата:

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

Вариант от ПРО хотя и побыстрее, но он проблемный (у меня на нем запустилось куда меньшее количество приводов чем на ВВ55)

У меня весь зоопарк имеющихся винтов прекрасно работает с ПРОшной "нэмой". Были какие-то странные проблемы с тестами из интернетов (типа не работали механические "винты" на длинных шлейфах), но в итоге я изучил оригинальную документацию по протоколу АТА, согласно "учебникам" написал свои п/п работы с IDE-устройствами, и все винты и шлейфы любой длины заработали без каких-либо проблем.

Цитата:

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

схема с ВВ55 есть "искаропки" на всех реализациях Ревизии-512, да и ручками паяется за вечер (чего там паять - разъем IDC40 и одна ЛН1).

На рев.512 я запаял насмерть ВВ55, до ЛН1 мне уже не добраться ))
Вроде в эмуле b2m есть поддержка КНГМД на ВВ55+ЛН1, как-нибудь поковыряю этот вариант. В любом случае, нужна аппаратная часть для отладки ПО.

Цитата:

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

В итоге я свой ПРО переделал под схему с ВВ55, прямо на ВВ55 на материнской плате (бывший порт принтера и конфигурации, конфиг DIP теперь у меня читается с АП6 - в версии 3.20 для этого есть слепыши под ВВ55). :)

На 10 МГц она тоже стабильно работает?

Насколько проигрывает по скорости "нэме" ?
10.03.2018, 16:55
Error404

Цитата:

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

Насчёт ПРО пока не знаю. Если будет готовое работающее и быстрое решение, то вполне можно поддержать его.
На О-128 уже разработана схемотехника аппаратного контроллера SDHC, и даже сделан опытный образец, осталось дело за программной поддержкой (после того, как до конца разберусь с НЖМД, сразу возьмусь за карты). Если контроллер покажет рекордную скорость обмена, тогда имеет смысл ориентироваться на него, имхо. Если чудо не случится, тогда будем ориентироваться на схемотехнически простое решение.

Если будет готовая схемотехника для ПРО, то можно попробовать спаять. В любом случае, без железки отлаживать ПО невозможно.
В своём ПО я использую два вида чтения сектора: целосекторное (512 байт) и побайтное. Запись всегда целосекторная. Это связано с особенностью работы НЖМД: он всегда читает целый сектор в свой буфер, а выдавать содержимое буфера хосту может как угодно. Т.о. для экономии времени читается только нужное кол-во данных (N целых секторов "оптом" + некратный хвост). Запись неполного сектора, к сожалению, физически невозможна, поэтому пишем всегда N секторов, с округлением в большую сторону ((
Т.е. требуется возможность чтения кратно одному байту.

Схемотехника у нас с PVV в виде платы подключающейся к ШД/ШУ любого 8080/Z80 компа, только селект требуемого порта определить. Готовой платы для ПРО конечно нет.
И процессор Ориона там работает с SD с той же скоростью, с какой он работает с памятью (или портами), и при этом следующий байт всегда готов (т.е. тупо цикл "читай да клади в буфер" из трех опкодов). Поэтому на "сырых" секторах (т.е. чтении/записи без ньюансов обработки) контроллер SD на внешнем микроконтроллере может быть быстрее только если он кладет сектор в память Ориона через DMA, во всех других случаях скорость внешнего контроллера будет такая же, а всего вероятнее она будет меньше, т.к. не думаю, что 10-МГц Z80 удастся так подружить с внешним контроллером, чтобы внешний был всегда готов для очередного обращения Z80, кроме того наверное внешнему нужно время на чтобы после получения номера сектора этот сектор прочитать (а схеме на регистре - нет), вряд ли он будет успевать между двумя соседними обращениями Z80 (4 такта) еще на SD лазать? Также, есть тема с мультисекторным чтением (когда "одной командой" а не посекторно можно прочитать с SD-карты хоть сотню секторов начиная с какого-то, а внешнему контроллеру такой объем просто негде буферизировать, да и если поставить дорогой контроллер с сотнями килобайт ОЗУ, то задержка хоста на предварительное чтение {там же не сквозной канал прямого доступа к SD} большого блока уже станет сильно заметной в сравнении с задержкой которую внешний дает при подсасывании одного очередного сектора).

Цитата:

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

У меня весь зоопарк имеющихся винтов прекрасно работает с ПРОшной "нэмой". Были какие-то странные проблемы с тестами из интернетов (типа не работали механические "винты" на длинных шлейфах), но в итоге я изучил оригинальную документацию по протоколу АТА, согласно "учебникам" написал свои п/п работы с IDE-устройствами, и все винты и шлейфы любой длины заработали без каких-либо проблем.

Если попадутся ошибки в моей реализации, телеграфируй. :)
Исходники уж не прошу.

Цитата:

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

На 10 МГц она тоже стабильно работает?
Насколько проигрывает по скорости "нэме" ?

Работает нормально на обоих частотах. Там у меня так получалось: те экземпляры приводов что работали в данной из схем (ПРО/ВВ55) работали (или не работали) на любой частоте проца. Поэтому у меня даже мыслю была убрать такты WAIT что делает ПРО при обращении к портам (типа ускорить работу с IDE). Хотя как по мне, скорости и так вполне хватает даже для CP/M (активно пользующей носитель).
Те приводы что работали в схеме ВВ55 на ПРО тоже работали все, а вот наоборот нет. Но тут я должен заметить, что именно HDD (т.е. привод с блинами и магнитными головками) я проверял только один (других нет, т.к. не планирую ими пользоваться ввиду меньшей удобности носителя), а вот CF попробовал до десятка от разных производителей и адаптеров CF->IDE четыре штуки разных.

При том, я пробовал и код написанный авторами ПРО (их загрузчик с НДД стартующий из ПЗУ, он урезанный по части команд АТА, я уже не помню точно в чем, помню только что мне не понравилось как там написано) и мой код (который отчасти тоже подсмотренный и Инете), приводы работали или не работали одинаково.

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

По скорости вариант ПРО с ВВ55 я не мерял, но если заглянуть в код, то вариант с ВВ55 думаю раза в два-три медленнее.
15.03.2018, 12:55
АлександрПП

Вложений: 2

Возник вопрос.
Возможна ли работа с ORI-сервером на "Орион-Про" через "прошную" плату COM-портов?
Вроде порты определяются, выделяется диск "G". На РС запускаю oriserv.exe, но связь не устанавливается.
DSDOS сборки 3.87. Как я понимаю, link.exe на "Орионе" в этой сборке отсутствует, вернее запускается с загрузкой ОС. Верно?
Прежние версии ОС не скачать, т.к. выходит сообщение, что сайт на реконструкции.
15.03.2018, 13:45
Denn

Цитата:

Сообщение от АлександрПП

Возможна ли работа с ORI-сервером на "Орион-Про" через "прошную" плату COM-портов?

Да, конечно.

Цитата:

Сообщение от АлександрПП

Вроде порты определяются, выделяется диск "G".

Прекрасно. Все шансы на успех есть! :)

Цитата:

Сообщение от АлександрПП

На РС запускаю oriserv.exe, но связь не устанавливается.

Порты, собранные по родной схемотехнике, ОС настраивает на скорость 38400 Бод (8-N-1). Не самые древние ВВ51А должны работать нормально.
Аналогичные настройки порта должны быть и на PC (конкретно в oriserv.exe). Ещё в настройках порта на сервере нужно правильно выставить контроль протокола ("hardware" или "none" - в зависимости от аппаратной реализации соединения). Само собой должен быть аппаратный линк между портами Ориона и PC (нуль-модемным кабелем), порты должны быть исправны.

В сборках ОС есть тесты COM-портов (если нет в сборке, то можно взять тут), со стороны PC можно использовать эту утилиту. Т.о. можно наглядно проверить соединение.

Цитата:

Сообщение от АлександрПП

Как я понимаю, link.exe на "Орионе" в этой сборке отсутствует, вернее запускается с загрузкой ОС. Верно?

link$ уже давно не используется в виду неактуальности, поэтому в сборки и не включается. Но работать он по-прежнему может, разумеется.
При загрузке ОС устанавливается не link, а драйвер поддержки более продвинутого протокола файлообмена.
25.03.2018, 17:04
Denn

Поддержка НЖМД (2xIDE), ОРИОН-ПРО

Пробная пилотная версия ОС DSDOS с поддержкой НЖМД. Пока только для ПРК "ОРИОН-ПРО".

Тестовая сборка - http://denn.ru/8bit/orion/soft/dsdos_pro_ide2.rar (образ ПЗУ ROM-диска, 64 Кб)

Поддерживаются одно (Master) или два (Master+Slave) IDE-устройства, подключенные к КНЖМД платы IDE-RTC.

В связи с этим и отказом от специальной поддержки SDHC, небольшая смена концепта - изменено назначение букв дисков:

- буквы "C" и "D" назначены на диски IDE0 и IDE1, вместо ~~никому не нужных~~ дисководов;
- буква "F" вместо предполагавшейся флеш-карты назначена на ГМД (дисковод №0);
- буква "H" по-умолчанию зарезервирована под дисковод №1, но при "холодной" загрузке ОС этот диск "закрыт".

Инициализация

Драйвер НЖМД представлен файлом IDE2, который загружается ОС автоматически при обнаружении накопителей, в результате будут активированы диски "C:", "D:".
При первичной загрузке этого не произойдёт, т.к. накопители не размечены в формате ОС DSDOS (ФС "DSFS").
Убедиться в наличии накопителей и посмотреть их ТТХ можно с помощью утилиты HDDINFO$, а отформатировать с помощью утилиты...

HDD$FMT

Из сборки исключена утилита FORMAT$, вместо неё - HDD$FMT. Это временное явление, впоследствии утилита FORMAT$ вернётся, но уже с поддержкой НЖМД.
Утилиты HDDINFO$ и HDD$FMT без параметров работают с накопителем на канале IDE0 (Master), для указания накопителя на канале IDE1 (Slave) необходимо явно задать параметр, например:

L HDD$FMT D:

Также допустим альтернативный вариант: L HDD$FMT 1

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

Как показывает практика, различные варианты накопителей и их сочетаний имеют свои особенности, и вообще HDD довольно капризные (или схемотехника контроллера платы IDE-RTC?), если будут выявлены баги, будем устранять по мере поступления. Для работы двух Фуджиков мне пришлось повоевать, не исключено, что с другими девайсами могут всплыть "сюрпризы".

Немного скриншотов с реала:

Скрытый текст

https://pp.userapi.com/c845221/v8452...cU7v_F8CYM.jpg

https://pp.userapi.com/c845419/v8454...rPYZ3KwvrY.jpg

https://sun9-2.userapi.com/c824204/v...-Yvh9x9AjA.jpg

https://pp.userapi.com/c846020/v8460...r5CMbFcMkE.jpg

[свернуть]
25.03.2018, 22:18
Error404

Какая схема партиций HDD используется?
Если MBR (чего хотелось бы) то предлагаю портануть еще SDOS от PVV/b2m (в качестве поддержки копирования с FAT16-партиций). Это удобно если например используется CF, который можно оперативно вынуть и на РС в кардридере на разделе с FAT16 работать с общими файлами Ориона.

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

Исходники тут:
http://www.nedopc.org/forum/viewtopi...rt=240#p143547

Там только обращение за секторами FAT16 партиции SD-карт заменить на обращение за секторами соответствующей FAT16 партиции IDE у тебя.
25.03.2018, 23:09
Denn

Цитата:

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

Какая схема партиций HDD используется?

Проприетарная :) Суть описывал чуть ранее здесь. Основная цель - "ехать".

Цитата:

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

Если MBR (чего хотелось бы) то...

Натягивать писишные дела смысла не вижу. Масштабы и задачи иные.

Цитата:

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

...предлагаю портануть еще SDOS от PVV/b2m (в качестве поддержки копирования с FAT16-партиций).

SDOS - это тоже какой-то свой формат хранения файлов?

Цитата:

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

Это удобно если например используется CF, который можно оперативно вынуть и на РС в кардридере на разделе с FAT16 работать с общими файлами Ориона.

В случае нужды файлообмена с писи, концепт DSDOS предлагает вариант через RS-232. Без механической переброски носителя.
25.03.2018, 23:24
Error404

Цитата:

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

Проприетарная :) Суть описывал чуть ранее здесь. Основная цель - "ехать".
Натягивать писишные дела смысла не вижу. Масштабы и задачи иные.

Но это же не сложно, а удобство использования возрастет в разы. Просто добавить MBR (первый сектор, достаточно только 4х primary разделов хранящихся в нем) и просто хранить все проприетарные дела с неким смещением указаным в таблице разделов и в процедурах доступа это смещение просто приплюсовывать (можно делать контроль границ раздела, но это не обязательно). На одном и том же диске можно будет хранить DSDOS, CPM, UZIX и MSDOS. :) Кому не надо например UZIX, запишут вместо него ORDOS6 при том не трогая DSDOS, CPM и MSDOS.

Цитата:

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

SDOS - это тоже какой-то свой формат хранения файлов?
В случае нужды файлообмена с писи, концепт DSDOS предлагает вариант через RS-232. Без механической переброски носителя.

Не, SDOS просто простая утилита для чтения\записи на стандартные тома FAT16. Просто чтобы унифицировать (ну и пока нет чего покруче). Она кстати уже из коробки есть в виде для Ориона для Ордос, но для SD. А что до RS-232, даже когда у нас кроме него будет и WIFI, формат ностеля это же совсем другое, зачем себя в этом ограничивать если это стоит совсем мало усилий (да и общепринято)?
26.03.2018, 17:08
Denn

Цитата:

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

Но это же не сложно, а удобство использования возрастет в разы. Просто добавить MBR (первый сектор, достаточно только 4х primary разделов хранящихся в нем) и просто хранить все проприетарные дела с неким смещением указаным в таблице разделов и в процедурах доступа это смещение просто приплюсовывать (можно делать контроль границ раздела, но это не обязательно).

По любому нужен доп. код расшифровки MBR, а также доп. изощрённость кода по расчёту свободного места с учётом других разделов.

Цитата:

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

На одном и том же диске можно будет хранить DSDOS, CPM, UZIX и MSDOS. :) Кому не надо например UZIX, запишут вместо него ORDOS6 при том не трогая DSDOS, CPM и MSDOS.

А для чего MSDOS там? Неужели у кого-то есть на неё планы применительно к Ориону? ))

Цитата:

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

А что до RS-232, даже когда у нас кроме него будет и WIFI, формат ностеля это же совсем другое, зачем себя в этом ограничивать если это стоит совсем мало усилий (да и общепринято)?

Я всё же рассматриваю Орион как самостоятельный и самодостаточный цифровой домен. Захотелось использовать для хранения данных винчестер - пожалуйста, вот есть решение. Задачи унификации не стояло, винчестер это не переносное устройство.
SD-карта - переносное, но в случае нужды её обработки на писи, проще написать писишный софт, чем заставлять Орион тратить ресурсы на поддержку инородных форматов. Орионовские файлы всё равно имеют формат, отличный от писишного.

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

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

Скрытый текст