CP/M для Вектора и Форматы файлов

[Black Cat / Era CG]

Тут для свой утилитки, что в подписи интересуюсь.
(http://zx.pk.ru/showthread.php?t=11294)

Два вопроса:

1. Хотелось бы заиметь пару-тройку-пятерку системных образов (сами файлы не интересуют, интересует именно содержимое системных дорог), для функции создания новых образов в моей утиле мне нужны они. Интересуют собственно не только именно то, что называлось CP/M, а все, где использовалась данная ФС.
Желательно б с таким вот описанием-содержимом шапки:

CP/M-80 vers. 2.2BIOS vers.2.0 (c)
НИИЯФ МГУ мп "МикС"
МОСКВА 1988
Просто чтобы не тревожить мне мою лень и не разбираться, как в эмуляторе сие увидеть:)

2. Еще очень бы хотел поиметь информацию о форматах различных файлов вектора:
Например вот прочитал в одном из образов:

Содержимое пакета:
Viewbsv - утилита просмотра файлов, содержащих копию экрана ПК "Вектор";
Viewpcx - утилита просмотра файлов формата PCX с IBM PC;
Viewrbr - утилита просмотра файлов графического редактора "Рембрант";
Viewscr - утилита просмотра файлов графического редактора "Карандаш";
Viewspr - утилита просмотра файлов графического редактора "Draw";
Viewszx - утилита просмотра файлов, содержащих копию экрана ПК "Spectrum";
Viewtxt - утилита просмотра текстовых файлов.
Ну с PCX и Спектрумовскими скринами все ясно. С текстами тем более:)
Вот хотелось бы еще научить утилку смотреть и остальные перечисленные форматы.
Да и Барсики, те, что с расширением BAS тоже бы разобрать хотелось.

Заранее спасибо за любую полезную информацию.

[Black Cat / Era CG]

Продолжаю разбираться.
Многое удалось выяснить, благодаря этой http://zx-pk.ru/threads/25281-sozdanie-graficheskogo-redaktora/page4.html теме.
На данный момент разобрался с форматом BSV - полная копия экрана. По крайней мере единственный имеющийся у меня в наличии файл смотрится (конвертируется в BMP) вполне достойно.

Сейчас копаюсь с форматом RBR (формат редактора "Рембрандт"). Нашел такую вот доку:
Формат графического файла редактора REMBRANDT

Выгруженные из REMBRANDTа на магнитофон картинки имеют формат MON и адрес начала 0000.

Байты
0-15 - палитра (цвета в обратном порядке с 15 по 0)
стандартная палитра по умолчанию совпадает с BASIC 2.5
- 0 - 64 (темно-синий) 01 000 000
- 1 - 128 (синий) 10 000 000
- 2 - 16 (темно-зеленый) 00 010 000
- 3 - 208 (голубой) 11 010 000
- 4 - 6 (ярко-красный) 00 000 110
- 5 - 134 (малиновый) 10 000 110
- 6 - 22 (кирпичный) 00 010 110
- 7 - 54 (желтый) 00 110 110
- 8 - 0 (черный) 00 000 000
- 9 - 197 (фиолетовый) 11 000 101
- 10 - 34 (ярко-зеленый) 00 100 010
- 11 - 192 (ярко-синий) 11 000 000
- 12 - 2 (темно-красный) 00 000 010
- 13 - 152 (бирюзовый) 10 011 000
- 14 - 82 (серый) 01 010 010
- 15 - 173 (белый) 10 101 101

16 - размер по X (в байтах)
17 - размер по Y (в точках)
18 - маска доступа к плоскостям
Начиная с байта 19 и до конца файла идет собственно изображение.
В строке данные идут слева направо, побайтно.
Сначала записывается составляющая строки с цветовым весом 1, потом с весами 2, 4 и 8
(если они не отключены в маске).
Строки идут сверху вниз.


Описание составил Иван Городецкий 18.05.2002
Спасибо за нее автору.

Но остаются вопросы:

