Просмотр полной версии : DSDOS для ПРК "Орион-128"
Публикую обещанное - программатор ПЗУ с электрическим стиранием: Winbond W27C512.
Уши этого устройства растут из варианта более универсального программатора УФ-стираемых ПЗУ (27x256, 27x512, 27C040, 27C080) для Орион-128. Практический опыт показал, что ПЗУ Winbond W27C512 самые удобные, и надобность в возможности прошивки УФ-стираемых ПЗУ, в общем-то, отпала. Для работы с W27C512 требуется меньше вариантов напряжений и минимум коммутации, в результате схема была ощутимо упрощена.
А поскольку W27C512 поддерживает мгновенное электрическое стирание, то было и упрощено ПО, обслуживающее программатор: не требуется отдельно выполнять проверку на чистоту и стирание, они выполняются автоматически перед прошивкой.
Исключительно с целью развлечения проект выполнен на совершенно "нефеньшуйной" элементной базе - SMD.
Фото программатора в сборе:
https://forum-img.guitarplayer.ru/2024/02/11/60Y6s.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog1.jpg)
https://forum-img.guitarplayer.ru/2024/02/11/60o8I.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog4.jpg)
Конструкция рассчитана на применение углового разъёма, т.о. программатор вставляется под углом 90 градусов к плате ПРК "Орион-128":
https://forum-img.guitarplayer.ru/2024/02/11/60qcU.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog5.jpg)
Форм-фактор устройства в виде "затычки на параллельный порт" выбран не случайно. Дело в том, что применение соединительного кабеля (шлейфа) вызывает большое количество проблем со стабильностью работы устройства, требуется довольно сложная помехозащищённая конструкция кабеля. В общем, повторяемость устройства в выносном варианте (с применением шлейфа) была бы сомнительная.
Устройство изначально разработано для ПРК "Орион-128" (под порт пользователя #F600), но его также возможно использовать фактически на любой 8-битке, имеющей свободный порт ВВ55. В частности у меня в данный момент устройство подключено к мультикарте ПРК "Орион-ПРО" (к порту #20, через переходник) и успешно используется в работе.
Принципиальная электрическая схема программатора - (ссылка) (http://denn.ru/8bit/orion/128/wbprog/wbprog_sch.jpg)
*Отдельное спасибо Сергею (aka Stampmaker) за помощь в разработке и изготовлении печатной платы и красивый чертёж схемы!
Внешнее питание не требуется, основное питание (+5в) конструкция берёт непосредственно из разёма порта, а необходимые для режимов записи/стирания напряжения (+12в и +14в) получаются при помощи step-up преобразования. Благодаря использованию высокочастотного (1,6 МГц) преобразователя LM27313XMF, возможно применение очень компактных компонентов обвеса (дросселя и конденсаторов), а также абсолютно бесшумная работа (никаких писков, свистов).
Ссылки на ключевые компоненты Step-Up преобразователя:
Преобразователь LM27313XMF (http://www.chipdip.ru/product/lm27313xmf-nopb-2/)
Дроссель CM453232-100KL, 10 мкГн (http://www.chipdip.ru/product/cm453232-100kl/)
Керамические LowESR чип-конденсаторы 10мкФ X7R 25В (http://www.chipdip.ru/product/grm32dr71e106k/)
Для привнесения в конструкцию "немного ламповости", коммутация адресной линии и напряжения +14в в режиме стирания выполнена на малогабаритном реле (https://www.chipdip.ru/product/1-1462037-8-im03ts) с двумя группами переключающих контактов. На самом деле была попытка сделать этот узел на транзисторных ключах, но там выходило то ли 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
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog_h.png)
Конструкция программатора такова, что питание и управляющие сигналы на ПЗУ подаются только во время выполнения операции, после завершения которой на всех выводах устанавливается нулевой потенциал, т.о. возможна безопасная смена микросхемы. Перед выполнением операций, стирающих информацию в ПЗУ, сначала выводится предупреждающий транспарант, требующий подтверждения действия (кроме режима "W"!).
Полный образ для прошивки ПЗУ W27C512 занимает 64 Кб, в один файл он не помещается, а также не помещается в ОЗУ пользователя (48 Кб). Вопрос решён традиционно разбивкой образа на два файла (по 32 Кб каждый), которые по очереди загружаются в ОЗУ во время работы программатора. Формат файлов образа: <Имя>+<Расширение>. Имя - произвольные символы, допустимые в именах файлов ОС DSDOS, максимальное кол-во = 6. Расширение - два символа вида <#N>, где N - порядковый номер файла образа (0, 1). У обоих файлов образа <Имя> должно быть одинаковое, различие только в номере параметра <Расширение>! При указании имени файла образа в параметрах запуска утилиты, расширение указывать не нужно, его утилита формирует автоматически при поиске требуемого файла.
Режимы работы программатора задаются ключами. Режимы проверки чистоты ПЗУ и стирания не требуют указания имени файла образа - вводится только ключ. В остальных режимах указывается имя файла образа и ключ, порядок следования параметров произвольный.
В ходе выполнения операций на экран выводится индикатор прогресса. В операциях с файлами - в два прохода, соответственно.
Итак, собственно режимы работы программатора.
Проверка чистоты микросхемы [ключ /C]:
https://forum-img.guitarplayer.ru/2024/02/11/605Xg.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog_c.png)
ПЗУ считается чистым, если во всех ячейках записано FFh. В противном случае выводится кол-во нестёртых ячеек.
Данный режим является наследием от ПО для программирования УФ-стираемых ПЗУ, большого практического смысла применительно к W27C512 в нём нет.
Ещё один режим, доставшийся от универсальной версии программатора - стирание [ключ /E]:
https://forum-img.guitarplayer.ru/2024/02/11/60pHv.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog_e.png)
Позволяет мгновенно (за 200 мс) стереть всю информацию в W27C512. Полезен скорее для отладки программатора.
Программирование [ключ /P]:
https://forum-img.guitarplayer.ru/2024/02/11/60EKp.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog_p.png)
Оба файла образа должны находиться на указанном устройстве (традиционно, без явного указания диска, поиск файлов осуществляется на рабочем диске ОС - "B:"), размер файлов должен быть 32768 байт. Возможна прошивка только одного файла (т.е. только первых 32 Кб ПЗУ), если второй файл образа отсутствует.
Перед началом программирования всегда выполняется стирание микросхемы!
Программирование каждого файла состоит из двух фаз: прошивка и проверка/допрошивка. Каждая фаза отображается своими символами, заполняющими индикатор прогресса.
Если во время проверки обнаруживаются несоответствия ячеек, то, согласно алгоритму производителя, выполняется до 10 попыток допрошить проблеммные ячейки.
В финале, если все ячейки запрограммированы успешно, выводится соотвествующее сообщение:
https://forum-img.guitarplayer.ru/2024/02/11/60dej.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog_ok.png)
Альтернативный режим программирования [ключ /W]:
https://forum-img.guitarplayer.ru/2024/02/11/60gIC.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog_w.png)
Отличие в отсутствии запроса подтверждения действия. Для ускорения работы продвинутых пользователей :)
Проверка [ключ /V]:
https://forum-img.guitarplayer.ru/2024/02/11/60t9r.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog_v.png)
Сравнение содержимого ПЗУ с образом. В режимах программирования выполняется автоматически.
Чтение [ключ /R]:
https://forum-img.guitarplayer.ru/2024/02/11/60G8u.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/128/wbprog/wbprog_r.png)
Чтение содержимого ПЗУ с сохранением в файлы образа на диск.
PS по вопросам изготовления печатной платы обращаться к Сергею (http://zx-pk.ru/members/7906-stampmaker.html)
Драйвер расширения 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
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_install.png)
Статус и версию установленного драйвера ExtDRV можно посмотреть утилитой SYSTEM$:
https://forum-img.guitarplayer.ru/2024/02/11/60NnY.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_sysinfo.png)
Концепт
Каждый элемент интерфейса представляется в виде т.н. окна, прямоугольной области символьного экрана, заключённой в рамку (или без неё). Рабочая область окна представляет собой уменьшенную версию символьного экрана, в котором действует стандартный функционал консольного ввода-вывода ОС DSDOS:
https://forum-img.guitarplayer.ru/2024/02/11/60SXF.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_win.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/wikipedia/commons/9/96/ZXSpectrum89.svg»;
20h..FDh – пользовательская**.
_____________________________
* вся площадь окна доступна для консольного ввода-вывода, в остальных случаях рабочая область окна: (Ширина - 2) х (Высота - 2);
** рамка рисуется символом с соответствующим ASCII-кодом.
https://forum-img.guitarplayer.ru/2024/02/11/604rS.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_cfg.png)
Работа с драйвером (информация по программированию)
Программный интерфейс драйвера описан в библиотеке WUI.L (SDK (http://denn.ru/8bit/orion/soft/dasm/dsdos_sdk.rar) ОС 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 (http://denn.ru/8bit/orion/soft/dasm/dsdos_sdk.rar) ОС 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
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_menu_vert.png)
https://forum-img.guitarplayer.ru/2024/02/11/60HKV.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_menu_horiz.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
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_fopen_min.png)
B расширенном задаётся режим отображения полей файлов в списке (вывести/скрыть: адрес посадки, длину hex/dec, атрибут защиты, страницу ОЗУ и дату):
https://forum-img.guitarplayer.ru/2024/02/11/60xNJ.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_fopen_full.png)
Процедуры 5Eh и 5Fh являются готовыми компонентами открытия и сохранения файла, соответственно. Они самостоятельно открывают своё отдельное сохраняемое окно, положение и размеры которого автоматически подбираются так, чтобы оно было расположено в центре экрана ПРК:
https://forum-img.guitarplayer.ru/2024/02/11/60C9m.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_fopen_medium.png)
По завершении выбора файла, окно диалога автоматически закрывается, содержимое экрана под ним восстанавливается и в программу пользователя возвращается дескриптор выбранного файла (в BIOS'е установлен текущим выбранный диск и имя файла).
В процедуре сохранения файла есть возможность выбрать имя файла из уже имеющихся в списке (запись «поверх») или ввести новое (соотв. поддиалог вызывается клавишей пробела):
https://forum-img.guitarplayer.ru/2024/02/11/60hJc.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_fsave_new.png)
В случае записи «поверх», процедура самостоятельно удаляет одноимённый файл на диске!
https://forum-img.guitarplayer.ru/2024/02/11/60ncy.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_fsave_over.png)
Непосредственно команды чтения/записи файлов и обработки статуса их исполнения программист выполняет самостоятельно, процедуры драйвера организуют только все необходимые подготовительные работы.
Во всех процедурах с файлами в рег. паре [HL] передаётся указатель на ASCII-строку (признак конца – 00h) шаблона(ов) для отбора файлов, отображаемых в списке. Если шаблонов несколько, то они разделяются пробелами. Например:
DB '.AS .TXT',0
При [HL]=0000h отбор игнорируется и выводится полный список файлов.
Кол-во файлов, видимых на экране (в окне) задаётся при вызове соответствующей процедуры. Если полный список длиннее, то реализуются скроллинг и листание страниц, а также переходы в начало/конец списка по Ctrl+[Home]/[End]. Навигация стрелками, [Home]/[End], [PgUp]/[PgDown], выбор файла – [Enter].
Выбор диска осуществляется нажатием соответствующей буквы [A..H], обновить содержимое текущего диска можно с помощью Ctrl+[R].
В заголовке отображается название действия, текущий диск и, если указан(ы), шаблон(ы) отбора файлов.
Внизу под списком файлов слева выводится номер текущего файла, на котором находится указатель, а справа в квадратных скобках общее количество файлов на диске.
В случае вызова файловых процедур с параметром «диск по-умолчанию» (имя диска = 00h, подробности в библиотеке WUI.L), страница и положение указателя последнего выбранного файла в списке запоминается, и при последующем вызове диалога восстанавливается (если содержимое диска к тому моменту не изменилось).
Заключительные две процедуры 60h и 61h выводят на экран сообщения в окне. Первая (WN_SHOW_ERROR) выводит расшифровку ошибки DSDOS, а вторая (WN_SHOW_MSG) выводит сообщение пользователя. Процедуры самостоятельно открывают и закрывают окно, размещение которого автоматически рассчитывается таким образом, чтобы оно было в центре экрана ПРК. В обоих случаях окно сохраняемого типа, в первом оно фиксированного красного цвета, во втором цвет (или его отсутствие) задаёт программист. Окно с сообщением пользователя имеет три режима:
1) Мигающий курсор после сообщения;
2) Курсор погашен;
3) Второй строкой выводится: [Enter]/[..]/[Esc].
Окно закрывается по нажатию любой клавиши, в программу возвращается её код, а флаги МП установлены как при возврате из процедуры INPUT_KEY модуля CONIO.
В процессе работы некоторых процедур драйвер использует область ОЗУ атрибутов цвета теневого экрана (8000..AFFFh стр.#1) для буферизации данных сохранения экрана под окнами и построения списка файлов по шаблону(ам), а также используются участки непереключаемого ОЗУ F300..F32Fh и F370..F37Fh для кода быстрого переноса экранных данных и формирования имён файлов, это следует учитывать при вызове процедур ExtDRV.
Демо
Для демонстрации возможностей драйвера ExtDRV написана программа EXTDEMO$, в архиве также прилагается её исходный код.
https://forum-img.guitarplayer.ru/2024/02/11/60vnh.png
альт.ссылка на изображение (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdrv_help.png)
__________________________________________________ __________________________________________________ _
Ссылка для скачивания - архив в формате *.ORI (http://denn.ru/8bit/orion/soft/dsdos/extdrv/extdemo.rar)
OrionExt
04.02.2018, 18:03
Denn, пилит свою ОСЬ (лет так 17 точно). Уважуха. Когда уже много задачность появиться на Орионе;)
- - - Добавлено - - -
Чоть навеело. Помню, исходники оси от Denn по модему качал.
Всё конечно замечательно описано, а почему не в отдельной теме даже если учесть что ПО под Орион. Программатор не укладывается в название темы: DSDOS для ПРК "Орион".
Когда уже много задачность появиться на Орионе;)
На 8-битке смысла нет. На классическом Орионе - тем более. Это если в привычном "писишном" смысле.
Виртуальная "многозадачность" в концепции DSDOS есть, она реализуется с помощью сохранения текущего состояния программ в конфигурационных файлах, т.о. запуск программы можно рассматривать как переключение к данной задаче. Оболочка ОС в качестве "переключателя". Также есть механизм call-вызова программы из программы. Имхо, для Ориона этого вполне достаточно.
Помню, исходники оси от Denn по модему качал.
Использовать писи для хранения файлов Ориона, емнип, я начал в конце 2015-го года, до этого жил на дискетах, т.е. полностью в 8-битном домене. Но и после 2015-го исходники публично не выкладывал. Соответственно, вопрос: откуда?
- - - Добавлено - - -
Всё конечно замечательно описано, а почему не в отдельной теме даже если учесть что ПО под Орион. Программатор не укладывается в название темы: DSDOS для ПРК "Орион".
Наверное, справедливое замечание.
Но с другой стороны, если я выложу сабж в разделе про железо (а по специфике форума оно как бы автоматом подразумевается для спектрума), то будет странно. Как известно, железка без ПО смысла не имеет, а ПО обслуживающее данный программатор есть только под Орион, и только под DSDOS.. получается, что есть смысл публиковать там, где обитает народ, интересующийся DSDOS. По-моему так (С)
https://cs6.livemaster.ru/storage/4e/73/32ef2433e2522611a7f7e778d4vi.jpg
Наверное, справедливое замечание.
Но с другой стороны, если я выложу сабж в разделе про железо (а по специфике форума оно как бы автоматом подразумевается для спектрума), то будет странно. Как известно, железка без ПО смысла не имеет, а ПО обслуживающее данный программатор есть только под Орион, и только под DSDOS.. получается, что есть смысл публиковать там, где обитает народ, интересующийся DSDOS. По-моему так (С)
Я не говорил переместить в другой раздел, а оставить в Орионе, но под новым заголовком.
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 начинает работать с другим типом носителя (флоп, винт, флэш).
HardWareMan
05.02.2018, 19:47
Denn, значит пора создавать твой раздел, с карточными играми и куртизанками!
OrionExt
05.02.2018, 23:17
Использовать писи для хранения файлов Ориона, емнип, я начал в конце 2015-го года, до этого жил на дискетах, т.е. полностью в 8-битном домене. Но и после 2015-го исходники публично не выкладывал. Соответственно, вопрос: откуда?
Ну, вы барин задачу ставите:D Поскрипел мозгами, пошуршал по дискам.
А это чье? Не мое:)
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 байт
; 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% оффлайн техника. Впрочем, ладно, это уже не важно :)
OrionExt
05.02.2018, 23:59
Denn, ну как откуда. С твоего сайта и качал модемом в начале нулевых. Ох, давно это было. Это ведь не твой двойник сайт сделал и исходники выложил:)
Зарождение промышленного шпионажа или еще раз о защите информации:-).
Stampmaker
06.02.2018, 13:40
http://orion-128.narod.ru/
как бы не отсюда ноги растут
barsik, спасибо за интерес к теме и вопросы.
Это мягко говоря, преувеличение. С документацией плохо...
...Но нет документации для программиста в нормальном виде. Да и для пользователя документации нет, это значит, что
надо читать всю эту тему, запоминать информацию. Даже HELP-ов нет, хотя это совсем не проблема - вывод текстового
файла на экран, если нажали <F1> и нужный HLP-файл есть на диске.
Упрёк голословный, на основании чего сделан вывод - не понятно. Оформление темы в хронологическом стиле - да, не очень информативно, особенно для "вновь входящих" и привыкших получать информацию в максимально "пережёванном" виде, но те, кто "в теме", знают где что искать.
Всё ПО имеет либо встроенную справку (выводится при запуске программы без параметров, либо с ключом "/?" или "/H"), либо отдельным текстовым файлом "*.H" или "*.HLP", либо по горячей клавише "H" в самой программе.
Информация для пользователя ОС есть на форуме (в первых постах), а также одним файлом в формате "*.doc".
Инфо для восьмибитных программистов (а таковые вообще есть в природе?) представлена в виде тех же "вордовских" файлов с подробным описанием API, распределением памяти, кодировки символов, кодов ошибок и т.п..
Более структурировано, в меру возможностей, пытаюсь оформить документацию тут - https://vk.com/dsdos_orion
Если будет время, то планирую сделать сайт, но это слишком масштабно.. пока не до этого.
Здесь все на PC, потому тексты должны быть сразу доступны на PC, а не в каком-то левом
формате, чтобы прочесть который надо истратить море времени и усилий.
Здесь всё исключительно на Орионе, а не на писи! Писюк в качестве хранилища и обменника был "прикручен сбоку" совсем недавно, но его роль лишь в логистике контейнеров с информацией (т.е. это своеобразный роутер для Ориона), не более того.
Я против смешивания 8-битки и писи, это совершенно разные миры.
Зачем применять нестандартную собственную кодировку, для конверсии из которой нет
программ.
One more time... Орион - это Орион, это прекрасный 8-битный мир, и он никому ничего не должен. Сабжевая ОС была написана исключительно на самом Орионе, его штатными средствами, и предназначена для работы на этом самом Орионе, с упором на максимальный комфорт и раскрытие возможностей платформы.
Для любителей "поковырять" орионовские файлы с помощью американских технологий (зачем?) был написан соответствующий инструмент -
http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=883707&viewfull=1#post883707
Вопрос преобразования кодировок он также решает.
Почему в DSDOS использована не КОИ-8 или КОИ-7 и даже не АЛЬТ-кодировка, а кодировка
полученная из КОИ-8, в которой для символов выше C0 отксорен бит D5.
DSDOS разрабатывалась и развивается по одному простому принципу - реальной насущной необходимости какого-либо функционала. Моей личной необходимости. Также по мере возможности воплощаются некоторые хотелки пользователей.
В своё время одних заглавных букв Монитора стало мало, понадобился "нижний регистр" и псевдографика. Нужно - сделали! Информации "как правильно" (или как "кому-то надо") не было, поэтому сделали как логично, исходя из данной ситуации. А логично было исходя из особенностей родной РК'шной клавиатуры прибывать константу к "сырому" коду F81Bh и получить соответствующую русскую букву. Аналогично с регистром букв - тоже воздействие константой на базовый код процедуры Монитора. Других стандартов не было, значит сделали свой. Задача для Ориона решена: имеем два языка, два регистра и псевдографику; текстовый редактор это всё поддерживает, можно ваять тексты и программы.
То, что не удобно на писи - ну, извиняйте, не для того роза цвела, как говорится.
Пришлось написать программку на QUICK-бейсике, чтобы конвертировать в нормальный вид
Забавно :) Пытаюсь представить масштабы нужды...
П.С. у меня под MSDOS в образовательных целях была написана утилита конвертации туда-обратно, в ДОСовскую 866-ю и в виндовую 1251. Практически не пользовался ни разу.
в одном файле нормальные разделители 0D,0A, а в других только 0D. Логично было ожидать
единообразие.
Двухбайтовый перевод строки это какая-то заморочка исключительно писишных файлов или какой-то писишной обработки, на Орионе такое расточительство ОЗУ не используется, у меня файлов с 0D0Ah нет.
Формат текстовых файлов на Орионе всегда был такой:
Коды символов: 20..7Eh (в DSDOS пошире - 20..FEh);
Разделитель строк - 0Dh;
Признак конца файла - FFh (как я понимаю, наследие Микрона);
Коды 00..0Ch и 0E..1Fh - не используются и считаются ошибкой формата.
Обычно экранные процедуры делают искейп-кодами, т.к тогда сохраняется к ним доступ из
ЯВУ.
Именно это и сделано в DSDOS. Выводом полностью можно рулить через п/п вывода сообщения. Включая управление режимом цвета, с недавней версии.
Только не "американскими" искейп-кодами, а экономными и прицельными последовательностями кодов, которые решают насущные задачи.
В данной системе нет разделения на DOS-BIOS и DOS-BDOS, один общий BDOS, потому и функции, что
должны быть в ROM-BIOS или в загружаемом драйвере включены в BDOS.
Никому ничего не должны. К счастью (да, именно так - к счастью!), на момент зачатия ОС мой мозг не был отягощён знаниями американских технологий, "как правильно" и прочими "уставами" и догматами, которые, как известно, являются не чем иным, как запретом мыслить. Повторюсь, всё создавалось по мере необходимости, исходя из имеющихся реалий.
Так вот, изначально DSDOS базировалась на ПЗУ Монитора в качестве базовой системы ввода-вывода, и представляла из себя только функционал работы с файлами, который и был "неправильно" (в "американском" смысле) назван BIOS'ом: базовая система ввода-вывода ФАЙЛОВ. Не "дисковая система", а ввод-вывод файлов - более широкое понятие, т.к. изначально предполагалась файловая организация обмена данными между программами, а сами файлы не только в виде физических дисков (ленты, дискет и т.п.), а также в виде RAM-дисков, виртуального "диска", буфера обмена и т.д.. Т.е. ОС состояла из файловой системы (BIOS) и процессора консольных команд (CCP, здесь название случайно совпало с американским :)).
Позже меня окончательно утомил дико тормозной 6-битный вывод символов, и я сделал надстройку над Монитором, которая позволяла использовать полноценное знакоместо 8х8 с вменяемой скоростью вывода. В процессе работы стало понятно, что "надстройка" (модуль консольного ввода-вывода, CONIO) бесповоротно переходит в статус "перманентно" и от API Монитора с его "прелестными" 64 символами в строке я отказываюсь.
Касательно включения чего-то в ROM-BIOS. Упор был на идеологию минимального вмешательства. Т.е. функционал базового Ориона не должен страдать, а ОС это "надстройка", дающая дополнительный функционал, для комфортной работы. Родной (RK86/ORDOS) софт Ориона должен "видеть" нативную среду (базовый М2 и API ORDOS). Иначе это уже не Орион, имхо.
Экранный драйвер с оконными функциями полезно выделить в отдельный файл (обозвав XBIOS), чтобы
его можно было использовать без DSDOS.
Кому полезно? Мне - нет :)
Драйвер завязан на функционал DSDOS (ввод-вывод символов, организация оконного режима вывода, операции с файлами). Вплоть до обращения к системным переменным ОС и её буферу каталога файлов.
Писать нечто универсальное (и дико тормозное, разумеется) задачи не стояло.
А ещё лучше сделать установку теневого ПЗУ (Shadowy ROM) в адресах 0...7FFF и прошить
туда...
Так сделайте.
...дополнив его процедурами для поддержки мыши и GUI.
Флаг Вам в руки.
В свою очередь, считаю мышь совершенно излишней на 8-битке. Но, если кто-то придумает ей применение и адекватно это реализует, то почему бы и нет.
Опять же, есть маленькая проблемка.. изначально у Ориона нет мыши. Чтобы заставить пользователя её "прикрутить" (а предварительно приобрести), нужно сделать что-то такое.. уж точно не банальную возможность "тыкать в файлы в нортоне", а что-то более мотивирующее.
..будет отнимать кучу места в ОЗУ ОРИОНА и дико тормозить, - это не важно..
Нет! Это как раз важно!
GUI на Орионе ради преклонения перед американскими технологиями, в ущерб производительности и вообще мимо какого-либо здравого смысла? Бесперспективняк.
Зачем понадобился формат ORI? Это нестандартный формат, его даже эмуляторы не поддерживают. Не
было смысла плодить сущности. Что он даёт относительно формата ORD, кроме никому ненужной сигнатуры?
ЕМНИП, это был 1998-ой год. Из оф. инфы по Ориону было описание ORDOS и SPDOS. Всё. На волне хайпа я поддался всеобщему соблазну американских технологий и пытался программировать на Си под MSDOS (на чужом лаптопе). Самодельная реализация RS-232 с помощью двух ног порта ВВ55 и мозгового штурма. Протокол RS-232 я расковырял выводя прилетающую с писюка инфу на экран Ориона. Далее придумал как выводить ОРДОС-файл, стало быть нужно было придумать формат его хранения на писи. Так родился формат ORI. Степень его "нестандартности" лично мне оценить сложно, т.к. других формат не было (слова "интернет" я не знал, в ФИДО была гробовая тишина на тему Ориона). Тут скорее принцип: кто первый, того и тапки. А о каких-либо стандартах говорить смешно, ибо писюк в мире Ориона это резиновая баба.
П.С. сигнатура нужна для исключения подлога: подсовывания левых файлов с переименованным расширением в ".ORI". Степень ненужности данного функционала каждый оценивает по-своему.
У меня все файлы для 4-х разных 8-ми разрядок имеют расширение ORD, потому что это удобнее, чем...
Это не удобнее, а это "мне так привычнее". Почувствуйте разницу ;)
Формату ORD не хватало контрольных сумм. Для PC это не актуально, а вот для реального ОРИОНА с
эл.диском из излишнего ОЗУ, где у памяти нет 9-го бита паритета для контроля дохлоты, КС намного полезнее, чем дата
файлов. Кстати, в других DOS такой проблемы нет, т.к есть КС секторов.
Тут я ничего не понял %)
Орионовский файл на писи это просто контейнер. Какие паритеты и КС, зачем они? Чтобы больше тормозил файлообмен?
Даты файлов изначально в DSDOS не было, но потом в ней возникла насущная необходимость, и даже место в заголовке нашлось, причём не влияя на родную структуру ORDOS. Было сделано и активно используется.
Но т.к апп.часов у меня в ОРИОНЕ не было, то бит с оффсетом 12 я обычно использовал...
В моих оболочках LORD специально есть команда нормализации ORD-файлов (директива <N>), которая
подставляет контр.сумму ORD-файла.
В эмуляторе на PC контр.сумма ORD-файла не важна, в то же время дата доступна. Потому разумно
этими 4-мя байтами распорядиться так...
В целом принцип понятен.. как в том анекдоте, по любому вопросу есть два мнения: моё и неправильное.
Логика панелей в нортоне DC$ имеет неудобство, т.е не как общепринято. При нажатии вправо в
левой панели указатель не должен сразу перескакивать на соседнюю панель.
И тут тоже понятно. Не как в американских технологиях, значит неправильно. Не как я привык, значит неудобно.
Я делал с нуля, поэтому изначально делал как мне реально удобнее и интуитивно понятнее. Стрелки гоняют курсор согласно соответствующим направлениям - это, имхо, логично. Табуляция тоже гоняет курсор между панелями (для совместимости с писишными привычками), но мне удобнее пользоваться стрелками.
По первому нажатию клавиши <вправо> указатель должен перескакивать на самую нижнюю строку
текущей страницы, а если уже на последней строке страницы (списка файлов), то на последнюю строку последней
страницы. И только если указатель стоит на самом нижнем файле в списке, то по нажатию вправо происходит переход в
правую панель. Для перехода между панелями служит TAB. А клавиши <влево> и <вправо> в панели служат для перехода к
первой и последней строке отображаемой страницы.
Для перемещения в начало конец списка на экране удобнее использовать соответствующие клавиши ([Home]/[End]), а для перемещения в самое начало и в самый конец всего списка их комбинации с Ctrl. Просто, быстро, логично, интуитивно.
Имхо, конечно.
Раз DSDOS теперь может работать с нормальным КНГМД, то отчего в дистрибутивах эмуляторов нет
поддержки дисковода в DSDOS-конфигах. Обычный нормальный КНГМД многие эмуляторы поддерживают, в отличие от КНГМД
для SP-DOS. Почему не попросить авторов эмуляторов доработать конфиг-файл, предназначенный для DSDOS? Это же
дописать всего несколько строк.
Вопросы "резиновой бабы" (эмуляции) меня мало интересуют, гораздо увлекательнее работать на реальной железке. Для этого и создана DSDOS и ПО под неё.
Для написания же статей (снятия скриншотов) я использую прекрасный эмулятор от камрада b2m, там виртуальный дисковод моя ОС видит и всё работает "из коробки", никаких специальных телодвижений для этого не требуется.
Нажимаем иконку дискеты, выбираем ODI-образ и DSDOS прекрасно видит эту "дискету" (пиши-читает файлы).
Другие эмуляторы не пробовал в виду отсутствия таковой нужды. Полагаю, что если в эмуле реализована одна из известных версий КНГМД для Ориона, то она также без проблем будет работать с моей ОС.
А в саму DOS полезно встроить внешний файл-драйвер, при замене которого DSDOS начинает
работать с другим типом носителя (флоп, винт, флэш).
Концепт ОС предполагает изначальную поддержку всех актуальных носителей, т.е. соответствующие драйвера уже включены в ядро. Также есть возможность проинсталлировать свой драйвер, в т.ч. "поверх" родного. Вариативность вполне достаточная, имхо.
https://pp.userapi.com/c543106/v543106810/2f620/uHvykH2d8rg.jpg
- - - Добавлено - - -
http://orion-128.narod.ru/
как бы не отсюда ноги растут
Stampmaker, исходники я не выкладывал на сайте.
Error404
06.02.2018, 15:10
По поводу контрольных сумм (КС) для файлов поделюсь мнением: они имели бы право на существование, если бы файл был чем-то константным. Но представьте такое: некий процесс (или несколько процессов) постоянно пишут в файлы (элементарно логи в /var ), причем они не новые файлы создают, а правят (или дописывают) существующие. И что же, ОС при этом после каждой записи (а их, напомню, архимного и архичасто) должна пересчитать КС всего файла (а если файлы большие, например всё те же логи в /var ?) и внести изменения в заголовок файла? Очевидно что такая система не жизнеспособна, и даже с небольшими файлами - будет работать сама на себя. А для ПЗУ (где файлы не меняются) КС тоже вряд ли имеет смысл, т.к. носитель не испортится (99,999%) и файлы не правятся. КС могла бы иметь место на единице хранения - блоке файловой системы, кратно корой происходит каждая единичная запись данных, но Ордос до таких категорий не доросла.
КС файла у меня реализована при файлообмене с виртуальным диском, т.к. там есть реальная нужда в этом (могут иметь место помехи передачи в железке). Но там КС упрощённая (XOR всех байтов тела файла), она вычисляется на лету (не увеличивает общую скорость обмена) и передаётся только между хостами, в заголовке файлов не хранится.
Пришлось написать программку на QUICK-бейсике, чтобы конвертировать в нормальный вид
Забавно. Пытаюсь представить масштабы нужды...
А что тут представлять? Простенькие конверторы проще всего писать именно на бейсике. Получается быстрее, чем на Си или ассемблере. Беру заготовку, где уже есть загрузка файла и запись результата в файл. Остаётся потратить пару минут на написание всего нескольких строк на бейсике, что и делают конверсию. И даже не требуется бейсик программу компилировать.
по любому вопросу есть два мнения: моё и неправильноеФраза как раз характеризует именно Ваше отношение, не моё. Явное нежелание даже хоть что-то обсуждать.
Напрасно Вы восприняли мой пост как "наезд". Я не критиковал, а высказал личное мнение, причём всего на пару моментов, о том что реально неудобно, но что при желании поправить совсем несложно.
Я понимаю, что при программировании интереснее написать своё, чем заимствовать. Но речь о базовых вещах, здесь изобретать велосипеды незачем.
использую прекрасный эмулятор от b2m, там дисковод моя ОС видит и всё работает
А я использую прекрасный эмулятор EMU80, где в меню выбора есть ОРИОН с DSDOS, но дисковода нет.
Нажимаем иконку дискеты, выбираем ODI-образ и 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, где нет КС.
В ROM-BIOS нужны процедуры для поддержки мыши и GUIФлаг Вам в руки. В свою очередь считаю мышь совершенно излишней на 8-битке
Разработчики мыши для БК-010 и Корвета так не считали. Эта мышь называется "манипулятор ММ 8031". Выдаёт результат в параллельном коде (с двух реверсивных счётчиков) и подключается просто и всего через один порт ППА.
GUI на Орионе ради преклонения перед американскими технологиями, в ущерб производительности и вообще мимо какого-либо здравого смысла? Бесперспективняк.
Глупости. Весь мир сделал свой выбор.
Теперь ясно, что Вы не Стивен Джобс, который увидев мышь сразу понял удобство графического интерфейса.
Речь о однозадачной ОС. Точнее даже не о ОС, а лишь об оболочке для любой ОС для управления файлами. Что-то типа 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 дорабатывать поздно, т.к в реале ей никто, кроме Denn-а не пользуется.
Вы бываете слишком категоричны. То порт никому не нужен, то ORDOS никем не используется... Ну я вот тоже пользуюсь и тем, и другим. И вполне разделяю точку зрения Denna.
Error404
07.02.2018, 11:59
Поэтому и искал Windows для ОРИОНА, что входила в дистрибутив CP/M-48K от ОРИОНСОФТ в 1993. Но так и не нашёл.
Это наверное все уже видели, смотреть там особенно не на что. См. во вложении этого поста (http://zx-pk.ru/threads/16969-kontroller-ngmd-orion-128-cborka-i-nastrojka-varianta-2011-fak.html?p=423949&viewfull=1#post423949).
Про файлы комментировать не буду, рассуждения продиктованы опытом, а у меня опыт другой (во многом с машин откуда и UZIX, где в порядке вещей с большой частотой открывать-закрывать файлы чтобы изменить в них только несколько байт, т.к. работа с файлами ведется не только пользователем, но и ядром и сервисами ОС для её собственных нужд).
А я использую прекрасный эмулятор EMU80, где в меню выбора есть ОРИОН с DSDOS, но дисковода нет.
Что значит "ОРИОН с DSDOS"? В смысле, подкинут образ ROM-диска со сборкой DSDOS ?
Ну, подкиньте тогда стандартный КНГМД (как он там официально называется, плата которого в комплекте плат "Орион-128 рев.512" ?).
А вот это совсем неправильно, т.к расширение ODI используется уже более 10 лет и этот формат общепризнан и поддержан эмуляторами и утилитами, как формат CP/M Ориона и Корвета.
ODI - это виртуальный образ дискеты объёмом 800 Кб (Прим.: копия секторов, без служебной разметки треков).
В чём неправильность? Что эмулятор b2m его поддерживает и/или что DSDOS с ним работает "из коробки" ?
Полагаю, что b2m сделал его поддержку, т.к. он известный, популярный и, в общем-то, наверное единственный в своём роде для данной задачи.
А в DSDOS просто есть поддержка работы с ГМД подходящей организации.
Обозвав так же формат дискет SPDOS, Вы ввели никому ненужную путаницу. Здесь как раз и необходимо было вводить новое расширение. Фантазии не хватило на собственное расширения для образов дискет SPDOS?
Зачем? Какое своё расширение? Устройство 800кб-дискет, равно как и формата ODI, не зависит от ОС, это просто хранилище (файл ODI - соответствующий контейнер).
Под форматом SPDOS имеется в виду логическая организация данных на диске (DIR & FAT). Вопросы авторства формата - к М.Короткину, я так понимаю формат придумал он. По крайней мере в описании никаких упоминаний о заимствовании нет.
Не знаю как в эмуляторе от b2m, но в EMU80 можно для каждой конфигурации задать используемый тип файлов с образами дисков.
Вопросами эмуляторов не владею, тут лучше обратиться к знающим людям.
Вообще-то диск подключённый по линии называется сетевым.
У меня почему-то язык не поворачивается называть RS-232 линк "сетью". Имхо, сеть - это нечто большее, чем соединение двух абонентов.
В данном случае как раз считаю, что было бы неграмотно (в "американском смысле") называть хранилище на писи "сетевым диском".
Он может и становится "сетевым" в случае расшаривания с помощью утилиты Google-Drive, но это частный случай использования, и сетевая функция уже виртуальная.
Речь шла о ORDOS-файлах, чтобы обнаруживать дохлоту в реале.
Для обнаружения дохлоты в реале лучше пользоваться осциллографом ;)
У меня за 17 лет "дохлоты" носителей не встречалось. Битые дискеты попадались конечно, но там без программной КС проблема обнаруживается. Сбоев квазидиска не было ни разу.
Считаю неразумным вводить тормоза файлообмена в угоду перманентного контроля неисправности аппаратуры.
При файлообмене без разницы какие два байта пересылать, два нуля или два байта КС. И всё как раз наоборот, - не имея готовой КС, при файлообмене КС придётся считать, что и затормозит, хотя и несущественно.
Считать КС придётся по любому, на каком этапе - без разницы. И это медленно. Лучше собрать нормальное неглючащее железо и работать на комфортной скорости, имхо.
Нелепый довод. Удивлён читая такое от Вас, т.к Вы знакомы с тем как программы работают с файлами. Во всех ДОС, кроме ORDOS, файл сначала открывают, а в конце работы закрывают, после чего никаких изменений с содержимым файла не происходит. Что за идиот стал бы перезаписывать КС при каждой очередной записи в файл, достаточно это сделать один раз при закрытии файла.
файл может быть не закрыт (зависли, вышли из программы некорректно и т.п.), получается что КС будет неверная.
Потом, неполадка (требующая контроля КС) может случиться в любое время, в т.ч. когда файл открыт.. и её нужно контролировать и обрабатывать, иначе смысл затеи теряется.
Но сейчас ORDOS дорабатывать поздно, т.к в реале ей никто, кроме Denn-а не пользуется.
Вы живёте в своём мире (увы, американском), и считаете, что остальные мыслят и делают всё также. Ну, или по крайней мере должны также.
Есть люди, которые до сих пор работают на Орионе в М1 и загружают ПО с магнитофона.
А есть те, кто программирует на калькуляторах. Кто-то прошивает РФ2 с помощью тумблеров.
Мир многогранен.
Для американского ПО существуют соответствующие американские компьютеры, и там оно всё адекватно. У русских, как известно, свой путь :)
Так что ORDOS - единственная в мире DOS, где нет КС.
Серьёзно?
Если бы на писи была КС, и при добавлении данных в файл выполнялся её пересчёт и контроль, то обработка видео в реальном времени была бы невозможна. Даже при нынешних гигагерцах и гигабайтах в секунду.
Разработчики мыши для БК-010 и Корвета так не считали. Эта мышь называется "манипулятор ММ 8031". Выдаёт результат в параллельном коде (с двух реверсивных счётчиков) и подключается просто и всего через один порт ППА.
Я рад за них. Их концепт пошёл в народ? Идею "ММ 8031" все бросились копировать? Написано ПО, которое вкусное и без этой их мыши ничего подобного не сделать?
Глупости. Весь мир сделал свой выбор.
За мир сделали выбор те, кто диктует правила (у кого есть власть/деньги). Тайд стирает лучше других порошков, это знают все правильные домохозяйки ;)
Теперь ясно, что Вы не Стивен Джобс, который увидев мышь сразу понял удобство графического интерфейса.
Джобс не в курсе про Орион-128, его возможности (ресурсы) и выполняемые задачи.
Самый удобный интерфейс для человека - голосовой (а ещё лучше силой мысли прямо в мозг). Сейчас к этому мир идёт.
Только всё должно быть адекватно. Если вывод "Hello World" заберёт все ресурсы ПК, то нет смысла в такой концепции ПО.
А я - да, не Джобс уж точно. Слава богу.
Естественно и графика поначалу получится некрасивой, но при желании всё можно довести до шедевра.
Простой вопрос - ЗАЧЕМ? Демосцена на Орионе? :)
Не понимаю Вашего страха перед GUI. Кстати, написание GUI это самая интересная задача, что осталась в системном программировании для ОРИОНА и СПЕЦИАЛИСТА.
Какой ущерб производительности?
Вероятно у нас разное понимание термина. Под GUI я понимаю ГРАФИЧЕСКИЙ интерфейс пользователя. Не символьный. Т.е. элементы интерфейса представлены графикой. Достаточно взять ТТХ Ориона и калькулятор, и станет понятна бессмысленность затеи.
У меня оболочка ОС выводит на экран по 25 файлов в каждой панели, итого 50 файлов появляются на экране почти мгновенно. Надеюсь размер вашей пиктограммы не 8х8 и она не монохромная ? Вот и прикиньте отрисовку хотя бы половины (или даже четверти) этого кол-ва пиктограмм на Орионе-128. А заодно посчитайте объём памяти, требующийся для хранения этих пиктограмм и смысл такой затеи для запуска М128 и прочих бэйсиков.
С объёмом ОЗУ 128кб и ROM-диском на 64кб такая ОС просто не взлетит, вероятно придётся грузиться с дискеты, а это даже не смешно.
Какая разница перемещать балку подсветки в нортоне курсорными клавишами или перемещать стрелку-указатель мышью в GUI.
Разница в объёме кода "прослойки" (ОС) и необходимости "махать паяльником".
Если отбросить мотив "шоб было крута как на американском компе", то для чего оно надо?
Полагаю, что b2m сделал его поддержку, т.к. он известный, популярный
Простая посекторная копия диска, как-бы, не имеет формата, ну кроме, может быть, порядка следования секторов в файле. Но он в подавляющем большинстве случаев одинаковый и логичный. То есть, какой-то специальной поддержки именно орионовских дисков в эмуляторе нет.
Чтобы отличать одни образы от других, используется расширение файла. Для меня известным и популярным становится то, что я в достаточном количестве нахожу в интернете. Для Ориона-128 это были файлы с расширением .odi и именно это расширение я указал в конфигах для выбора файлов-образов.
Black Cat / Era CG
07.02.2018, 14:14
ну кроме, может быть, порядка следования секторов в файле
Ну там на практике (то есть в большинстве утилит, которые я встречал) для подобных форматов используется след. негласные соглашения:
- сектора упорядочиваются по значению в ID-маркере сектора сектора (если возможно), а не по физическому расположению,
- для двусторонних дисков: стороны хранятся не раздельно, а чередуясь для каждого цилиндра (цилиндр_0 сторона_0, цилиндр_0 сторона_1, цилиндр_1 сторона_0, цилиндр_1 сторона_1,...).
И все.
Что значит "ОРИОН с DSDOS"? Это название пункта в меню выбора платфомы в эмуляторе. Значит автор эмулятора включил конфиг под такое железо и ПО. И посчитал ненужным включать туда дисковод. Видимо это было давно, когда DSDOS ещё не поддерживала обычный КНГМД, а позднее Вы поленились послать автору эмулятора образы дискет в формате SPDOS.
посчитайте объём памяти, требующийся для хранения этих пиктограмм и смысл такой затеи для запуска М128 и прочих бэйсиков
Насчёт смысла, - это свойственная Вам депрессия. Зачем Вы постоянно всё депресуете? Нужна, наоборот, моральная поддержка. А зачем этот сайт читают и пишут? Это такое хобби. И оно лучше, чем клеить кораблики внутри бутылок.
С чего Вы взяли, что большой объём памяти тратится на пиктограммы. Типов иконок, допустим 8. Типоразмеров иконок, для начала два: 24*32 и 16*24. Итого расход на пиктограммы всего ~1 кб. А вот на окна действительно уходит много памяти, но 2-х банок хватит. Кстати, я ориентируюсь на больше, чем 2 банки, мне нужен RAM-диск, а лишь DOS+GUI занимают 2 банки.
С объёмом ОЗУ 128 кб и ROM-диском в 64 кб такая ОС просто не взлетит. Вероятно придётся грузиться с дискеты, а это даже несмешно.
Не взлетит, - это непонятный жаргон. Что Вы этим утверждаете? Что будет работать неудовлетворительно или вообще не будет работать? На Apple-IIe хватило 128 кб и тормозного флопа на 140 кб. ROM-диска там вообще не было.
Чего "несмешного" в загрузке с дискеты? 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).
У меня оболочка ОС выводит на экран по 25 файлов в каждой панели, итого 50 файлов появляются на экране почти мгновенно. Надеюсь размер вашей пиктограммы не 8х8 и она не монохромная?В графическом интерфейсе в окне можно выводить и список файлов, так что интерфейс Нортона можно считать окном GUI со списком. Размеры иконок масштабируются пользователем, так что нужны картинки всех размеров от 8*12 до 32*48.
Из этого вопроса и потому, что Вы считаете, что возможностей ОРИОНА для 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).
http://ipic.su/img/img7/fs/Apple-IIeMousedesk4.1518031008.png
http://ipic.su/img/img7/fs/Apple-IIeMousedesk3.1518030852.png
http://ipic.su/img/img7/fs/Apple-IIeMousedesk1.1518029629.png
Так что ORDOS - единственная в мире DOS, где нет КС Серьёзно? Если бы на Пи-Си была КС...
Вы прекрасно знаете, что в DOS работающих с носителем с помощью БИС контрольные суммы есть у физических секторов. И даже в DOS, где сам процессор заменяет БИС, контрольные суммы всегда используют. А для CD и DVD даже используются исправляющие контрольные коды.
файл может быть не закрыт (зависли, вышли из программы некорректно и т.п.), получается что КС будет неверная ... ужас от Ваших доводов. Если файл открытый на запись не закрыт, то его каталоговая запись неверна и волноваться надо уже не о том, что КС не совпала, а о том, что содержимое файла не то. Но речь-то об ORDOS, где нет даже такого.
Понятно, что КС разумнее иметь у секторов, т.к это единица обмена, но речь-то о 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.
Ладно, проехали и забыли. Исходил из того, что Вы программируете для ОРИОНА и сделал неверные выводы. Убедился, что Вам на всё наплевать.
Вы бываете слишком категоричны. То порт никому не нужен, то ORDOS никем не используется...
Согласен. Учту.
Исходил из того, что не встречал ранее людей, кто применил третий ППА. На платах ташкентского Турбо-10 МГЦ и принтер и ROM-диск обслуживает один порт F500. Зачем тогда нужен третий ППА? Он только излишне грузит шину и снижает надёжность при турбировании по схеме Турбо-200%. Гораздо разумнее на этом месте было бы поставить ВИ53. Но он и вручную удобно ставится на это место.
И вполне разделяю точку зрения Denn-a.
А какую конкретно точку зрения Denn-а Вы разделяете? Я уловил у него только одну точку зрения, что GUI для 8-ми разрядки - это чушь собачья, а мировой опыт не в счёт, т.к это изобрели мерзкие американцы.
Исходил из того, что не встречал ранее людей, кто применил третий ППА. На платах ташкентского Турбо-10 МГЦ и принтер и ROM-диск обслуживает один порт F500. Зачем тогда нужен третий ППА? Он только излишне грузит шину и снижает надёжность при турбировании по схеме Турбо-200%. Гораздо разумнее на этом месте было бы поставить ВИ53. Но он и вручную удобно ставится на это место.
"Орион" хорош тем, что это своего рода радиолюбительский конструктор. Авторы дали основу, пусть и небезупречную (это нам теперь хорошо рассуждать апостериори, а тогда - они сделали, а мы - нет!). Каждый, разумеется, видит свой путь усовершенствования ЛК. Кто-то хочет более быстрый процессор, больше памяти, CP/M с существующим обширным ПО. А кто-то считает, что смысл существования такого компьютера в том, что можно быстро набросать примитивную программу, легко подключить какое-то своё железо и поработать с ним, как сейчас в стиле Ардуино. У меня на железном "Орионе" есть и расширенная память, и контроллер дисковода, и ROM-диск, и ещё всяких железных разностей, но я давно уже понял, что для моих целей вполне достаточно 128 кБ ОЗУ, текстового экрана с символами 6х8, ROM-диска на 64 кБ и дискеты для оперативного сохранения результатов своей работы. Дисковод, возможно, в будущем заменю на CF.
Поэтому третий порт у меня постоянно используется, проблем с нагрузкой на шину пока не замечал. Правда, ПЗУ с "Монитором" у меня включена через буфер, но это я делал только лишь для динамического питания РФ2, поскольку справочник утверждает, что при таком питании инфа в ней хранится дольше.
А какую конкретно точку зрения Denn-а Вы разделяете? Я уловил у него только одну точку зрения, что GUI для 8-ми разрядки - это чушь собачья, а мировой опыт не в счёт, т.к это изобрели мерзкие американцы.
Принцип разумной достаточности.
Error404
08.02.2018, 11:25
А какую конкретно точку зрения Denn-а Вы разделяете? Я уловил у него только одну точку зрения, что GUI для 8-ми разрядки - это чушь собачья, а мировой опыт не в счёт, т.к это изобрели мерзкие американцы.
Строго говоря, мировой опыт насчитывает куда как более обширную историю и разнообразие CLI (и при наличии и поддержки бизнес-графики на тех платформах в том числе), чем GUI. И поныне весь сегмент средней и высшей стоимости выч.техники и ПО это прежде всего CLI (даже Windows пришлось допиливать до приличной CLI когда Билл решил влезть на этот сегмент рынка IT).
Массовое же внедрение GUI имело под собой вполне конкретную бизнес-задачу: в товарных количествах привлечь бытовых хомяков в сферу продаж вычислительной техники (что стало возможно при удешевлении техники на волне повышения степени интеграции). Что мы пожинаем и по сию пору: представьте насколько лучше была бы социальная жизнь не будь этих б-гомерзких смартфонов с социальными сетями, вытеснившими живое общение.
Поскольку мы не те хомяки (их на орионовщине почти не было, это все же не Спектрум), то GUI сделать конечно можно - если очень хочется для получения собственного удовольствия, но говорить что оно нам принесет что-то недостающее - это вряд ли. Хотя посмотреть будет очень интересно из соображений что удастся выжать из этой идеи. Оно конечно реализуемо (сделали же SymbOS), но количество затраченных человеко-часов конечно будет запредельное, поэтому и не хочется за это браться.
Windows производства Орион-Софт уже посмотрели по моей ссылке?
Это название пункта в меню выбора платфомы в эмуляторе. Значит автор эмулятора включил конфиг под такое железо и ПО. И посчитал ненужным включать туда дисковод. Видимо это было давно, когда DSDOS ещё не поддерживала обычный КНГМД, а позднее Вы поленились послать автору эмулятора образы дискет в формате SPDOS.
Как неоднократно упоминал ранее, вопросы эмуляции меня мало заботят, т.к. предпочитаю реальное железо.
Я не "ленился", а просто не интересовался данным вопросом.
Каждый занимается своим делом. Тот, кто развивает эмуляторы, сам ищет востребованные фишки и воплощает их в своих детищах.
образы дискет в формате SPDOS.
По поводу форматов уже отвечал ранее.
Дискета - это наследие от старых времён, сейчас я ими не пользуюсь. Поддержка их в DSDOS сохранилась.
Вы натолкнули меня на идею включать в комплект поставки сборки ОС набор ПО, не поместившегося в 64К-вариант ROM-диска, в виде образа дискеты!
Это мысль! спасибо ;)
Насчёт смысла, - это свойственная Вам депрессия. Зачем Вы постоянно всё депресуете?
Призыв к здравому смыслу вгоняет вас в депрессию? По каким причинам?
Нужна, наоборот, моральная поддержка.
GUI на Орионе бесперспективен в практическом смысле, так что тут я не готов поддерживать.
А зачем этот сайт читают и пишут? Это такое хобби. И оно лучше, чем клеить кораблики внутри бутылок.
На счёт корабликов согласен :)
С чего Вы взяли, что большой объём памяти тратится на пиктограммы.
Вы же не планируете их хранить в JPG, ведь так? /-)
Типов иконок, допустим 8.
Зачем они тогда нужны? Что принципиально меняет использование восьми иконок для конечного пользователя?
Без подколов, просто хочу докопаться до истины. Может я чего-то не понимаю в компьютерах...
Надеюсь всем понятно, что ПРК Орион не для домохозяек, мягко говоря. Зачем 8-битному юзеру запуск М128 или PENX'а через иконку?
Масштаб работы по возделыванию GUI этого стоит?
Типоразмеров иконок, для начала два: 24*32 и 16*24.
Это 96 и 48 байт на картинку, соответственно.
К примеру, это 14 шт. пиктограмм займут объём, который занимает весь код ORDOS. Код их обслуживания.. наверное чуть больше М128$ или даже М256$.
При этом для пользователя функционально ничего не изменится. А вот ОЗУ пользователя станет меньше, места в ROM-диске тоже.
В чём профит?
А вот на окна действительно уходит много памяти, но 2-х банок хватит. Кстати, я ориентируюсь на больше, чем 2 банки, мне нужен RAM-диск, а лишь DOS+GUI занимают 2 банки.
Может лучше сделать прикладное ПО, собственно для которого ПК и предназначен?
А в ОС заложить возможность предоставить максимум комфорта пользователю при минимуме отжора ресурсов.
Не взлетит, - это непонятный жаргон.
Это местный жаргон на форуме. "Не получится".
Что будет работать неудовлетворительно или вообще не будет работать?
Не влезет в стандартный (классический) Орион.
Точнее так, влезти может и влезет, а вот ресурсов для ПО не останется. И вместо комфорта получим ограничения и раздражающие тормоза.
На Apple-IIe хватило 128 кб и тормозного флопа на 140 кб. ROM-диска там вообще не было.
Я рад за Яблочников. Понятие "хватило" весьма относительное.
Зато я чётко представляю чего хватает и чего не хватает для Ориона, и для комфортной работы на нём. Работы, а не демомэйкерства.
Чего "несмешного" в загрузке с дискеты? DOS грузится с дискеты или ROM-диска,
Без слёз смотреть загрузку ОС и подгрузку её модулей с дискеты во время работы невозможно.
Слава богу, в Орионе изначально придуман классный концепт загрузки ПО (как минимум, системного) из ROM-диска.
Но родной ROM-диск это 64 Кб, точнее даже 62 Кб... приходится крутиться и вертеться, и уж точно без графики.
Всё, естественно, работает из ОЗУ. Весь код для работы с графикой в банке где экран, а код DOS и TPA в другой банке.
А программы пользователя можно не запускать, ибо уже негде :)
Если кроме шуток, то ОЗУ пользователя (яснопонятный русскоязычный термин, использованный в оф. лит-ре авторами Ориона, в отличие от TPA "оттуда")
в идеале должно максимально стремиться к целой банке (64 Кб), имхо. К сожалению, в Орионе оно фактически ограничено 48 Кб из-за экранной области, лежащей в общем адресном пространстве ОЗУ пользователя. Но хотя бы все эти 48 Кб предоставить прикладному ПО. Для ОС и её нужд фактически остаётся вторая страница, и то не полная, а "зазоры" между областями атрибутов цвета экранных областей.
Можно, конечно, пойти путём размещения ОС и её причиндалов в 3-ей банке, но тогда либо сильно урезаем квазидиск, либо лишаемся его вообще, а это очень серьёзная полезняшка, от которой лично я не готов отказываться.
Не сомневаюсь, что получится тормознуто, но вовсе не из-за графики, а из-за небайтовых шрифтов. Придётся использовать шрифты 5*9, 6*9 и 7*9, и кстати, драйверы придётся переделать, чтобы символы можно было помещать в любое место экрана, а не только в позиции знакомест.
Забудьте про честный графический вывод символов на Орионе. Просто забудьте. Серьёзно.
П.С. кстати, мир перешёл на векторные шрифты. Сотни мух не могут ошибаться, ведь так? ;)
Натянем на Орион? Чем не челендж? ;)
Вот тогда и понадобится Z80 на такте 4.5 МГЦ (пиксель клок 9 МГЦ, экран 448*256).
Если вы ещё не поняли (читая форум), то все аппаратные доработки Ориона будут делать полтора человека - вы и может кто-то ещё (начнёт, но не доделает).
В графическом интерфейсе в окне можно выводить и список файлов, так что интерфейс Нортона можно считать окном GUI со списком. Размеры иконок масштабируются пользователем, так что нужны картинки всех размеров от 8*12 до 32*48.
Вопрос "зачем?" я уже задавал.
Масштабировать будете высшей математикой или туполинейным набором картинок всех размеров? Объём кода и ж/ч vs. реальная необходимость этой красоты?
Из этого вопроса и потому, что Вы считаете, что возможностей ОРИОНА для GUI не хватит, думаю что Вы не пользовались GUI на Apple-II или на Apple MAC-128 из 1984 года.
Не пользовался. Из 8-биток мне интересен только Орион.
В GUI на слабых машинах применяют монохром,
Монохромная графика уныла и невыразительна, на мой взгляд. Впрочем, талантливый художник возможно предложил бы красивые решения и в таком формате, но пока таковых не встречал.
хотя особенности цвета Специалиста позволяют оцветить без торможения.
Здесь Орион. Как есть. Доработки никто делать не будет. Никто. Потомучто.
В цветных Amiga и Atari - GUI тоже монохромный. GEM от DR для EGA тоже в основном монохромный.
Так это ж нерусские платформы. С нерусскими идеями, задачами, мышлением. Оно уже всё придумано и воплощено.
На запорожец наверное можно поставить фары от форда, но какой смысл?
Посмотрите вид графического интерфейса на Apple-IIe работающем на CPU с тактом в 1 МГЦ, ОЗУ 128 кб и экраном 560*192. Интерфейс
монохромного MAC выглядит похоже (только белый и графика лучше, т.к там растр 512*342).
http://ipic.su/img/img7/fs/Apple-IIeMousedesk4.1518031008.png
http://ipic.su/img/img7/fs/Apple-IIeMousedesk3.1518030852.png
http://ipic.su/img/img7/fs/Apple-IIeMousedesk1.1518029629.png
По-своему занятно. Но лично мне такое не нужно на Орионе, т.к. чётко понимаю ресурсы Ориона и задачи для него.
Я мысленно созрел на символьно-клавиатурный оконный интерфейс для некоторого ПО, но графика и мышь точно нет.
Вы прекрасно знаете, что в DOS работающих с носителем с помощью БИС контрольные суммы есть у физических секторов. И даже в DOS, где сам процессор заменяет БИС, контрольные суммы всегда используют. А для CD и DVD даже используются исправляющие контрольные коды.
Мимо обсуждаемого вопроса. Мы говорили про подсчёт КС средствами ОС и хранение её в заголовке файла.
Но речь-то об ORDOS, где нет даже такого.
...
Понятно, что КС разумнее иметь у секторов, т.к это единица обмена, но речь-то о ORDOS, где нет ни секторов, ни контрольных сумм.
В данном топике речь про DSDOS, а не про ORDOS.
Польза программной КС очень сомнительна. Польза даты очевидная. И дата была введена в DSDOS задолго до поддержки аппаратных RTC.
Потому и совершенно очевидно решение исправления ситуации, - иметь КС на целый файл, тем более, что файлы маленькие. Иметь КС удобно, т.к это даёт гарантию, что файл не повреждён.
Мне за 17 лет реальной работы на Орионе это ни разу не понадобилось. Обычным пользователям тем более не нужно.
Хорошо, допустим я программирую на Орионе, сохраняюсь на квазидиск и после неудачного "мазка" у меня код улетает в космос, по пути оставляя следы в квазидиске. Что в этом случае мне даст ваша КС? То, что файл исходника испорчен, я и так узнаю (текстовый редактор при открытии рабочего файла проверяет на ошибки формата, а ассемблер умеет обнаруживать более "высокоинтеллектуальные" ошибки исходника).
Какой профит от КС? Она же не снимет порчу :)
Я лишь предложил с пользой использовать свободные 4 байта в метке ORD-файла. Точнее предложил даже не использовать, т.к и так давно это использую, а ввести единообразие, стандартизовать.
Стандартизация с какой целью? Ориону глубоко фиолетово в каком виде его файлы хранятся на дисках.
Контейнера *.ORI вполне достаточно для хранения файлов Ориона на писи. За 20 лет у меня не возникла потребность как-то его дорабатывать.
Вы храните свои файлы в ORD, я храню в ORI, а остальные "полтора" человека хранят на дискетах ("половинка" на реальной, а "целый" в ODI), вот и вся реальность :)
Очевидно, что глупо было отводить на имя всего 8 символов, а для программ всего 7, оставляя в то же время 4 байта в ORDOS-метке неиспользованными.
За что люблю Орион и его изначальный ORDOS-концепт: достаточный минимализм.
Красивый и лаконичный 16-байтовый заголовок файла, однобуквенные команды ОС.
Для ресурсов Ориона идеально.
Для "многообразия" ПО на Орионе 8(7) символов для имени файла достаточно. По мере необходимости в них же запросто "запихивается" расширение.
Главное без фанатизма и желания натянуть неуместные здесь писишные масштабы и навороты.
Кстати, в SPDOS разумно было бы ввести нормальные имена файлов, т.е, как Вы это называете - сделать "как принято в Америке", а не в
ORDOS.
Зачем?
Но, судя по второй части предложения, кажется, вы уже начинаете всё сами понимать.
Я уловил у него только одну точку зрения, что GUI для 8-ми разрядки - это чушь собачья, а мировой опыт не в счёт, т.к это изобрели
мерзкие американцы.
Уловили неверно.
Не "чушь", а на мой взгляд бесполезное изобретение из разряда "круто", неадекватное задачам и ресурсам Ориона.
Мирового опыта у Ориона нет и никогда не будет, ибо это платформа для творчества узкого круга людей с определённым менталитетом, а не для коммерции и "домохозяек".
Американцы не мерзкие, просто у них свой путь.
OrionExt
09.02.2018, 20:26
Как всегда прикольно смотреть на битвы гигантов.
Denn, Давай меньше демотиваци. А то песня про все Орион-ы, которые сгнили (это было не в этом топике), уже не канает.
OrionExt, вот все не сгнившие - http://zx-pk.ru/threads/27165-perepis-naseleniya.html
Плюс-минус, но в общем картина понятна.
HardWareMan
10.02.2018, 08:52
Denn, а ты не реагируй на старого форумчанина, профиль которого вообще другая платформа. Чего он на Орионе то забыл?
Почему у меня появляется такое сообщение при попытке отформатировать диск В.
ОС DSDOS последней декабрьская версии 2017 года.
ОЗУ 128 кб
RD3AY, загрузчик ОС не обнаружил в аппаратуре квазидиск, соответственно диск В: недоступен.
Вероятная причина - мало ОЗУ. Минимальный требуемый объём, чтобы была возможность организовать квазидиск - 256 Кб.
Через утилиту SYSTEM$ можно переназначить рабочий диск на другой:
http://denn.ru//8bit/orion/soft/dsdos/system.png
Но этот другой диск в системе должен быть. Без рабочего диска пользоваться ОС можно, но не будет сохраняться конфигурация программ при выходе из них, не будет работать буфер обмена, драйвер расширения и т.д..
Вероятная причина - мало ОЗУ. Минимальный требуемый объём, чтобы была возможность организовать квазидиск - 256 Кб.
Да, видимо причина в этом, у меня ОЗУ 128 кБ 16 штук КР565РУ5Г.
А версии ОС для ОЗУ 128 кБ у Вас есть? Или это жесткие необходимые требования ОС.
HardWareMan
14.02.2018, 09:59
RD3AY, но коллега, РУ7 это 256К, или ты их тупо вместо РУ5 воткнул?
у меня ОЗУ 128 кБ 16 штук КР565РУ7Г
У меня тоже 16 шт. РУ7, но они внезапно дают 512 Кб!
А версии ОС для ОЗУ 128 кБ у Вас есть? Или это жесткие необходимые требования ОС.
Чудо, к сожалению, не случится, при физическом отсутствии необходимого ОЗУ квазидиск не сделать.
Без диска В: ОС будет работать, специальных версий не требуется.
но коллега, РУ7 это 256К, или ты их тупо вместо РУ5 воткнул?
Ошибочка, РУ5Г стоят, все с "синей" платой путаю. Там РУ7К стоят, 512 кБ.
Ошибочка, РУ5Г стоят
Можно закрыть вопрос такой штукой - http://zx-pk.ru/threads/25367-gibridnyj-elektronnyj-disk-dlya-prk-orion.html?p=880943&viewfull=1#post880943
Или ещё лучше такой - http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=881433&viewfull=1#post881433
По последнему: в разработке более упрощённый, функционально полностью аналогичный вариант на ПЗУ-логике, надеюсь в ближайшее время отмакетирую и выложу проект.
Формат графических файлов ОС DSDOS
Для поддержки всего многообразия организаций экранных областей ПРК Орион разработан универсальный формат хранения растровой графики.
Файлы в этом формате имеют расширение *.GF (альтернативный вариант - *.G).
Характеристики формата
Размер изображения: 8x1...512x256 точек;
Бит-планы: передний, задний, оба вместе;
Режимы: м/х спрайт, спрайт атрибутов цвета, монохромный (палитры №1 и №2), 4-цветный (палитры №1 и №2), 16-цветный (палитровый), 16-цветный 4-плоскостной (в разработке);
Сжатие: по алгоритму D16K™.
Алгоритм сжатия D16K™
Основан на кодировании часто встречающихся в графике последовательностей одинаковых байтов в виде: "счётчик количества, значение байта".
В отличие от похожего алгоритма сжатия в популярных форматах *.PC и *.4C, в D16K™ применена более гибкая адаптация к длине последовательностей, что позволяет эффективнее сжимать данные. Например, полностью однородный фон заднего плана экрана размером 512x256 сожмётся всего в три байта.
Скорость отработки алгоритма не хуже вышеупомянутых "классических", объём кода немного больше.
Сжатая информация представляют собой последовательность конструкций вида: "идентификатор/счётчик - данные". Данные представляют собой либо последовательность различающихся байтов, либо значение повторяющегося байта. Если последовательность короче 64-х байт, то идентификатор (2 бита) и счётчик (6 бит) кодируются одним байтом, если длина последовательности 64...16384 байта, то они кодируются двумя байтами: первый содержит идентификатор (2 бита) и старший байт счётчика (6 бит), а второй содержит младший байт счётчика (8 бит).
Для удобства (оптимизации по скорости) распаковки, содержимое первого байта конструкции кодируется следующим образом: биты D7..D2 содержат соответствующее значение счётчика, бит D1 кодирует длину последовательности (0 - 1..63, 1 - 64..16384), бит D0 кодирует вид последовательности (0 - разные, 1 - одинаковые).
Окончание данных алгоритм упаковки/распаковки вычисляет в процессе работы, исходя из данных о размерах картинки.
Структура данных файлов формата *.GF
Offset - DATA
__________________________________________________ ___________
0000h - признак формата = FBh (1 байт)
0001h - видеорежим (1 байт)
0002h - высота картинки в пикселях (1 байт)
0003h - ширина картинки в байтах (1 байт)
0004h - данные изображения, сжатые по алгоритму D16K™ (N байт)
__________________________________________________ ___________
Видеорежимы
00h - монохромный, палитра №1, данные содержат только передний план;
01h - монохромный, палитра №2, данные содержат только передний план;
02h - монохромный спрайт, видеорежим не определён, данные содержат только передний план;
03h - спрайт атрибутов цвета, видеорежим не определён, данные содержат только задний план;
04h - 4-цветный, палитра №1, данные содержат передний и задний планы;
05h - 4-цветный, палитра №2, данные содержат передний и задний планы;
06h - 16-цветный палитровый, данные содержат передний и задний планы;
07h - зарезервирован (пока аналогично режиму 06h);
08h - 16-цветный 4-плоскостной (мультикарта Орион-ПРО).
На будущее заложена возможность расширения: старшие два бита видеорежима зарезервированы под кодирование алгоритма сжатия, значения D7=D6=0 кодируют сжатие по алгоритму D16K™.
Данные изображения
Видеорежимы 04..07h содержат два бит-плана изображения, в этом случае сначала идут данные переднего плана, а за ними данные заднего плана. Изображение кодируется сверху-вниз, слева-направо.
Поддержка
В настоящий момент написана утилита просмотра графических файлов во всех популярных форматах (опубликую позже), поддерживающая новый формат *.GF.
Традиционно в SDK DSDOS будет включена библиотека работы с данным форматом.
Если повторяется менее 64-х одинаковых байтов, то...
Да, удачная идея компрессии графики, т.к действительно в реальных картинках цепочки повторов не длинны. Только логичнее под счётчик брать биты D0...D5, а биты D6, D7 использовать как служебные. И это ускорит. Потому-что бит D7 проверяется проще, к тому же в цепочках длиннее 64-х байт эти 6 битов, являющиеся в этом случае старшим байтом длины, приходится сдвигать на 2 позиции.
barsik, изначально так и было задумано (идентификатор в старших битах), но при программировании алгоритма выяснилось, что проще и быстрее "разматывать" именно такой "бутерброд", который сделан в финальной версии.
Помимо старшего бита D7, также нужно анализировать и предыдущий - D6, после чего оба этих бита нужно отбрасывать (обнулять) дабы получить значение счётчика. В варианте кодирования идентификатора в младших битах мы убиваем трёх зайцев: анализ каждого бита одной командой ЦПУ (ротация битов через флаг <C>) + параллельно их обнуление и после анализа биты счётчика автоматом оказываются на нужных позициях.
Пример участка кода распаковки:
XRA A ; <C>=0
MOV B,A ; [B]=0
LOOP:
CALL GetBYTE
;<C>=0
RAR
JC UnpackSame
; серия разных
;<C>=0
RAR
JNC UnpackDiff1
; серия разных 64..16384
MOV B,A
CALL GetBYTE
UnpackDiff1:
MOV C,A
UnpackDiff2:
CALL GetBYTE
MOV M,A
; адрес следующего байта на экране
CALL NextScreenADDR
RZ; конец алгоритма
UnpackDiff3:
DCX B
MOV A,B
ORA C
JNZ UnpackDiff2
JMP LOOP
UnpackSame:
; серия одинаковых
CMC; <C>=0
RAR
JNC UnpackSame1
; серия одинаковых 64..16384
MOV B,A
CALL GetBYTE
UnpackSame1:
MOV C,A
CALL GetBYTE
STA UnpackSame2+1
UnpackSame2:
MVI M,0
; адрес следующего байта на экране
CALL NextScreenADDR
RZ; конец алгоритма
UnpackSame3:
DCX B
MOV A,B
ORA C
JNZ UnpackSame2
JMP LOOP
Если была бы шапка с ссылками или хотя бы историей обновлений в первой сообщении этой темы, было бы проще ориентироваться или возможно это привлекло других орионщиков. Я например прочитав там, что данная ось работает только с КНГМД из
дальше и не интересовался. О том что новые версии работают и с другими контроллерами узнал из параллельной ветки.
Откорректировал заглавный пост - http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=634440&viewfull=1#post634440
Спасибо за рацпредложение!
Отлично, а то я уже стал сам каталог составлять из темы в word файле. Теперь все стало на много удобней.
Запустил сегодня СОМ1 порт, даже не интересно, все сразу заработало:).
Хотя подходящего кварца на 7.3728 МГц не нашлось, поставил на 7200 кГц.
Просто протестировать работу клоков, работает....
Протестировал работу с ORI - сервером.
Это просто песня какая то !!!
Одно обидно, зачем КГМД делал, от теперь и не к чему...:)
Нужно теперь делать плату ROM-RAM а то ОС постоянно ругается на отсутствие диска В:
Штатных 128 кб мало.
Что посоветуете к сборке?
Запустил сегодня СОМ1 порт, даже не интересно, все сразу заработало:)
И вправду, тоска зелёная )) никакого ORIального секаса - так не интересно :)
Хотя подходящего кварца на 7.3728 МГц не нашлось, поставил на 7200 кГц.
Просто протестировать работу клоков, работает....
По скриншоту вижу, что коннект на 14400 Бод. А разгонять до 38400 не пробовали?
Протестировал работу с ORI - сервером.
Это просто песня какая то !!!
Одно обидно, зачем КГМД делал, от теперь и не к чему...:)
Ну, это же разные песни. Сервер - это фактически эмуляция, а дискогрыз - он настоящий, тёплый ламповый ;)
Нужно теперь делать плату ROM-RAM а то ОС постоянно ругается на отсутствие диска В:
Штатных 128 кб мало.
Что посоветуете к сборке?
Нарастить родное ОЗУ Ориона я бы всё таки порекомендовал. Квазидиск самый быстрый из всех накопителей, с ним наибольший комфорт в работе.
Электронный диск (http://zx-pk.ru/threads/25367-gibridnyj-elektronnyj-disk-dlya-prk-orion.html?p=880943&viewfull=1#post880943) (ROM-RAM) простая конструкция, но скорость работы RAM-части довольно медленная из-за используемого интерфейса.
Наиболее удачный по объёму/скорости - RAM7 (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=881433&viewfull=1#post881433). Но по схемотехнике он сложный. Как писал выше, в разработке более простой вариант RAM7, но его надо будет подождать...
Тут смотрите по имеющимся в наличии наличию ЗУ и опыту сборки. Программная поддержка всех видов дисков в ОС есть.
128 кб мало. Что посоветуете к сборке?
Любой вариант, кроме глупой установки платки расширения ОЗУ этажеркой с лишними буферами.
Мне больше всего нравится вариант установки РУ5 в два этажа. Я ставил так 256 кб на десяток плат ОРИОНА. Но если есть хоть одна банка РУ7, то лучше использовать вариант М.Домарёва, когда 256 кб получаются из одной банки РУ7 и одной банки РУ5. А ещё можно применить две банки РУ7 и получить 512 кб (но сам я такого не делал).
А ещё приятный и экономичный по току вариант получается, если есть DIP статика типа 62256/w24512/w24257. Она ставится просто (также как ПЗУ, т.е адреса прямо от CPU без мультиплексоров). Я никогда не распаивал преобразователь 12 вольт (т.к сразу догадался, что дисковод он не потянет, зачем он тогда нужен?) и на месте преобразователя сверлил отверстия и ставил одну панельку под 62256 (2 штуки напаянные друг на друга). Так я самым первым (в январе 1991) получил на ОРИОНЕ 192 кб ОЗУ.
Запустил сегодня СОМ1 порт, даже не интересно, все сразу заработалоФото печатной платы интерфейса Вы выложили, а где её схема? И главный вопрос - какую программу на IBM PC использовали для обмена по последовательному интерфейсу?
barsik, схемы и ПО - всё есть в теме, нет смысла дублировать.
OrionExt
16.02.2018, 19:26
Denn, это прекрасно буржуйские микрухи для рам диска. Но это прошлый день. Отстаем. Так сказать не грубо (20лет прошло).
А не пора бы уже напрячь ВВ55 в отношении IDE?
Denn, это прекрасно буржуйские микрухи для рам диска. Но это прошлый день. Отстаем. Так сказать не грубо (20лет прошло).
А не пора бы уже напрячь ВВ55 в отношении IDE?
Ничего не понял из этих двух предложений. Конкретнее, плиз.
Фото печатной платы интерфейса Вы выложили, а где её схема? И главный вопрос - какую программу на IBM PC использовали для обмена по последовательному интерфейсу?
Схема из топика от Denn а. Я только под свои детали заточил, ну кончились у меня ЛН1 :v2_dizzy_roll:и интегрального генератора на 7.3728 нет.
Сделал генератор по классической схеме от ориона-128 только на К555ЛА3.
Преобразователь уровней TTL-USART на SOIC-16 ST232D, что было в ящике от стола.
Дешифратор старенькая К155ИД3, 1533ИД3 в узком корпусе, тоже нет.
Тестировал через терминалку Terminal.exe
https://sites.google.com/site/terminalbpp/
ПК Windows 7 максимальная SP1 CPU Intel(R) Core(TM) 3.5 ГГц 64 разрядная.
Вопрос, как переключиться на скорость 38400 Бод, вроде бы на такой скорости тестировал работу СОМ порта в терминалке.
Изменить значение [F1] Делитель: 0DH на .....
- - - Добавлено - - -
По скриншоту вижу, что коннект на 14400 Бод. А разгонять до 38400 не пробовали?
Сейчас в ORI -сервере в установках скорости СОМ порта, пробовал разные значения, конект идет только на скорости 38400 Бод.
- - - Добавлено - - -
По скриншоту вижу, что коннект на 14400 Бод. А разгонять до 38400 не пробовали?
Сейчас в ORI -сервере в установках скорости СОМ порта, пробовал разные значения, конект идет только на скорости 38400 Бод.
RD3AY, всё верно, это я затупил, на схеме же аппаратно зафиксирована скорость протокола, поэтому от настроек теста Ориона она не зависит (это настройки 580ВИ53).
Главное, что 38400 работает стабильно (при том, что кварц неточный!). Это максимум для ВВ51, и это уже приемлемая скорость для работы.
Хотел спросить, при нажатии F5 появляется окно копирования файла, так вот, у меня на белом фоне окна не видно белых надписей,
у вас фон окна свело-серое, и белые надписи видно. В монохромном режиме, все нормально.
как это можно поправить?
Предполагаю что нужно подбирать резисторы в схеме формирования полутонов на выходе формирователя видеосигнала.
Или как то еще...
Итак, в продолжение темы графики (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=950562&viewfull=1#post950562), обещанная утилита просмотра картинок, поддерживающая различные форматы файлов растровой графики ПРК "Орион" - PICVIEW$.
Утилита имеет два режима работы: консольный (режим командной строки) и т.н. WUI (оконный интерфейс). В первом варианте при вызове утилиты, в командной строке указываются параметры (имя файла или запрос справки "/?"):
http://denn.ru/8bit/orion/soft/grf/picview00.png
Во втором варианте (вызов без параметров в командной строке) открывается собственный интерфейс выбора файлов для просмотра и некоторых других параметров:
http://denn.ru/8bit/orion/soft/grf/picview01.png
Во втором варианте требуется наличие в системе установленного драйвера расширения ExtDRV версии не ниже 2.7 !
Далее будет описание оконного интерфейса.
Поддерживаются все известные файлы картинок, включая новый формат DSDOS (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=950562&viewfull=1#post950562) ( *.GF ). Применены быстрые алгоритмы распаковки и вывода изображений.
По нажатию любой клавиши, кроме [F1], , [Esc] и [F4], открывается диалог выбора файла для просмотра:
http://denn.ru/8bit/orion/soft/grf/picview02.png
В списке отображаются только файлы графических форматов, имеющиеся на текущем диске. Для выбора диска необходимо нажать соответствующую клавишу - [A]..[H].
Навигация по списку файлов стандартная для подобных диалогов в ОС DSDOS: [↑], [↓], [Home], [End], а также их сочетания с [Ctrl+]. Выбор файла для просмотра - [Enter].
Также действуют следующие клавиши:
[L] - включение/выключение отображения длины файлов;
[T] - включение/выключение отображения даты файлов;
[+] - увеличение количества отображаемых на экране файлов (max=22);
[-] - уменьшение количества отображаемых на экране файлов (min=3);
[I]Выбранные значения параметров сохраняются в конфигурационном файле (PVIEW.CF) утилиты на рабочем диске ОС DSDOS.
http://denn.ru/8bit/orion/soft/grf/picview03.png
После выбора файла производится его загрузка в буфер, а затем вывод на экран:
http://denn.ru/8bit/orion/soft/grf/picview04.png
Картинка выводится на чёрном фоне, в центре экрана (утилита автоматически рассчитывает координаты, в зависимости от размеров).
Видеорежим ПРК "Орион" устанавливается в соответствии с информацией в файле. Поддерживаются все аппаратные режимы Ориона, кроме "гашения экрана".
После успешной загрузки изображения, возможен просмотр детализации его параметров (клавиша - [I]):
http://denn.ru/8bit/orion/soft/grf/picview05.png
Выводятся:
- полное имя файла;
- размеры в пикселях;
- требуемый видеорежим (в скобках указана палитра, 1 или 2);
- используемые бит-планы: передний (FG), задний (BG) или оба вместе (FG BG).
По нажатию любой клавиши, кроме [F4] (выход в ОС), детализация убирается с экрана.
Окно детализации выводится всегда в 16-цветном режиме, в связи с этим, если картинка в 4-цветном, то на время вывода детализации она может быть искажена:
http://denn.ru/8bit/orion/soft/grf/picview06.png http://denn.ru/8bit/orion/soft/grf/picview07.png
Файлы копий экрана в формате ZX-Spectrum выводятся в 16-цветном режиме Ориона:
http://denn.ru/8bit/orion/soft/grf/picview08.png http://denn.ru/8bit/orion/soft/grf/picview09.png
Утилита автоматически выполняет приведение цветового пространства к орионовскому при выводе изображения.
Выход из программы в любой момент по клавише [F4], а из режима просмотра изображения также по клавише [Esc].
Напоследок ещё пара прекрасных картинок с "вражеской" платформы :)
http://denn.ru/8bit/orion/soft/grf/picview10.png http://denn.ru/8bit/orion/soft/grf/picview11.png
Ссылки для скачивания:
в формате ORI - http://denn.ru/8bit/orion/soft/grf/PICVIEW$.ori
архивом - http://denn.ru/8bit/orion/soft/grf/picview.rar
- - - Добавлено - - -
RD3AY, вот цвета в эмуляторе:
https://pp.userapi.com/c834104/v834104313/c3370/gz2uOB0tYNE.jpg
А вот цвета на реале:
https://pp.userapi.com/c841639/v841639313/5f0dc/cqVF6ARCRjY.jpg
Фото с реала не один-в-один как жизни, но примерно похоже. В общем, градации яркости вполне читаемые.
Думаю в Вашем случае дело в формировании видеосигнала или в устройстве отображения. Сигнал I (яркостый "цвет") корректно заведён в монитор?
А как можно завести сигнал I при подключении по SCART?
HardWareMan
20.02.2018, 10:23
А зачем?
Да читаю посты выше о некорректности отображения некоторых цветов. В моем Орионе тоже некоторые цвета отображаются некорректно, например вместо розового стабильно красный. Хотя основные цвета выглядят правильно.
Вот и подумал, что наверное нужно как-то задействовать выход яркостного сигнала.
Проверял директивой С.
ПысПыс: у меня пока задействованы R G B и Sync
HardWareMan
20.02.2018, 12:33
Ну правильно. I подмешивается к RGB на самой плате. Делая их не 2х ступенчатыми (0 - нет, 1 - есть) а 4х (0 - нет, 1 - слабый, 2 - сильнее, 3 - сильный). В спектруме подмешивание таково, что 1 шаг отсутствует (что дает возможность рисовать интенсивными цветами на черном без артефактов), из-за атрибута на целое знакоместо.
mr.Lee, сигнал "I" нужно обязательно задействовать, тогда на экране будут задуманные 16 цветов. Без него будет только 8 цветов, и цвета с кодами 8..15 будут просто дублировать цвета 0..7. Замес сигнала "I" нужно делать до SCART'а (резистивные делители и диоды).
Собственно да, только 8 и наблюдаю.
Собрал на макетке делитель, уже можно различить красный и розовый:), но нужно подобрать номиналы.
Разбираюсь потихоньку с интерфейсом IDE-устройств на Орионе. В связи с этим родилась небольшая утилита вывода ТТХ винчестера, может кому-нибудь пригодится в хозяйстве:
http://denn.ru/8bit/orion/soft/hdd/hddinfo.png
Утилита униплатформенная, традиционно поддерживаются Орион-128 и Орион-ПРО (автодетект средствами API DSDOS).
КНЖМД на Орион-128 ищется по базовому адресу F790h (DS-Card), на Орион-ПРО - 50h (карта IDE-RTC).
В случае ошибки выводится её подробная расшифровка (не безликий код, как в популярных тестах).
Ссылка для скачивания - http://denn.ru/8bit/orion/soft/hdd/hddinfo.ori - обновлена 03.03.2018 !
П.С. фото с Орион-128:
https://pp.userapi.com/c840026/v840026071/54475/6NtbqJZgP2k.jpg
Ссылки по теме:
Программирование жесткого диска (http://www.zxpress.ru/article.php?id=3075)
Описание стандарта ATA с командами (http://www.ihdd.ru/download/documentation/ATA-ATAPI-standard-1/d0791r4c_ATA-ATAPI-1.pdf)
Коды обязательных команд АТА (http://src-code.net/kody-obyazatelnyx-komand-ata/)
Немного про LBA режим (http://zx-pk.ru/threads/14634-rabota-s-hdd!!!.html?p=597849&viewfull=1#post597849)
Информация о жестких дисках (https://smarthdd.com/rus/database/)
RD3AY, вот цвета в эмуляторе:
А вот цвета на реале:
Фото с реала не один-в-один как жизни, но примерно похоже. В общем, градации яркости вполне читаемые.
Думаю в Вашем случае дело в формировании видеосигнала или в устройстве отображения. Сигнал I (яркостый "цвет") корректно заведён в монитор?
Я использую адаптер для монитора Zxkit VGA & PAL, к сожалению прошивка к нему не до конца доработана под ОРИОН, обрезает две верхние строки и ни как не реагирует на сигнал I.
Пробовал его отключать/подключать, ни чего не меняется.
Интересно, есть сейчас нормальная прошивка под этот адаптер Zxkit VGA & PAL для ОРИОНа?
С платой GBS 8200 V4.0 все работает, хотя изображение не такое четкое как с адаптером Zxkit VGA & PAL.
RD3AY, у меня такой адаптер - http://zx-pk.com/forum/viewtopic.php?f=7&t=3292
Вроде как тот же Zxkit VGA & PAL. Прошивка 2.08. Всё заработало сразу и без проблем.
Вроде как тот же Zxkit VGA & PAL. Прошивка 2.08. Всё заработало сразу и без проблем.
Ну у меня не совсем тоже самое, плата от Павла Рябцова, https://yadi.sk/i/Wla12W6L3SydaS
распаивал элементы на плату и прошивал ПЛИС сам.
Пробовал "ковырять" исходники ПЛИС, получалось сместить экран вниз, вверху видно, низ подрезался.
Грешу что у меня монитор 6х9 и на нем невозможно получить раскладку экрана от стандарта ОРИОН.
Да и с градациями цветов тоже не в порядке.
Грешу что у меня монитор 6х9 и на нем невозможно получить раскладку экрана от стандарта ОРИОН.
Это просто проверить. Подключить монитор к писи, и выставить режим 800х600@60.
Да и с градациями цветов тоже не в порядке.
С этим надо разбираться. У меня сразу всё корректно заработало, и что мне очень нарвится - все цвета очень хорошо подобраны!
Это просто проверить. Подключить монитор к писи, и выставить режим 800х600@60.
Спасибо, попробую.
С этим надо разбираться. У меня сразу всё корректно заработало, и что мне очень нарвится - все цвета очень хорошо подобраны!
У вас нет случайно прошивки для используемого Вами адаптера RGB-VGA http://zx-pk.com/forum/viewtopic.php?f=7&t=3292?
Поделитесь...
Начал разбираться с редактором, набрал и скомпилировал первый файл!!!:v2_dizzy_punk:
Все работает!!!
TEST https://yadi.sk/i/EjzKKQg-3T3HuW
- - - Добавлено - - -
https://yadi.sk/i/EjzKKQg-3T3HuW
RD3AY, прошивок у меня нет. Покупал девайс готовый - тут (http://zx-pk.com/forum/viewtopic.php?f=7&t=3292). Прошивка 2.08.
Попробуйте обратиться к автору темы по продаже.
- - - Добавлено - - -
Начал разбираться с редактором, набрал и скомпилировал первый файл!!!:v2_dizzy_punk:
Все работает!!!
Отлично, поздравляю! ;)
Сейчас благодаря новому ассму я перешёл на библиотечную модель программирования (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=936060&viewfull=1#post936060), там ещё понятнее и проще, фактически программа лепится из готовых кубиков (библиотек). В планах разработать т.н. "билдер" на базе ассемблера, это вообще будет вариант для "домохозяек" :)
По возможности буду отписываться в тематической группе ВК (https://vk.com/topic-139842174_35803795).
https://yadi.sk/i/EjzKKQg-3T3HuW
Сейчас благодаря новому ассму я перешёл на библиотечную модель программирования, там ещё понятнее и проще, фактически программа лепится из готовых кубиков (библиотек).
Да, я видел эту информацию. Хоте уже попробовать, "втянул" все файлы в образ ГМД DISK_L.ODI при помощи программы SteinBlume.exe http://era-cg.su/steinblume/
Читаю диск - в ответ "Каталог пуст"
Видимо что то делаю не так, если у Вас есть возможность, выложите одним файлом все библиотеки в образе *.ODI
Попробую записать на дискету и загрузить.
(Ох как бы сейчас пригодился СОМ1 с виртуальным диском G).
Но он у меня установлен на другой плате, а там ОЗУ всего 128 кБ.
А на эту плату еще печатку не сделал, да и детали только заказал, будут не раньше 1-2 недель.
Микросхемы MSM82C51A-2RS 9-14 банк. дн.
Микросхемы TL16C550CN 9-14 банк. дн.
Кварцы 7.372 МГц (HCMOS/TTL) 7 банк. дн.
Микросхемы MAX232N
Микросхемы MC146818AP
Микросхемы КР512ВИ1
Кварцы Кварц 7.3728 МГц HC-49U
Микросхема КР1533ИД3
Error404
05.03.2018, 20:23
https://yadi.sk/i/EjzKKQg-3T3HuW
Да, я видел эту информацию. Хоте уже попробовать, "втянул" все файлы в образ ГМД DISK_L.ODI при помощи программы SteinBlume.exe http://era-cg.su/steinblume/
Читаю диск - в ответ "Каталог пуст"
Видимо что то делаю не так, если у Вас есть возможность, выложите одним файлом все библиотеки в образе *.ODI
SteinBlume.exe записывает CP/M форматы, у DSDOS другой формат хранения файлов.
если у Вас есть возможность, выложите одним файлом все библиотеки в образе *.ODI
Без проблем. Добавил в архив SDK (http://denn.ru//8bit/orion/soft/dasm/dsdos_sdk.rar) файл sdk.odi
P.S. пока нет возможности закидывать файлы напрямую в Орион через порт, можно действительно это делать через образы дискет. А закидывать файлы в образы можно с помощью эмулятора. Правда, предварительно их придётся закинуть в эмулятор с помощью.. эмулятора СОМ-порта (http://denn.ru/8bit/emu_b2m/VSPE.zip) %))
Сборка эмулятора тут - http://denn.ru/8bit/emu_b2m/emu.rar
Там в папке "emu\Orion\ODI\" есть образ чистой отформатированной дискеты - "~empty.odi", я обычно копирую этот файл в новый целевой, затем открываю его в эмуляторе и работаю с диском "С:" как обычно на Орионе (виртуальном), в результате содержимое файла образа наполняется необходимой информацией.
Мини отчёт, вести с полей так сказать.
Наконец-то, дошли руки до жёстких дисков. Разработан оптимизированный под 8-битные реалии формат хранения данных, написана утилита форматирования диска и драйвер под ОС DSDOS.
Вариант подключения по схемотехнике от ОРИОН-ПРО (карта IDE-RTC, как я понимаю - калька с "вражеского" NEMO_IDE).
Скорость работы порадовала безумно! Файлы летают со скоростью самолёта :) Вот небольшой наколенный ролик:
https://www.youtube.com/watch?v=O20_Nf4t69Y
Пилотная версия драйвера пока не поддерживает подкаталоги, впоследствии данный функционал будет добавлен.
Утилита форматирования выполняет разметку с учётом будущего расширения функционала драйвера. Поддерживаются накопители от 16 Мб до 1 Тб! Однако нижний предел теоретический.. Дело в том, что работа с НЖМД организована строго в режиме LBA, который, судя по информации из интернетов, поддерживают только накопители от 512 Мб и выше.
Организация информации на диске следующая. Традиционно, ОС DSDOS ничего не "знает" о больших носителях и подкаталогах, она работает с текущим диском, максимальное количество файлов на котором - 255, соответственно суммарный (теоретический) объём не более 16 Мб.
В случае больших носителей вводится понятие подкаталога (диск в диске), т.о. в основном (корневом каталоге) может быть до 255 подкаталогов (на самом деле 254 из-за особенностей устройства FAT DSFS). Подкаталог представляет собой 16-мегабайтный сегмент общего пространства. Т.о. суммарно корневой каталог + 254 подкаталога займут 16 Мб х 256 = 4096 Мб = 4 Гб. Для возможности использования ещё большего пространства используется второй уровень виртуализации - каждый подкаталог также может содержать подкаталоги. Т.о. возможно использование до 4 Гб х 256 = 1024 Гб = 1 Тб дискового пространства.
В результате имеем следующее. Если объём диска менее 4 Гб, то доступен корневой каталог и некоторое кол-во (в зависимости от объёма) подкаталогов первого уровня, если объём диска ровно 4 Гб, то доступно максимальное кол-во подкаталогов - 254. Если объём диска равен 8 Гб, то доступен корневой каталог + 254 подкаталога + по одному подкаталогу второго уровня в каждом подкаталоге первого уровня. И так далее: каждые 4 Гб добавляют ещё один "слой" подкаталогов второго уровня.
Организация достаточно мудрёная, однако её поддержка использует минимум ресурсов ПРК и при этом скорость работы чрезвычайно быстрая!
Аналогично будет сделана поддержка карт SDHC в ОС DSDOS. В следующей версии ОС поддержка больших накопителей будет включена.
А Compact Flash разве не все в режиме LBA работают? А то у мня валяются парочка на 128Мб...
А Compact Flash разве не все в режиме LBA работают? А то у мня валяются парочка на 128Мб...
Не могу сказать, всё многообразие накопителей в мире не изучал. Ранее (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=952585&viewfull=1#post952585) выкладывал утилиту, которая расскажет всю правду о накопителе, в т.ч. и про поддержку LBA. Также можно "пробить" в гугле ТТХ своего диска.
Утилита форматирования проверяет факт поддержки режима LBA, и в случае её отсутствия, выдаст соответствующую ошибку.
Error404
10.03.2018, 11:19
Дело в том, что работа с НЖМД организована строго в режиме LBA, который, судя по информации из интернетов, поддерживают только накопители от 512 Мб и выше.
Врут интернетчики, еще когда начинал играть с IDE и с разбора еще были диски мелких размеров, успел пощупать несколько ноутбучных винтов середины прошлого века (2.5" но толстенькие - одни из первых выпущенных такого формфактора, я брал только ноутбучные чтобы было питание только +5В) все они были объемом от 100 до 200 Мб и все поддерживали LBA.
Аналогично будет сделана поддержка карт SDHC в ОС DSDOS. В следующей версии ОС поддержка больших накопителей будет включена.
Сразу предлагаю определиться со схемотехникой. КМК лучшим вариантом для Ориона был бы вариант схемы на ИР24(29) - максимальная возможная для Z80 скорость при затратах (в минималке) в полдюжины корпусов дешевой мелкой логики. Предлагаю вариант от PVV из соседней профильной темы. У него получился самый быстродействующий вариант (думаю, по скорости уделает IDE любой схемы) т.к. в моем варианте на ИР24 я сэкономил один корпус за счет выполнения двух IN/OUT (второй для запуска счетчика пакета), а у него запуск регистра автоматизирован и байт с SD читается за один IN/OUT. Единственно, я бы добавил узел предустановки обеспечивающий пакеты не кратные 8 (как в моей схеме), но это уже детали к списку TODO.
- - - Добавлено - - -
Мини отчёт, вести с полей так сказать.
Вариант подключения по схемотехнике от ОРИОН-ПРО (карта IDE-RTC, как я понимаю - калька с "вражеского" NEMO_IDE).
Планируешь ли добавить вариант для схемы на ВВ55 (http://zx-pk.ru/threads/25327-periferiya-quot-orionpro-quot.html?p=842650&viewfull=1#post842650)? Вариант от ПРО хотя и побыстрее, но он проблемный (у меня на нем запустилось куда меньшее количество приводов чем на ВВ55), а схема с ВВ55 есть "искаропки" на всех реализациях Ревизии-512, да и ручками паяется за вечер (чего там паять - разъем IDC40 и одна ЛН1).
Тем более что драйвер тоже уже есть (например в варианте для Z80 (https://github.com/serge-404/AltairDOS/blob/master/BIOSIDE.MAC), думаю что тип проца не проблема).
- - - Добавлено - - -
В итоге я свой ПРО переделал под схему с ВВ55, прямо на ВВ55 на материнской плате (бывший порт принтера и конфигурации, конфиг DIP теперь у меня читается с АП6 - в версии 3.20 для этого есть слепыши под ВВ55). :)
Сразу предлагаю определиться со схемотехникой. КМК лучшим вариантом для Ориона был бы вариант схемы на ИР24(29) - максимальная возможная для Z80 скорость при затратах (в минималке) в полдюжины корпусов дешевой мелкой логики.
Насчёт ПРО пока не знаю. Если будет готовое работающее и быстрое решение, то вполне можно поддержать его.
На О-128 уже разработана схемотехника аппаратного контроллера SDHC, и даже сделан опытный образец, осталось дело за программной поддержкой (после того, как до конца разберусь с НЖМД, сразу возьмусь за карты). Если контроллер покажет рекордную скорость обмена, тогда имеет смысл ориентироваться на него, имхо. Если чудо не случится, тогда будем ориентироваться на схемотехнически простое решение.
Предлагаю вариант от PVV из соседней профильной темы. У него получился самый быстродействующий вариант (думаю, по скорости уделает IDE любой схемы)
Если будет готовая схемотехника для ПРО, то можно попробовать спаять. В любом случае, без железки отлаживать ПО невозможно.
Единственно, я бы добавил узел предустановки обеспечивающий пакеты не кратные 8 (как в моей схеме), но это уже детали к списку TODO.
В своём ПО я использую два вида чтения сектора: целосекторное (512 байт) и побайтное. Запись всегда целосекторная. Это связано с особенностью работы НЖМД: он всегда читает целый сектор в свой буфер, а выдавать содержимое буфера хосту может как угодно. Т.о. для экономии времени читается только нужное кол-во данных (N целых секторов "оптом" + некратный хвост). Запись неполного сектора, к сожалению, физически невозможна, поэтому пишем всегда N секторов, с округлением в большую сторону ((
Т.е. требуется возможность чтения кратно одному байту.
Планируешь ли добавить вариант для схемы на ВВ55 (http://zx-pk.ru/threads/25327-periferiya-quot-orionpro-quot.html?p=842650&viewfull=1#post842650)?
Если останется место в финальной версии драйвера (после добавления поддержки подкаталогов), то можно сделать.
Вариант от ПРО хотя и побыстрее, но он проблемный (у меня на нем запустилось куда меньшее количество приводов чем на ВВ55)
У меня весь зоопарк имеющихся винтов прекрасно работает с ПРОшной "нэмой". Были какие-то странные проблемы с тестами из интернетов (типа не работали механические "винты" на длинных шлейфах), но в итоге я изучил оригинальную документацию по протоколу АТА, согласно "учебникам" написал свои п/п работы с IDE-устройствами, и все винты и шлейфы любой длины заработали без каких-либо проблем.
схема с ВВ55 есть "искаропки" на всех реализациях Ревизии-512, да и ручками паяется за вечер (чего там паять - разъем IDC40 и одна ЛН1).
На рев.512 я запаял насмерть ВВ55, до ЛН1 мне уже не добраться ))
Вроде в эмуле b2m есть поддержка КНГМД на ВВ55+ЛН1, как-нибудь поковыряю этот вариант. В любом случае, нужна аппаратная часть для отладки ПО.
В итоге я свой ПРО переделал под схему с ВВ55, прямо на ВВ55 на материнской плате (бывший порт принтера и конфигурации, конфиг DIP теперь у меня читается с АП6 - в версии 3.20 для этого есть слепыши под ВВ55). :)
На 10 МГц она тоже стабильно работает?
Насколько проигрывает по скорости "нэме" ?
Error404
10.03.2018, 16:55
Насчёт ПРО пока не знаю. Если будет готовое работающее и быстрое решение, то вполне можно поддержать его.
На О-128 уже разработана схемотехника аппаратного контроллера SDHC, и даже сделан опытный образец, осталось дело за программной поддержкой (после того, как до конца разберусь с НЖМД, сразу возьмусь за карты). Если контроллер покажет рекордную скорость обмена, тогда имеет смысл ориентироваться на него, имхо. Если чудо не случится, тогда будем ориентироваться на схемотехнически простое решение.
Если будет готовая схемотехника для ПРО, то можно попробовать спаять. В любом случае, без железки отлаживать ПО невозможно.
В своём ПО я использую два вида чтения сектора: целосекторное (512 байт) и побайтное. Запись всегда целосекторная. Это связано с особенностью работы НЖМД: он всегда читает целый сектор в свой буфер, а выдавать содержимое буфера хосту может как угодно. Т.о. для экономии времени читается только нужное кол-во данных (N целых секторов "оптом" + некратный хвост). Запись неполного сектора, к сожалению, физически невозможна, поэтому пишем всегда N секторов, с округлением в большую сторону ((
Т.е. требуется возможность чтения кратно одному байту.
Схемотехника у нас с PVV в виде платы подключающейся к ШД/ШУ любого 8080/Z80 компа, только селект требуемого порта определить. Готовой платы для ПРО конечно нет.
И процессор Ориона там работает с SD с той же скоростью, с какой он работает с памятью (или портами), и при этом следующий байт всегда готов (т.е. тупо цикл "читай да клади в буфер" из трех опкодов). Поэтому на "сырых" секторах (т.е. чтении/записи без ньюансов обработки) контроллер SD на внешнем микроконтроллере может быть быстрее только если он кладет сектор в память Ориона через DMA, во всех других случаях скорость внешнего контроллера будет такая же, а всего вероятнее она будет меньше, т.к. не думаю, что 10-МГц Z80 удастся так подружить с внешним контроллером, чтобы внешний был всегда готов для очередного обращения Z80, кроме того наверное внешнему нужно время на чтобы после получения номера сектора этот сектор прочитать (а схеме на регистре - нет), вряд ли он будет успевать между двумя соседними обращениями Z80 (4 такта) еще на SD лазать? Также, есть тема с мультисекторным чтением (когда "одной командой" а не посекторно можно прочитать с SD-карты хоть сотню секторов начиная с какого-то, а внешнему контроллеру такой объем просто негде буферизировать, да и если поставить дорогой контроллер с сотнями килобайт ОЗУ, то задержка хоста на предварительное чтение {там же не сквозной канал прямого доступа к SD} большого блока уже станет сильно заметной в сравнении с задержкой которую внешний дает при подсасывании одного очередного сектора).
У меня весь зоопарк имеющихся винтов прекрасно работает с ПРОшной "нэмой". Были какие-то странные проблемы с тестами из интернетов (типа не работали механические "винты" на длинных шлейфах), но в итоге я изучил оригинальную документацию по протоколу АТА, согласно "учебникам" написал свои п/п работы с IDE-устройствами, и все винты и шлейфы любой длины заработали без каких-либо проблем.
Если попадутся ошибки в моей реализации, телеграфируй. :)
Исходники уж не прошу.
На 10 МГц она тоже стабильно работает?
Насколько проигрывает по скорости "нэме" ?
Работает нормально на обоих частотах. Там у меня так получалось: те экземпляры приводов что работали в данной из схем (ПРО/ВВ55) работали (или не работали) на любой частоте проца. Поэтому у меня даже мыслю была убрать такты WAIT что делает ПРО при обращении к портам (типа ускорить работу с IDE). Хотя как по мне, скорости и так вполне хватает даже для CP/M (активно пользующей носитель).
Те приводы что работали в схеме ВВ55 на ПРО тоже работали все, а вот наоборот нет. Но тут я должен заметить, что именно HDD (т.е. привод с блинами и магнитными головками) я проверял только один (других нет, т.к. не планирую ими пользоваться ввиду меньшей удобности носителя), а вот CF попробовал до десятка от разных производителей и адаптеров CF->IDE четыре штуки разных.
При том, я пробовал и код написанный авторами ПРО (их загрузчик с НДД стартующий из ПЗУ, он урезанный по части команд АТА, я уже не помню точно в чем, помню только что мне не понравилось как там написано) и мой код (который отчасти тоже подсмотренный и Инете), приводы работали или не работали одинаково.
- - - Добавлено - - -
По скорости вариант ПРО с ВВ55 я не мерял, но если заглянуть в код, то вариант с ВВ55 думаю раза в два-три медленнее.
АлександрПП
15.03.2018, 12:55
Возник вопрос.
Возможна ли работа с ORI-сервером на "Орион-Про" через "прошную" плату COM-портов?
Вроде порты определяются, выделяется диск "G". На РС запускаю oriserv.exe, но связь не устанавливается.
DSDOS сборки 3.87. Как я понимаю, link.exe на "Орионе" в этой сборке отсутствует, вернее запускается с загрузкой ОС. Верно?
Прежние версии ОС не скачать, т.к. выходит сообщение, что сайт на реконструкции.
Возможна ли работа с ORI-сервером на "Орион-Про" через "прошную" плату COM-портов?
Да, конечно.
Вроде порты определяются, выделяется диск "G".
Прекрасно. Все шансы на успех есть! :)
На РС запускаю oriserv.exe, но связь не устанавливается.
Порты, собранные по родной схемотехнике, ОС настраивает на скорость 38400 Бод (8-N-1). Не самые древние ВВ51А должны работать нормально.
Аналогичные настройки порта должны быть и на PC (конкретно в oriserv.exe). Ещё в настройках порта на сервере нужно правильно выставить контроль протокола ("hardware" или "none" - в зависимости от аппаратной реализации соединения). Само собой должен быть аппаратный линк между портами Ориона и PC (нуль-модемным кабелем), порты должны быть исправны.
В сборках ОС есть тесты COM-портов (если нет в сборке, то можно взять тут (http://denn.ru/8bit/orion/soft/test/tests@pro.odi)), со стороны PC можно использовать эту утилиту (http://denn.ru/8bit/oriserv/com-test.exe). Т.о. можно наглядно проверить соединение.
Как я понимаю, link.exe на "Орионе" в этой сборке отсутствует, вернее запускается с загрузкой ОС. Верно?
link$ уже давно не используется в виду неактуальности, поэтому в сборки и не включается. Но работать он по-прежнему может, разумеется.
При загрузке ОС устанавливается не link, а драйвер поддержки более продвинутого протокола файлообмена.
Пробная пилотная версия ОС 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
Утилита запрашивает дополнительное подтверждение действия, после чего выполняет форматирование. Во время процесса на экран выводится счётчик. По окончании, в случае успеха выводится кол-во доступных директорий, а в системе будет активирован соответствующий диск.
Поддержка подкаталогов (папок) была описана ранее (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=893089&viewfull=1#post893089), тут всё практически аналогично виртуальному диску.
Как показывает практика, различные варианты накопителей и их сочетаний имеют свои особенности, и вообще HDD довольно капризные (или схемотехника контроллера платы IDE-RTC?), если будут выявлены баги, будем устранять по мере поступления. Для работы двух Фуджиков мне пришлось повоевать (http://zx-pk.ru/threads/28951-programmnaya-podderzhka-dvukh-ide-ustrojstv-na-odnom-shlejfe-(-).html), не исключено, что с другими девайсами могут всплыть "сюрпризы".
Немного скриншотов с реала:
https://pp.userapi.com/c845221/v845221612/fa71/dcU7v_F8CYM.jpg
https://pp.userapi.com/c845419/v845419612/fc13/irPYZ3KwvrY.jpg
https://sun9-2.userapi.com/c824204/v824204612/f8a27/d-Yvh9x9AjA.jpg
https://pp.userapi.com/c846020/v846020612/aff5/Mr5CMbFcMkE.jpg
Error404
25.03.2018, 22:18
Какая схема партиций HDD используется?
Если MBR (чего хотелось бы) то предлагаю портануть еще SDOS от PVV/b2m (в качестве поддержки копирования с FAT16-партиций). Это удобно если например используется CF, который можно оперативно вынуть и на РС в кардридере на разделе с FAT16 работать с общими файлами Ориона.
- - - Добавлено - - -
Исходники тут:
http://www.nedopc.org/forum/viewtopic.php?f=71&t=9407&start=240#p143547
Там только обращение за секторами FAT16 партиции SD-карт заменить на обращение за секторами соответствующей FAT16 партиции IDE у тебя.
Какая схема партиций HDD используется?
Проприетарная :) Суть описывал чуть ранее здесь (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=953639&viewfull=1#post953639). Основная цель - "ехать".
Если MBR (чего хотелось бы) то...
Натягивать писишные дела смысла не вижу. Масштабы и задачи иные.
...предлагаю портануть еще SDOS от PVV/b2m (в качестве поддержки копирования с FAT16-партиций).
SDOS - это тоже какой-то свой формат хранения файлов?
Это удобно если например используется CF, который можно оперативно вынуть и на РС в кардридере на разделе с FAT16 работать с общими файлами Ориона.
В случае нужды файлообмена с писи, концепт DSDOS предлагает вариант через RS-232. Без механической переброски носителя.
Error404
25.03.2018, 23:24
Проприетарная :) Суть описывал чуть ранее здесь (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=953639&viewfull=1#post953639). Основная цель - "ехать".
Натягивать писишные дела смысла не вижу. Масштабы и задачи иные.
Но это же не сложно, а удобство использования возрастет в разы. Просто добавить MBR (первый сектор, достаточно только 4х primary разделов хранящихся в нем) и просто хранить все проприетарные дела с неким смещением указаным в таблице разделов и в процедурах доступа это смещение просто приплюсовывать (можно делать контроль границ раздела, но это не обязательно). На одном и том же диске можно будет хранить DSDOS, CPM, UZIX и MSDOS. :) Кому не надо например UZIX, запишут вместо него ORDOS6 при том не трогая DSDOS, CPM и MSDOS.
SDOS - это тоже какой-то свой формат хранения файлов?
В случае нужды файлообмена с писи, концепт DSDOS предлагает вариант через RS-232. Без механической переброски носителя.
Не, SDOS просто простая утилита для чтения\записи на стандартные тома FAT16. Просто чтобы унифицировать (ну и пока нет чего покруче). Она кстати уже из коробки есть в виде для Ориона для Ордос, но для SD. А что до RS-232, даже когда у нас кроме него будет и WIFI, формат ностеля это же совсем другое, зачем себя в этом ограничивать если это стоит совсем мало усилий (да и общепринято)?
Но это же не сложно, а удобство использования возрастет в разы. Просто добавить MBR (первый сектор, достаточно только 4х primary разделов хранящихся в нем) и просто хранить все проприетарные дела с неким смещением указаным в таблице разделов и в процедурах доступа это смещение просто приплюсовывать (можно делать контроль границ раздела, но это не обязательно).
По любому нужен доп. код расшифровки MBR, а также доп. изощрённость кода по расчёту свободного места с учётом других разделов.
На одном и том же диске можно будет хранить DSDOS, CPM, UZIX и MSDOS. :) Кому не надо например UZIX, запишут вместо него ORDOS6 при том не трогая DSDOS, CPM и MSDOS.
А для чего MSDOS там? Неужели у кого-то есть на неё планы применительно к Ориону? ))
А что до RS-232, даже когда у нас кроме него будет и WIFI, формат ностеля это же совсем другое, зачем себя в этом ограничивать если это стоит совсем мало усилий (да и общепринято)?
Я всё же рассматриваю Орион как самостоятельный и самодостаточный цифровой домен. Захотелось использовать для хранения данных винчестер - пожалуйста, вот есть решение. Задачи унификации не стояло, винчестер это не переносное устройство.
SD-карта - переносное, но в случае нужды её обработки на писи, проще написать писишный софт, чем заставлять Орион тратить ресурсы на поддержку инородных форматов. Орионовские файлы всё равно имеют формат, отличный от писишного.
Дмитрий2012
26.03.2018, 18:41
Немного скриншотов с реала:
Скрытый текст
Почему у дисков с разной емкостью утилитка показывает одинаковое количесво цилиндров, головок и секторов?
Не могу создать больше 5 подкаталогов, это баг или пока преднамеренно сделано такое ограничение?
Почему у дисков с разной емкостью утилитка показывает одинаковое количесво цилиндров, головок и секторов?
Так нам дано свыше :)
"Система координат" CHS (Цилиндр-Головка-Сектор) позволяет адресовать только до 504 8064 Мб. В нашем случае объёмы дисков больше, поэтому значения CHS "упёрты в потолок". Подробнее - тут (https://ru.wikipedia.org/wiki/Объём_жёсткого_диска#504_Мб).
Эти данные актуальны для античных накопителей, и выводятся утилитой просто так - для информации.
В ОС DSDOS используется LBA-адресация, так что на цилиндры/головки можно не смотреть.
П.С. Дим, покажи ТТХ своего "винта", который испытываешь с Орионом. Интересно =)
А также, интересна стабильность работы (в т.ч. детекта при закгрузке), и микросхемы каких серий в КНЖМД?
Не могу создать больше 5 подкаталогов, это баг или пока преднамеренно сделано такое ограничение?
Это фича, о которой должна была честно предупредить утилита форматирования в финале. Максимально допустимое количество папок и подпапок зависит от объёма диска, подробности расписывал ранее - тут (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=953639&viewfull=1#post953639).
Дмитрий2012
26.03.2018, 20:52
Так нам дано свыше
Как все сложно то ))
Это фича, о которой должна была честно предупредить утилита форматирования в финале. Максимально допустимое количество папок и подпапок зависит от объёма диска, подробности расписывал ранее - тут.
А, вон оно как ... не внимательно прочитал сообщение. Проще говоря каждая папка это как бы отдельный диск на 16мб?
Ладно, поставил флеш диск на 1Гбт, теперь на много интереснее стало. Уже могу создать 59 "папок" :)
Теперь вопрос... как удалить созданную "папку" ? у меня ничего не получается...
И еще, не могу создать в папке еще одну "папку". Выскакивает ошибка: "02 Переполнение каталога" Может чего не так понял. Можно ли в данной версии ос создавать "папку" в "папке" ?
П.С. Дим, покажи ТТХ своего "винта", который испытываешь с Орионом. Интересно =)
А также, интересна стабильность работы (в т.ч. детекта при закгрузке), и микросхемы каких серий в КНЖМД?
Я пользуюсь CF картами, винтов у меня нет, да и громоздки они. Пока проблем в работе с CF картами не обнаружил. в КНЖМД все микрухи серии КР1533
а что происходит с часиками в этой версии DSDOS? раньше я такого не замечал. И в других ОС вроде все работает нормально. Это у меня так работают часики или еще у кого-нибудь?
https://youtu.be/uTueyU_-SIM
ps: Не реклама. На барахолке продают не дорого б/у CF карты от 64мб до 1Гбт. Мною в работе с DSDOS проверены карты Sandisk на 512мб, на 1Гбт Cisco и Stec, все отлично работают в прошечном IDE-контроллере. Можно смело брать :)
Error404
26.03.2018, 21:29
А для чего MSDOS там? Неужели у кого-то есть на неё планы применительно к Ориону? ))
Для красного словца. :) В данном случае подразумевался раздел с FAT16. Но могла бы быть наверное и МSХ-DOS какая-нибудь или SymbOS если бы кто портировал, они же на FAT работают и разработаны для Z80.
А, вон оно как ... не внимательно прочитал сообщение. Проще говоря каждая папка это как бы отдельный диск на 16мб?
Ладно, поставил флеш диск на 1Гбт, теперь на много интереснее стало. Уже могу создать 59 "папок" :)
...
И еще, не могу создать в папке еще одну "папку". Выскакивает ошибка: "02 Переполнение каталога" Может чего не так понял. Можно ли в данной версии ос создавать "папку" в "папке" ?
В данной версии никаких "демонстрационных" ограничений нет. Только "физиология" :)
"Переполнение" значит, что больше нельзя. Физически нельзя. От слова - совсем :) Нету соответствующей области на диске.
Папку в папке можно начиная от 8 Гб и выше - см. объяснение по той же ссылке (http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=953639&viewfull=1#post953639).
Теперь вопрос... как удалить созданную "папку" ? у меня ничего не получается...
В Нортоне такая функция забанена из-за вирт. диска - там низя удалять папки (я не разобрался как это делать на писи из С++). Через командную строку можно ;)
На эту тему два момента!
1) Ни в коем случае нельзя удалять возвратную папку "..";
2) Содержимое удалённой папки не удаляется (позже может быть сюрприз :)).
Папка ".." позволяет перейти в каталог уровнем выше. Если её удалить (помним, что папки это специальные файлы, и ОС про папки ничего не "знает"), то вернуться будет невозможно - придётся форматировать диск заново! По-умолчанию, у ".." установлен атрибут защиты от удаления, но для пытливого русского человека это не является помехой ))
Папка, а точнее мета-файл перехода к каталогу (подкаталогу) является указателем на соответствующую 16Мб-область диска. Поэтому удаление папки лишь удаляет файл-указатель, при этом содержимое диска (подкаталога) остаётся нетронутым. При создании очередной папки, указателю будет присвоен номер первой свободной области, и если это будет ранее удалённая папка, то в новой папке окажется её содержимое. Авто-вычищение содержимого при создании новой папки я делать не стал, пусть будет фичей (а когда-нибудь кому-то может сэкономит пучок нервных клеток :)).
Я пользуюсь CF картами, винтов у меня нет, да и громоздки они. Пока проблем в работе с CF картами не обнаружил.
Мелковатые они по объёму.. а в остальном конечно же одни плюсы.
в КНЖМД все микрухи серии КР1533
Я слышал звон, что у народа проблемы с 1533, типа работоспособны только 555 (в причинных узлах). Но проблемы вроде тока с "механикой", насчёт флэш-эмуляторов х/з.
а что происходит с часиками в этой версии DSDOS? раньше я такого не замечал. И в других ОС вроде все работает нормально. Это у меня так работают часики или еще у кого-нибудь?
https://youtu.be/uTueyU_-SIM
В каментах под видео я отписался. У меня были приколы с конкретным экземпляром ВИ1 (из ЧипДипа). Причём глючил переход на конкретной дате и только в конкретном месяце! Замена на исправную решила вопрос.
Но сперва я бы попробовал просто переинициализировать эту вонючку утилитой TIME$, она полностью программирует заново все настройки RTC.
@ Дмитрий2012 - вот нашёл видео с тем самым глюком бракованной ВИ1:
https://www.youtube.com/watch?v=2WyxwtqX868
Сабж был куплен в ЧиД и датировался 2000-ым г.в.. Видимо, своеобразная Y2k-problem :)
Дмитрий2012
27.03.2018, 20:39
Но сперва я бы попробовал просто переинициализировать эту вонючку утилитой TIME$, она полностью программирует заново все настройки RTC.
Странно все это, подобный глюк с часиками я наблюдаю только в DSDOS :v2_conf2:.
Вот видео с работой часиков в ORDOS7, никаких глюков не наблюдается. Время читаю из ВИ1.
https://youtu.be/_CupIwdsY8s
Дмитрий2012, как ты понимаешь, DSDOS часы "за руку" не переводит, более того сама ОС вообще никак не работает со временем, его показания ПО (например, оболочка) просто забирают из регистров микросхемы (вычитывают через порт), и изменением показаний чип занимается самостоятельно внутри себя. Так что ОС тут совершенно ни при чём.
Касательно того, что глюк данной микросхемы не проявляется на другом ПО, могу предположить, что другое ПО использует исчисление в другой арифметике, и в этом режиме брак не проявляется. Как известно, ВИ1 умеет оперировать в двоичной и в двоично-десятичной арифметике, я пользуюсь первой, а вторая, как я понимаю, более популярная (т.к. используется на Спектрумах), вероятно в ОРДОС7 не стали изобретать велосипед и скопипастили соотв. иноземное ПО, попутно прихватив BCD-режим работы.
П.С. на моём экземпляре ВИ1 твой глюк не высекается, дело точно в глючном чипе.
https://www.youtube.com/watch?v=F9Tebk4cKJE
Sancho45
06.06.2018, 08:28
Планируется ли в данной оси работа с портами pFC,pFD,pFE c z80 ? На плате Рябцова, страницы rom-диска переключаются через pFE, и тд.
Sancho45, что делают порты pFC, pFD (требуется ли ОС что-то знать про них) ?
По поводу переключения страниц ПЗУ через порт pFE. ЕМНИП, данный порт не имеет обратки, т.е. автодетектом его не отловить. Можно попробовать "кидать" в него параллельно, если это не помешает работе стандартного Ориона.
К сожалению, таковой железки у меня нет, проверить не на чем. Если найдутся желающие потестировать, попробую сделать.
- - - Добавлено - - -
Информацию по pFD нашёл: "pFD это AY8910". Эти знания нужны софту, который обслуживает AY, ОС данную аппаратуру напрямую не использует.
OrionExt
06.06.2018, 13:26
Эх, я бы уже переступил через нехачуку каждого в отдельности. И сделал бы раздел (тему) по портам и стандартам. И если кто влево 2 два шага, расстрел на месте:v2_dizzy_tired2:
Раз так уж сложилилось (две калеки + толпа сочувствующий), что весь движняк тут.
Ну, это просто так (глас вопиющего в пустыне из толпы), можно не обращать внимания:)
OrionExt, я традиционно ничего не понял из предложений, написанных выше ((
http://i2.tabor.ru/feed/2016-05-30/13410717/58893_760x500.jpg
OrionExt
06.06.2018, 14:08
А зачем сразу комментировать? Раз не понял. Недельку в метро (машине) обдумай и скажи чего в тему сообщения.
А так в сообщении есть 3-й абзац, на всякий случай :)
Sancho45
06.06.2018, 14:52
По поводу переключения страниц ПЗУ через порт pFE. ЕМНИП, данный порт не имеет обратки, т.е. автодетектом его не отловить.
Можно в конфигураторе или параллельно.
К сожалению, таковой железки у меня нет, проверить не на чем. Если найдутся желающие потестировать, попробую сделать.
Готов потестить в свободное время.
Ps На плате Рябцова, в сборках на 128 и 256 кб(3.87) шелл не запустить пока страницу не переключишь. 512 и 1024 не пробовал
OrionExt
06.06.2018, 15:06
Порт pFE – давно в теме (но не признан в DSDOS) и стандарт от Error404. Почему теперь мне не понятно?
Что так щимет? Не понятно.
Чтобы устранить дальнейшее словоблудство, процитирую себя
Эх, я бы уже переступил через нехачуку каждого в отдельности. И сделал бы раздел (тему) по портам и стандартам.
Забыл :) И если кто влево 2 два шага, расстрел на месте.
Творчество это прекрасно, но только в рамках стандарта. Которого пока нет. Даже от ведущих толкателей платформы.
История Орион-а под прессом журнала не послужила задумкам авторов в плюс.
Вышел то ли Специалист, то ли Радио86рк. Но с цветом. С экраном аж 24кБ при частоте 2.5Мгц.
Мое личное мнение. Максимум что может окучить Z80 (4uHz) - это 16кБ экрана.
Порт pFE – давно в теме (но не признан в DSDOS) и стандарт от Error404.
В какой теме? Аппаратная доработка, сделанная у полутора человек?
Мне (и, как показывает статистика, многим другим) не интересна доработка "Z80-card" вторым этажом, поэтому за неимением ничего другого, я пошёл наиболее простым путём преодоления 64К-барьера ROM-диска, требующим минимального вмешательства в оригинальную схемотехнику. Оно и поддерживается в DSDOS. Замечу, до сегодняшнего дня вопрос о поддержке pFE не поднимался, что намекает о масштабах необходимости.
Полагаю, вопрос о pFE можно закрыть. Если запись в этот порт ничего не будет портить в стандартном варианте Ориона, то в следующей версии ОС добавлю OUT 0FEH и всё.
Хуже обстоит дело с поддержкой HDD на юзер-порте. Универсализация требует напряжного увеличения кода, и самое неприятное добавляет ощутимые тормоза при загрузке ОС (попытка автодетекта в случае отсутствия HDD на F600h). Также могу возникнуть конфликтные ситуации в случае использования порта пользователя по прямому назначению. Имхо, даже в случае упрощёнки следовало бы задействовать под HDD отдельную ВВ55, включённую в область ВУ (F7xx).
Error404
06.06.2018, 19:59
Я на стандарты не претендую. :) Просто использовал селект из уже имеющихся. Можно использовать какой-то другой вместо pFE, например pFB который аппаратно есть как на плате Z80CardII, так и на стандартном Орионе с 8080 на одной из тамошних ИД4, т.е. страницы РОМ-диска под Z80 будут включаться параллельно адресам банок диспетчера по 16к что никак не помешает и в обоих случаях это будет происходить по OUT FB (только надо помнить при D7=0 у Z80 включение диспетчера, поэтому для универсальности лазить в страницы ROM-диска надо с FB.D7=1 даже в коде от 8080).
Вообще, для меня было уже тутошним (21 века) открытием что Z80 не всем нужен. В 90-х когда Орион был рабочей лошадкой это было просто очевидно - любой состоятельный парень ставил Z80 при первой же возможности: чтобы почти даром получить кучу профита, как и пересаживался с ВАЗ2101 на ВАЗ2109. Нынче конечно уже меньше смысла с каким процессором тот антиквариат, все равно его два раза в год включают - понастальгировать и один раз глянуть чего там афтар накропал за год труда.
Denn, если люди просят, что-то для совместимости придется добавить. Это я могу себе позволить отправить просителя в исходники (мол всё выложено, каждый может собрать себе порты во вкусу), а ты же не практикуешь opensource. ;)
...по OUT FB (только надо помнить при D7=0 у Z80 включение диспетчера, поэтому для универсальности лазить в страницы ROM-диска надо с FB.D7=1 даже в коде от 8080).
А монитор под Z80 при старте инициализирует D7=1 или по-умолчанию на Орионе с Z80-card диспетчер оказывается включенный?
Denn, если люди просят, что-то для совместимости придется добавить.
Это без проблем.
Error404
07.06.2018, 16:20
А монитор под Z80 при старте инициализирует D7=1 или по-умолчанию на Орионе с Z80-card диспетчер оказывается включенный?
Мониторы версий Z80 при старте инициализируют pFB в значение 80h. Если используется Монитор никак не инициализирущий порт FB (например авторские), то это тоже не страшно: аппаратно на платке Z80Card-II этот порт состоит из ТМ9 (биты 0,1,2,3,5,6 по /res инициализирующиеся в 0 - "всё выключено") и половинки ТМ2 (тот самый бит D7) по /res инициализирующейся в 1 входом set (т.е. в состояние "диспетчер выключен").
Stanislav1972
16.07.2018, 23:45
-
Давно хотел оценить количественно скорость работы накопителей в ОС DSDOS, и наконец-то, что называется, дошли руки.
Для удобства была создана утилита генерации тестовых файлов:
Утилита FILEGEN$ позволяет создавать на целевом диске произвольное количество тестовых файлов определённого размера. Также возможно групповое удаление тестовых файлов, созданных утилитой ранее.
Параметры генерации задаются с помощью командной строки. Краткая справка выводится при запуске утилиты без параметров:
http://denn.ru/8bit/orion/soft/dsdos/filegen.png
Подробности в сопроводительном текстовом файле помощи - FLGEN.HP
Измерения проводились под ОС версии 3.88, на двух платформах:
1) "ОРИОН-128 рев.512" (ЦП ВМ80А, ОЗУ 512Кб, квазидиск 360Кб, НЖМД через переходник на порт пользователя #F6, виртуальный диск на 16C550 @ 115200 Бод);
2) "ОРИОН-ПРО v3.10F" (ЦП Z80B*, ОЗУ 512Кб, квазидиск 360Кб, НЖМД по схемотехнике NEMO-IDE, виртуальный диск на 82C51A @ 115200 Бод).
__________________________________________________ ___________________________________
* В двух программно-аппаратных конфигурациях: CLK=2,5МГц и CLK=10МГц.
Цели исследования:
- оценка реальной (боевой) скорости работы с файлами;
- сравнение скоростей основных быстрых накопителей;
- оценка вклада быстродействия ЦП, интерфейса накопителя, алгоритмов работы ОС.
Полный протокол измерений собран в этой таблице (http://denn.ru/8bit/orion/soft/dsdos/foper_spd_dsdos38.xls).
Измерения на ОРИОН-ПРО в конфигурации "CLK=2,5МГц" производились фактически для сравнения двух типов КНЖМД: NEMO_IDE vs. ВВ55_IDE-затычка.
Все виды тестов проводились в двух вариантах:
1) Обработка 253-х тестовых файлов, каждый размером 512 байт;
2) Обработка 4-х тестовых файлов, каждый размером 32768 байт;
В обоих случаях общий объём полезной информации примерно одинаковый - около 128 Кб. В первом случае добавляется (ощутимый) вклад операций с файловой системой (далее - ФС), во втором случае им можно пренебречь - измеряется фактически чистая скорость переноса полезной информации (содержимого файлов).
Итак, результаты.
Безусловный лидер по скорости во всех видах состязаний, разумеется, квазидиск [B:]:
Запись на диск 4-х файлов по 32Кб: 2 сек / 3 сек / менее 1 сек *
Запись на диск 253-х файлов по 512 байт: 20 сек / 22 сек / 9 сек **
Чтение с диска 4-х файлов по 32Кб: 2 сек / 2 сек / менее 1 сек
Чтение с диска 253-х файлов по 512 байт: 20 сек / 20 сек / 8 сек
Удаление с диска 4-х файлов: 0 сек / 0 сек / 0 сек ***
Удаление с диска 253-х файлов: 12 сек / 13 сек / 6 сек
__________________________________________________ __________________________________________________ _____________
* замеры производились вручную с использованием секундомера, точность +/-0,5 сек.
** указаны значения для трёх конфигураций: ОРИОН-128@2,5МГц / ОРИОН-ПРО@2,5МГц / ОРИОН-128@10МГц, соответственно.
*** слишком быстро, доля секунды, вручную измерить не представляется возможным!
Характерные особенности:
- при обслуживании ФС отсутствуют операции записи/чтения каталога диска;
- скорость записи/чтения информации максимальная (определяется скоростью работы МПС);
- при записи/чтении данных используются ускоренные алгоритмы с использованием операций со стеком;
- размер кластера 256 байт.
Резюме: на ПРК с тактовой частотой 2,5 МГц чистый битрейт чтения/записи данных составляет около 64 Кб/сек,
при "нарезке" данных файлами малого объёма на первый план выходит обработка ФС (поиск файла в каталоге, поиск секторов в FAT), и скорость падает на порядок - около 6 Кб/с;
на ПРК с тактовой частотой 10 МГц (виртуально около 7 МГц, ибо вэйты при обращении к ОЗУ/ВУ) получается 128 Кб/с и 16 Кб/с, соответственно.
Из реальной практики: работаю в текстовом редакторе с большими исходниками (около 40 Кб), периодически сохраняюсь - жму Ctrl+S и тут же продолжаю печатать, т.е. пока палец перемещается к очередной клавише, комп успевает полностью перезаписать файл 40 Кб.
Второе место достаётся накопителю с IDE-интерфейсом (НЖМД, диск [C:]):
Запись на диск 4-х файлов по 32Кб: 10 сек / 3 сек / 2 сек
Запись на диск 253-х файлов по 512 байт: 3:25 сек / 1:13 сек / 31 сек
Чтение с диска 4-х файлов по 32Кб: 8 сек / 2 сек / 1 сек
Чтение с диска 253-х файлов по 512 байт: 21 сек / 19 сек / 8 сек
Удаление с диска 4-х файлов: 2 сек / 1 сек / 1 сек
Удаление с диска 253-х файлов: 2:23 сек / 57 сек / 24 сек
Характерные особенности:
- обслуживание ФС сопровождается операциями записи(каждый раз)/чтения(однократно) каталога диска + FAT (4+4=8 Кб);
- за один такт накопитель записывает/считывает два байта информации (определяется схемотехникой КНЖМД);
- при записи/чтении данных используются ускоренные алгоритмы с использованием операций со стеком;
- размер кластера 4096 байт.
Резюме: в случае применения КНЖМД по схемотехнике NEMO чистый битрейт чтения данных аналогичен квазидиску - около 64 Кб/с (@2,5МГц)!
Упрощённое подключение НЖМД через порт ВВ55 проигрывает по скорости чтения больших файлов аж в 4 раза, в случае большого кол-ва маленьких файлов битрейт аналогичен NEMO и квазидиску - около 6 Кб/с (@2,5МГц).
Чистый битрейт записи данных на NEMO примерно в 1,5 раза уступает чтению - 43 Кб/с (@2,5МГц), на ВВ55-переходнике в 5 раз - 13 Кб/с (@2,5МГц).
На ПРК с тактовой частотой 10 МГц и NEMO удаётся получить чистые 128 Кб/с (чтение) и 64 Кб/с (запись), соответственно. В случае "файлонарезки" показатели падают в 8 и в 15 раз, соответственно.
Невероятно печальные показатели на 2,5МГц-платформе с подключением НЖМД через ВВ55-переходник: многофайловая запись - 0,6 Кб/с (с NEMO в 3 раза быстрее - 1,8 Кб/с).
На третьем месте виртуальный диск [G:]:
Запись на диск 4-х файлов по 32Кб: 13 сек / 13 сек / 12 сек
Запись на диск 253-х файлов по 512 байт: 1:23 сек / 1:12 сек / 1:05 сек
Чтение с диска 4-х файлов по 32Кб: 13 сек / 12 сек / 12 сек
Чтение с диска 253-х файлов по 512 байт: 27 сек / 25 сек / 19 сек
Удаление с диска 4-х файлов: 0 сек / 0 сек / 0 сек *
Удаление с диска 253-х файлов: 58 сек / 50 сек / 50 сек
__________________________________________________ __________________________
* слишком быстро, доля секунды, вручную измерить не представляется возможным!
Характерные особенности:
- обслуживание ФС сопровождается операциями записи(каждый раз)/чтения(однократно) каталога диска (размер = кол-во файлов * 16 байт);
- линейная (бескластерная) организация хранения/передачи данных;
- скорость передачи данных определяется приемущественно скоростью работы COM-порта (тест проводился на максимальной - 115200 Бод);
Резюме: скорость многофайлового чтения на 2,5МГц-платформах приближается к таковой у НЖМД/квазидиска и составляет - 5 Кб/с.
Чистый битрейт чтения данных хуже NEMO/квазидиска в 6 раз - 11 Кб/с.
Чистый битрейт записи данных хуже НГМД (NEMO) в 4 раза - 9,8 Кб/с. Средний битрейт многофайловой записи - 1,7 Кб/с (меняется нелинейно с ростом кол-ва файлов в каталоге).
Тактовая частота ЦП практически не влияет на скорость чтения/записи файлов.
Кэширование каталога (чтение файлов).
НЖМД [C:]:
Чтение с диска 4-х файлов по 32Кб с кэшированием: 8 сек / 2 сек / 1 сек
Чтение с диска 4-х файлов по 32Кб без кэширования: 10 сек / 3 сек / 1 сек
Чтение с диска 253-х файлов по 512 байт с кэшированием: 21 сек / 19 сек / 8 сек
Чтение с диска 253-х файлов по 512 байт без кэширования: 2:16 сек / 45 сек / 19 сек
Резюме: очевидное приемущество кэширования каталога при многофайловых операциях - ускорение в 7 раз с ВВ55-переходником и в 3 раза с NEMO-IDE.
Виртуальный диск [G:]:
Чтение с диска 4-х файлов по 32Кб с кэшированием: 13 сек / 12 сек / 12 сек
Чтение с диска 4-х файлов по 32Кб без кэширования: 13 сек / 12 сек / 12 сек
Чтение с диска 253-х файлов по 512 байт с кэшированием: 27 сек / 25 сек / 19 сек
Чтение с диска 253-х файлов по 512 байт без кэширования: 2:04 сек / 1:57 сек / 1:51 сек
Резюме: также очевидное приемущество кэширования каталога при многофайловых операциях - ускорение в 5 раз.
Копирование файлов между дисками (в порядке убывания производительности).
1. НЖМД -> квазидиск:
4-х файлов по 32Кб: 10 сек / 5 сек / 2 сек
253-х файлов по 512 байт: 42 сек / 41 сек / 17 сек
Резюме: на 2,5МГц-системе с NEMO-IDE чистый битрейт около 26 Кб/с, многофайловый поток - 3 Кб/с,
увеличение такта ЦП до 10МГц увеличивает скорость примерно вдвое.
2. Квазидиск -> НЖМД:
4-х файлов по 32Кб: 13 сек / 5 сек / 2 сек
253-х файлов по 512 байт: 3:45 сек / 1:35 сек / 39 сек
Резюме: чистый битрейт аналогичен предыдущему варианту - около 26 Кб/с.
Падение скорости при многофайловой "нарезке" данных ощутимо больше: в 18 раз (против 8 раз в предыдущем),
что связано с отсутствием кэширования каталога при записи на НЖМД (на каждый записываемый файл размером 512 байт в нагрузку записывается каталог 8 Кб, и так 253 раза!).
3. Вирт. диск -> квазидиск:
4-х файлов по 32Кб: 15 сек / 14 сек / 13 сек
253-х файлов по 512 байт: 47 сек / 47 сек / 27 сек
Резюме: чистый битрейт около 9 Кб/с, многофайловый поток - 3 Кб/с
4. Квазидиск -> вирт. диск:
4-х файлов по 32Кб: 16 сек / 16 сек / 12 сек
253-х файлов по 512 байт: 1:32 сек / 1:30 сек / 1:12 сек
Резюме: чистый битрейт около 8 Кб/с, многофайловый поток - 1,4 Кб/с
"Просадка" многофайлового битрейта по сравнению с предыдущим вариантом вызвана добавлением пересылки каталога,
т.к. после записи файла в вирт.диск содержимое каталога меняется и Орион вынужден загружать каталог по-новой (в этом случае кэширование по сути не работает).
5. НЖМД -> вирт. диск:
4-х файлов по 32Кб: 23 сек / 15 сек / 13 сек
253-х файлов по 512 байт: 03:37 сек / 01:56 сек / 01:22 сек
Резюме: чистый битрейт около 9 Кб/с (NEMO-IDE) и 6 Кб/с (ВВ55-IDE).
С многофайловым потоком всё ощутимо хуже - 1,1 Кб/с и 0,6 Кб/с, соответственно.
Катастрофическое падение производительности связано с совмещением буфера каталогов дисков [C:] и [H:],
в следствие чего при обработке каждого файла производится два чтения и одна запись каталогов!
6. Вирт. диск -> НЖМД:
4-х файлов по 32Кб: 25 сек / 15 сек / 13 сек
253-х файлов по 512 байт: 7:25 сек / 3:38 сек / 02:37 сек
Резюме: чистый битрейт аналогичен предыдущему варианту - 9 Кб/с (NEMO-IDE) и 6 Кб/с (ВВ55-IDE).
С "файлонарезкой" всё ещё печальнее - 0,6 Кб/с и 0,3 Кб/с, соответственно.
В данном случае имеем самые невыгодные условия при обработке файла: чтение каталога вирт.диска (4 Кб) + чтение каталога НЖМД (8 Кб) + запись каталога НЖМД (8 Кб), итого к каждому файлу "прицеп" в 20 Кб.
https://www.katushka.top/torrents/00113429/screenshot_1.jpg
Полагаю, вопрос о pFE можно закрыть. Если запись в этот порт ничего не будет портить в стандартном варианте Ориона, то в следующей версии ОС добавлю OUT 0FEH и всё.
Случайно вспомнил про эту тему и сегодня проверил на реале (ОРИОН-128 рев.512): запись в порт #FE переключает экранные области, далее выяснил что остальные порты также имеют клоны - F8=FC, F9=FD, FA=FE, т.е. в стандартном варианте ПРК на ВМ80А дешифрация портов упрощённая, и дублировать № банки ROM-диска в #FE нельзя ((
П.С. в эмуляторе эффект не проявляется, вероятно там "дешифрация" честная.
HardWareMan
02.12.2018, 06:14
Так и есть, 20 сигнал не используется.
http://jpegshare.net/images/91/8d/918def75a6714f335e4130ea02f8f3a4.png
Sancho45
10.12.2018, 22:06
Случайно вспомнил про эту тему и сегодня проверил на реале (ОРИОН-128 рев.512): запись в порт #FE переключает экранные области, далее выяснил что остальные порты также имеют клоны - F8=FC, F9=FD, FA=FE, т.е. в стандартном варианте ПРК на ВМ80А дешифрация портов упрощённая, и дублировать № банки ROM-диска в #FE нельзя ((
П.С. в эмуляторе эффект не проявляется, вероятно там "дешифрация" честная.
ответил в соотв. теме.
Sancho45, спасибо.
Придумал обнаружение порта #FE по следующему незатейливому принципу. Выставляю адрес 0000h читаю два байта, запоминаю. Далее, пишу 01h в порт #FE и также читаю два байта с 0000h, сравниваю с запомненными. Возвращаю 00h в порт #FE. Если полное совпадение обоих байтов, значит либо порт #FE отсутствует в системе, либо воткнуто ПЗУ 64 Кб - оба варианта означают бесполезность управления банками через порт #FE, т.о. работаем с банками ROM-диска стандартно - через порт клавиатуры.
Sancho45
11.12.2018, 23:41
Если вм80, то OUT FEh будет как mov FEFEh, a
Может проц сначала задетектить или если обратно записывается 0 в порт fe, то особо можно не беспокоиться ? И какова вероятность совпадения 2-х байт в разных страницах, может там заголовок или еще чего?
- - - Добавлено - - -
В общем готов потестить, если будет релиз(как время будет, с чем проблемы, как и у многих. И нюансы всякие на новодельной плате обсудить.
Может проц сначала задетектить или если обратно записывается 0 в порт fe, то особо можно не беспокоиться ?
В моменты чтения из верхних банок на номальном Орионе будет мерцать экран, это имхо некрасиво.
Детектить проц - лишний код, к тому же возможны разные варианты натягивания Z80 на Орион-128... КМК, алгоритма, описанного выше, будет достаточно. В причинном месте кода будет "00 00", а в случае прочтения различающейся инфы при единоразовом тесте во время загрузки ОС, туда будет вставлено "D3 FE". Я уже проверил на своём ВМ80-варианте, такой быстрый тест даже не вызывает заметного моргания экрана.
В общем готов потестить, если будет релиз(как время будет, с чем проблемы, как и у многих. И нюансы всякие на новодельной плате обсудить.
Спасибо! Да, релиз в процессе, будут разные новшества, включая поддержку обоих вариантов адресации ВИ1 и полную эмуляцию ORDOS (чтоб работал весь софт, включая нагло лазающий напрямую в ОЗУ квазидиска). Надеюсь к НГ успею :)
Очень хотел релизнуть к НГ :) Но всего доделать не успел, поэтому обещанная "предновогодняя" сборка ОС DSDOS, но "альфа" v3.90a для Орион-128.
Краткий список новшеств:
► поддержка RTC на базе БИС КР512ВИ1 на уровне BIOS;
► поддержка альтернативного управления переключением банков ПЗУ ROM-диска (через порт #FE);
► поддержка двух вариантов "посадки" RTC (F76x и F7Bx);
► поддержка двух вариантов КНЖМД (через порт юзера #F6 и NEMO-IDE @F79x);
► новый код эмуляции API ОС ORDOS, полная поддержка всех векторов;
► исправлены ошибки в поддержке подкаталогов на НЖМД и SDHC;
► изменены буквы дисков: НЖМД №0 = "C:", НЖМД №1 = "D:", НГМД №0 = "F:", НГМД №1 = "H:";
► поддержка подкаталогов в оболочке для дисков C, D, G и H;
► интеграция драйвера расширения ExtDRV v2.8;
► конфигурационные файлы текстового редактора Gemini-EDIT и оболочки ОС хранятся на рабочем диске ОС;
► изменения некоторых горячих клавиш в текстовом редакторе, добавление новых комбинаций;
► в сборку включён графический редактор PENX$, который теперь прекрасно и полноценно работает!
Подробнее напишу позже, а пока традиционно:
▼▼▼ Ссылки для скачивания различных вариантов сборок ▼▼▼
Для ПРК ОРИОН-128/512:
ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s64.rar)
ПЗУ ROM-диска объёмом 128 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s128.rar)
ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s256.rar)
ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s512.rar)
ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s1024.rar)
специализированная "программерская", ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p512.rar)
специализированная "программерская", ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p1024.rar)
Для ПК ОРИОН-ПРО:
"Стандарт-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s64.rar)
"Стандарт-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s256.rar)
"Игровая-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g64.rar)
"Игровая-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g256.rar)
"Программист-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p64.rar)
"Программист-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p256.rar)
Внутри архивов под объёмы 256 Кб находится два варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска, и четырьмя файлами по 64 Кб (файлы romdiskN.bin) для старого варианта диска (в составе мультикарты).
Внимание! Архивы были обновлены до версии 3.92 , 13.01.2019 !
П.С. Всех с Наступившими! :)
Итак, более подробно о релизе. Традиционно, нетерпеливый предновогодний пост отредактирован – архивы сборок обновлены до версии 3.91 :)
Новая версия сборщика ROM-диска – CRTDSK$
Заново переписана «с нуля» утилита подготовки образов ROM-дисков для прошивки в ПЗУ. Помимо более информативного интерфейса, также добавлен новый функционал. Утилита позволяет собирать диски «бесконечного» объёма, «полёт фантазии» ограничен лишь размерами дисков, на которых размещаются файлы, ну и текущим максимальным поддерживаемом объёмом ПЗУ ROM-диска Ориона = 1 Мб. Старая версия утилиты «запиналась» при неудачном расположении файлов и физически не позволяла «монтировать» подряд идущие очень длинные файлы. В новой версии эти недостатки устранены, корректно компонуются любые файлы, в любом порядке следования, в т.ч. при попадании заголовка файла на границу между банками. По-умолчанию производится разбивка на 32 Кб фрагменты, необходимые для прошивки больших ПЗУ непосредственно с помощью Ориона, опционально доступна разбивка на фрагменты по 2, 8 и 16 Кб – для прошивки ПЗУ соответствующих актуальных размеров (РФ2, РФ4, 27128).
Традиционно сохранена возможность сборки ROM-диска в формате ORDOS (округление длин файлов кратно 16) – указанием ключа «/O». А также опция сокрытия системных файлов в каталоге – ключ «/H».
Добавлена возможность указывать в списке файлов команды смены каталогов! Т.о. теперь не обязательно размещение всех исходных файлов собираемого ROM-диска в одном каталоге виртуального диска или винчестера.
В случае ошибки чтения или записи файла в процессе обработки, утилита предоставляет возможность повторить операцию (диск был не готов, «отвалился» и т.п.) или выбрать другой диск (на текущем место закончилось). Т.о. теперь есть возможность собирать диск, не имея в наличии «жирных» носителей для выходных файлов, фрагменты образа можно «размазать» по нескольким дискам малого объёма.
Благодаря новой версии утилиты удалось более логично скомпоновать файлы в сборках, а также сделать 1Мб-версию для Орион-128. К сожалению, для Ориона-ПРО нет аппаратного решения для ROM-диска более 256 Кб, или оно мне не известно, поэтому для «ПРОшки» традиционно два варианта дисков на 64 и 256 Кб.
Видео пример процесса сборки образа ROM-диска на 512 Кб - https://www.youtube.com/watch?v=Mq_6iFt_tAc
Теперь непосредственно про ОС. Данным релизом сменилась значимая часть номера версии, что означает критичные изменения (новшества) в API ОС, таким образом ПО созданное под версию 3.9x работать в предыдущих версиях (3.8x и ниже) не будет! Поддержка старого ПО в новой ОС остаётся в полном объёме. Нововведения не меняют концепции взаимодействия с ОС, а просто ещё немного упрощают код прикладного ПО и позволяют практически полностью отказаться от вызова п/п Монитора, а также унифицировать код для разных платформ (128/ПРО). В новой версии работа с RTC абстрагирована от конкретной реализации в «железе» и доступна через API DSDOS.
Все изменения внесены в соотв. библиотеки SDK - http://denn.ru/8bit/orion/soft/dasm/dsdos_sdk.rar
Поддержка обоих вариантов «посадки» часов ВИ1
Так случилось, что для Ориона-128 популярны два варианта включения отечественных часиков реального времени на базе БИС КР512ВИ1: по адресам F7B0/F7B1 и по адресам F760/F761 (с реверсной адресацией регистров). В новой версии ОС сделана прозрачная поддержка обоих вариантов. Если каким-то чудесным образом в системе присутствуют оба, то приоритет первому (авторскому), его поиск при автодетекте производится первым. Обнаружение м/сх часов производится посредством записи и считывания контрольной информации в последнюю ячейку CMOS. Прикладное ПО начиная с версии 3.9 работает через API, поэтому оно даже не «в курсе» какой вариант посадки RTC используется. Тем не менее, при желании программист может узнать эту информацию: п/п инициализации “#B0” выдаёт номер обнаруженных RTC (или 00h при их отсутствии).
Эмуляция API нативной авторской ОС ORDOS
Как неоднократно упоминал ранее, ПО под ORDOS (в т.ч. авторское) часто пытается работать с дисками напрямую, т.е. тело файла вычитывается не средствами ОС, а непосредственно из ОЗУ квазидиска. Поскольку диски в ОС DSDOS организованы совсем иначе (кластерное хранение данных, и в случае квазидиска - в разных банках доп. ОЗУ), непосредственно реализовать «уязвимость» ORDOS не представляется возможным. В итоге было принято решение организовать т.н. «песочницу», т.е. на лету имитировать ORDOS-структуру квазидиска в области атрибутов цвета теневого экрана (8000h-AFFFh). При вызове п/п поиска файла, код эмуляции API ORDOS загружает найденный файл в «песочницу» и программе предоставляет физические адреса тела файла честно во второй странице ОЗУ, т.е. на лету организуется кусок структуры ORDOS'овского квазидиска персонально под запрошенный файл. Также с помощью «песочницы» реализован функционал последовательной записи в ORDOS-файл, а по факту закрытия файла он уже сохраняется в виде файла DSDOS на текущем диске.
Эмулируются все п/п ОС ORDOS, сообщение об ошибке возможно только при выходе за границы «песочницы», размер её буфера - 12 Кб, а также при попытке нарушения границ тела файла в ОЗУ виртуального квазидиска.
На такие заморочки сподвигнуло давно не дающее покоя «шило» - PENX. Одна из выдающихся авторских программ на Орионе, по сути визитная карточка ПРК. Собственно вариантов было два: либо перепилить работу с файлами у PENX'а, либо гора идёт к Магомету :)
Графический редактор был успешно дизассемблирован, работа с файлами через API ORDOS понята, но в последний момент решил не «портить» этот шедевр, а всё же подстроиться со своей стороны. Однако чуть-чуть подпилить PENX всё же пришлось, т.к. выяснилось, что он не запускается, если квазидиск ORDOS заполнен выше 8000h, а «песочница» как раз расположена именно там! Пришлось заткнуть эту проверку, т.к. в данном случае она не актуальна, с 8000h у нас временный буфер, а реальные файлы хранятся совсем в другом месте. Плюс подкорректировал некорректное «упрощённое» обращение к знакогенератору, использующееся при «быстром» выводе цифр кратности положения пера восьми. Работает! Программа суперская, реально шедевр программирования, автору однозначно респект.
Поддержка НЖМД
Собственно о поддержке жёстких дисков я уже писал ранее и даже выкладывал версию 3.88, сам активно пользовался почти весь прошлый год. За этот период были найдены некоторые недочёты и даже серьёзные баги, которые успешно исправлены в релизе v3.9.
Критичным багом была некорректная работа с т.н. «каталогами в каталоге», в результате чего данные содержимого подкаталога располагались в произвольном месте жёсткого диска, которое зависело от имён файлов в родительском каталоге %)
Также много хлопот доставило обнаружение НЖМД при загрузке ОС. Дело в том, что согласно тех. документации по IDE, при отработке команды сброса (аппаратного или программного) винчестер может «тянуть с ответом» до 30 секунд! И как показала практика, при включении (подаче питания) некоторые модели HDD «выгребают» этот лимит по-полной! Понятное дело – раскручивание шпинделя, внутренние тесты… но лично я уже привык к почти моментальной загрузке ОС, и тут вдруг такие тормоза!
Совсем печально обстоит дело с вариантом подключения HDD по т.н. упрощёнке (через порт пользователя #F6xx), а точнее с неподключением туда диска. Если в случае NEMO-контроллера достаточно мгновенно убедиться в аппаратном отсутствии самого КНЖМД и не ждать ответа от накопителя, то в случае ВВ55 – порт же всегда есть в системе, и если на нём нет накопителя, то приходится честно ждать пол минуты его ответ (а вдруг он там всё таки есть?).
К счастью обнаружилась приятная аппаратная особенность интерфейса IDE – если накопитель присутствует, но не выбран, то он подтягивает все линии шины к лог. «1», а «голый» порт ВВ55 наоборот выдаёт все «0». Благодаря этой фишке удалось избавиться от тормозов в случае отсутствия НЖМД на ВВ55.
Лично я долго и упорно сопротивлялся пускать «винты» в свои Орионы (скорее по «религиозным» соображениям), но, как и в случае с виртуальным диском (vs. дискеты) , объёмы + скорость и, как следствие, комфорт одержали победу. Осталось только совсем что называется наступить на горло песне и поставить SSD через китайский переходник IDE-SATA )) - ну всё же хочется идеальной тишины от Ориона. Хотя честно говоря хороший ноутбучный «винт» вполне себе нешумный, даже в полной ночной тишине.
В связи со всей этой историей наметился вектор постепенного (или не очень?) ухода от поддержки дискет в ОС DSDOS. По крайней мере по-умолчанию. Всегда есть возможность установки драйвера экзотического устройства вместо какого-то родного диска или, на худой конец, отдельной утилиты для работы с НГМД. Кмк, в базовой комплектации ОС поддержка дискет «для галочки» имеет мало смысла в наше время, а драгоценное место код отжирает, что ограничивает дальнейшее развитие.
Тем не менее, в версии 3.9 поддержка НГМД сохранена, но изменились буквы дисков. Ранее ассоциированные с дискетами имена дисков [C:] и [D:] присвоены НЖМД №0 и НЖМД №1 («Master» и «Slave», соответственно).
При загрузке ОС и обнаружении КНГМД по-умолчанию виден только дисковод №0 – диск [F:] (ассоциация «Floppy»), дисковод №1 неявно присутствует как диск [H:] (его можно сделать видимым через SYSTEM$). Дело в том, что конфигурация Ориона с двумя дисководами исчезающе маловероятна в наше время, кмк, но возможность поддержки такого варианта сохранена.. пока :)
Драйвер расширения ExtDRV v2.8
Ранее было подробное описание, а теперь он стал неотъемлемой частью всех сборок, кроме 64Кб-варианта (физически мало места, с драйвером уже не помещается базовый набор утилит).
Подгружается драйвер в BOOT автоматически. Нативный текстовый редактор Gemini-EDIT использует функционал драйвера расширения для диалогов чтения/записи файлов. Также оконный интерфейс драйвера использует утилита просмотра графических файлов – PICVIEW$. Соответственно, в варианте 64Кб-сборок загрузка рабочих файлов в данных программах возможна только через командную строку.
При создании ПО в дальнейшем также планируется активное использование ExtDRV API.
Хранение конфигурационных файлов SHELL и Gemini-EDIT на рабочем диске ОС
Изначально «центром вселенной» был квазидиск, он же был и «рабочим» диском согласно концепту ОС DSDOS. Все файлы конфигурации складывались туда же – в квазидиск. Потом появились варианты: «ЭД™» и «RAM7™», информация в которых не пропадает при выключении питания. Мне показалось логичным немного изменить концепт: при обнаружении в системе SRAM-диска, рабочим назначать его, чтобы конфигурационные и рабочие файлы сохранялись на нём, и, как следствие, при включении пользователь получал аналог выхода из «спящего» режима (состояние ПРК такое же, как на момент выключения), а квазидиск используется для временных файлов и как виртуальная память.
Опыт реальной работы на Орионе показал некоторые минусы второго варианта концепта, поэтому он пока в стадии осмысления. Самый главный минус – скорость загрузки ПО. К хорошему, как известно, привыкаешь, а к хорошей скорости работы – очень сильно :)
Подгрузка конфигурационных файлов при запуске некоторых программ это по сути загрузка двух файлов с разных дисков, а значит подгрузка и обработка каталогов этих дисков, поиск файлов на них… короче говоря, хоть это и доли секунды, но разница с т.з. комфорта при активной работе ощутимая, особенно на Орионе-128 с ВМ80 (@2,5 МГц).
В любом случае всегда можно переназначить рабочий диск через SYSTEM$.
Горячие клавиши в Gemini-EDIT
Тут изменения коснулись комбинаций клавиш работы с буфером обмена. Работать на PC приходится часто, поэтому писишные привычки очень сильны, но и на Орионе много работаю с текстами программ, поэтому вынужден был сделать «стандартные» Ctrl+C, Ctrl+V, Ctrl+Ins, Shift+Ins, Shift+Del, Ctrl+D.
Sancho45
07.01.2019, 10:23
Привет. Страницы по порту FEh выше 512 кб какими битами переключаются? Там вроде первые три бита, 4-й бит работает со спикером, и 5 и 6 с переключением остальных страниц ЕМНИП. Я в отпуске, компа нет под рукой, проверить. Через пару дней посмотрю.
Error404
07.01.2019, 12:39
Привет. Страницы по порту FEh выше 512 кб какими битами переключаются? Там вроде первые три бита, 4-й бит работает со спикером, и 5 и 6 с переключением остальных страниц ЕМНИП. Я в отпуске, компа нет под рукой, проверить. Через пару дней посмотрю.
ЕМНИП D0..D4=2Мб max
те биты что у Спектрума были под клаву (5 линий из матрицы 5х8)
- - - Добавлено - - -
Хотя опять же припоминая, в CP/M я никак не обходил "звуковой" D5, там номер сектора и дорожки в адрес в ПЗУ транслируется сплошняком. Т.е. оно будет и более 2Мб работать, но попердывая в спикер. :) Тут другой вопрос встает: надо ли иметь более 2Мб в ПЗУ - вместо гирлянды параллельных ПЗУ уже надо нормальный носитель (если не карты памяти, то хотя бы те же spi-ПЗУ которые за 16Мб по 3 проводам стоят 50руб).
Страницы по порту FEh выше 512 кб какими битами переключаются?
К сожалению, на форуме нет систематизированной и конкретно оформленной в одном быстро доступном месте информации по портам. Банальная логика мне подсказывает, что для переключения банков должны быть задействованы четыре младших бита (D0..D3) порта #FE.
Там вроде первые три бита, 4-й бит работает со спикером, и 5 и 6 с переключением остальных страниц ЕМНИП.
Если это так, то очень странно и не логично, имхо. За спикер вроде должен отвечать порт с другим адресом - #FF.
Через пару дней посмотрю.
Буду премного благодарен. У меня нету аппаратной реализации порта #FE, поэтому не проверить.
- - - Добавлено - - -
Тут другой вопрос встает: надо ли иметь более 2Мб в ПЗУ
При составлении сборки на 1 Мб уже буквально пришлось "пихать всё подряд". Можно конечно закинуть в ROM-диск различные файлы с данными (картинки, AY-музыка и т.п.), но большого смысла в этом лично я не вижу. Read-only носитель всё же предполагает хранение базового набора ПО (преимущественно системного), а файлы ресурсов логичнее хранить на других, перезаписываемых носителях.
Есть ещё и такой момент: увеличение объёма предполагает увеличение кол-ва файлов на диске, при этом увеличивая объём носителя более 1 Мб мы скорее всего упрёмся в ограничение "max 255 файлов на диске", и к тому же неудобно с т.з. юзабилити искать нужные файлы в списке из 200 и более файлов.
Если делать ROM-диск на большие объёмы, то придётся думать в сторону другой (кластерной) организации хранения файлов и введения подкаталогов, но это уже совсем другая история, которая потянет переделку ROM-загрузчика в ПЗУ Монитора...
...вместо гирлянды параллельных ПЗУ уже надо нормальный носитель (если не карты памяти, то хотя бы те же spi-ПЗУ которые за 16Мб по 3 проводам стоят 50руб).
Можно, но придётся придумать прозрачное аппаратное решение, которое для Ориона будет эмулировать классический параллельный интерфейс ROM-диска на ВВ55. И, как писал выше, придумывать файловую систему с подкаталогами, что ударит по совместимости с классикой и быстродействию, а также по отжираемым ОС ресурсам :)
- - - Добавлено - - -
На данном этапе для меня очень ясно нарисовалась вкусная и вполне конкретная аппаратная хотелка для Ориона - трушный SRAM-диск объёмом 1 Мб (а ещё лучше - 2 Мб :) ), с батареечный резервным питанием, "лежащим" в адресном пространстве МП, организованный как дополнительные 16 банков, переключаемые через порт #F9, с номерами страниц, идущими после ОЗУ. Фиг с ним - пусть даже со стандартной орионовской потерей верхних 4 Кб в каждой банке, дабы не усложнять дешифрацию и коммутацию. Можно было бы полностью разгрузить основное ОЗУ от кода ОС, предоставив прикладному ПО всё стандартное (расширенное) ОЗУ ПРК. Закэшировать каталоги всех дисков, что очень ощутимо повысило бы скорость работы одновременно с несколькими дисками. Получить полноценный сохраняемый рабочий диск по скорости работы аналогичный квазидиску. Появилась бы возможность сделать поддержку расширенного экрана (480/512 точек по горизонтали). Короче говоря, профит был бы ощутимый!
Error404
07.01.2019, 16:59
На данном этапе для меня очень ясно нарисовалась вкусная и вполне конкретная аппаратная хотелка для Ориона - трушный SRAM-диск объёмом 1 Мб (а ещё лучше - 2 Мб :) ), с батареечный резервным питанием, "лежащим" в адресном пространстве МП, организованный как дополнительные 16 банков, переключаемые через порт #F9, с номерами страниц, идущими после ОЗУ. Фиг с ним - пусть даже со стандартной орионовской потерей верхних 4 Кб в каждой банке, дабы не усложнять дешифрацию и коммутацию. Можно было бы полностью разгрузить основное ОЗУ от кода ОС, предоставив прикладному ПО всё стандартное (расширенное) ОЗУ ПРК. Закэшировать каталоги всех дисков, что очень ощутимо повысило бы скорость работы одновременно с несколькими дисками. Получить полноценный сохраняемый рабочий диск по скорости работы аналогичный квазидиску. Появилась бы возможность сделать поддержку расширенного экрана (480/512 точек по горизонтали). Короче говоря, профит был бы ощутимый!
Это кстати вполне можно сделать, например в виде платы второго этажа над основным ОЗУ (на журнальном Орионе-128 и его клонах). Например в Ревизии-512 на эту плату выводятся сигналы КТ2 КТ3 для выборки еще двух банок РУ7 (т.е. 513..1024кб) и есть несколько незанятых контактов на тех же разъемах куда можно подать еще дополнительные адреса (потребуется расширить порт F9). Это может быть вариант платы с 6 СОЗУ 512 кб и одной 8битной ИРxx для защелки RAS (демультиплексировать адрес) - итого получится 2Mb ОЗУ. Ну, или делать внешнюю плату в слоте, тут чуть посложнее будет.
Это может быть вариант платы с 6 СОЗУ 512 кб...
А почему с 6-ю (3 Мб)? Это как-то не 8-битно что ли... Ну и чересчур жирно, пожалуй :)
Обычно либо 2, либо 4, либо 8.
Ну, или делать внешнюю плату в слоте, тут чуть посложнее будет.
Тут дело такое, конструкция должна вставляться в слот, в идеале - в системный, как доп. плата расширения, в противном случае дело пахнет поножовщиной и МГТФингом, а это не вариант. Что-то меня терзают смутные сомнения, что возможно внедрить доп. СОЗУ малой кровью. По крайней мере в Орион-128, в "ПРО" вроде есть такая возможность.
Sancho45
12.01.2019, 17:32
https://i.ibb.co/LvQQDhp/20190112-200102.jpg (https://ibb.co/LvQQDhp)
https://i.ibb.co/99qvKY9/20190112-194328.jpg (https://ibb.co/99qvKY9)
Образ 256кб 3.91, первое включнеие, как-то не все работает на новоделе. Впечатление, будто определилось, но не задействовано или что-то нажать надо ?!
- - - Добавлено - - -
с этого образа часы работалти
https://zx-pk.ru/threads/27462-sborka-nastrojka-platy-orion-128(uknts)-ps-2(caro)-fdd-ide-z80card2.html?p=952199&viewfull=1#post952199
upd: после нажатий кнопок в конфигураторе и выхода из него, другие страницы ром диска увиделись и шелл запустился.
Sancho45, спасибо за помощь в тестировании. Да, я тоже обнаружил косяки в релизе 3.91 по части инициализации часов, а также есть косяк и по части порта #FE (проявится при чтении файла, тело которого попадает на разные банки).
Всё уже исправлено, сегодня вечером обновлю образы и отпишусь.
Попутно взялся оптимизировать код работы файловой системы, и как выяснилось, там есть потенциал для ускорения алгоритмов.
Так что пока пауза до v3.92, там будет что потестировать ;)
П.С. кстати, косяк с часами из v3.91 проявляется только если CMOS "слетает" и ход часов останавливается; на ПРО (мой основной рабочий ПРК) я косяк даже не заметил, т.к. там ВИ1 никогда не сбивается, в отличие от 128-го (
Sancho45
13.01.2019, 14:00
IDE тоже не определился, у меня СF карта через переходник.
С часами проверю....
- - - Добавлено - - -
Привет. Страницы по порту FEh выше 512 кб какими битами переключаются? Там вроде первые три бита, 4-й бит работает со спикером, и 5 и 6 с переключением остальных страниц ЕМНИП. Я в отпуске, компа нет под рукой, проверить. Через пару дней посмотрю.
На плате Рябцова в выборке страниц РОМ-диска учавствуют D0-D3 биты, D4 идет на вкл/откл спикера и далее D5 и D6 тоже на выборку страниц ром диска,но уже на разьем расширения.
- - - Добавлено - - -
Только не понятно зачем?! На разьем расширения выведены все сигналы, в том числе и pFE, а биты D5 и D6, идут после тригера страниц на основной плате, но почему то без младших битов 0-3, так что смысла в них нет, на плате расширения надо будет отдельно тригер страниц делать
IDE тоже не определился, у меня СF карта через переходник.
И опять мой косяк (( Вероятно речь про вывод информации о диске. В сборку для О-128 нечаянно попала не та утилита HDDINFO$, она ищет только HDD по схемотехнике NEMO (на портах #F79x).
Утилита форматирования HDD$FMT должна определять жёсткий диск корректно.
На плате Рябцова в выборке страниц РОМ-диска учавствуют D0-D3 биты, D4 идет на вкл/откл спикера и далее D5 и D6 тоже на выборку страниц ром диска,но уже на разьем расширения.
Битов D0..D3 достаточно, получаются доступными 16 банков, т.е. 1024 Кб (1 Мб), переключение банков в DSDOS должно работать корректно.
- - - Добавлено - - -
Обновлённая (исправленная) версия DSDOS v3.92
https://pp.userapi.com/c849424/v849424014/105e47/TxrgQ3JVFPM.jpg
Изменения:
1). Исправлена недоработка в поддержке альтернативного переключения страниц ROM-диска через порт #FE;
2). Исправлена ошибка инициализации RTC в утилите TIME$;
3). Исправлена ошибка поддержки НЖМД через порт юзера #F6 в утилите HDDINFO$;
4). Оптимизация алгоритмов поддержки файловой системы (модули BIOS, KERN);
5). Радикальное ускорение работы ЭД™ !!!
По последним двум пунктам стоит написать чуть подробнее. Были проведены сравнительные тесты на файловых операциях (254 файла размером 512 байт), результаты которых были опубликованы ранее (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=989145&viewfull=1#post989145). Результаты оптимизации впечатляющие:
Квазидиск [B:]
Чистая запись файлов: 0:20 -> 0:12 *
Запись файлов "поверх": 0:40 -> 0:22
Удаление файлов: 0:12 -> 0:04
Чтение файлов: 0:20 -> 0:16
Резюме: скорость записи выросла почти в 2 раза! Скорость чтения "подтянулась" до уровня ЭД™. Скорость удаления файлов стала в 3 раза выше.
ЭД™ [E:]
Чистая запись файлов: 1:03 -> 0:14
Запись файлов "поверх": 1:39 -> 0:25
Удаление файлов: 0:28 -> 0:05
Чтение файлов: 0:16 -> 0:15
Резюме: скорость записи выросла в 4,5 раза! Скорость чтения сохранилась практически на прежнем уровне (небольшой прирост из-за оптимизации алгоритма поиска файла в каталоге). Скорость удаления файлов возросла в 5,6 раз!
Самое важное: скорость работы ЭД™ стала практически аналогичной квазидиску, т.е. его уже вполне можно рассматривать как альтернативу и использовать в качестве рабочего диска.
__________________________________________________ ____________
* <время до оптимизации> -> <время после оптимизации>, в мин:сек
▼▼▼ Ссылки для скачивания различных вариантов сборок ▼▼▼
Для ПРК ОРИОН-128 всех ревизий:
ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s64.rar)
ПЗУ ROM-диска объёмом 128 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s128.rar)
ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s256.rar)
ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s512.rar)
ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s1024.rar)
специализированная "программерская", ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p512.rar)
специализированная "программерская", ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p1024.rar)
- - - Добавлено - - -
П.С. отдельное спасибо камраду Sancho45 за помощь в тестировании на альтернативном железе
Sancho45
13.01.2019, 21:55
Всё тоже самое. Нажимаю Esc- пишет шелл не найден,нажимаю D, выводит только 1ую страницу ром, захожу и выхожу в конфигуратор(system$), потом обязательно D (dir), пролистывает все файлы (из др страниц тоже), только потом при нажатии Esc вываливается шелл. Часы так же не видит. И IDE даже в конфигураторе не видит, на скринах выше видно
- - - Добавлено - - -
образ 256кб
- - - Добавлено - - -
загрузил Altair-dos, через IDE для проверки, часы видит, время кажет, выключил, переставил ром, и утилита TIME$ все равно не видит часы
- - - Добавлено - - -
Гружу Altair dos, часы сбиты.
- - - Добавлено - - -
Update
Утилита HDD$FMT увидела CF, но после вторичного запуска, в первый раз написала прерваная команда, а HDDINFO не найдена адрес метка. После HDDinfo тоже распознала CF карту в IDE
Всё тоже самое.
На всякий случай, сборка точно новая встала? Версия 3.92 ?
Нажимаю Esc- пишет шелл не найден,нажимаю D, выводит только 1ую страницу ром, захожу и выхожу в конфигуратор(system$), потом обязательно D (dir), пролистывает все файлы (из др страниц тоже), только потом при нажатии Esc вываливается шелл.
Идею понял, причину нашёл (загрузчик не дёргал переключалку..), исправил. Нужно перескачать образ по тем же ссылкам.
Часы так же не видет.
Так, смотрю скриншот и вижу, что SYSTEM$ находит в системе RTC первого типа, т.е. по адресам посадки #F7B0(данные), #F7B1(адрес).
Часы действительно там сидят?
И IDE даже в конфигураторе не видит, на скринах выше видно
Как аппаратно реализован интерфейс IDE ?
Если запустить тест юзер-порта (TEST#F6$), какое состояние линий он показывает?
- - - Добавлено - - -
Update
Утилита HDD$FMT увидела CF, но после вторичного запуска, в первый раз написала прерваная команда, а HDDINFO не найдена адрес метка.
В случае посадки IDE на юзер-порт, для обнаружения используется особенность интерфейса HDD: при отсутствии обращения хоста, он подтягивает все сигнальные линии к лог."1". Как ведёт себя CF-карта через переходник, честно говоря не знаю. Можно посмотреть с помощью утилиты теста порта: TEST#F6$
После HDDinfo тоже распознала CF карту в IDE
Можно скриншот HDDINFO, плиз? Интересно в деталях, как определяется CF-карта на Орионе :)
Sancho45
13.01.2019, 23:11
На всякий случай, сборка точно новая встала? Версия 3.92 ?
Да
Так, смотрю скриншот и вижу, что SYSTEM$ находит в системе RTC первого типа, т.е. по адресам посадки #F7B0(данные), #F7B1(адрес).
Часы действительно там сидят?
в этом сообщении сборка работала с часами, там вроде порт F76x
https://zx-pk.ru/threads/27462-sborka-nastrojka-platy-orion-128(uknts)-ps-2(caro)-fdd-ide-z80card2.html?p=952199&viewfull=1#post952199
В случае посадки IDE на юзер-порт, для обнаружения используется особенность интерфейса HDD: при отсутствии обращения хоста, он подтягивает все сигнальные линии к лог."1". Как ведёт себя CF-карта через переходник, честно говоря не знаю. Можно посмотреть с помощью утилиты теста порта: TEST#F6$
после второго запуска утилит, они видят СF.........
- - - Добавлено - - -
надо 2 раза запустить HDDMFT, тогда все работает. Новый образ скачал, вроде ром диск заработал как надо.
https://i.ibb.co/VV7fsCT/20190114-020912.jpg (https://ibb.co/VV7fsCT)
https://i.ibb.co/3z7xGPj/20190114-020952.jpg (https://ibb.co/3z7xGPj)
У нас уже время 3 часа вперед .........))
Так, смотрю скриншот и вижу, что SYSTEM$ находит в системе RTC первого типа, т.е. по адресам посадки #F7B0(данные), #F7B1(адрес).
Часы действительно там сидят?
Нет, вру... посмотрел код SYSTEM$, под "RTC1" имеется в виду наличие ВИ1 по любому из адресов. "RTC2" - это часы на базе DS1307, так сказать заначка на будущее.
- - - Добавлено - - -
после второго запуска утилит, они видят СF.........
Никаких счётчиков кол-ва запусков в утилитах точно нет :) Алгоритм всегда одинаково работает.
CF-карта явно не механическая, так что на ракрутку шпинделя списать тоже не получается..
Новый образ скачал, вроде ром диск заработал как надо.
Отлично! Спасибо.
У нас уже время 3 часа вперед .........))
Да, точно, завтра ж рабочий день /-)
- - - Добавлено - - -
Я кажется понял насчёт часиков. Запуск TIME$ без параметров (как я вижу из скриншота) просто выводит показания времени, при этом инициализация RTC не производится! Это штатный алгоритм.
В таком случае, если ранее RTC не были инициализированы, то разумеется будет ошибка.
Для инициализации (первичного запуска) нужно либо явно задать параметры времени, либо, если есть связь с ORI-сервером, запустить с ключом синхронизации: TIME$ /S
Должно заработать ;)
- - - Добавлено - - -
ВИ1 по адресам #F7Bx у меня точно работают на реале. Альтернативные по адресам #F76x работают в эмуляторе, значит и в железе должны.
- - - Добавлено - - -
Размер CF-карты какой-то странный, она действительно на 249 Мб? Поддержка LBA есть - круть :)
Sancho45
13.01.2019, 23:47
Hddmft надо 2 раза запускать только при включении, потом все работает. Hddinfo можно сколько угодно раз запускать, без толку, пока 2 раза не запустишь hddmft. После первого раза hddmft всегда пишет прерванная команда.
CF -256 MB китай
Sancho45, а после двух запусков HDD$FMT в SYSTEM$ начинает определяться IDE1 ?
- - - Добавлено - - -
Также всё таки TEST#F6$ что показывает на шинах IDE ? До и после запусков HDD$FMT.
Sancho45
14.01.2019, 10:31
В случае посадки IDE на юзер-порт, для обнаружения используется особенность интерфейса HDD: при отсутствии обращения хоста, он подтягивает все сигнальные линии к лог."1". Как ведёт себя CF-карта через переходник, честно говоря не знаю. Можно посмотреть с помощью утилиты теста порта: TEST#F6$
С СF картой порты B и C все разряды 0, что до hddmft, что после. В конфигураторе не определяется ни до, ни после. Подключил баракуду 250Гб, при вкл. три точки и ждет, пока раскрутится, потом запускается дос, в конфигураторе по прежнему не видется, HDD info емкость каждый раз по разному определяет, серийник и модель выдает правильно, но не всегда полностью, те только первые 3-6 символов. Подключил 40 гб, меньше нет, тоже самое, но иногда вообще hddinfo зависает. Разряды B и C все в еденичках до запуска утилит и после.
Часы с указанием даты и времени заработали. Но при запуске Date$ без параметров сбиваются на 31.01.19, а в шеле показывают 0.01.19
Rom диск работает, но дос не видит шелл иногда (1 из 10 примерно), пока D не жмакнешь
- - - Добавлено - - -
Емкость Cf всегда правильно выводит, в altair-dos тоже 249 в инфо о диске выдает
- - - Добавлено - - -
Винты подключал как мастер по дефолту, если на 40гб перествавить мычку как 32гб лимит, то поведение меняется в лучшую сторону, но все равно как то не правильно емкость пишет
- - - Добавлено - - -
Шлейф обычный, я думаю ultra ata не наш случай )))
Hddmft надо 2 раза запускать только при включении, потом все работает. Hddinfo можно сколько угодно раз запускать, без толку, пока 2 раза не запустишь hddmft. После первого раза hddmft всегда пишет прерванная команда.
Как я понимаю, по сути "контроллер" IDE представляет из себя одну микросхему - порт ВВ55, глючить там нечему. Либо плохой контакт в шлейфе, либо какие-то шины висят в воздухе, и после того как словят правильную наводку, всё начинает работать.
- - - Добавлено - - -
С СF картой порты B и C все разряды 0, что до hddmft, что после. В конфигураторе не определяется ни до, ни после.
Тут всё чертовски логично. Детект наличия HDD производится по подтяжкам к "1". Если на линиях "0", значит ПО "видит", что железки нет. Иначе быстро никак не определить наличие HDD.
Подключил баракуду 250Гб, при вкл. три точки и ждет, пока раскрутится, потом запускается дос, в конфигураторе по прежнему не видется
Такого быть не может. Механизм детекта одинаковый - в загрузчике и в конфигураторе. Барракуда это честный "винт", он должен подтягивать линии к "1" и на исправной аппаратуре однозначно определяться в ПО.
Три точки и ожидание раскрутки - это всё верно, так и работает поддержка HDD в DSDOS.
HDD info емкость каждый раз по разному определяет, серийник и модель выдает правильно, но не всегда полностью, те только первые 3-6 символов. Подключил 40 гб, меньше нет, тоже самое, но иногда вообще hddinfo зависает.
Что-то с аппаратной частью не в порядке, имхо.
Разряды B и C все в еденичках до запуска утилит и после.
И ещё три младших разряда порта А должны быть также в "1". Это правильная ситуация.
Часы с указанием даты и времени заработали. Но при запуске Date$ без параметров сбиваются на 31.01.19, а в шеле показывают 0.01.19
Хм, странно. Проверю в эмуляторе..
Rom диск работает, но дос не видит шелл иногда (1 из 10 примерно), пока D не жмакнешь
Как-то не понятно. Если уж работает управление через #FE, то оно должно работать всегда.
Когда не работает, то конфигуратор показывает наличие порта #FE ?
Могу только предположить вариант горячей замены ПЗУ ROM-диска, тогда действительно такое может быть. Дело в том, что ОС кэширует каталог диска (предполагается, что содержимое ROM-диска изменяться не может). Если же содержимое внезапно изменилось, то файл оболочки не будет найден в нужном месте, перечитывание каталога исправит ситуацию.
Винты подключал как мастер по дефолту, если на 40гб перествавить мычку как 32гб лимит, то поведение меняется в лучшую сторону, но все равно как то не правильно емкость пишет
Поддерживается оба логических устройства: "Master" и "Slave". По-умолчанию работа идёт с "Master". Если нужно посмотреть INFO или отформатировать "Slave", то при запуске утилиты указывается параметр "1".
Лимитирование при работе в DSDOS не требуется, поддерживается полная ёмкость накопителей, а работа производится в режиме "LBA".
Шлейф обычный, я думаю ultra ata не наш случай )))
Ну, как сказать... если проблема из-за помех в слишком длинном шлейфе, то может и имеет смысл поставить 80-контактный. Особенно для CF-карты, т.к. судя по всему в ней нет терминирующих резисторов на питание (отсутствует подтяжка к "1").
Sancho45
14.01.2019, 12:34
С жестким диском питалово просаживается, может это и есть причина, потом проверю с др бп. А вот c CF картой cp/m грузится с нее 10 из 10 без проблем. С ром диском возможно контакты, я ее часто меняю. Вроде работает.
С жестким диском питалово просаживается, может это и есть причина, потом проверю с др бп.
Ещё может быть вариант земляной петли. Дело в том, что земля к HDD подводится дважды: через гнездо питания и через интерфейсный шлейф. При неудачной топологии получается контур, который эффективно ловит наводки, и они попадают на линии интерфейса IDE. Как вариант для проверки - запитать HDD отдельно.
А вот c CF картой cp/m грузится с нее 10 из 10 без проблем.
СР/М грузится с физически другой карты или с той же самой?
Насколько успешно проходит процесс форматирования с помощью HDD$FMT ?
С ром диском возможно контакты, я ее часто меняю. Вроде работает.
Дальние файлы в списке корректно загружаются?
- - - Добавлено - - -
Хм, странно. Проверю в эмуляторе..
Проверил, вышеописанный баг не обнаружил. Но, эмулятор конечно не железка..
У меня есть экземпляр ВИ1, который глючит только в определённом диапазоне дат в октябре, в остальное время ведёт себя как исправный. В данном случае может тоже глюк подобного рода...
Sancho45
16.01.2019, 13:31
Такого быть не может. Механизм детекта одинаковый - в загрузчике и в конфигураторе. Барракуда это честный "винт", он должен подтягивать линии к "1" и на исправной аппаратуре однозначно определяться в ПО.
Три точки и ожидание раскрутки - это всё верно, так и работает поддержка HDD в DSDOS.
Еще как может и проверка это подтверждает !
И так, подключил более мощный бп, напруги в норме.
Есть 2 баракуды 40 и 80 гб (250гб SATA винт, ошибся в посте).
Модель 40гб - никаких единиц не вешает на шину, ну соответствено не определяется автодетектом и HDDINFO инициализирует его(идет раскрутка), но вместо инфы - мусор, 7.3гб всего по 236(головок, цилиндров и тд), модель и серийник не выдает. (в CP/M винт не видится, но винт работает на PC 100%)
https://i.ibb.co/ryWZNY2/20190116-154612.jpg (https://ibb.co/ryWZNY2)
https://i.ibb.co/gd9p2Jd/20190116-154413.jpg (https://ibb.co/gd9p2Jd)
Второй винт(ST3180021) выдает на шину единички, серийник и модель hddinfo выдает. Размер НЕ правильно определяет 512мб(в cp/m так же,всю инфу правильно выдает кроме размера), но в конфигураторе везде X, т.е. нет там отметки ide1 или ide0.
https://i.ibb.co/DzSQ5Lm/20190114-152252.jpg (https://ibb.co/DzSQ5Lm)
Не форматировал еще ничего, времени нет.
Винты рабочие, шлейф менял на 80 пиновый, разницы нет.
До этого к ориону не подключал винты, работал только с CF картой (256мб,32 мб), меня устраивает)) HDDINFO о ней правильную инфу выдает, только с детектом трабл, тк там нули на шине.
Наверное на такой вв55 IDE нужны винты меньшего обьема или программный интерфейс по другому ......Я в этом вопросе не разбирался........
Получается есть винты которые не выдают ед. на шину.
Может пересмотреть автодетект или сделать выбор в конфигураторе?!
Теперь часы, проблема софтовая! пробовал другой чип на всякий......
При первоначальной установке часы работают хорошо, проблем нет. Если запустить конфигуратор или DATE без параметров, то сбивается число и разраяд часов (месяц, год, минуты и секунды в порядке). Как и было ранее, сбивается число на 31, а шелл показывает 0 число , явно софтовый глюк.
https://i.ibb.co/7XqD12C/20190116-154508.jpg (https://ibb.co/7XqD12C)
https://i.ibb.co/pfXGxDb/20190116-154517.jpg (https://ibb.co/pfXGxDb)
- - - Добавлено - - -
с ром диском, вопрос отложен, тк есть подозрения на железо, использую тип чипа отличный от того на который разводка. но проблем особо нет, 19 из 20 раз работает все гуд))
Еще как может и проверка это подтверждает !
Тут могу только повториться: детект наличия HDD в загрузчике ОС и в конфигураторе одинаковый. По "1"-ам на А0..А2, В0..В7 и С0..С7.
Модель 40гб - никаких единиц не вешает на шину, ну соответствено не определяется автодетектом и HDDINFO инициализирует его(идет раскрутка), но вместо инфы - мусор, 7.3гб всего по 236(головок, цилиндров и тд), модель и серийник не выдает. (в CP/M винт не видится, но винт работает на PC 100%)
Прежде чем выпустить в свет поддержку НЖМД, я проверил работоспособность на следующем оборудовании:
1) Орион-128 (рев.512), НЖМД через порт юзера (ВВ55);
2) Орион-ПРО, НЖМД через специализированный NEMO-контроллер;
3) НЖМД IDE на базе флэш-ПЗУ, Transcend 1 Gb;
4) НЖМД IDE 7,8 Гб, классический "Фуджик MPG";
5) НЖМД IDE 9,2 Гб, "Фуджик MPE";
6) Три различных модели НЖМД mini-IDE от ноутбуков: 20, 80 и 120 Гб (мой основной рабочий на Орионе-ПРО), Самсунг, Тошиба и ещё какой-то;
7) НЖМД IDE Самсунг на 20 Гб;
8) НЖМД IDE Самсунг на 120 Гб (основной рабочий на О-128);
9) НЖМД IDE Сигейт на 40 Гб, вроде тоже Барракуда, но из первых (не "7200.7");
10) НЖМД IDE Самсунг на 500 Гб (форматировать не пробовал, т.к. там ценные писишные данные, только смотрел ТТХ на Орионе).
Со всеми накопителями на обеих платформах поведение одинаковое, корректное определение ТТХ и стабильная работа, кроме одной модели ноутбучного "винта", который напрочь отказывается работать с NEMO-контроллером на "ПРО" (просто вообще "не алё", и как выяснилось эта проблема с "нэмой" известная), но прекрасно работает через ВВ55.
Второй винт(ST3180021) выдает на шину единички, серийник и модель hddinfo выдает. Размер НЕ правильно определяет 512мб(в cp/m так же,всю инфу правильно выдает кроме размера), но в конфигураторе везде X, т.е. нет там отметки ide1 или ide0.
Тут вот как всё устроено. Мы выдаём в HDD одну единственную однобайтовую команду "запрос ТТХ" и далее считываем ответ "сектор 512 байт с данными", после чего просто из соотв. полей выводится информация о накопителе. Стало быть возможны следующие два варианта:
- команда не прошла, соотв. никакого ответа не будет, ПО выдаст ошибку накопителя;
- команда прошла, в статусе ответила "ок", считанная инфа из буфера накопителя валидна.
Если считывание данных происходит (аппаратных ошибок в интерфейсе нет), но данные "левые", значит такие данные выдаёт "винт" (повреждена соотв. область, где они хранятся в накопителе).
"Икс" в конфигураторе говорит лишь о том, что на нужных линиях порта нет всех единичек. Только и всего.
Не форматировал еще ничего, времени нет.
CF-карта быстро отформатируется. 40-гиговый будет ощутимо дольше..
Винты рабочие, шлейф менял на 80 пиновый, разницы нет.
Рабочие были когда-то раньше или после неудачных экспериментов с Орионом, на писи по-прежнему корректно определяются и работают?
работал только с CF картой (256мб,32 мб), меня устраивает)) HDDINFO о ней правильную инфу выдает, только с детектом трабл, тк там нули на шине.
Мне не понятно каким образом такой накопитель будет работать в системе, где выходной буфер с открытым коллектором? Каким образом на линиях будет выставляться лог."1" ?
Наверное на такой вв55 IDE нужны винты меньшего обьема или программный интерфейс по другому ......Я в этом вопросе не разбирался........
Никакой связи ВВ55 и объёмов нет. Поддержка соотв. протоколов осуществляется чисто программно, аппаратура только пропускает соотв. сигналы, интерфейс IDE стандартный для всех видов накопителей и протоколов.
Получается есть винты которые не выдают ед. на шину.
Меня терзают смутные. Скорее это неисправность (выгорели резисторы подтяжек?). Либо напаять подтяжки, либо слэйвом кинуть второй нормальный "винт", который заодно выполнит роль подтяжки :)
Может пересмотреть автодетект или сделать выбор в конфигураторе?!
А где этот выбор запоминать? Или после каждой загрузки ходить в конфигуратор? Если б хотя бы, например, часы ВИ1 были стандартно во всех Орионах, то можно было бы хранить настройки ОС в их CMOS..
Теперь часы, проблема софтовая! пробовал другой чип на всякий......
Если бы была софтовая, то на моих Орионах и/или в эмуляторе она бы воспроизвелась. Но, к сожалению, у меня она не проявляется, соответственно, мне эту проблему не пощупать, и это говорит о локальной проблеме, возможно даже какой-то хитрой аппаратной.
Опять таки, ВИ1 - это простая штука, с т.з. ПО это обычное ОЗУ, подключенное через порт. Для записи/чтения показаний часов, мы обращаемся к определённым ячейкам. Чтобы сбить показания с одних на другие, нужно специально написать такое ПО, и оно бы на всех ПРК работало одинаково.
При первоначальной установке часы работают хорошо, проблем нет. Если запустить конфигуратор или DATE без параметров, то сбивается число и разраяд часов (месяц, год, минуты и секунды в порядке). Как и было ранее, сбивается число на 31, а шелл показывает 0 число , явно софтовый глюк.
"0" - это переполнение, "31" - скорее всего тоже. Вероятно по факту из ячейки (или голой шины?) читается "FF".
Конфигуратор при детекте часов записывает в последнюю ячейку CMOS тестовый байт, а затем пытается его оттуда считать и сравнить. На показания часов это никак не должно влиять, потому как регистр находится совсем по другому логическому адресу ВИ1.
с ром диском, вопрос отложен, тк есть подозрения на железо, использую тип чипа отличный от того на который разводка. но проблем особо нет, 19 из 20 раз работает все гуд))
Проблема может быть вызвана длинным шлейфом от ВВ55 до ПЗУ. Как вариант. "Длинный" - это более 3..5 см, как показывает практика. Либо слишком медленной ПЗУ и слишком быстрым Орионом :)
Ранее у меня глючила работа ROM-диска, если читать данные на полной скорости (Орион на ВМ80, клок ЦП=2,5МГц), и в ранних версиях ОС стояли задержки между выставлением адреса и взятием данных (два NOP'а). Потом я укоротил шлейф и проблема исчезла, в итоге я отказался в ПО от торможения чтения ROM-диска. Если Орион на Z80 и такт 5 МГц и выше, то могут быть проблемы с чтением из "медленных" ПЗУ. Ещё я слышал байки про "неуспевающие" ВВ55, но живьём таких не встречал.
- - - Добавлено - - -
...(250гб SATA винт, ошибся в посте)
ВВ55 не поддерживает SATA, там уровни сигналов другие, да и скорости.. ;)
Sancho45
16.01.2019, 19:21
Тут могу только повториться: детект наличия HDD в загрузчике ОС и в конфигураторе одинаковый. По "1"-ам на А0..А2, В0..В7 и С0..С7.
Повторюсь и я. В конфигураторе нет отметки, даже если винт определился загрузчиком........
"Икс" в конфигураторе говорит лишь о том, что на нужных линиях порта нет всех единичек. Только и всего.
единички есть, смотрим пост выше.
Второй винт(ST3180021) выдает на шину единички,
CF-карта быстро отформатируется. 40-гиговый будет ощутимо дольше..
дело не в скорости, а в данных на карте в файловой системе ср/м, надо образ сохранить, чистых карт нет
Рабочие были когда-то раньше или после неудачных экспериментов с Орионом, на писи по-прежнему корректно определяются и работают?
на писи работает сейчас через переходник IDE -USB
Меня терзают смутные. Скорее это неисправность (выгорели резисторы подтяжек?).
некогда с этим возиться, он работает сейчас через переходник, смотрим выше
(на обычном ide тоже работал, сейчас компа нет рабочего с ide на мамке)
Если бы была софтовая, то на моих Орионах и/или в эмуляторе она бы воспроизвелась. Но, к сожалению, у меня она не проявляется, соответственно, мне эту проблему не пощупать, и это говорит о локальной проблеме, возможно даже какой-то хитрой аппаратной.
На СРМ все работает, часы проходили несколько месяцев без замечаний, выдернул другой чип с мамки PC, поведение такое же, на СРМ работают, на DSDOS такое же поведение
роблема может быть вызвана длинным шлейфом от ВВ55 до ПЗУ.
шлефа нет, пзу на плате разведено.Разводка под другую цоколевку.
да и вроеде написал, этот вопрос в сторону, сам разберусь, к теме не относится в данный момент.
ВВ55 не поддерживает SATA, там уровни сигналов другие, да и скорости.
Ну уж совсем бред не надо тут, я не собирался подключать SATA , это третий винт мой, просто в указании емкости ошибся постами выше, не 250 был(SATA) , а 80 гб IDE
Теперь по делу, стабильной работы 80 гб удалось добиться установкой другой вв55, поставил квазаровскую вместо импорта и был удивлен))
так же с 80пиновым шлейфом.
Полная инфа о винте и правдивые данные о размере. НО В конфигураторе как были х так и остались, винт по раскрутке определяется еще в загрузчике.
https://i.ibb.co/D58xWXb/20190116-212359.jpg (https://ibb.co/D58xWXb)
https://i.ibb.co/f4fBgD0/20190116-212421.jpg (https://ibb.co/f4fBgD0)
10 из 10 выходит как надо, но если HDDinfo после запуска конфигуратора, то подвисает..........тоже самое и HDDFMT, те все работает и они видят винт после ресета, вкл.выкл, но после конфигуротора зависон, пока не вкл.выкл
Error404
16.01.2019, 19:31
Немного вклинюсь.
Чтобы успевали порты на 5МГц всегда стараюсь ставить либо К580ВВ55А (с буквой А) либо импортные 82С55 (хотя есть в коллекции например и ИК55 и i8255 образца 197х годов). На 10М без Wait (например журнальный О-128 с Z80 по схеме Орион-Сервиса и подать 10М вместо 5М) К580ВВ55А уже не успевают, но это не наш случай, у нас 5М, тут действительно все ВВ55А должны работать (кроме брака и дифундировавших). Еще стараюсь использовать короткие шлейфы (есть несколько фабричных по 20см, т.е. не сам укорачивал а снял откуда-то уже такие).
Sancho45
16.01.2019, 19:39
дык 82с55 и был, но заработал как надо квазар ВВ55 с индексом A ))) Шлейф 80-ка, на разьем посередине который, те короткий
Sancho45, у меня начали закрадываться подозрения в сторону корректности загрузки ПО с ROM-диска, и, как следствие, всевозможные необъяснимые глюки. Особенно различие поведения ПО от номера попытки :)
В связи с чем предлагаю следующие проверки контрольных сумм. Итак, начнём с "проблемной" утилиты DATE$. Открываем её на просмотр "[F3] в Нортоне", выбираем бинарный режим просмотра [H] и сверяем контрольную сумму всего файла (справа внизу - "К/с файла"):
https://pp.userapi.com/c851428/v851428874/932b7/cgavuqcNYGw.jpg
Правильное значение = 2526h
Можно пооткрывать файл несколько раз, чтобы убедиться, что каждый раз файл читается из ПЗУ одинаково.
Далее проверка пожёстче - попробуем загрузить DATE$, потом сохранить его из ОЗУ в файл "1" на квазидиск:
https://pp.userapi.com/c851428/v851428874/932c7/KgF5LsxP9TQ.jpg
и вновь проверить контрольную сумму, но уже нового файла, который мы скопировали из ОЗУ:
https://pp.userapi.com/c851428/v851428874/932cf/7WdWrJh4zQk.jpg
Должны быть всё те же 2526h.
Ну, и TIME$ до кучи:
https://pp.userapi.com/c851428/v851428874/932bf/5elznv9UJvE.jpg
У меня получилось 026Ah.
Sancho45
16.01.2019, 21:08
проверил для чистой совести , все сходится со скринами. Проблем нет с загрузкой по с ром диска, СРМ тоже на ром диске и работает замечательно. Другие файлы тоже работают с этого образа, без всяких проблем.
В порту А правые три разряда 000 со всеми винтами , остальные единички и в портах В и С с 80Гб винтом тоже единички
- - - Добавлено - - -
update
От этих трех разрядов и зависит определение в конфигураторе, но там 000, а hddinfo выводит правильную инфу.
Может на этих 3-х сигналах не должно быть 1, если нет подтяжки к +5в на материнке?
других винтов нет.
- - - Добавлено - - -
наверное все таки надо все подтянуть к +5 в !!! Будет время, сделаю.
может вообще убрать автодетект, в MBOOT просто выбираю загрузку с IDE и проверив загруз. данные на винте он тупо грузит
проверил для чистой совести , все сходится со скринами. Проблем нет с загрузкой по с ром диска
Тогда не понятно откуда рандомное поведение ПО.
Вытянул вв55 из панельки и в конфигураторе появился IDE1 )))
Всё дело в волшебных пузырьках единичках ;)
В порту А правые три разряда 000 со всеми винтами , остальные единички и в портах В и С с 80Гб винтом тоже единички
Мы говорим об этой схеме подключения НЖМД:
http://denn.ru/8bit/orion/128/ide/ide@f600.gif
???
может вообще убрать автодетект, в MBOOT просто выбираю загрузку с IDE и проверив загруз. данные на винте он тупо грузит
Места на меню в 2 Кб загрузчика уже не осталось. Вообще. Совсем ((
Когда крайний раз исправлял загрузчик (добавлял переключалку для #FE) пришлось урезать системное сообщение. Больше реально места для кода нет.
А также проблема 30 секунд остаётся: при включении HDD "выходит на рабочий режим" и нужно ждать. И если HDD по факту нет, то придётся ждать пол минуты, это не приемлемо для загрузки ОС!
Sancho45
16.01.2019, 21:32
Мы говорим об этой схеме подключения НЖМД:
Да, об этой, но три разряда порта А, это разряды адреса, они точно должны быть в единицах(это входные сигналы для винта).
На линиях данных - понятно , но на этих трех ???
Чёрт, проверил код детекта драйвера, который в загрузчике.. таки есть небольшое отличие! В драйвере из-за экономии места я схалявил сделал чуть проще: только проверка портов В и С на FFh! В конфигураторе экономить место не требуется, поэтому там полноценная проверка, с маскированием трёх младших битов порта А в том числе. Но суть не меняется, IDE обязан честно подтягивать все линии к "1".
Sancho45
16.01.2019, 21:39
Тогда не понятно откуда рандомное поведение ПО
рандомное поведение только с часами,
в винтом прояснилось.... БП, вв55 ......
- - - Добавлено - - -
Но суть не меняется, IDE обязан честно подтягивать все линии к "1"
Еще раз- это входные линии адресса для винта (А0-А3), не должен он их подтягивать к +5, они должны быть в 3-ем состоянии ИМХО
- - - Добавлено - - -
https://ru.wikipedia.org/wiki/ATA
На линиях данных - понятно , но на этих трех ???
На 100% не уверен. Проверял на всех своих "винтах", в связи с чем сделал выводы, что везде так должно быть. Причём даже пробовал прозванивать тестером - все линии подтянуты!
Sancho45
16.01.2019, 21:46
От туда - Адресация регистров организована при помощи трёх адресных линий DA0-DA2.
На 100% не уверен. Проверял на всех своих "винтах", в связи с чем сделал выводы, что везде так должно быть
Может там подтяжка на плате IDE вв55 всех выводов к +5в ???
- - - Добавлено - - -
Не должен он на входные данные выставлять сигнал
рандомное поведение только с часами
Тут совсем не понятно мне, если честно.
Еще раз- это входные линии адресса для винта (А0-А3), не должен он их подтягивать к +5, они должны быть в 3-ем состоянии ИМХО
Да, но на живых винтах они подтянуты. Я думаю, что терминирование обязательно должно быть выполнено для всех линий одинаково, вне зависимости от их назначения.
В принципе я готов отказаться от проверки трёх адресных линий на "1", она на данный момент производится только в SYSTEM$.
- - - Добавлено - - -
Может там подтяжка на плате IDE вв55 всех выводов к +5в ???
Свою я сам паял, на МГТФе, руками :)
https://pp.userapi.com/c840639/v840639767/6e8cf/jhMfIn2KNj8.jpg
https://pp.userapi.com/c834101/v834101767/ff642/vF7ZgVmONEM.jpg
Не должен он на входные данные выставлять сигнал
Это не выставление сигнала, а терминирование линии на другом (приёмном) конце. Так делают ещё со времён дисководов!
Sancho45
16.01.2019, 21:54
Я думаю, что терминирование обязательно должно быть выполнено для всех линий одинаково
термирование это одно, а выставление единиц на шине данных при отсутсвии обращение это другое(данные 2-х напрвленая шина, адрес нет )
Мы не можем проверять что там винт делает со своими входными сигналами или их подтяжку, потому что сам винт не выставляет там сигнал
Свою я сам паял, на МГТФе, руками
Ну так подтяжка там на все сигналы ?
Ещё момент. В утилитах HDDINFO$ и HDD$FMT не производится проверка наличия HDD на шлейфе с помощью подтяжек, там уже предполагается, что накопитель есть (иначе зачем их запускать?), выдаётся команда и ожидается ответ.
- - - Добавлено - - -
Ну так подтяжка там на все сигналы ?
В "контроллере" Ориона нет подтяжек.
- - - Добавлено - - -
термирование это одно, а выставление единиц на шине данных при отсутсвии обращение это другое(данные 2-х напрвленая шина, адрес нет )
Ок, будем называть терминированием. Не вопрос.
Sancho45
16.01.2019, 22:01
Ещё момент. В утилитах HDDINFO$ и HDD$FMT не производится проверка наличия HDD на шлейфе с помощью подтяжек, там уже предполагается, что накопитель есть (иначе зачем их запускать?), выдаётся команда и ожидается ответ.
Ну так заработали же они после замены ВВ55, выше сообщил
Мы не можем проверять что там винт делает со своими входными сигналами или их подтяжку, потому что сам винт не выставляет там сигнал
Но мы можем проверить состояние порта, настроив все его линии на ввод. Что я и сделал, и увидел одинаковую картину на более десятка устройств. Картина везде одинаковая и вполне конкретная, только поэтому решено было по ней делать быстрое определение наличия накопителя.
- - - Добавлено - - -
Да, я потом добавлял резисторы подтяжки:
https://sun9-26.userapi.com/c840628/v840628113/6b6b4/UsXNhIbi_cs.jpg
Но они относятся ко входам инверторов ЛН1, чтобы конкретизировать их состояние до момента, пока порт будет настроен программно и выставлены правильные сигналы на ШУ накопителя. Потому, как по-умолчанию (при сбросе ВВ55) линии порта в Z-состоянии, а на выходах ЛН1 должны быть "1".
Sancho45
16.01.2019, 22:09
Я думаю с винтами вопрос прояснился.
Остались часы. Может играет разница интерфейса Z80 вм80 ?
В СРМ с Z80 точно работают, 100 % без проблем
И тут работают, пока SYSTEM или DATE не запустишь
Я думаю с винтами вопрос прояснился.
Прекрасно!
Остались часы. Может играет разница интерфейса Z80 вм80 ?
Я бы мог подумать, что например ВИ1 не успевает... но у меня Орион-ПРО летает на 10 МГц! Правда ВУ вэйтятся, но тем не менее.
В СРМ с Z80 точно работают, 100 % без проблем
И тут работают, пока SYSTEM или DATE не запустишь
Попробуем поразмышлять. SYSTEM$ "мучает" RTC записью/чтением последней ячейки CMOS. С показаниями часов/календаря она никак не связана, но тут хотя бы производится запись, которая теоретически может как-то что-то портить. DATE$ без параметров только читает ячейки ВИ1, ничего никуда не пишет, т.е. порча данных в CMOS в принципе не возможна.
Более того, Нортон точно также читает те же самые данные, причём делает это несколько раз в секунду, если не нажимаются клавиши!
- - - Добавлено - - -
Может играет разница интерфейса Z80 вм80 ?
Надеюсь, с Z80 адресация портов #F7xx работает стандартно - через обращения к памяти?
Sancho45
16.01.2019, 22:24
прошло более часа, шелл выдает 1 час сколько то минут и сек. , Выключил./ вкл ничего не жмакал, шелл выдает 0 часов и те же минуты что до выключения
Может от монитора зависит или еще от чего, данные напрямую считываются с ви1 или через служебные ячейки ОЗУ ???
Может от монитора зависит или еще от чего, данные напрямую считываются с ви1 или через служебные ячейки ОЗУ ???
Нет, работа с ВИ1 идёт напрямую, монитор вообще не участвует.
- - - Добавлено - - -
Может автодетект вида подключения ВИ1 как-то сбивает с толку? Запись/чтение несуществующих портов #F7B1 и #F7B0 как-то ведёт себя странно на данной плате?
Sancho45
16.01.2019, 22:42
Дату установил, часы переходят и не сбиваются. Если дата сбилась , то и часы сбиваются. TIME работает корректно. Если часы в DSDOS, то в СРМ они сбиты, если в СРМ установить , то в DSDOS они сбиты , но по отдельности в каждой операц. они работают, после перегруза или вкл.выкл, все норм, пока не запустишь те утилиты
- - - Добавлено - - -
Может автодетект вида подключения ВИ1 как-то сбивает с толку? Запись/чтение несуществующих портов #F7B1 и #F7B0 как-то ведёт себя странно на данной плате?
не исключено
прошло более часа, шелл выдает 1 час сколько то минут и сек. , Выключил./ вкл ничего не жмакал, шелл выдает 0 часов и те же минуты что до выключения
Такого чтобы сбивалось время, у меня нет. Но при выключении/включении на Орионе-128 часто слетает ВИ1 в принципе! Требуется инициализация. В причинах я пока не разобрался, но думаю проблема в том, что по упрощённой схеме чипселект ВИ1 всегда выбран. В Орионе-ПРО никаких проблем с ВИ1 нет вообще, но там специальный схемный наворот по части чипселекта! Он активируется по факту выставления адреса ВИ1 и снимается по факту записи или чтения данных. Всё остальное время ВИ1 "спит". На О-128 микросхема "просыпается" с подачей питания на Орион и "засыпает" при его выключении.
Sancho45
16.01.2019, 22:49
Мне уже пора.
Я так понимаю, будет новый образ с исправленным SYSTEM по части IDE !?
C часами потом как нибудь, я посмотрю схему и софт, как время будет.
Алгоритм работы с ВИ1 на "128" и "ПРО" одинаковый. Разница только в способе адресации: на "128" обращение как к ячейкам памяти (STA/LDA), на "ПРО" через порты (OUT/IN)
- - - Добавлено - - -
Я так понимаю, будет новый образ с исправленным SYSTEM по части IDE !?
Да, "почикаю" проверку А0..А2, ломать - не строить :)
С часами хочется тоже решить вопрос, потом оптом внести все исправления.
C часами потом как нибудь, я посмотрю схему и софт, как время будет.
Хорошо. Хочется добить уж эту ВИ1 :)
Тут помимо реверсной адресации и других адресов порта добавляются Z80 и 5 МГц.
- - - Добавлено - - -
Обращения к ВИ1 не вэйтятся? Может действительно проблема в этом? Не зря же в ПРО'шке заморочились.
Есть возможность временно снизить тактовую частоту? (В идеале до 2,5 МГц)
Sancho45
17.01.2019, 10:49
Выборка часов дублируется по адресам F7Ex
Выборка часов дублируется по адресам F7Ex
Ай, красота! Как говорится, жопа "радость" пришла откуда не ждали :)
Теперь хоть всё стало ясно: по F7Ex предполагается быстрый COM-порт (ака "COM2"), и, как раз SYSTEM$ и DATE$ при запуске детектируют его наличие, т.е. делают определённые манипуляции по записи в регистры F7Ex. Соответственно, если "туда смотрят" часики, то данные в них могут портиться, что на практике и наблюдаем.
- - - Добавлено - - -
Есть возможность что-нибудь ампутировать на плате, дабы отучить её от такой вольности?
- - - Добавлено - - -
П.С. а, случайно, в F7Fx ничего не "смотрит" ? По этим адресам предполагается посадка быстрого SRAM-диска, и при загрузке там происходит движуха на тему детекта..
HardWareMan
17.01.2019, 12:48
Смотрю я на всё это и не понимаю: а что, схемы никто не читает? А кто проектирует - всегда использует упрощённую дешифрацию и не документируют это? Ну прям спектрум головного мозга.
Sancho45
17.01.2019, 13:02
П.С. а, случайно, в F7Fx ничего не "смотрит" ? По этим адресам предполагается посадка быстрого SRAM-диска, и при загрузке там происходит движуха на тему детекта..
В дешифраторе флопа, соответственно и часов, отсутствует бит A07, поэтому все адреса от F700-F77F дублируются на F780-F7FF
Конкретно порт F770-F77F === F7F0-F7FF висит в воздухе.
Есть возможность что-нибудь ампутировать на плате, дабы отучить её от такой вольности?
всегда есть, но требуется МГТФ и время, первое есть, второго нет !!!
Заявку на порты вроде подавал в своё время:
F780..F78F - резерв
F790..F79F - КНЖМД (NEMO)
F7A0..F7AF - AY-музыка (YM2149F)
F7B0..F7BF - часы на ВИ1 (v2)
F7С0..F7СF - часы на DS1307
F7D0..F7DF - SDHC
F7E0..F7EF - Порты СОМ2 и COM3 (16С550)
F7F0...F7FF - RAM-диск 1МБ
:)
- - - Добавлено - - -
В дешифраторе флопа, соответственно и часов, отсутствует бит A07, поэтому все адреса от F700-F77F дублируются на F780-F7FF
И это есть (_|_)
КНЖМД и музыка наложатся на КНГМД, авторский вариант часов ВИ1 наложится на таймер ВИ53, часы на DS1307 наложатся на СОМ1... картина маслом смазкой!
всегда есть, но требуется МГТФ и время, первое есть, второго нет !!!
Это да, знакомо хорошо. И пахнет тут не только МГТФ, но и ИД3..
- - - Добавлено - - -
Вот ещё нашёл:
https://pp.userapi.com/c841039/v841039298/b666/62qKKuOUQ1Q.jpg
- - - Добавлено - - -
Что касается аппаратной клавиатуры (нынче это PS/2, очевидно) и более вменяемых часов DS1307, то есть планы посадить их красиво на порт клавиатуры #F4xx, в ближайшее время напишу соотв. пост в теме про железо.
Sancho45
17.01.2019, 14:43
Есть возможность что-нибудь ампутировать на плате, дабы отучить её от такой вольности?
У себя я сделаю, как время будет. Не понятно, кто-то еще на плате Рябцова будет юзать эту дос и кто вообще собрал ее.
Но возвращаясь к IDE, хотелось бы юзать СF, бесшумно и весит меньше. Не охота 16 резюков паять. Может в отдельный драйвер вынести, если не предполагается загрузка с винта ?
У себя я сделаю, как время будет. Не понятно, кто-то еще на плате Рябцова будет юзать эту дос и кто вообще собрал ее.
Вероятно, будет переиздание, переработанное и дополненное :)
Но возвращаясь к IDE, хотелось бы юзать СF, бесшумно и весит меньше. Не охота 16 резюков паять. Может в отдельный драйвер вынести, если не предполагается загрузка с винта ?
Отдельный драйвер - без проблем. Тут ещё смотря какие масштабы. 249 Мб это как-то совсем мало для работы, кмк :) С таким объёмом не будет поддержки вложенных подкаталогов.. Мне, например, видится оптимальным накопитель на 120 Гб :) Ещё лучше - два накопителя, чтобы можно было важное бэкапить, на случай внезапного помирания основного HDD.
П.С. мне надоел гул механики в ночи, я планирую под свой Орион взять 120-ку SSD :)
Error404
17.01.2019, 17:01
Вот ещё нашёл:
https://pp.userapi.com/c841039/v841039298/b666/62qKKuOUQ1Q.jpg
Вот это вот тогда очень в стиле авторов было: когда уже вышли другие решения в т.ч. и в центровом ж-ле Радио, и на Митино продали миллион плат под это, спустя приличное время явиться в менее популярном Радиолюбителе с репликой "вам всё надо переделать под наш стандарт под который у нас пока ничего нет и вряд ли будет".
Что касается аппаратной клавиатуры (нынче это PS/2, очевидно) и более вменяемых часов DS1307, то есть планы посадить их красиво на порт клавиатуры #F4xx, в ближайшее время напишу соотв. пост в теме про железо.
Это полезное решение, и я больше скажу, это решение уже тут пробегало и в железе и в программном варианте для 8080. Лет пять тому назад дело было. Автор - eugeny7, который ай-яй-яй тут давно уже не показывается, а еще модератор! ;) Было в его теме про 8-битный комп в "разном" вроде(?) на всех возможных процессорах.
Кроме самой 1307 надо 2 вывода ВВ55 на вывод, один на ввод и 2 резистора, повесить часы можно было бы вместо магнитофона (на О-128 он вряд ли кому нужен, а в ПРО эти ножки на F400 вообще висят неиспользуемые).
Я даже подумывал это имплементировать из-за простоты подключения, но поскольку все что я имплементирую я сначал эмулирую в эмуляторе, а эмулировать еще одни часы было лень и все равно один хрен никому не надо, а у самого меня ВИ1, то забил. Также еще что остановило: I2C очень громоздко реализуется в программной части (еще сложнеe чем SPI), т.е. это будет медленно (съедать много процессорных тактов), что например критично для UZIX где и так уже много их уходит на обслуживание переключения контекстов и выполнения кода во всех страницах ОЗУ, а тут еще часы повиснут гирей. :)
- - - Добавлено - - -
Во, вот тут (https://zx-pk.ru/threads/25682-samodelnyj-kompyuter-na-z80-i-ne-tolko.html?p=868353&viewfull=1#post868353) исходники для Z80 и PCF8583 (тоже I2C часы), но вроде у него же где-то раньше было и для 8080 с DS1307.
Sancho45, исправил детект HDD в SYSTEM$, убрал проверку битов порта А.
Добавил ручной безусловный установщик драйвера для CF-карты: CF$DRV.
Ссылка на "кастомный" образ 256кб - http://denn.ru/8bit/orion/soft/dsdos-128_s256_2.rar
П.С. остальные образы по ссылкам выше тоже обновил (там стандартный набор, без CF$DRV), т.к. в последний раз туда случайно попали старые версии драйверов ЭД и RAM7 ((
Убирать в SYSTEM$ обнаружение быстрого СОМ-порта на #F7Ex не буду, тут надо исправлять грубую ошибку платы. Поэтому часы она видимо будет портить ((
В утилите DATE$ этот момент можно обойти, запустив её с минусом в качестве параметра:
L DATE$ -
т.о. игнорируется взятие даты с ORI-сервера, т.е. манипуляций с СОМ2 не будет.
Мини отчёт по подключению SD/SDHC-карт по интерфейсу IDE через переходник-адаптер (https://ru.aliexpress.com/item/3-5-IDE-SD-3-5-40Pin-IDE/32878574546.html):
https://pp.userapi.com/c852228/v852228271/db4d3/VHbPeUFvxyY.jpg
Идея возникла давно, но для проверки нужно было время ей "настояться", а потом дождаться поставки адаптера.
Как и предполагалось, всё работает замечательно, вот небольшая фотосессия:
Карта SDHC №1 (2 Гб):
https://pp.userapi.com/c853520/v853520269/3c52/nN8DGI2AgVk.jpg
https://pp.userapi.com/c855032/v855032269/38bd/qXxNAmVlKNc.jpg
Карта SDHC №2 (2 Гб):
https://pp.userapi.com/c850024/v850024603/151cc4/yfs40c7lXXE.jpg
https://pp.userapi.com/c849424/v849424603/14bc8d/NkywkM6WiDk.jpg
Карта SD (512 Мб):
https://pp.userapi.com/c854520/v854520269/38d9/M6Pe4EbMdqg.jpg
https://pp.userapi.com/c849428/v849428603/147239/iD9nmOyWMFM.jpg
Интересно будет сравнить скорость с реальным HDD. Но попугаи будут позже.. :)
Добавлено
Провёл сравнение HDD (Samsumg SpinPOINT 0802) и SDHC (SmartBUY, 2 Гб) через адаптер, всё таки карта чуть медленнее! Хоть и не критично, но всё же.
Вот тайминги файловых операций (HDD / SDHC):
Чистая запись 254-х файлов по 512 байт: 00:30 / 00:34
Запись 254-х файлов по 512 байт с предварительным удалением: 00:56 / 01:02
Удаление 254-х файлов: 00:23 / 00:25
Чтение 254-х файлов по 512 байт: 00:08 / 00:08
* время в секундах, тест проводился на ПРК "Орион-ПРО", с тактовой частотой ЦП = 10 МГц
Sancho45
18.03.2019, 15:35
Интересно будет сравнить скорость с реальным HDD. Но попугаи будут позже..
Думается мне, что любой современный HDD или SD card смогут работать быстрее чем скорость интерфейса IDE на Орионе, так что в теории попугаи должны быть одинаковы.
Слабое звено сам Орион и его IDE интерфейс.
Интересны эксперименты SD карты с Wi-FI.
Думается мне, что любой современный HDD или SD card смогут работать быстрее чем скорость интерфейса IDE на Орионе, так что в теории попугаи должны быть одинаковы.
Я почему захотел сравнить... на глаз мне показалось, что с картой работает медленнее.
SD карты с Wi-FI.
Какой такой Wi-Fi ?
Sancho45
18.03.2019, 21:42
Какой такой Wi-Fi ?
Да есть такие, гуглятся .... Сижу вот, читаю. Наверное это сложное решение.
По умолчанию только пердают картинки по вай-фай. Но так же есть инфа, что Toshiba FlashAir позволяет загружать на саму карту файлы, без ненужных телодвижений. Карты эти под linux работают,к слову, народ вроде расшарил и рут получил. Конечно там FAT32, но можно использовать контроллер Морозова, например. Будет ром диск в виде SD и WiFi. Конечно atmega в Орионе - не лампово, ну так и WiFi , тоже не на лампах)
HardWareMan
19.03.2019, 07:06
Какой такой Wi-Fi ?
Это карты для фотографов. Позволяют скидывать RAWки прямо на хран большой.
Интересное есть на Хабре (https://habr.com/ru/post/191742/).
https://jpegshare.net/images/5e/8e/5e8ec2ec7b4f0c63e89374b5215e7377.jpg
https://www.youtube.com/watch?v=yEwHQU8MLnQ
Sancho45
19.03.2019, 10:36
Интересное есть на Хабре.
Зачем такие сложности ?! Можно проще - тут (https://www.flashair-developers.com/en/documents/api/uploadcgi/)
- - - Добавлено - - -
Не нравится то, что после изменений на карте через сеть - ее надо переподключать.
Error404
19.03.2019, 10:42
Тут на форуме пару лет назад пролетала тема (с отсылкой к проекту в git) где к готовой SPI/SD шине через резисторную развязку подключается ESP и пишет(и читает, понятно) на эту используемую в другом приборе SD по WIFI сети (типа для 3D-принтеров сделано) в стандартном SMB/cifs окружении (т.е. тупо файлшара в любой ОС). Вот это удобно, и стоит 100 рублей в отличие от фабричных WIFI-SD которые чаще всего readonly через кривое Андроид-приложение, и вообще замудохаешься их приводить хоть к какому-то приемлимому виду.
Sancho45
19.03.2019, 11:25
Тут на форуме пару лет назад пролетала тема (с отсылкой к проекту в git)
TyT (https://github.com/ardyesp/ESPWebDAV) И тут реализация с указанием ограничений (https://3dtoday.ru/blogs/jeka-tm/sd-card-with-wifi-with-your-own-hands/)
- - - Добавлено - - -
и вообще замудохаешься их приводить хоть к какому-то приемлимому виду.
FlashAir вроде раскурили.....
Да есть такие, гуглятся .... Сижу вот, читаю. Наверное это сложное решение.
По умолчанию только пердают картинки по вай-фай. Но так же есть инфа, что Toshiba FlashAir позволяет загружать на саму карту файлы, без ненужных телодвижений. Карты эти под linux работают,к слову, народ вроде расшарил и рут получил. Конечно там FAT32, но можно использовать контроллер Морозова, например. Будет ром диск в виде SD и WiFi. Конечно atmega в Орионе - не лампово, ну так и WiFi , тоже не на лампах)
Я конечно всё понимаю, но это уже как-то совсем за гранью феньшуя. Ещё и от Ориона защищаться шапочкой из фольги.. ))
Error404
19.03.2019, 13:22
TyT (https://github.com/ardyesp/ESPWebDAV) И тут реализация с указанием ограничений (https://3dtoday.ru/blogs/jeka-tm/sd-card-with-wifi-with-your-own-hands/)
Да, оно. Как по мне очень удачное решение. Из ограничений реально может мешать только невозможность одновременного доступа от Ориона и от ВЕБ-сервера ESPхи, но то такое - плата за простоту реализациии, да и легко решаемо своим внутренним регламентом, типо "не жми на кнопки Ориона, пока заливаешь на карту файлы по WiFI". :)
вот еще бы эту же ESP уметь использовать по прямому назначению как сетевушку Ориона, и было бы вообще супер.
Stampmaker
21.03.2019, 15:15
Решил избавиться от шнура, соединяющий Орион с PC для обмена по OriNET.
На известном сайте нашел вот такой радиомодуль (https://ru.aliexpress.com/item/HC-12-SI4463/32961266879.html?spm=a2g0s.9042311.0.0.2e6d33edVwR Ocz)
Это обычный интерфейс RS232 с уровнями ТТЛ.
Со стороны PC прицепил переходник-"свисток" USB->RS232TTL (https://ru.aliexpress.com/item/Free-Ship-5pcs-lot-PL2303-TA-USB-TTL-RS232-Convert-Serial-Cable-PL2303TA-Compatible-Win-XP/32581254228.html?spm=2114.13010708.0.0.3a9933edgUU xAq) + радиомодуль,
https://pp.userapi.com/c850424/v850424914/e66a7/p_9QECUuDCU.jpg
со стороны Ориона только радиомодуль.
https://pp.userapi.com/c850424/v850424914/e66d4/Utq6Dq-CVwQ.jpg
в результате имеем OriNET по воздуху.
список файлов на PC
https://pp.userapi.com/c850424/v850424914/e66db/LB6SwYE7Npg.jpg
этот же список файлов на Орионе
https://pp.userapi.com/c850424/v850424914/e66e2/_7atMio5uC0.jpg
Следует отметить, что данный модуль работает на любой стандартной скорости формата RS232. В данном случае на 115200.
Как работать с модулем и что он из себя представляет, можно почитать, например, здесь. (http://cxem.net/review/review26.php)
Господи, китайцы уже и до Ориона добрались со своими гаджетами! :)
П.С. круто, тоже хочу =) только уже сразу хост на андройде...
HardWareMan
21.03.2019, 16:07
На известном сайте нашел вот такой радиомодуль (https://ru.aliexpress.com/item/HC-12-SI4463/32961266879.html?spm=a2g0s.9042311.0.0.2e6d33edVwR Ocz)
Это обычный интерфейс RS232 с уровнями ТТЛ.
О, только сегодня видел его у Цыгана:
https://www.youtube.com/watch?v=ZoyQgKPax9A
Всплывает проблема, однако. Протокол обмена с виртуальным диском не защищён от атаки "дядька посередине"... =)
Sancho45
07.05.2019, 09:51
В дешифраторе флопа, соответственно и часов, отсутствует бит A07, поэтому все адреса от F700-F77F дублируются на F780-F7FF
Дешифрацию поправил, с часами теперь все гуд. Только вопросик - если установить первым дату, потом при установке времени - дата сбивается и надо повторно запускать DATE. Если в первую очередь установить время, потом дату, то все гуд.
Добавил ручной безусловный установщик драйвера для CF-карты: CF$DRV.
Что с ним делать ? утилиты HDDFORMAT и HDDINFO не видят CF. Или его как то особенно надо запускать ?
Дешифрацию поправил, с часами теперь все гуд.
Отлично! Если не трудно, поделитесь тех. подробностями доработки для общественности.
Только вопросик - если установить первым дату, потом при установке времени - дата сбивается...
Сбивается на какую? "01.01.1900" или какую-то другую?
...и надо повторно запускать DATE. Если в первую очередь установить время, потом дату, то все гуд.
В данный момент под рукой только эмулятор, на нём воспроизвести эффект не удалось:
https://pp.userapi.com/c845120/v845120632/1f9abf/7dmiOfSmiYc.jpg
Вечером проверю на реале. За всю практику не сталкивался, впрочем возможно ни разу не запускал в такой последовательности, плюс у меня при (пере)загрузке каждый раз случается синхронизация с ORI-сервером..
Что с ним делать ? утилиты HDDFORMAT и HDDINFO не видят CF. Или его как то особенно надо запускать ?
Достаточно давняя история, мне надо будет освежить подробности. ЕМНИП, было что-то на тему детекта IDE-устройства..
Вероятно, драйвер-то я подправил под конкретную задачу, а в утилитах "Инфо" и "Формат" всё осталось по-прежнему, соответственно они и не видят CF-оборудование.
Sancho45
07.05.2019, 12:08
Проявляется при первой иниц., когда в ви1 мусор. Потом норм
https://i.ibb.co/4t6bpqr/20190507-150043.jpg (https://ibb.co/4t6bpqr)
https://i.ibb.co/TwVhBSS/20190507-150129.jpg (https://ibb.co/TwVhBSS)
https://i.ibb.co/mJB5Hxz/20190507-150206.jpg (https://ibb.co/mJB5Hxz)
Sancho45, занятно. Т.е. первый раз глюк срабатывает, а второй раз нет.
Может о5 какой-то фокус с "египетской" дешифрацией портов пула F7xx ? Попробуйте повторить опыты, но вызов утилиты DATE$ всегда выполняйте с параметром "-", как в моём примере. Это запретит обращение к СОМ-порту, которое она делает по-умолчанию для синхронизации с ORI-сервером.
Sancho45
07.05.2019, 12:45
но вызов утилиты DATE$ всегда выполняйте с параметром "-", как в моём примере.
параметр до даты или после даты ставить, во время установки даты ? или для выводя текущей даты ?
Достаточно давняя история, мне надо будет освежить подробности. ЕМНИП, было что-то на тему детекта IDE-устройства..
На СF карте данные не подтянуты к +5в и она не детектится , от переходника зависит....
параметр до даты или после даты ставить, во время установки даты ? или для выводя текущей даты ?
Только при выводе текущей даты с помощью утилиты. Во время установки даты параметр "-" ставить не нужно, в этом режиме обращение к СОМ-порту нет производится.
На СF карте данные не подтянуты к +5в и она не детектится , от переходника зависит....
Вечером посмотрю исходники утилит xINFO и xFMT, скорее всего там тоже в детекте используется притяжка шин к "1".
Sancho45
07.05.2019, 13:27
Только при выводе текущей даты с помощью утилиты.
тоже самое,сбивается дата при установке времени, но только когда мусор в ви1. Потом все в поряде
тоже самое,сбивается дата при установке времени, но только когда мусор в ви1. Потом все в поряде
Всё, теперь до меня дошло в чём дело!
Утилита DATE$ изначально была написана для ПРК без микросхемы аппаратных часов, понятие "дата" были чисто программное, показания даты при загрузке инициализировались датой файла BIOS, а далее пользователь с помощью утилиты мог менять это значение на актуальное.
Позднее появилась синхронизация с ORI-сервером и утилита научилась брать дату с большого брата при запуске без параметров.
И уже после всего этого появилась поддержка ВИ1, соответствующий функционал был "прикручен сбоку" и в утилиту DATE$.
Но! Данная утилита не производит инициализацию RTC, она только оперирует показаниями даты, и то - в случае, когда микросхема инициализирована (проверяется считыванием контрольной информации из спец. ячейки CMOS). Отсутствие инициализации утилита считает за отсутствие микросхемы, в этом случае работает по "старым тропам".
Напротив, утилита TIME$ была написана специально под железку ВИ1, она и выполняет инициализацию чипа, в т.ч. прописывает контрольную информацию.
П.С. т.е. всё верно работает, это не глюк, а "фича" :)
Sancho45
07.05.2019, 17:06
это не глюк, а "фича"
может костыль ?)) В алфавитном порядке первым идет Date, поэтому и запускал его, потом time ....
Добрался до DISM$ , как данные отделить ? Первый байт данных рисует как DB, следующие кажет как код ?
В шапке нет мануала . А коменты он умеет в автомате к известным портам и адресам ?))))
может костыль ?))
Можно назвать как угодно, но там оно всё логично с исторической точки зрения ;)
После введения в ОС поддержки ВИ1 у меня были мысли сделать общую утилиту RTC$, но всё же от этой идеи я отказался.
В алфавитном порядке первым идет Date, поэтому и запускал его, потом time ...
Замечание справедливое, спасибо. Постараюсь исправить в последующих сборках.
Добрался до DISM$ , как данные отделить ? Первый байт данных рисует как DB, следующие кажет как код ?
В шапке нет мануала .
Есть такой механизм. Нужно в текстовом редакторе создать файл, в котором будут перечислены области данных, например:
0000H-007FH
0510H-0517H
1001H-1003H
После чего скормить этот текстовый файл утилите MDAT$, она сгенерирует выходной файл ADDR.DAT - это зарезервированный файл, который DISM$ умеет использовать для отделения мух от котлет данных от кода.
Все файлы (в т.ч. DISM$) должны быть на одном диске.
А коменты он умеет в автомате к известным портам и адресам ?))))
Такое предполагалось сделать, но в своё время руки не дошли. Пока использую функцию поиска с заменой в текстовом редакторе :)
Sancho45
07.05.2019, 19:19
Есть такой механизм. Нужно в текстовом редакторе создать файл, в котором будут перечислены области данных, например:
Это же дизасм, откуда мне знать где там данные, если прога кажет их как код ?
И DASM.NfO в первую очередь воспринимается, как инфа к дизасм, а там к ASSM))
- - - Добавлено - - -
В алфавитном порядке первым идет Date, поэтому и запускал его, потом time ....
Поправка: в сборке 256, первой идет Time, ошибся, не помню почему Date первой запускал
Это же дизасм, откуда мне знать где там данные, если прога кажет их как код ?
Тогда я, видимо, не понял основного вопроса. Знать где код, а где данные может только человек, дизассемблер этого знать никак не может!
Возможно, продвинутые писишные дизассмы и научились какому-то ИИ (я не в курсе, не пользовался никогда), но на Орионе такое точно нереально.
Дизассемблирование это творческий процесс, и он всегда начинается с визуального изучения исходника в кодах и поиска блоков данных, о чём и сообщается дизассму.
В принципе, можно дизассемблировать и без этого, тогда DISM$ "скушает" весь дамп как исполняемый код, но для анализа полученный листинг будет непригоден.
DASM.NfO в первую очередь воспринимается, как инфа к дизасм, а там к ASSM))
Справка по дизассемблеру выводится при запуске DISM$ без параметров. В принципе этой информации вполне достаточно. Про MDAT$ я рассказал выше.
Если будут вопросы - спрашивайте, расскажу.
Поправка: в сборке 256, первой идет Time, ошибся, не помню почему Date первой запускал
Действительно. Я удивился, что в сборке может идти DATE$ первой, но поверил на слово и проверять не стал :)
Sancho45
08.05.2019, 05:02
Что с ним делать ? утилиты HDDFORMAT и HDDINFO не видят CF.
Отбой! заменил глюкавую лн1 в интерфейсе IDE и усЁ гуд. И винты теперь и на длинном шлейфе видны с первого раза. CF работает.
Тогда я, видимо, не понял основного вопроса.
Первоначально вопрос был правильно понят. Второе- это я уже так ....... после иды-это каменный век )))
после иды-это каменный век )))
После писи или даже андройд-девайса любая 8-битка это каменный век. Однако, форум ZX-PK до сих пор жив и здоров ;)
Скажу так, если бы мне дали программу, которая дизассемблирует сама, образно говоря "в один клик", то я бы ей пользоваться не стал - не интересно вообще. Равно как если бы мне дали ИИ, который пишет ПО по моему словесному описанию задачи, то я бы даже не попробовал это чудо.
Sancho45
08.05.2019, 13:21
Скажу так, если бы мне дали программу, которая дизассемблирует сама, образно говоря "в один клик", то я бы ей пользоваться не стал
Да ладно, так дизассемблер и делает это в пару нажатий. По вашей логике надо лист бумаги и карандаш, и половина кодов на память...., что я и делал надцать лет назад.
Речь шла об удобстве, а не о ИИ. Указал где код, а где данные и сиди думай, правильно или нет.... Вроде в предыдущем сообщении было-
Первоначально вопрос был правильно понят.
Не нашел просто инструкции.... и вспомнил , как это просто и интерактивно в ИДЕ
Не нашел просто инструкции...
Если нет рядом с программой текстового файла справки, то, как правило, информацию по использованию можно получить запустив программу с параметром "/?", либо вообще без параметров. В случае сложного ПО нагляднее почитать описание со скриншотами и примерами, например здесь в этой теме или в тематической группе ВК (https://vk.com/dsdos_orion).
Sancho45
08.05.2019, 14:52
Если нет рядом с программой текстового файла справки, то, как правило, информацию по использованию можно получить запустив программу с параметром "/?", либо вообще без параметров. В случае сложного ПО нагляднее почитать описание со скриншотами и примерами, например здесь в этой теме
Дык я о том !
В шапке нет мануала .
Не нашел просто инструкции....
shapipovo
26.11.2019, 20:28
А куда делся DC$?
А куда делся DC$?
Вот тут подробности - https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=895531&viewfull=1#post895531
- - - Добавлено - - -
и тут - https://vk.com/topic-139842174_35703989
Предновогодняя сборка ОС DSDOS v3.92 для Орион-ПРО.
Изменения:
► исправлена ошибка инициализации таймера ВИ53 при работе с портом COM2;
► новая версия утилиты тестирования портов COM1 и COM2;
► поддержка портов COM3 и COM4 на базе чипов 16C550;
► улучшенный BASIC v2.4 (с исправлением для процессора Z80).
▼▼▼ Ссылки для скачивания различных вариантов сборок ▼▼▼
"Стандарт-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s64.rar)
"Стандарт-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s256.rar)
"Игровая-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g64.rar)
"Игровая-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g256.rar)
"Программист-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p64.rar)
"Программист-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p256.rar)
Внутри архивов под объёмы 256 Кб находится два варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска, и четырьмя файлами по 64 Кб (файлы romdiskN.bin) для старого варианта диска (в составе мультикарты).
П.С. АРХИВЫ ОБНОВЛЕНЫ 04.01.2020 !!!
Некоторые пояснения по новой утилите TEST$COM.
Она заменяет две утилиты TEST$COM1 и TEST$COM2, входившие в прошлые сборки. Т.о. она позволяет проверять оба стандартных порта платы расширения COM/AY, построенных на базе микросхем КР580ВВ51 (82C51x).
https://sun9-39.userapi.com/c200520/v200520306/263e9/VPBpFVAIRs0.jpg
Выбор проверяемого порта осуществляется клавишей [Tab]. Переключение работает только в случае доступности обоих портов в системе. Если присутствует только какой-то один, то он будет активирован при загрузке программы по-умолчанию и переключение работать не будет. В случае отсутствия обоих портов утилита не запустится, а пользователю будет выведено соответствующее сообщение об ошибке.
Для удобства работы с утилитой, значения делителей для стандартных скоростей обмена (1200, 2400, 4800, 9600, 14400, 19200 и 38400 Бод) оформлены в виде пресетов, циклически перебираемых клавишами стрелок вверх/вниз.
При выходе из программы, запоминаются текущие настройки и режим работы в конфигурационном файле TCOM.CF на рабочем диске ОС. Также запоминается тестовая строка режима "Дамп". При последующих запусках утилиты параметры восстанавливаются из файла.
Если более не требуется сохранение конфигурации утилиты, то выход производится комбинацией [Shift]+[F4], в результате конфигурационный файл удаляется с рабочего диска и последующий запуск будет с параметрами по-умолчанию.
https://sun9-12.userapi.com/c200520/v200520306/263f1/VlCt-D4-RT4.jpg
Добрый день!
В релизе версии 3.92 для ОРИОН-ПРО (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=1040397&viewfull=1#post1040397) обнаружены ошибки (огромное спасибо @ АлександрПП !):
- некорректное сохранение файлов в квазидиске при превышении объёма 120 Кб;
- некорректная работа драйвера IDE.
Ошибки устранены, исправленные варианты сборок перезалиты 04.01.2020, ссылки для скачивания (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=1040397&viewfull=1#post1040397) прежние.
Коллеги прислали занятную ссылку - DSDOS online (http://zvzd3d.ru/Orion128/Orion128Main.html#ROMDisk_dsdos392)
Виртуально-виртуального диска и всяких вкусных железок конечно нет, но в качестве ознакомления для безреальщиков вполне годно :v2_thumb:
https://sun9-23.userapi.com/c205816/v205816163/33106/oQw8wSb3xaI.jpg
Пост-новогодняя сборка ОС DSDOS v3.93 для Орион-ПРО.
Изменения:
► добавлена поддержка RAM-диска (https://zx-pk.ru/threads/25327-periferiya-quot-orionpro-quot.html?p=814210&viewfull=1#post814210);
► улучшен функционал переименования файла в оболочке - теперь работает [Shift+6] / [Shift+F6];
► в оболочке добавлены две новые опции: вывод атрибутов [Y] и вывод контрольной- и XOR-суммы текущего файла[S];
► также в оболочке устранена ошибка: не работал вывод информации о текущем диске, если на нём не было ни одно файла;
► исправлена (старая) ошибка вычисления объёма диска;
► ускорено обновление каталогов дисков.
Далее подробнее.
RAM-диск
По-умолчанию поддерживается ОЗУ объёмом 1 Мб. В утилите SYSTEM$ будет отмечен соответствующий чекбокс "RAMD".
Традиционно, при обнаружении устройства на этапе загрузки ОС, драйвер подгружается по-умолчанию, в системе диск становится доступен как [E:]. Актуальный фактический объём 1016 Кб:
https://sun9-52.userapi.com/c855232/v855232357/1d4a3c/qxa9ZFqWISA.jpg
Форматирование диска производится автоматически на этапе загрузки драйвера, в случае, если он не был размечен ранее.
В "жирных" сборках "в нагрузку" включена утилита FMT$RAMD, с помощью которой можно выполнить принудительное быстрое форматирование RAM-диска.
В экспериментальных целях добавлен загружаемый пользователем драйвер отдельной (младшей) части [SRAM, 128 Кб] - SRAM$DRV, а также сопутствующая утилита форматирования - FMT$SRAM. При успешной загрузке драйвера, в системе становится доступен диск [H:], фактический объём 124 Кб.
Пока что большого практического смысла в этом диске лично я не вижу, но пусть будет "для галочки". Впоследствии возможно сделаю на его основе эмулятор ROM-диска [A:], т.к. информация сохраняется при выключении питания ПК.
Доработки оболочки SHELL
Иногда требуется просмотр информации о файле, которая не поместилась на экране в основных панелях, а именно - дата создания и номер рабочей страницы. Ранее приходилось либо нажимать "копирование" файла чтобы посмотреть его дату, либо выводить каталог директивой D через командную строку, и там смотреть информацию о странице ОЗУ нужного файла. В общем - не удобно! Для упрощения жизни добавлена клавиша [Y], по которой выводится соответствующая информация о текущем файле:
https://sun9-28.userapi.com/c855232/v855232704/1d3bdc/8Pw6P4KQt7U.jpg
Также из практики: периодически требуется узнать контрольную сумму файла. Для этого приходилось открывать его на просмотр по [F3] и там переходить в режим HEX-дампа [H] - долго, муторно. Теперь для этого сделана клавиша [S], заодно выводится и XOR-"сумма" текущего файла:
https://sun9-64.userapi.com/c855232/v855232704/1d3bd4/-ZCYgmTUKWc.jpg
Обновление каталога диска
Когда-то давно в DSDOS был использован "тяжёлый" и "неправильный" алгоритм подсчёта объёмов диска [занято, свободно, всего]. К тому же он давал ошибку на размер кластера диска. В версии ОС для ПРК "Орион-128" давно было исправлено, а для ПРО'шки, как выяснилось, нет. В данной версии изменён на правильный.
П.С. спасибо @АлександрПП за любезно предоставленную для отладки драйвера плату RAM-диска!
▼▼▼ Ссылки для скачивания различных вариантов сборок - прежние ▼▼▼
"Стандарт-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s64.rar)
"Стандарт-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s256.rar)
"Игровая-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g64.rar)
"Игровая-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g256.rar)
"Программист-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p64.rar)
"Программист-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p256.rar)
Внутри архивов под объёмы 256 Кб находится два варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска, и четырьмя файлами по 64 Кб (файлы romdiskN.bin) для старого варианта диска (в составе мультикарты).
san010101
20.03.2020, 19:55
Для орион 128.2 512к будет версия ОС DSDOS v3.93 ?
san010101, да, в планах стоит. Хотел совместить с поддержкой нового быстрого интерфейса IDE, но пока нет времени заняться его сборкой и отладкой.
Sancho45
05.05.2020, 15:58
И все таки проблемки с определением винтов на IDE(ВВ55) есть.
Появился у меня еще один винт ST351a/x. Всего 40мб, но тем не менее решил я его к ориону, погонять. Подключаю и..... автодетекта при запуске ОСи нет. Вспомнив, что автодетект работает по подтяжкам ШД к +5в, открыл на него доку(stason.org) и прочитал
The ST351A/X family drives do not use terminating resistors. Итого у меня 2 винта из 3-х без подтяжки и не определяются.
Соответственно буква ему не выделяется, даже если утилитами HDDinfo или HDDfmt удается инициализировать его.
Далее сам HDDinfo, если винт не инициализирован, чаще тупо висит, тайм аута в нем нет, как я понимаю. Самая полезная утилитка, CF$drv - всегда 100% инитит любой драйв и выходит.
После сброса системы, винт все равно не детектится, хоть и проинициализирован (подтяжка то так и не появилась) и буква харду не выделяется.
The ST351A/X family drives do not use terminating resistors. Итого у меня 2 винта из 3-х без подтяжки и не определяются.
ЕМНИП, в крайней версии детект по наличию подтяжек трёх линий. Напаять три резистора на плату "контроллера" и вопрос закрыт.
После сброса системы, винт все равно не детектится, хоть и проинициализирован (подтяжка то так и не появилась) и буква харду не выделяется.
Как писал ранее, корень проблемы из двух причин:
1) Неудачный выбор "стандарта" порта для IDE;
2) Слишком большое время детекта накопителя согласно стандарту IDE.
Из п.1 следует, что на порте пользователя #F6 может использоваться устройство, для которого "дрыганье произвольными линиями" при загрузке ОС - недопустимо!
И, например, у меня есть такое устройство - программатор Winbond'а. Произвольная подача напряжения программирования (+14в) и выборка кристалла могут привести к неприятным последствиям.
Из п.2 следует, что при отсутствии реального НЖМД на порте пользователя, загрузка ОС будет тупо висеть 30 сек. Оно такое надо? Имхо, нет.
Error404
06.05.2020, 13:14
ЕМНИП, в крайней версии детект по наличию подтяжек трёх линий. Напаять три резистора на плату "контроллера" и вопрос закрыт.
Всегда был только за то, чтобы если проблема решается "порезом и резистором" - делать порез и резистор. Орион не священная корова и далеко не эталон дальновидности (хотя конечно не RK-86 в котором вообще мрак) и чтобы на нем что-то приличное работало (а новое писалось не ценой прогрессирующего аутизма разработчика) - аппаратные адаптации делать надо. Главное чтобы они были просты, без дополнительных плат-аэродромов. Такое мое ИМХО.
1) Неудачный выбор "стандарта" порта для IDE;
2) Слишком большое время детекта накопителя согласно стандарту IDE.
Из п.1 следует, что на порте пользователя #F6 может использоваться устройство, для которого "дрыганье произвольными линиями" при загрузке ОС - недопустимо!
И, например, у меня есть такое устройство - программатор Winbond'а. Произвольная подача напряжения программирования (+14в) и выборка кристалла могут привести к неприятным последствиям.
Из п.2 следует, что при отсутствии реального НЖМД на порте пользователя, загрузка ОС будет тупо висеть 30 сек. Оно такое надо? Имхо, нет.
Нет никакого стандарта ИДЕ а Орионе, ни удачного, ни неудачного (но есть простая - а это важно потому что см. выше - схема на ВВ55, которая в силу своей удачности расползлась на все 8-битки, приятно что Орион был в числе первых таких клонов). Поэтому мне при адаптации этой схемы пришлось сделать что адрес ППА жестко указан только в одном месте - в ПЗУ с холодным загрузчиком ROM F800 (или MBOOT$), а далее при загрузке передается в ОС как параметр, которая сама себя пересчитывает на эти адреса. А все программы лазающие в IDE "напрямую" мимо ОС (такие бывают - FAT32, FDISK или например UZIX) работают через общий драйвер сырого доступа, который также имеет параметр - адрес порта. Сам я долгое время жил с IDE на F500 (без ром-диска).
Критичные устройства должны или иметь аппаратные особенности (ключи) для защиты от пропила (джампер хотя бы) или регламентом защищаться (по факту самодисциплиной, поломал - сам виноват :) ). Второе не дает 100% защиты, т.к. кроме человеческого фактора никто что ли не видел пропил памяти (когда экран моментально закрашивается стеком)? В особенности на самоделках типа Ориона. А такой стек и порты пропилит, и без всякой софтины IDE. Кстати, поломать "пропилом" данные на приводе IDE почти невозможно - там ведь регистры, а не прямые сигналы: слишком нерандомный рандом должен быть чтобы соответствующе выставить регистры.
Хотелось бы поблагодарить автора за то, что работает в данном направлении и очень грамотно. Как когда то писал Чистяков-главное софтверная поддержка. Желаю дальнейшего развития темы, могу чем смогу помогать. У меня собран недавно, причём, Орион на полностью 74 серии, на Z80 и память 256. Я по большей части "железячник". Нарисовал плату по образцу 1990 года из РАДИО, остальные платы лишь интерфейсный размер 95х95 соблюдая сам развёл.
Ugloff, спасибо на добром слове!
Железячная помощь была бы кстати, приемущественно по части макетирования новых разработок и разводки плат.
Если не трудно, можете отметиться здесь - https://zx-pk.ru/threads/27165-perepis-naseleniya.html
Ещё интереснее - с фото.
Платы мое любимое, конечно. Вот кое что нарисовал из твоих схем(рисованы рукой, но догадка радиоинженера спасает, чтоб прочесть). Развел, но пока не изготовил, напимер, rtc на ви1.
Быть может мой вопрос прозвучит ламерски или станет следствием невнимательности. Но в утилите SYSTEM$ есть пункт по поводу AY, в шапке в разделе Hardware я не нашёл точной схемы подключения. Всё, что я лично об этом знаю-то, что писал Чистяков когда то в 90х. Хотелось бы ссылку/схему, ну конечно в случае если хоть одна программа/игра её поддерживает :) Спасибо.
...в утилите SYSTEM$ есть пункт по поводу AY, в шапке в разделе Hardware я не нашёл точной схемы подключения
Всё верно! На Орионе-ПРО посадка AY стандартизирована авторами и имеет готовую аппаратную реализацию в виде соответствующей карты расширения, программно в DSDOS поддержана плеером от Дмитрий2012.
На Орионе-128 зарезервирована посадка AY по адресам F7Ax (схема включения стандартная), но готовой аппаратной реализации у меня пока нет, в связи с этим отложено написание соответствующего ПО под данную платформу. В утилите SYSTEM$ обнаружение AY реализовано.
Что-то не получается стартануть DS-DOS с ROM-диска на OrionPro. Мусор на экране и зависон. Странно. Сам ROM-диск работает, в мониторе через команды O/I данные успешно читаются. Диск собран по схеме из темы про периферию Ориона-ПРО. Ни у кого таких проблем небыло?
Romych, в диск прошита сборка для ОРИОН-ПРО ? Перемычки на плате по феньшую выставлены?
Да, конечно для Орион ПРО отсюда (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=1042795&viewfull=1#post1042795). Странно, если отключить загрузку с ROM-диска, потом в power-командере, если переключать ПЗУ-шки, то файлы видны только на 3-ей ПЗУ-шке (KERN, CONIO, IDE2, SYSTEM$ и т.п. игр несколько), на 1-й и 2-й пусто, а на 0-вой один странный файл с названием WRITING.
Сечас залит образ 256к в играми. Пробовал программерский, тоже так же не грузится. В ROM-диске стоит W27C020.
Такое ощущение, что страницы перепутаны. Однако, если бы это было так, Орион не находил бы ROM-диск при загрузке вообще, т.к. не нашел бы сигнатуру, а он находит и пробует грузиться.
Проверял шифратор ROM-диска, получается что-то такое:
port 2c A16 A17
0001 1 1
0010 1 0
0100 0 1
1000 0 0
Получается, что действительно страницы идут задом наперед. А вообще, курильщик его разрабатывал, в исходном ROM-диске можно было программно врубить 2 ПЗУ одновременно на чтение, неужели нельзя было добавить в схему дешифратор? А в современной схеме с большой ПЗУ, его просто убрать и не пихать в схему шифратор.
- - - Добавлено - - -
Интересно, записал на все 4 страницы одинаковые образы (объеденил 4 64-х килобайтных) и все загрузилось!
а на 0-вой один странный файл с названием WRITING.
Такого в сборках точно нет.
Такое ощущение, что страницы перепутаны. Однако, если бы это было так, Орион не находил бы ROM-диск при загрузке вообще, т.к. не нашел бы сигнатуру, а он находит и пробует грузиться.
Там нет никаких проверок. Максимум что может быть - проверка на 00h и FFh (типа чистую ПЗУ или её отсутствие), и то вряд ли.
История с сигнатурой это для ROM-диска в новом формате.
Проверял шифратор ROM-диска, получается что-то такое:
port 2c A16 A17
0001 1 1
0010 1 0
0100 0 1
1000 0 0
Выборка кристалла соответствующей ПЗУ (в оригинальном диске на чипах по 64 Кб) осуществляется уровнем "0". Тут наблюдается какая-то инверсная логика...
А вообще, курильщик его разрабатывал, в исходном ROM-диске можно было программно врубить 2 ПЗУ одновременно на чтение
Не то что две, а все четыре можно! Это конечно лютый треш, согласен.
Denn, спасибо за пояснения и за интересную ОС. Еще раз проверю работу шифратора, может я чего напутал, хоть вроде и проверял всё. А "WRITING" там и правда есть в начале файла romdisk3.bin в игровой ПЗУ, но это не файл, конечно, а просто кусочек строки "INPUT NUMBER OF WRITING PLAN (1-5)?", который power commander воспринимает как имя файла.
- - - Добавлено - - -
Проверил, странно, у меня все равно выборка идет "1" битом порта 2C, как не крути. Я рисовал плату и схему ROM-диска по файлу DIP-Drace от АлександраПП из темы про периферию Ориона ПРО.
Загнал кусок схемы, относящейся к шифратору в симулятор, получил логику работы полностью совпадающую с моей платой.
Раз у всех нормально работает ROM-диск, то получается, что файл АлександраПП не соответствует тем платам, на которых все собирали ROM-диски.
Проверил, странно, у меня все равно выборка идет "1" битом порта 2C, как не крути. Я рисовал плату и схему ROM-диска по файлу DIP-Drace от АлександраПП из темы про периферию Ориона ПРО.
Загнал кусок схемы, относящейся к шифратору в симулятор, получил логику работы полностью совпадающую с моей платой.
Посмотрел схему, а там выходы на чипселекты берутся с инверсных выходов порта ТМ8. Получается, что программно мы выбираем нужный бит "1", а на ПЗУ всё приходит как надо - "0".
Странные чедеса происходят на Орионе-ПРО с частотой CPU, раньше такого не замечал.
Не пойму где проблема? Частоту ведь можно на 2,5 только программно поменять?
Этот глюк проявляется только с установленной платой IDE-RTC (и то и то работает)
Romych, прикольно. Т.е. аппаратно не переключается клок ЦП. Что-то с конфигурационной ВВ55, видимо.
Не, реально если твоя утилита пишет 2,5, то и клок на процессоре 2,5. Только он слетает сам.
Экспериментально, удалось вылечить, вытянул 82с55 из платы ROM-IDE (F600h) и глюк пропал. Причем диск на F600 работал в Altair DOS, но, понятное дело, не работал в DSDOS. Причем и Орион с двумя дисками пускается нестабильно. Видимо уже просто перебор по количеству ВВ55 на шине данных :)
Сейчас у меня на Орионе в DSDOS стабильно работают RTC (на KS82C6818A), RAM-Диск 1Мб, IDE на IDE-RTC. Непонятно ведет себя SRAM-Диск, не сохраняет данные. При запуске SRAM$DRV его точно не очищает? У меня 3 разных DS1245Y, одна точно должна быть нормальная, по крайней мере похожа на настоящую. Над одной я надругался:), но батарея была напряжением 2,9В - как бы достаточно. Ну да ладно, я в мониторе попробую через порты ее потестировать еще.
При запуске SRAM$DRV его точно не очищает?
"Форматирование диска производится автоматически на этапе загрузки драйвера, в случае, если он не был размечен ранее."
Последняя сборка DSDOS 3.93 (Программерская). Вчера сделал небольшой ассемблерный файл, который отлично компилировал ASSM$. На ночь, скопировал его с квази-диска на флоппи. Утром вернул обратно. Визуально внутри файла ничего не изменилось. Но теперь, ассемблер выдает на первом проходе ошибку "Ошибка формата".
При загрузке файлов производится проверка формата, и если файл не является текстовым, то работа компилятора прерывается с сообщением: "Ошибка формата".
Файл без проблем редактируется встроенным редактором. Denn, вопрос, по каким критериям ASSM$ определяет, что файл текстовый?
вопрос, по каким критериям ASSM$ определяет, что файл текстовый?
При загрузке файлов производится проверка формата, и если файл не является текстовым, то работа компилятора прерывается с сообщением: "Ошибка формата". (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=933658&viewfull=1#post933658)
Текстовый файл представляет собой набор строк, разделённых символом перевода строки (ASCII-код 0Dh). Признаком конца текстового файла является символ с кодом FFh.
Каждая строка может иметь длину от 0 до 255 символов с кодами от 20h до FEh включительно (расширенная кодировка ОС DSDOS, ExtASCII).
Символы с кодами от 00h до 0Ch и от 0Eh до 1Fh включительно не используются и считаются ошибочными для данного формата (https://vk.com/topic-139842174_39352955?post=145)
- - - Добавлено - - -
Визуально внутри файла ничего не изменилось.
Сравнение файлов (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=895531&viewfull=1#post895531) с разных дисков подтверждает совпадение?
Но теперь, ассемблер выдает на первом проходе ошибку "Ошибка формата".
Показывает в каком месте ошибка?
Denn, спасибо за более чем подробный ответ. Оказалось все просто. На дискете "сломался" файл DSDOS.L, который подключен через INCL, я брал за основу шаблон, который шел в комплекте NEW.AS.
Плохо, что ассемблер не показал место ошибки. В данном случае, это оказался вообще другой файл.
Плохо, что ассемблер не показал место ошибки. В данном случае, это оказался вообще другой файл.
По хорошему, каждое ПО требует целой "жизни" или работы команды разработчиков, тогда будут свистелки, рюшечки и прочие удобства. Когда делаешь в одиночку ВСЁ, то на каждую задачу выделяется квант времени, и что успелось, то и имеем. А так задумок по "допиливанию" ассемблера много, конечно...
Я не критикую же, спасибо за то, что есть.
Доброго дня. Всех с наступающими праздниками!
Традиционное предновогоднее обновление, на этот раз для обеих платформ: версия 3.93r для Орион-128 и версия 3.94r для Орион-ПРО.
Список изменений:
► исправлена неприятная ошибка в процедуре чтения тела файла определённого размера с ГМД;
► исправлена ошибка обнуления показаний секунд RTC при "холодной" загрузке ОС;
► устранены редко проскакивающие глюки в показаниях даты и времени в оболочке;
► присутствующий в сборках BASIC$ для всех платформ - версии 2.4 (с исправлением для процессора Z80);
► исправления по SDK "программерских" сборок:
- добавлены библиотеки COLOR.L и WUI.L
- добавлен пример кода обработки командной строки CMD.AS
- отсутствовал в сборках файл рабочей среды ED.INI
- была ссылка на некорректное имя файла шаблона NEW.AS
► мелкие изменения некоторых горячих клавиш в оболочке (Ctrl+W продублировано на [W] вместо выхода);
► в сборках более 64 Кб добавлен текстовый файл SHELL.HP с описанием горячих клавиш оболочки;
► изменён цвет отображения количества файлов в панелях оболочки;
► в сборках для Орион-128 также добавлен функционал (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=1042795&viewfull=1#post1042795), который был доступен ранее для Орион-ПРО:
- улучшен функционал переименования файла в оболочке - теперь работает [Shift+6] / [Shift+F6];
- в оболочке добавлены две новые опции: вывод атрибутов [Y] и вывод контрольной- и XOR-суммы текущего файла [S].
▼▼▼ Ссылки для скачивания обновлённых вариантов сборок ▼▼▼
Для ПРК ОРИОН-128/512:
https://forum-img.guitarplayer.ru/2021/01/04/oilUf.png
ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s64.rar)
ПЗУ ROM-диска объёмом 128 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s128.rar)
ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s256.rar)
ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s512.rar)
ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s1024.rar)
специализированная "программерская", ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p512.rar)
специализированная "программерская", ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p1024.rar)
Для ПК ОРИОН-ПРО:
https://forum-img.guitarplayer.ru/2021/01/04/oiot4.png
"Стандарт-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s64.rar)
"Стандарт-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s256.rar)
"Игровая-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g64.rar)
"Игровая-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g256.rar)
"Программист-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p64.rar)
"Программист-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p256.rar)
Внутри архивов под объёмы 256 Кб находится два варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска, и четырьмя файлами по 64 Кб (файлы romdiskN.bin) для старого варианта диска (в составе мультикарты).
П.С. АРХИВЫ ОБНОВЛЕНЫ 04.01.2021 !!!
Молодец, Denn, спасибо за подарок под елку, прямо к новому году!
sergey_sitnik
31.12.2020, 18:44
Да это реальный подарок!!! Спасибо!!! Поторопился я, три ПЗУ запрограммировал.... уже, придется "повторить" !
Всех с наступающим новым годом!!!
Также традиционные пост релизные поправки =)
Спасибо комраду Ugloff, он обнаружил неработоспособность команды LOAD в Бэйсике. Проблема, вероятно, возникла с выходом 31.12.2018 версии 3.9 (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=993125&viewfull=1#post993125), и связана с изменением алгоритмов эмуляции API ORDOS. Расследование показало недокументированное использование п/п поиска файла (BFE5h) в Бэйсике, вероятно автор знал устройство кода ORDOS и решил "срезать угол". В старом варианте эмуляции недокументированная "фича" случайно совпала и проблем не было, в новой эмуляции код изменился и оно уже "не прокатывает". Возможно ещё какое-то ПО под ORDOS использует данную лазейку.
Заплатку сделал, сборки пересобрал, архивы обновил (ссылки те же). Кому важна загрузка файлов в Бэйсике, придётся перепрошить ROM-диск.
П.С. в том же Бэйсике команда FILES не работает и работать под DSDOS не будет! Это связано с очень глубоким некорректным использованием ресурсов ОС: вместо запроса списка файлов на диске через соотв. п/п ОС, код Бэйсика сам сканирует структуру квазидиска в ОЗУ второй страницы и ищет свои файлы. В DSDOS квазидиск устроен совершенно иначе и такой вид обработки невозможен.
Работа над ошибками продолжается. Совершенно неожиданным "сюрпризом" всплыл издавна притаившийся баг в драйвере IDE, причём для обеих платформ.
До некоторого момента баг себя никак не проявляет, я например три года работал на Орионе и напоролся только сейчас!
Суть ошибки в следующем, при вычислении старшего байта LBA, в причинном месте кода пропущена команда сдвига регистра, в результате ненулевые значения этого байта оказываются как бы умноженные на два, а данные некорректно "разбросаны" по жёсткому диску.
На практике это выливается в следующее. Файлы в корневом каталоге, а также подкаталоги первого уровня работают без ошибок, данные локализуются в правильных местах на диске, ошибка никак не проявляется.
Подкаталоги второго уровня вложенности локализуются в некорректных областях, и до некоторого их количества делают вид что работают корректно. Начиная с некоторого "магического" номера (по счёту), попытка зайти в подкаталог приводит к фатальной ошибке диска, приходится перезагружаться. А начиная с некоторого другого "магического" номера, данные записанные в один подкаталог, всплывают (дублируются) в другом... это происходит из-за того, что драйвер пытается выставить винчестеру несуществующий сектор, что приводит к отбрасыванию лишних бит и формированию некорректного LBA.
Ошибка очень печальная, т.к. её устранение приводит к недоступности ранее записанных файлов в подкаталогах второго уровня.
В связи с чем решил пока не убирать предыдущие версии сборок ОС от 04.01.2021, а исправленные выложить отдельными архивами.
Кто не пользуется НЖМД и не предполагает это делать в дальнейшем, те могут игнорировать данный пост и пользоваться ранее прошитой сборкой ОС DSDOS.
Кто не пользовался НЖМД, но планирует, а также тем, кто пользуется, но пока не глубже подкаталогов первого уровня, настоятельно рекомендую обновиться на исправленную версию для соответствующей платформы (см. ниже).
И самый тяжёлый вариант для тех, кто пользуется подкаталогами второго уровня вложенности - придётся переносить данные из старой разметки на новую, например через другие диски. Либо не обновлять ОС, но при этом не пытаться создавать новые подкаталоги!
Также в новых версиях по просьбам трудящихся сделана небольшая доработка команды ОС сохранения дампа ОЗУ в файл - можно указать номер страницы ОЗУ сохраняемого дампа:
S [d:]Filename Addr,Long [/n]
где
d - диск (A..H)
Filename - имя файла
Addr - физический адрес начала дампа (адрес посадки файла)
Long - длина дампа
n - 0..7 номер страницы ОЗУ (по-умолчанию 0) или как ранее: P - защита от удаления.
Номера исправленных версий для обеих платформ увеличены: 3.94 для Орион-128 и 3.95 для Орион-ПРО, соответственно. Сборки от 14.01.2021.
▼▼▼ Ссылки для скачивания сборок исправленных версий ▼▼▼
Для ПРК ОРИОН-128/512:
ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s64.zip)
ПЗУ ROM-диска объёмом 128 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s128.zip)
ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s256.zip)
ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s512.zip)
ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s1024.zip)
специализированная "программист", ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p512.zip)
специализированная "программист", ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p1024.zip)
Для ПК ОРИОН-ПРО:
"Стандарт-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s64.zip)
"Стандарт-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s256.zip)
"Игровая-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g64.zip)
"Игровая-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g256.zip)
"Программист-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p64.zip)
"Программист-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p256.zip)
Внутри архивов под объёмы 256 Кб находится два варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска, и четырьмя файлами по 64 Кб (файлы romdiskN.bin) для старого варианта диска (в составе мультикарты).
П.С. Файлы, записанные на НЖМД прошлыми версиями ОС могут быть недоступны!!!
А когда DS DOS увидит 1 Мб ОЗУ?
А когда DS DOS увидит 1 Мб ОЗУ?
Всё забываю, что на планете Земля существует один "метровый" Орион :)
Сделать детект 1024 Кб ОЗУ можно, ни вопрос! Но практической пользы в третьем поколении ОС - никакого, т.к. ПО не знает про такие конфигурации и использовать память выше 512 Кб не будет.
В четвёртом поколении ОС будет детект до 4 (или даже до 16) Мб ОЗУ, и там оно будет реально использоваться.
Судя по 3.94 недолго осталось.
Держись дядя Федор, всего три платья осталось! :)
Судя по 3.94 недолго осталось.
Проект "трёшки" логически завершён. Там уже достигнуты всевозможные ограничения, дальше просто некуда развивать данный концепт.
Новые версии 3.хх - это работа над ошибками, плюс пожелания трудящихся.
"Четвёрка" это совсем другая история, как раз ориентированная на "жирное" железо, большие объёмы всевозможной памяти, гибкость. Там есть куда расти и развиваться.
Держись дядя Федор, всего три платья осталось! :)
Тут, как говорится, "всё сложно". Проект начат в 2018 году, но изначально слишком масштабен и сложен, поэтому до сих никаких результатов, которые можно пощупать нет.
Очень надеюсь, что в этом году появятся первые версии, но "это не точно".
Electricman
22.01.2021, 00:19
Раз тут вышло обновление, то что ж не обновиться то до новой версии. :) Загнал версию 128кБ (загнал бы и 256, но это сложнее) и наступил на грабли. При старте и начальной установке портов, в дополнительный триггер ROM-диска что-то пишется уже после сигнала сброса, а с "автономным" сбросом компьютер перезагружается только по питанию. Неприятно немного, ну да ладно.
Кстати, а почему всё прошло мимо классической флэш-памяти, она же ЭСППЗУ? Энергонезависимо, в отличие от СОЗУ, перепрограммируется просто. Просто с СОЗУ больших объёмов у меня проблемы, а всяких 29F1610 пруд-пруди. :) Или я просто где-то что-то пропустил по этому поводу? :)
При старте и начальной установке портов, в дополнительный триггер ROM-диска что-то пишется уже после сигнала сброса, а с "автономным" сбросом компьютер перезагружается только по питанию.
Прочёл несколько раз - не понял(
Опиши проблему подробнее, плз.
Кстати, а почему всё прошло мимо классической флэш-памяти
Видимо, потому, что флэш-память прошла мимо меня :)
Энергонезависимо, в отличие от СОЗУ, перепрограммируется просто.
Никак нет. В своё время я пытался "вгрызаться" в алгоритмы прошивки флэш-ПЗУ, там нет линейного режима и произвольного доступа, там как-то очень заморочно секторами пишется, мудрёный алгоритм прошивки. Забил именно из-за сложности, т.к. проверить было не на чем, а писать поддержку железки без самой железки это практически бессмысленно.
Просто с СОЗУ больших объёмов у меня проблемы
Могу заслать, их есть у меня разных.
- - - Добавлено - - -
а всяких 29F1610 пруд-пруди
Если есть чем зашить, то без проблем можно в качестве ROM-диска использовать.
Electricman
22.01.2021, 21:23
Прочёл несколько раз - не понял(
Опиши проблему подробнее, плз.
Суть - кривовато у меня работает расширенный ROM-диск по схеме с первой страницы. И причина вот какая - при сбросе и установке ВВ55 происходят неопределённости, ТТЛ регистр ТМ8 пишет мусор от болтающихся входов. И в результате выбрано всё, что угодно, кроме младших 64кБ диска. Если сброс RC-цепью - то подбирая можно добиться, что сигнал 1 на входе /R регистра появится позже настройки портов - в результате на выходах 0, выбраны младшие 64кБ. Но он автономен и работает только при подаче питания. Нажимаем сброс - неопределённости - мусор в регистре. А внутренний сброс компьютера пропадёт раньше неопределённостей на выводах регистра. Как-то так, выяснил при расследовании. :)
В своё время я пытался "вгрызаться" в алгоритмы прошивки флэш-ПЗУ, там нет линейного режима и произвольного доступа, там как-то очень заморочно секторами пишется, мудрёный алгоритм прошивки.
Ну, при записи нет - а при чтении как обычная память. Пишется секторами по 128 байт, перед этим - несколько байт "активации" записи. Да, надо добивать программы до объёма, кратного 128. Но тут тоже жёсткой привязки вроде как нет. Сектор вроде как можно начать хоть с адреса 0000h, хоть с 0002h. Впрочем, это так, чисто спортивный интерес - сам не пробовал, хотя было бы интересно, может руки дойдут. :) А то их тут на 15 десятка мБ, а если писать/читывать словами - все 30 :)
Суть - кривовато у меня работает расширенный ROM-диск по схеме с первой страницы. И причина вот какая - при сбросе и установке ВВ55 происходят неопределённости, ТТЛ регистр ТМ8 пишет мусор от болтающихся входов. И в результате выбрано всё, что угодно, кроме младших 64кБ диска. Если сброс RC-цепью - то подбирая можно добиться, что сигнал 1 на входе /R регистра появится позже настройки портов - в результате на выходах 0, выбраны младшие 64кБ. Но он автономен и работает только при подаче питания. Нажимаем сброс - неопределённости - мусор в регистре. А внутренний сброс компьютера пропадёт раньше неопределённостей на выводах регистра.
При подаче питания ПРК, причинный триггер сбрасывается в "банк №0" при помощи RC-цепочки. Установка триггера возможна только положительным перепадом на стробирующем входе, тобишь от соответствующей линии порта клавиатуры.
Загрузчик ОС DSDOS работает только с нулевым банком, переключать он не умеет. После того, как отработает загрузчик, RC-цепь должна уже перестать "давить на сброс". Далее, сама ОС переключает банки только в момент сканирования каталога диска и чтения файлов с него, после каждой операции номер банка принудительно сбрасывается на нулевой, т.о. загрузчик монитора корректно отрабатывает после любой перезагрузки ПРК - как программной, так и аппаратной.
Идеально было бы на сброс триггера вместо RC-цепочки завести общий сигнал /RESET.
Ни разу с данным узлом проблем не было.
Что могу подозревать в твоём случае. В момент аппаратного сброса портов ВВ55, их выводы переключаются в Z-состояние, т.е. фактически в этот момент стробирующий вход триггера повисает в воздухе. Далее монитор настраивает порт клавиатуры, и на его выходах устанавливаются лог."0". Если используется микросхема 155-ой серии, то она в "висячем" состоянии умеет сама себе наводить лог."1", соответственно будет ложное защёлкивание мусора с также зависшей в воздухе ША ROM-диска. С микросхемами 555 и 1533 серий такого эффекта нет, видимо поэтому ни у кого не проявлялось ещё.
Могу посоветовать сделать подтяжку стробирующего входа триггера к общему (GND) через резистор 2 ком, скорее всего проблема уйдёт.
- - - Добавлено - - -
П.С. наверное я перепутал 155-ю серию с 1533-ей... не суть, наводка может быть в любом случае, и глюкавость будет зависеть от конкретного монтажа, поэтому лучше изначально сделать подтяжку сигнала к общему.
Electricman
22.01.2021, 22:31
Ну, я это и имел ввиду, говоря болтающихся входах и неопределённостяъ - 155ая серия хорошо тянет входы к единице, поэтому даже резистор строб-общий в 1кОм не помогает, не говоря уж о выводах ВВ55, которые после сброса являются входами и явно не тянут выводы к общему. :) Наверное, проще поставить 555ую серию.
поэтому даже резистор строб-общий в 1кОм не помогает, не говоря уж о выводах ВВ55, которые после сброса являются входами и явно не тянут выводы к общему
Злее 2 ком я бы не стал тянуть, там же ещё сам вход триггера, а у 580-ой серии оч слабая нагрузочная способность.
Electricman
25.01.2021, 02:00
Злее 2 ком я бы не стал тянуть
Что поделать, ТТЛ - такая вещь, резистор даже в 1кОм она может не заметить. :) Но пока для пробы воткнул КМОП - там всё хорошо притягивается. Стартует и перезагружается комп нормально, только сказывается быстродействие - ну, для пробы я воткнул древнейшую 4076, при чтении старшей части сбоит. :)
Теперь очередь за часиками и расширением памяти - 120кБ, конечно, за глаза, но лишним не будет.
только сказывается быстродействие - ну, для пробы я воткнул древнейшую 4076, при чтении старшей части сбоит.
Из КМОП отлично подойдут: 74HC175, 74HCT175, 74ACT175, 74AC175
Electricman
25.01.2021, 16:33
74HC175, 74HCT175, 74ACT175, 74AC175
Чего нет - того нет. :) Решил всё просто - неинвертирующая цепь на КМОПе по тактовому входу.
Решил всё просто - неинвертирующая цепь на КМОПе по тактовому входу.
Тоже вариант. Но мне кажется, резистор-подтяжка помог бы на 146%.
Два минорных дополнения по вашим просьбам.
1) В сборках для ОРИОН-128 загрузчик ОС определяет ОЗУ до 1024 Кб;
2) В сборках для ОРИОН-ПРО, для дисков на 256 Кб добавлен файл romdisk_0x3.bin с "кривой" (поменяны местами банки 0 и 3) прошивкой - для владельцев соответствующих версий плат.
Номера версий ОС для обеих платформ сравнялись - 3.95
Изменения коснулись только ZIP-архивов последних (с исправленной ошибкой в драйвере IDE) версий ОС.
▼▼▼ Ссылки для скачивания сборок прежние ▼▼▼
Для ПРК ОРИОН-128/512:
ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s64.zip)
ПЗУ ROM-диска объёмом 128 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s128.zip)
ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s256.zip)
ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s512.zip)
ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_s1024.zip)
специализированная "программист", ПЗУ ROM-диска объёмом 512 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p512.zip)
специализированная "программист", ПЗУ ROM-диска объёмом 1024 Кб (http://denn.ru/8bit/orion/soft/dsdos-128_p1024.zip)
Для ПК ОРИОН-ПРО:
"Стандарт-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s64.zip)
"Стандарт-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_s256.zip)
"Игровая-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g64.zip)
"Игровая-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_g256.zip)
"Программист-64", ПЗУ ROM-диска объёмом 64 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p64.zip)
"Программист-256", ПЗУ ROM-диска объёмом 256 Кб (http://denn.ru/8bit/orion/soft/dsdos-pro_p256.zip)
Внутри архивов под объёмы 256 Кб находится три варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска с корректной разводкой платы, полным образом для платы с ошибкой A0<->A3 (файл romdisk_0x3.bin) и четырьмя файлами по 64 Кб (файлы romdiskN.bin) для старого варианта диска (в составе мультикарты).
П.С. Файлы, записанные на НЖМД прошлыми версиями ОС могут быть недоступны!!! (подробности тут (https://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=1099101&viewfull=1#post1099101))
Обновил систему. У меня 1024 кб не увидел.
Обновил систему. У меня 1024 кб не увидел.
К сожалению, на реале не имею возможности проверить - за неимением такового с 1 Мб ОЗУ. Но эмулятору от b2m склонен доверять:
https://forum-img.guitarplayer.ru/2021/02/04/rzGXh.png
https://forum-img.guitarplayer.ru/2021/02/04/rzNrP.png
Подождем, что остальные владельцы мегабайтных Орионов скажут
Подождем, что остальные владельцы мегабайтных Орионов скажут
Предлагаю не ждать, а попробовать так:
1) Открываем редактор (в "нортоне" кнопка "ЗБ")
2) Набираем следующий текст программы:
https://forum-img.guitarplayer.ru/2021/02/04/rzjNV.png
3) Нажимаем [АР2] затем [A]
4) Выполняем скомпилированную программу:
https://forum-img.guitarplayer.ru/2021/02/04/rzkV2.png
5) Если результат как на скрине (0F), то у нас честно доступен 1 Мб ОЗУ.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot