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

Тут для свой утилитки, что в подписи интересуюсь.
(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 тоже бы разобрать хотелось.

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

Продолжаю разбираться.
Многое удалось выяснить, благодаря этой http://zx-pk.ru/threads/25281-sozdan...ora/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 пикселей) последней строки четвертой плоскости,

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

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

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

Вложений: 1

Есть 3. Вот. С образа viewgraf.fdd
Вложение 57477

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

Цитата:

Сообщение от ivagor

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

Да, смотрит довольно странно.

Цитата:

Сообщение от Black Cat / Era CG

1 строка 1 плоскость,
1 строка 2 плоскость,
1 строка 3 плоскость,
1 строка 4 плоскость,

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

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

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

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

Цитата:

Сообщение от AzAtom

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

До 128 выравнивается из-за CP/M. Насчет 256 не в курсе.

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

Цитата:

Сообщение от AzAtom

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

Получается так.

Вложений: 1

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

Вложений: 3

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

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

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

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

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

Цитата:

Сообщение от Black Cat / Era CG

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

Похоже (судя по скринам) синий с красным перепутаны.

Вложений: 1

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

Вложение 57498

Цитата:

Сообщение от AzAtom

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

Вот и у меня таких нет:(

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

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

Цитата:

Сообщение от 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 ничем не отличаются? Просто варианты расширений?

Цитата:

Сообщение от Black Cat / Era CG

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

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

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

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

Цитата:

Сообщение от Black Cat / Era CG

RMB и RBR ничем не отличаются? Просто варианты расширений?

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

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

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

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

Цитата:

Сообщение от AzAtom

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

а они же сразу сдвигаются на 0, 1, 2 и 3.
А потом все вместе на 4:)

Цитата:

Сообщение от AzAtom

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

Да вроде скорости более, чем достаточно.

Цитата:

Сообщение от AzAtom

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

О! Это уже интересно!

Цитата:

Сообщение от AzAtom

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

Это во обоих форматах?

Цитата:

Сообщение от AzAtom

Точно, там только распределение по плоскостям отличается

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

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

Цитата:

Сообщение от AzAtom

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

я уже писал

Цитата:

Сообщение от ivagor

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

Цитата:

Сообщение от ivagor

программой sprview

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

Вложений: 1

Цитата:

Сообщение от Black Cat / Era CG

А потом все вместе на 4

Проглядел. 12 ночи :)

Цитата:

Сообщение от Black Cat / Era CG

Это во обоих форматах?

Смотрел только в .rmb.

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

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

Цитата:

Сообщение от ivagor

я уже писал
Сообщение от ivagor
Работу с rbr/rmb в sprview надо править

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

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

Цитата:

Сообщение от Black Cat / Era CG

Да вроде скорости более, чем достаточно.

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

Цитата:

Сообщение от Black Cat / Era CG

RMB и RBR - это одно и тоже?

Насколько я знаю - да

Цитата:

Сообщение от AzAtom

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

Конечно

Цитата:

Сообщение от ivagor

Насколько я знаю - да

Спасибо за внесение ясности:)

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

Цитата:

Сообщение от AzAtom

файл с расширением .grf

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

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

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

Цитата:

Сообщение от AzAtom

ivagor, понятно. Вроде разобрался с ним, только непонятна осталась одна вещь.
Картинка 128х128 пикселей, разбита на блоки 8х8 пикселей. Блоки идут слева направо, потом сверху вниз.
...
Непонятен зачем был нужен такой зигзаг в порядке байтов. :)

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

Цитата:

Сообщение от AzAtom

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

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

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

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

Цитата:

Сообщение от Black Cat / Era CG

А подскажите, пожалуйста, какая палитра используется, как стандартная (для просмотра SCR например надо)?
...

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

Цитата:

Сообщение от KTSerg

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

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

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

Цитата:

Сообщение от yevrowl

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

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

Цитата:

Сообщение от aGGreSSor

Имелись ввиду ESC-последовательности?

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

Цитата:

Сообщение от aGGreSSor

POKE(63526),15:POKE(63525),128

Спасибо, программа компилировалась.

Цитата:

Сообщение от aGGreSSor

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

Какую версию посоветуете? И где можно раздобыть сей образ дискеты?

Вложений: 1

Цитата:

Сообщение от yevrowl

Какую версию посоветуете? И где можно раздобыть сей образ дискеты?

Сложно какую-то посоветовать. Модификаций очень много. Брать разные и смотреть что работает, а что нет.
Есть справка от Tim0xA в теме Операционные системы (она более подходит для этих разговоров).
Брать можно на old-dos (раньше их там было больше), в Базисе, также в самой софтине 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 RETURN

[свернуть]

Вложение 83052

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

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