18 - маска доступа к плоскостям
Насколько я понял значение 0F (00001111) означает что задействованы все 4 плоскости. Правильно?

Начиная с байта 19 и до конца файла идет собственно изображение.
В строке данные идут слева направо, побайтно.
Сначала записывается составляющая строки с цветовым весом 1, потом с весами 2, 4 и 8
(если они не отключены в маске).
Строки идут сверху вниз.
А вот тут на ум приходят 2 варианта:
- данные хранятся в следующем виде:

1 строка 1 плоскость,
1 строка 2 плоскость,
1 строка 3 плоскость,
1 строка 4 плоскость,
...
Последняя строка 1 плоскость,
Последняя строка 2 плоскость,
Последняя строка 3 плоскость,
Последняя строка 4 плоскость
- данные хранятся так:

1 байт (8 пикселей) 1 строки первой плоскости,
1 байт (8 пикселей) 1 строки второй плоскости,
1 байт (8 пикселей) 1 строки третьей плоскости,
1 байт (8 пикселей) 1 строки четвертой плоскости,
2 байт (8 пикселей) 1 строки первой плоскости,
2 байт (8 пикселей) 1 строки второй плоскости,
2 байт (8 пикселей) 1 строки третьей плоскости,
2 байт (8 пикселей) 1 строки четвертой плоскости,
...
Последний байт (8 пикселей) 1 строки первой плоскости,
Последний байт (8 пикселей) 1 строки второй плоскости,
Последний байт (8 пикселей) 1 строки третьей плоскости,
Последний байт (8 пикселей) 1 строки четвертой плоскости,
...
Последний байт (8 пикселей) последней строки первой плоскости,
Последний байт (8 пикселей) последней строки второй плоскости,
Последний байт (8 пикселей) последней строки третьей плоскости,
Последний байт (8 пикселей) последней строки четвертой плоскости,

Однако (если честно) ни тот, ни другой вариант почему-то пока не дает правильной картинки.
Конечно, я мог и сам где-то накосячить, но, возможно, я просто как-то не так понял доку?

[KTSerg]

Не нашел у себя ни одного файла с расширением RBR, что-бы глянуть содержимое...
Откопал пару вариантов самого Рембранта, но в эмуле не разобрался как сохранить на диск (имя задавал, а запись вроде так и не происходила)... Или ему какой-то конкретный МикроДос нуден...

[ivagor]

Описание формата рембрандта правильное, т.к. я его в тетрадке записал в 90х, когда сделал процедуру вывод его картинок на экран (она работала правильно), а в 2002 просто набрал. А вот реализация чтения и записи rmb/rbr в sprview может хромать, т.к. (про это я написал в readme) это единственный формат, который я не проверял на реальных файлах (выгруженных из графического редактора). Надо или сохранить тестовый файл из графического редактора или попробовать загрузить файл в него.

[Black Cat / Era CG]

Есть 3. Вот. С образа viewgraf.fdd
57477

[ivagor]

Работу с rbr/rmb в sprview надо править

[Black Cat / Era CG]

Работу с rbr/rmb в sprview надо править
Да, смотрит довольно странно.

[AzAtom]

1 строка 1 плоскость,
1 строка 2 плоскость,
1 строка 3 плоскость,
1 строка 4 плоскость,
Да, так и есть. Подряд идут байты первой строки из первой плоскости, потом первая строка второй плоскости и т.д.

Вообще, применительно к вектору странный способ построчной организации. Это же его надо отдельно в память загружать и перетасовывать при выводе на экран.

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

Ещё, похоже, размер файла выровнен до кратного 256 байт.

[Black Cat / Era CG]

Ещё, похоже, размер файла выровнен до кратного 256 байт.
До 128 выравнивается из-за CP/M. Насчет 256 не в курсе.

[AzAtom]

В файле DINO.RBR по описанию должно быть 16+3+16*124*4 = 7955 байт, а файл 8192 байт, разница 237 байт. Вот и получается кратно 256 байт.

