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

[Denn]

При запуске SRAM$DRV его точно не очищает?

"Форматирование диска производится автоматически на этапе загрузки драйвера, в случае, если он не был размечен ранее."

[Romych]

Последняя сборка DSDOS 3.93 (Программерская). Вчера сделал небольшой ассемблерный файл, который отлично компилировал ASSM$. На ночь, скопировал его с квази-диска на флоппи. Утром вернул обратно. Визуально внутри файла ничего не изменилось. Но теперь, ассемблер выдает на первом проходе ошибку "Ошибка формата".

При загрузке файлов производится проверка формата, и если файл не является текстовым, то работа компилятора прерывается с сообщением: "Ошибка формата".

Файл без проблем редактируется встроенным редактором. Denn, вопрос, по каким критериям ASSM$ определяет, что файл текстовый?

[Denn]

вопрос, по каким критериям ASSM$ определяет, что файл текстовый?

При загрузке файлов производится проверка формата, и если файл не является текстовым, то работа компилятора прерывается с сообщением: "Ошибка формата".

Текстовый файл представляет собой набор строк, разделённых символом перевода строки (ASCII-код 0Dh). Признаком конца текстового файла является символ с кодом FFh.
Каждая строка может иметь длину от 0 до 255 символов с кодами от 20h до FEh включительно (расширенная кодировка ОС DSDOS, ExtASCII).

Символы с кодами от 00h до 0Ch и от 0Eh до 1Fh включительно не используются и считаются ошибочными для данного формата

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

Визуально внутри файла ничего не изменилось.

Сравнение файлов с разных дисков подтверждает совпадение?

Но теперь, ассемблер выдает на первом проходе ошибку "Ошибка формата".

Показывает в каком месте ошибка?

[Romych]

Denn, спасибо за более чем подробный ответ. Оказалось все просто. На дискете "сломался" файл DSDOS.L, который подключен через INCL, я брал за основу шаблон, который шел в комплекте NEW.AS.
Плохо, что ассемблер не показал место ошибки. В данном случае, это оказался вообще другой файл.

[Denn]

Плохо, что ассемблер не показал место ошибки. В данном случае, это оказался вообще другой файл.

По хорошему, каждое ПО требует целой "жизни" или работы команды разработчиков, тогда будут свистелки, рюшечки и прочие удобства. Когда делаешь в одиночку ВСЁ, то на каждую задачу выделяется квант времени, и что успелось, то и имеем. А так задумок по "допиливанию" ассемблера много, конечно...

[Romych]

Я не критикую же, спасибо за то, что есть.

[Denn]

Доброго дня. Всех с наступающими праздниками!
Традиционное предновогоднее обновление, на этот раз для обеих платформ: версия 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 также добавлен функционал, который был доступен ранее для Орион-ПРО:
- улучшен функционал переименования файла в оболочке - теперь работает [Shift+6] / [Shift+F6];
- в оболочке добавлены две новые опции: вывод атрибутов [Y] и вывод контрольной- и XOR-суммы текущего файла [S].


▼▼▼ Ссылки для скачивания обновлённых вариантов сборок ▼▼▼

Для ПРК ОРИОН-128/512:




ПЗУ ROM-диска объёмом 64 Кб

ПЗУ ROM-диска объёмом 128 Кб

ПЗУ ROM-диска объёмом 256 Кб

ПЗУ ROM-диска объёмом 512 Кб

ПЗУ ROM-диска объёмом 1024 Кб

специализированная "программерская", ПЗУ ROM-диска объёмом 512 Кб

специализированная "программерская", ПЗУ ROM-диска объёмом 1024 Кб


Для ПК ОРИОН-ПРО:




"Стандарт-64", ПЗУ ROM-диска объёмом 64 Кб
"Стандарт-256", ПЗУ ROM-диска объёмом 256 Кб

"Игровая-64", ПЗУ ROM-диска объёмом 64 Кб
"Игровая-256", ПЗУ ROM-диска объёмом 256 Кб

"Программист-64", ПЗУ ROM-диска объёмом 64 Кб
"Программист-256", ПЗУ ROM-диска объёмом 256 Кб

Внутри архивов под объёмы 256 Кб находится два варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска, и четырьмя файлами по 64 Кб (файлы romdiskN.bin) для старого варианта диска (в составе мультикарты).


П.С. АРХИВЫ ОБНОВЛЕНЫ 04.01.2021 !!!

[Romych]

Молодец, Denn, спасибо за подарок под елку, прямо к новому году!

[sergey_sitnik]

Да это реальный подарок!!! Спасибо!!! Поторопился я, три ПЗУ запрограммировал.... уже, придется "повторить" !
Всех с наступающим новым годом!!!

[Denn]

Также традиционные пост релизные поправки =)

Спасибо комраду Ugloff, он обнаружил неработоспособность команды LOAD в Бэйсике. Проблема, вероятно, возникла с выходом 31.12.2018 версии 3.9, и связана с изменением алгоритмов эмуляции API ORDOS. Расследование показало недокументированное использование п/п поиска файла (BFE5h) в Бэйсике, вероятно автор знал устройство кода ORDOS и решил "срезать угол". В старом варианте эмуляции недокументированная "фича" случайно совпала и проблем не было, в новой эмуляции код изменился и оно уже "не прокатывает". Возможно ещё какое-то ПО под ORDOS использует данную лазейку.

Заплатку сделал, сборки пересобрал, архивы обновил (ссылки те же). Кому важна загрузка файлов в Бэйсике, придётся перепрошить ROM-диск.


П.С. в том же Бэйсике команда FILES не работает и работать под DSDOS не будет! Это связано с очень глубоким некорректным использованием ресурсов ОС: вместо запроса списка файлов на диске через соотв. п/п ОС, код Бэйсика сам сканирует структуру квазидиска в ОЗУ второй страницы и ищет свои файлы. В DSDOS квазидиск устроен совершенно иначе и такой вид обработки невозможен.