PDA

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



Black Cat / Era CG
03.12.2015, 23:11
Тут для свой утилитки, что в подписи интересуюсь.
(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
29.06.2016, 06:55
Продолжаю разбираться.
Многое удалось выяснить, благодаря этой 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
29.06.2016, 17:20
Не нашел у себя ни одного файла с расширением RBR, что-бы глянуть содержимое...
Откопал пару вариантов самого Рембранта, но в эмуле не разобрался как сохранить на диск (имя задавал, а запись вроде так и не происходила)... Или ему какой-то конкретный МикроДос нуден...

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

Black Cat / Era CG
29.06.2016, 18:58
Есть 3. Вот. С образа viewgraf.fdd
57477

ivagor
30.06.2016, 04:38
Работу с rbr/rmb в sprview надо править

Black Cat / Era CG
30.06.2016, 10:42
Работу с rbr/rmb в sprview надо править
Да, смотрит довольно странно.

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

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

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

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

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

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

Black Cat / Era CG
30.06.2016, 14:06
Вот и получается кратно 256 байт.
Получается так.

AzAtom
30.06.2016, 16:11
Вот так правильно?
57492

Black Cat / Era CG
30.06.2016, 16:26
Примерно так. Насчет черепов по цветам не очень уверен (хотя сравниваю только с эмулятором)

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

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

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

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

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

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

57498

Black Cat / Era CG
30.06.2016, 18:30
Ещё бы картинки с 1-2-3 задействованными плоскостями.
Вот и у меня таких нет:(

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

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

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

Black Cat / Era CG
30.06.2016, 19:24
Можете показать вашу реализацию? Интересно другим взглядом посмотреть.
В смысле код?

AzAtom
30.06.2016, 21:50
В смысле код?
Да.

Black Cat / Era CG
30.06.2016, 22:37
Там г..код, собственно. Ну ладно, сейчас.

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

Вот кусок, который расковыривает сами пиксели и сохраняет все это в формате, годном для 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
30.06.2016, 23:24
Я предупреждал
Примерно так делал, когда преобразовывал картинки от спектрума. Но эти сдвиги мне не понравились, поэтому, просто развернул третий вложенный цикл. Писать чуть больше, но выполняется проще и быстрее.

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

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


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

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

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

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

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

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

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


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


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

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

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

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

Black Cat / Era CG
01.07.2016, 04:48
программой sprview блин! совсем что-то я плох, я почему-то прочитал "в редакторе".
То есть все-таки RMB и RBR - это одно и тоже?

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


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

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

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


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

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


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

ivagor
01.07.2016, 16:51
RMB и RBR - это одно и тоже?
Насколько я знаю - да


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

Black Cat / Era CG
01.07.2016, 18:31
Насколько я знаю - да
Спасибо за внесение ясности:)

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

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

AzAtom
02.07.2016, 06:48
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
02.07.2016, 15:32
ivagor, понятно. Вроде разобрался с ним, только непонятна осталась одна вещь.
Картинка 128х128 пикселей, разбита на блоки 8х8 пикселей. Блоки идут слева направо, потом сверху вниз.
...
Непонятен зачем был нужен такой зигзаг в порядке байтов. :)
Я с ним (с этим форматом) не разбирался конечно, но мне кажется я понял идею...
При переносе данных картинки на экран, можно использовать указатель адреса экранной памяти без "восстановления" его начального значения при переходе с "блока" на "блок" (или между плоскостями), просто сначала значение указателя увеличивается, затем - уменьшается (младший байт указателя), остаётся корректировать только старший байт указателя. Мне кажется элегантно. :)
Или я снова ничего не понял... :(

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

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

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

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

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