[Black Cat / Era CG]

Вот и получается кратно 256 байт.
Получается так.

[AzAtom]

Вот так правильно?
57492

[Black Cat / Era CG]

Примерно так. Насчет черепов по цветам не очень уверен (хотя сравниваю только с эмулятором)

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

Вот скриншоты с эмуля
57493 57494 57495

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

То есть с цветовыми составляющими немного напутано получилось:)

[KTSerg]

...
То есть с цветовыми составляющими немного напутано получилось:)
Похоже (судя по скринам) синий с красным перепутаны.

[AzAtom]

Точно, синий и красный перепутал в палитре. Теперь нормально. Только не реализовал выбор плоскостей. Ещё бы картинки с 1-2-3 задействованными плоскостями.

57498

[Black Cat / Era CG]

Ещё бы картинки с 1-2-3 задействованными плоскостями.
Вот и у меня таких нет:(

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

Тоже добил (блин, 2 дня искал ошибку там, где ее не было!).
Пора приступать к scr и spr.

[AzAtom]

Тоже добил
Можете показать вашу реализацию? Интересно другим взглядом посмотреть.

[Black Cat / Era CG]

Можете показать вашу реализацию? Интересно другим взглядом посмотреть.
В смысле код?

[AzAtom]

В смысле код?
Да.

[Black Cat / Era CG]

Там г..код, собственно. Ну ладно, сейчас.

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

Вот кусок, который расковыривает сами пиксели и сохраняет все это в формате, годном для 4-битного бмп
//Обрабатываем массив пикселей
for row:=0 to PicHeight-1 do begin
InSrc:=($13+(PicHeight-row-1)*PicWidth*BPCount);
for col:=0 to PicWidth-1 do begin
for pix:=0 to 7 do begin
InSrcTp:=InSrc;
if (pix mod 2)=0 then begin
ColByte:=%00000000;
if (BPMask and %00000001)<>0 then begin
ColByte:=ColByte or (((File4View[InSrcTp] and (%10000000>>pix))>>(7-pix))<<0);
Inc(InSrcTp,PicWidth);
end;
if (BPMask and %00000010)<>0 then begin
ColByte:=ColByte or (((File4View[InSrcTp] and (%10000000>>pix))>>(7-pix))<<1);
Inc(InSrcTp,PicWidth);
end;
if (BPMask and %00000100)<>0 then begin
ColByte:=ColByte or (((File4View[InSrcTp] and (%10000000>>pix))>>(7-pix))<<2);
Inc(InSrcTp,PicWidth);
end;
if (BPMask and %00001000)<>0 then begin
ColByte:=ColByte or (((File4View[InSrcTp] and (%10000000>>pix))>>(7-pix))<<3);
Inc(InSrcTp,PicWidth);
end;
ColByte:=ColByte<<4;
end
else begin
if (BPMask and %00000001)<>0 then begin
ColByte:=ColByte or (((File4View[InSrcTp] and (%10000000>>pix))>>(7-pix))<<0);
Inc(InSrcTp,PicWidth);
end;
if (BPMask and %00000010)<>0 then begin
ColByte:=ColByte or (((File4View[InSrcTp] and (%10000000>>pix))>>(7-pix))<<1);
Inc(InSrcTp,PicWidth);
end;
if (BPMask and %00000100)<>0 then begin
ColByte:=ColByte or (((File4View[InSrcTp] and (%10000000>>pix))>>(7-pix))<<2);
Inc(InSrcTp,PicWidth);
end;
if (BPMask and %00001000)<>0 then begin
ColByte:=ColByte or (((File4View[InSrcTp] and (%10000000>>pix))>>(7-pix))<<3);
Inc(InSrcTp,PicWidth);
end;
MBuffer.WriteByte(ColByte);
end;
end;
Inc(InSrc);
end;
end;

Я предупреждал:)

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

Ну и да. Еще вопросик. RMB и RBR ничем не отличаются? Просто варианты расширений?

[AzAtom]

