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

[RD3AY]

Почему у меня появляется такое сообщение при попытке отформатировать диск В.

ОС DSDOS последней декабрьская версии 2017 года.

ОЗУ 128 кб

[Denn]

RD3AY, загрузчик ОС не обнаружил в аппаратуре квазидиск, соответственно диск В: недоступен.
Вероятная причина - мало ОЗУ. Минимальный требуемый объём, чтобы была возможность организовать квазидиск - 256 Кб.

Через утилиту SYSTEM$ можно переназначить рабочий диск на другой:



Но этот другой диск в системе должен быть. Без рабочего диска пользоваться ОС можно, но не будет сохраняться конфигурация программ при выходе из них, не будет работать буфер обмена, драйвер расширения и т.д..

[RD3AY]

Вероятная причина - мало ОЗУ. Минимальный требуемый объём, чтобы была возможность организовать квазидиск - 256 Кб.

Да, видимо причина в этом, у меня ОЗУ 128 кБ 16 штук КР565РУ5Г.
А версии ОС для ОЗУ 128 кБ у Вас есть? Или это жесткие необходимые требования ОС.

[HardWareMan]

RD3AY, но коллега, РУ7 это 256К, или ты их тупо вместо РУ5 воткнул?

[Denn]

у меня ОЗУ 128 кБ 16 штук КР565РУ7Г

У меня тоже 16 шт. РУ7, но они внезапно дают 512 Кб!

А версии ОС для ОЗУ 128 кБ у Вас есть? Или это жесткие необходимые требования ОС.

Чудо, к сожалению, не случится, при физическом отсутствии необходимого ОЗУ квазидиск не сделать.
Без диска В: ОС будет работать, специальных версий не требуется.

[RD3AY]

но коллега, РУ7 это 256К, или ты их тупо вместо РУ5 воткнул?

Ошибочка, РУ5Г стоят, все с "синей" платой путаю. Там РУ7К стоят, 512 кБ.

[Advertiser]

[Denn]

Ошибочка, РУ5Г стоят

Можно закрыть вопрос такой штукой - http://zx-pk.ru/threads/25367-gibrid...l=1#post880943

Или ещё лучше такой - http://zx-pk.ru/threads/21984-dsdos-...l=1#post881433

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

[Denn]

Формат графических файлов ОС 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 будет включена библиотека работы с данным форматом.

[barsik]

Если повторяется менее 64-х одинаковых байтов, то...

Да, удачная идея компрессии графики, т.к действительно в реальных картинках цепочки повторов не длинны. Только логичнее под счётчик брать биты D0...D5, а биты D6, D7 использовать как служебные. И это ускорит. Потому-что бит D7 проверяется проще, к тому же в цепочках длиннее 64-х байт эти 6 битов, являющиеся в этом случае старшим байтом длины, приходится сдвигать на 2 позиции.

[Denn]

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