Я предупреждал
Примерно так делал, когда преобразовывал картинки от спектрума. Но эти сдвиги мне не понравились, поэтому, просто развернул третий вложенный цикл. Писать чуть больше, но выполняется проще и быстрее.

Кстати, у вас в первой ветке, когда pix чётное, разве не должно в конце сдвигаться на 4, 5, 6 и 7? А то все биты попадают в 4 младших бита BMP.

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


RMB и RBR ничем не отличаются? Просто варианты расширений?
Созданный программой sprview файл .rmb этой же процедурой не открылся. Похоже там байты плоскостей идут не построчно, а целиком.

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

Точно, там только распределение по плоскостям отличается, а палитра, размеры и используемые плоскости одинаковые.

Ещё значение 0 в байте размера означает 256. :)

[Black Cat / Era CG]

Кстати, у вас в первой ветке, когда pix чётное, разве не должно в конце сдвигаться на 4, 5, 6 и 7? А то все биты попадают в 4 младших бита BMP.
а они же сразу сдвигаются на 0, 1, 2 и 3.
А потом все вместе на 4:)

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

Созданный программой sprview файл .rmb этой же процедурой не открылся. Похоже там байты плоскостей идут не построчно, а целиком.
О! Это уже интересно!


Ещё значение 0 в байте размера означает 256.
Это во обоих форматах?


Точно, там только распределение по плоскостям отличается
То есть все строки 1 составляющей, потом 2 и т.д.?

Можно, кстати, RMB сюда?

[ivagor]

Созданный программой sprview файл .rmb этой же процедурой не открылся.
я уже писал

Работу с rbr/rmb в sprview надо править

[Black Cat / Era CG]

программой sprview блин! совсем что-то я плох, я почему-то прочитал "в редакторе".
То есть все-таки RMB и RBR - это одно и тоже?

[AzAtom]

А потом все вместе на 4
Проглядел. 12 ночи :)


Это во обоих форматах?
Смотрел только в .rmb.

Вот этот файл. Просто он уже был размером 256х256 пикселей, специально не тестировал.
57504

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


я уже писал
Сообщение от ivagor
Работу с rbr/rmb в sprview надо править
Т.е., и там тоже должно быть сначала все первые строки от всех плоскостей, затем все вторые строки и т.д.?

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


Да вроде скорости более, чем достаточно.
Это я со своей колокольни смотрю просто. :) Делал преобразователь из формата спектрума в bmp, в дальнейшем задумываю свой эмулятор накалякать, поэтому скорость была интересна и критична. Начал с варианта со сдвигами, 1200 fps, закончил самым оптимальным вариантом с 15000 fps на core i5-2520M, причём, это преобразование сразу в 2 варианта, с flash и без него.

[ivagor]

RMB и RBR - это одно и тоже?
Насколько я знаю - да


Т.е., и там тоже должно быть сначала все первые строки от всех плоскостей, затем все вторые строки и т.д.?
Конечно

[Black Cat / Era CG]

Насколько я знаю - да
Спасибо за внесение ясности:)

[AzAtom]

ivagor, А там sprview ещё выдаёт файл с расширением .grf. Странное там что-то открывается, полосатое. Может, помните его описание или сохранилось?

[ivagor]

файл с расширением .grf
Это узкоспециальный формат, который я "изобрел", чтобы сохранять в удобном для компоновки с игрушкой виде тайлы малобюджетных Hudsonовских игрушек. Если кто вдруг захочет заняться конверсиями с msx, я посижу над исходником и накропаю описание.

[AzAtom]

ivagor, понятно. Вроде разобрался с ним, только непонятна осталась одна вещь.

Картинка 128х128 пикселей, разбита на блоки 8х8 пикселей. Блоки идут слева направо, потом сверху вниз.
В блоке строка представляется 4 байтами, аналогично представлению в векторе и с такими же цветовыми плоскостями. Одному блоку соответствует 32 байта следующим образом:


Плоскость: 0 1 2 3
Строка в блоке (сверху вниз): 0 1 2 3 4 5 6 7 | 7 6 5 4 3 2 1 0 | 0 1 2 3 4 5 6 7 | 7 6 5 4 3 2 1 0
Байт: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

Непонятен зачем был нужен такой зигзаг в порядке байтов. :)

[KTSerg]

ivagor, понятно. Вроде разобрался с ним, только непонятна осталась одна вещь.
Картинка 128х128 пикселей, разбита на блоки 8х8 пикселей. Блоки идут слева направо, потом сверху вниз.
...
Непонятен зачем был нужен такой зигзаг в порядке байтов. :)
Я с ним (с этим форматом) не разбирался конечно, но мне кажется я понял идею...
При переносе данных картинки на экран, можно использовать указатель адреса экранной памяти без "восстановления" его начального значения при переходе с "блока" на "блок" (или между плоскостями), просто сначала значение указателя увеличивается, затем - уменьшается (младший байт указателя), остаётся корректировать только старший байт указателя. Мне кажется элегантно. :)
Или я снова ничего не понял... :(

[ivagor]

зачем был нужен такой зигзаг в порядке байтов
Как написал KTSerg, для ускорения вывода на экран. PPC писал про это (вывод зигзагом) подробнее

[AzAtom]

Понятно. Так получается немного быстрее выводить спрайты 8х8 и 8х16, например.

[Black Cat / Era CG]

А подскажите, пожалуйста, какая палитра используется, как стандартная (для просмотра SCR например надо)?
Дело в том, что используя палитру от BASIC 2.5, получаю в качестве цвета 0 - 64 (темно-синий), вместо черного.
Попался мне тут исходник ScrView 1.5, там политра используется точно такая же, за исключением цвета 0 (там он =0, как и цвет 8).

[KTSerg]

А подскажите, пожалуйста, какая палитра используется, как стандартная (для просмотра SCR например надо)?
...
В эмуляторе посмотрел, "Карандаш" показывает палитру, в ней цвет 0 - тёмно синий.

[Black Cat / Era CG]

В эмуляторе посмотрел, "Карандаш" показывает палитру, в ней цвет 0 - тёмно синий.
Отлично. Спасибо. Тааак. Еще с одной мелочью разобрался.
Итак, готовы BSV (дамп экрана - только 256х256 сделал, 512х256 пока не стал, не знаю надо ли), RBR/RMB, SCR и SPR. Больше по Вектору инфы не имею.

[yevrowl]

Существует ли возможность при помощи управляющих кодов CP/M написать команду, аналогичную COLOR 15, 128 и которую бы принял BasCom?

[aGGreSSor]

Существует ли возможность при помощи управляющих кодов CP/M написать команду, аналогичную COLOR 15, 128 и которую бы принял BasCom?
Не очень ясно причём здесь управляющие коды CP/M. Имелись ввиду ESC-последовательности?
В некоторых версиях распространявшихся МикроДОС, невероятным образом сохранивших совместимость с изначальными МикроДОС 3.0, в программе на бейсике можно сделать POKE(63526),15:POKE(63525),128
Программу придётся распространять на FDD-образе содержащем МикроДОС с которой она работает.

[yevrowl]

Имелись ввиду ESC-последовательности?
Да, видимо применил технически некорректную терминологию.


POKE(63526),15:POKE(63525),128
Спасибо, программа компилировалась.


Программу придётся распространять на FDD-образе содержащем МикроДОС с которой она работает.
Какую версию посоветуете? И где можно раздобыть сей образ дискеты?

[aGGreSSor]

Какую версию посоветуете? И где можно раздобыть сей образ дискеты?
Сложно какую-то посоветовать. Модификаций очень много. Брать разные и смотреть что работает, а что нет.
Есть справка от Tim0xA в теме Операционные системы (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=180407&viewfull=1#post180407) (она более подходит для этих разговоров).
Брать можно на old-dos (http://old-dos.ru/index.php?page=files&mode=files&do=show&id=5235) (раньше их там было больше), в Базисе (https://caglrc.cc/scalar/categories/os/), также в самой софтине SteinBlume, слава создателям, можно делать Файл/Создать образ.../Vector-06C и дальше понятно. Когда развлекался изучением этой разницы, написал маленькую программу VSET на CBASIC. Вы, судя по всему, из-за недостатка информации пытаетесь делать что-то похожее :):

AR$=COMMAND$
A1$=UCASE$(MID$(AR$,1,1))
GOSUB TERM
IF COMMAND$="" THEN GOSUB HELP
IF A1$="H" THEN GOSUB HELP
IF A1$="V" THEN GOSUB VER
IF A1$="C" THEN PRINT CL$
IF A1$="J" THEN PRINT BP$
IF A1$="4" THEN PRINT FL$
IF A1$="8" THEN PRINT FS$
IF A1$="D" THEN PRINT "INK:";PEEK(63526);", PAPER:";PEEK(63525)
IF A1$="Z" THEN POKE(63526),0:POKE(63525),164
IF A1$="W" THEN POKE(63526),255:POKE(63525),0
IF A1$="R" THEN POKE(63526),7:POKE(63525),0
IF A1$="G" THEN POKE(63526),56:POKE(63525),0
IF A1$="Y" THEN POKE(63526),63:POKE(63525),0
IF A1$="B" THEN POKE(63526),248:POKE(63525),0
IF A1$="S" THEN GOSUB SETUP
STOP
VER:
PRINT NG$;" MICRODOS TTY SETUP V(0.1) ":PRINT " * PLASTIC WORLD ";CHR$(2);" 2025 * ";PV$:RETURN
HELP:
GOSUB VER:PRINT
PRINT "OPTIONS:":PRINT
PRINT "V - VERSION"
PRINT "H - HELP"
PRINT "C - CLEAR SCREEN"
PRINT "4 - WIDTH TO 40 COLUMNS"
PRINT "8 - WIDTH TO 80 COLUMNS"
PRINT "D - CURRENT COLORS"
PRINT "Z - W/B COLORS LIKE ON ZX SPECTRUM"
PRINT "R - B/R COLORS WITH CONTRASTING RED"
PRINT "G - B/G COLORS WITH CONTRASTING GREEN"
PRINT "B - B/B COLORS WITH CONTRASTING BLUE"
PRINT "Y - B/B COLORS WITH CONTRASTING YELLOW"
PRINT "W - B/W COLORS WITH CONTRASTING WHITE"
PRINT "S <INK>,<PAPER> - SET PHYSICAL COLORS"
PRINT "J - JINGLE"
RETURN
SETUP:
L=LEN(AR$):DV=MATCH("\,",AR$,3)
IF (L<3) THEN RETURN:REM None args
IF (DV<>0) THEN GOTO SET1
POKE (63526),VAL(MID$(AR$,3,3)):RETURN:REM 1 arg (INK)
SET1:
POKE (63526),VAL(MID$(AR$,3,DV-3)):REM first arg (INK)
POKE (63525),VAL(RIGHT$(AR$,L-DV)):REM second arg (PAPER)
RETURN
TERM:
CL$=CHR$(27)+CHR$(74):REM Clear screen
NG$=CHR$(27)+CHR$(54):REM Inverse on
PV$=CHR$(27)+CHR$(55):REM Inverse off
FL$=CHR$(27)+CHR$(93):REM 40 columns (undocumented)
FS$=CHR$(27)+CHR$(94):REM 80 columns (undocumented)
BP$=CHR$(7):REM Beep
RETURN83052

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

Если подумать, то с точки зрения поддержки кириллицы мне идеально заходила МикроДОС 3.1 (BIOS 3.11.F.11) (https://caglrc.cc/scalar/ware/757/).
А с точки зрения читаемости и шрифта "из коробки", МикроДОС 47 BoldBIOS
(https://caglrc.cc/scalar/ware/835/), однако в ней куча глюков, как и вообще у PPC (при всём масштабе его деятельности).