Программирование

[parallelno]

M80, а что такое irp/irpc? Может можно найти замену?

- - - Updated - - -

M80, возможно .generate может заменить irp. А вот для irpc придется писать какой то внешний распарсиватель.

[M80]

Вот, вот. Считаю m80 классикой, с его макросредствами. При том что хрен-знамо каких годов! Вот нашел L80)
QP/M 2.7 62K
A>dir
POWER .COM : PCPLUS .BIN : XDIR .COM : RUN .COM
ZSID .COM : DIS .COM : XSUB .COM : RDR .COM
L80 .COM : M80 .COM : DDTZ .COM : 1 .bas
BOOTGEN .COM : XLOAD .COM : DEBUGZ .COM : DBGINST .COM
SYSGEN .COM : 2 .bas : 3 .bas : BAS .COM
CONVERT .COM : MBASIC .COM : REBOOT .COM
A>l80


Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft

*

[M80]

Вот и пусть чего не катят на Билла Гейстса! 1981 год, однако продукт пользуется, кто бы чего не говорил. Какие есть возражения?

[parallelno]

У меня нет возражений. :)

[x-code]

Кстати, можно очищать и LFSRом по точкам

В "Болдере" Лебедева, если не ошибаюсь, именно такой алгоритм очистки экрана был.
Ещё будучи школотой в начале 1990х и, увы, ничего не зная про LFSR - ломал голову, что это у автора игры за хитрый random generator, который не повторяется и гарантированно покрывает все точки экрана.

[parallelno]

Добавил ссылки на документацию по AY-3-8910 и КР580ВИ53 в раздел о звуке

[svofski]

Добавил ссылки на документацию по AY-3-891 и КР580ВИ53 в раздел о звуке

Можно поправить ссылку на музон из Арканоида на прямую -- https://svofski.github.io/pretty-8080-assembler/?arkmus

[ivagor]

Извините за полуоффтоп, но я послушал версию по ссылке и ее звук мне не нравится. Если что - критикую себя, т.к. указан там в качестве ответственного за тонгенератор. Берем абсолютно те же ноты svofski и играем семплами через таймер (https://zx-pk.ru/threads/28132-bipernaya-muzyka-na-vektore-06ts.html?p=1046587&viewfull=1#post1046587) (лучше Arkan_Sample2_NoBuzz2) в v06x (в других эмуляторах не стоит, в крайнем случае в emu80) или на реале - совсем другое дело.

[svofski]

Вариант с семплами безусловно звучит чище, но он занимает почти всю память. А тот, что в рыбе -- крохотный.

[ivagor]

В варианте с семплами выполняется переброска семплов из исходных позиций в "выровненные". Это был задел на зацикливание, но в арканоиде это не нужно и можно просто играть семплы по исходным адресам, при этом будет занимать 11 Кб. Да, это много, но все же не вся память. Надо бы вернуться к несемплерному варианту и попробовать улучшить.

[parallelno]

Добавил информацию про редктор звуковых эффектов в раздел по звуку.

[parallelno]

Читая документацию по AY немного запутался.
В этой доке http://tenroom.ru/scalar/ware/766/index.html указано управление через порты 4, 5, 6
В этой http://tenroom.ru/scalar/ware/765/index.html порты 15, 14
В гигачад плеере тоже используются 15 и 14 порты.
И то и то правильно, эмуляторы поддерживают все варианты? По скорости и удобству второй вариант выглядит удобнее.

[Improver]

управление через порты 4, 5, 6Это альтернативный вариант подключения AY, в порт ПУ Вектора.

[parallelno]

Что-то уже не стало хватать квазидиска. :)) Подскажите пожалуйста как читать с диска и есть ли какие-либо тулзы для автоматизации создания дискеты.

[svofski]

v06x создает образ открытого дискетой каталога в виде dirimage.fdd, но там есть нюансы. Попробуй загрузиться с какого-нибудь диска (я попробовал T-72, был под рукой) и подключить каталог в дисковод B: -- из файлов в каталоге соберется образ dirimage.fdd. За всех не скажу, но VV имеет аналогичную фичу.

[parallelno]

svofski, спасибо, попробую. А как читать из диска?

[svofski]

svofski, спасибо, попробую. А как читать из диска?

Ты имеешь ввиду из своей программы? Это занудно и скучно. Нужен или МикроДОС, у него все функции CP/M доступны, но это для игры совсем печаль-тоска. Или самому писать работу с секторами. Если без файлов, то в общем это совсем несложно -- посмотри работу с портами FDD. Я думаю тебе проще всего разобраться с ними по сорцам эмулятора.

Но лучше сжать код и данные получше :)

[parallelno]

Да из своей программы. Понял. Посмотрю. Спасибо!
Код и данные конечно можно ещё пожать, но много не вииграть мне кажется так как и так все сжато с zx0. Я тут подумал что мне поможет дополнительный квазидиск. Но вот даже не знаю насколько это распространено. Сможет кто-нибудь протестировать на реальном устройстве или нет? А v06x поддерживает два квазидиска?

[svofski]

А v06x поддерживает два квазидиска?
Нет, но это хороший мотиватор сделать поддержку нескольких квазидисков. В реалах я думаю, что это очень большая редкость. Но ты ведь можешь выпустить игру на картридже в порту ПУ и тогда тебе вообще все будет нипочем.

Кстати, поддержка ПЗУ в ПУ это тоже то, чего в v06x пока нет и нужен хороший мотиватор, чтобы сделать.

[Improver]

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


Сможет кто-нибудь протестировать на реальном устройстве или нет?Протестить я смогу, например, по мере возможности.

[ivagor]

Подключение двух квази-дисков было сделано давно, чему свидетельствует тест "Дождь"
Занудно добавлю, что судя по Дождю подключали до 8 квазов, интересно бы глянуть, как это выглядело.

[parallelno]

Привет!
Какие есть хорошие форматы сжатия индексированных картинок?
Возможно есть такая тема, но я не нашел к сожалению.

вот пример того что хочется сжать
https://i.ibb.co/YkpV7xP/image-intro2-0.png

Пробовал упаковывать индексы цветов по два на байт, затем zx0, получилось 15481 байт. Если сжимать RAW картинку, то получается хуже.
Уверен что можно гораздо лучше. Подскажите пожалуйста как. :v2_dizzy_roll:

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

Пытаюсь экспериментировать.

увеличение контраста - 13627 байт
https://i.ibb.co/s6S28JF/image-intro2-dither.png (https://imgbb.com/)
picture upload (https://imgbb.com/)

без дизеринга - 9853 байт
https://i.ibb.co/ydhZ7WW/image-intro2.png (https://imgbb.com/)

free image sharing (https://imgbb.com/)

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

UPKR упаковшик дает 9026 bytes для подконтрасченой картинки без дизера

[ivagor]

Кроме перехода к более мощным упаковщикам еще одно средство - изменение порядка обхода со строк на те или иные квадраты.

[parallelno]

Кроме перехода к более мощным упаковщикам еще одно средство - изменение порядка обхода со строк на те или иные квадраты.
А что за квадраты имеются ввиду?

- - - Updated - - -

У меня есть мысль разбить картинку на тайлы. Тайлы проанализировать на схожесть и реиспользовать тайлы которые похожи. Но явно я переизобретаю какой то велосипед. :)

[ivagor]

А что за квадраты имеются ввиду?
Например
0 1
2 3
вместо 0 1 2 3

У меня есть мысль разбить картинку на тайлы. Тайлы проанализировать на схожесть и реиспользовать тайлы которые похожи.
Векторное кодирование. Пробовал для однобитных (двухцветных) картинок, в принципе приемлемо. Сжатие с потерями, а дальше можно пробовать дожимать обычными упаковщиками.

[parallelno]

Спросил ChatGPT4 как ему идея. Он сказал что это похоже на Vector Quantization алгоритм и в частности есть стандартное решение VQ-based Image Compression (VBIC). :)

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


Например
0 1
2 3
вместо 0 1 2 3


попробовал. получилось чуть хуже
2x2 blocks - 10218 bytes
может конечно что-то упустил или ошибся.

[ivagor]

попробовал. получилось чуть хуже
Зависит от картинки. Переформулирую более обще: "Кроме перехода к более мощным упаковщикам еще одно средство - изменение порядка обхода". Например для третьей картинки (без дизера) лучше подходит обход по столбцам.

[svofski]

Прям хочется вернуться к LFSR-Пушкину, но я сдержусь.

[parallelno]

Спросил ChatGPT4 как ему идея. Он сказал что это похоже на Vector Quantization алгоритм и в частности есть стандартное решение VQ-based Image Compression (VBIC). :)

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



попробовал. получилось чуть хуже
2x2 blocks - 10218 bytes
может конечно что-то упустил или ошибся.

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

[parallelno]

Помогло на 40 байт :)

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


Прям хочется вернуться к LFSR-Пушкину, но я сдержусь.

Извини, Понкратова-Черного знаю, LFSR-Пушкина не знаю. Кто это? :)

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

После того как отсортировал индексы по яркости, UPKR сжал до 8636 bytes (26.35498%)

[ivagor]

Но там уже было по столбцам когда я опубликовал тесты.

без дизеринга - 9853 байт
У меня по столбцам получилось 9828 байт

UPKR упаковшик дает 9026 bytes
8929 байт.
Не учитывал палитру, если надо учесть, то +16 байт.

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

Понял, почему расхождение. Я для эксперимента брал не исходный 256цветный png, а 16цветный bmp (конверснул в IrfanView), в котором цвета палитры перетасованы.

[parallelno]

да, там палитра и еще всякие небольшие вкрапления, так что маленькие расхождения не критичны.
Сжал по методу Vector Quantization (VQ), блоки 8x8 пикселей. Получилось 5175 байт с ZX0 и 4534 bytes (13.83667%) с помощью UPKR. Конечно сжатие заметно, но результат интересный. :)

https://i.ibb.co/YNRx87d/tmp-rgb-compressed.png (https://imgbb.com/)
exam animated gif (https://imgbb.com/)

Вот крупнее
https://i.ibb.co/1Jp3r7m/shot-230416-215612.jpg (https://ibb.co/Fqf95mD)

[ivagor]

Если для главной заставки, то наверно лучше так не стоит, а для картинок по ходу игры вполне приемлемо.

Хочу реабилитировать квадраты. C zx0 они для данной картинки ничего хорошего не дают, но с upkr или rip квадраты размером 32x32 (обход по столбцам) сжимаются лучше:
upkr - 8647 байт
rip - 9057 байт
Это без палитры (+16 байт).
Если картинка одна, то надо учитывать и размер распаковщика и перестановщика и тогда более простой вариант с чуть большей по размеру картинкой может оказаться более выгодным.

[parallelno]

Согласен. Нужно учитывать все.
Пока результат меня радует. Напоминает кадр из СD фильма на паузе :D

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

Обновил статистику
5175 байт с ZX0 и 4534 bytes (13.83667%) с помощью UPKR.

https://i.ibb.co/1Jp3r7m/shot-230416-215612.jpg (https://ibb.co/Fqf95mD)


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

Картинка с дизером
5740 байт с ZX0 и 4953 bytes (15.115356%) с помощью UPKR.


https://i.ibb.co/0nBwr16/shot-230416-223213.jpg (https://ibb.co/10sSTBP)
original photo download (https://imgbb.com/)

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

Имхо вполне не плохо при таком коэфициенте сжатия

[ivagor]

Посмотрел tmp-rgb-compressed.png (256x256). По этой картинке еще нельзя судить о том, что будет на векторе. Надо привести к 16 цветам и в рамках векторовской палитры. К сожалению качество неминуемо ухудшится, но скорее всего улучшится сжатие.

[parallelno]

Посмотрел tmp-rgb-compressed.png (256x256). По этой картинке еще нельзя судить о том, что будет на векторе. Надо привести к 16 цветам и в рамках векторовской палитры. К сожалению качество неминуемо ухудшится, но скорее всего улучшится сжатие.

Наверное я в торопях выложил не приведенную к палитре вектора картинку. Но упаковка адаптирует палитру перед сжатием, поэтому коэффициент сжатия не измениться.
Я сжимал всю картинку, где по сути продублированы тайлы. если сжимать только уникальные тайлы, то UPKR выдает что-то примерно 4600. И ещё будет 1024 индексный массив из байтов. Нужно будет пожать все это безобразие и сравнить.

[ivagor]

У меня возникло много вопросов, но думаю они все прояснятся когда увижу результат сжатия под вектор.

[svofski]

Извини, Понкратова-Черного знаю, LFSR-Пушкина не знаю. Кто это?
У меня есть технология получения довольно компактного Пушкина в стиле импрессионизма, типа такого:
78782
Причем проверено, что и с Гоголем алгоритм работает:
78783

На самом деле я его все-таки расчехлил и даже с дохленьким лаптопным GPU прогнал его на примере parallelno, но пришел к выводу, что здесь он совершенно не подходит.

[nzeemin]

parallelno, ещё такую идею хочу предложить.
Вам же не обязательно нужна вот эта же самая картинка, прямо один-в-один?
С помощью AI можно получить десяток очень похожих на неё, но немного отличающихся.
И всю серию уже пробовать сжимать -- какая лучше сожмётся.

https://disk.yandex.ru/d/4jGJckl0_mCM9w -- вот тут четыре картинки "по мотивам", 512x512

[parallelno]

nzeemin, на самом деле эта было сгенерировано с помощью AI midjourney. :) Да, мне не принципиально. Это точно.
Кстати я уже допилил упаковщик. Точнее сказать упроститель.. :) сейчас собираю статистику. Скоро выложу. Имхо интересные результаты. :)

[parallelno]

Буду сюда выкладывать сравнения.
Для сравнения я взял картинку, адаптировал под размер и палитру Вектора, затем индексы цвета двух соседних вертикальных пикселей объеденил в один байт. Добавил палитру, все упаковал UPKR упаковщиком.
Вторая картинка это та же картинка только прогоненая через vector quantization, затем декодированная обратно, востановлена палитра (местами неточно). Потом индексы цвета двух соседних вертикальных пикселей объеденил в один байт, упаковано UPKR упаковщиком.

То есть подход по сути не упаковщик, а упрошатель картинок. :)
Я сделал свой формат на тайлах, но он начинает сильно жирнеть когда тайлов больше 256, поэтому отказался в пользу просто востановленной картинки после квантизации и упакованой как та с которой идет сравнение.

и так lossless vs lossy:

contrast_dither_adaptive
original image to upkr: 8886 // lossless, 8886 байт
vector quantization to upkr:
3608, rate: 0.41, tile_size: 4, n_clusters: 256 // lossy, 3608 байт. rate это во сколько он меньше чем lossless
4473, rate: 0.50, tile_size: 4, n_clusters: 1536
6605, rate: 0.74, tile_size: 2, n_clusters: 1536

https://i.ibb.co/bJLMjDY/result-contrast-dither-adaptive-comp.png (https://ibb.co/BNj5HFv)

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

original image to upkr: 8886
vector quantization to upkr:
3554, rate: 0.40, tile_size: 4, n_clusters: 256
4428, rate: 0.50, tile_size: 8, n_clusters: 256
5531, rate: 0.62, tile_size: 2, n_clusters: 1536

https://i.ibb.co/XkXXfTy/result-image-intro-comp.png (https://ibb.co/qFBBLw0)
[/url]

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

image_intro2
original image to upkr: 8049
vector quantization to upkr:
3651, rate: 0.45, tile_size: 8, n_clusters: 256
4386, rate: 0.54, tile_size: 4, n_clusters: 1024
5273, rate: 0.66, tile_size: 2, n_clusters: 1536

https://i.ibb.co/tX2kPDx/result-image-intro-2-comp.png (https://geojsonlint.com/)

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

img06
original image to upkr: 10230
vector quantization to upkr:
4333, rate: 0.42, tile_size: 8, n_clusters: 256
4873, rate: 0.48, tile_size: 8, n_clusters: 512
5322, rate: 0.52, tile_size: 2, n_clusters: 1536

https://i.ibb.co/9833PpC/result-img06-comp.png (https://ibb.co/WxppCHY)


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

img14
original image to upkr: 3818
vector quantization to upkr:
2828, rate: 0.74, tile_size: 4, n_clusters: 512
3295, rate: 0.86, tile_size: 2, n_clusters: 512
3604, rate: 0.94, tile_size: 2, n_clusters: 1536

[url=https://ibb.co/bLvY6Qz]https://i.ibb.co/q9ghD7k/result-img14-comp.png (https://imgbb.com/)

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

img17
original image to upkr: 3008
vector quantization to upkr:
2751, rate: 0.91, tile_size: 2, n_clusters: 96
2877, rate: 0.96, tile_size: 2, n_clusters: 1536

https://i.ibb.co/h188K6P/result-img17-comp.png (https://ibb.co/prXX37t)

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

svofski, а какие размеры получились у писателей? у тебя сохранились оригиналы, хочется прогнать через VQ алгоритм.

[svofski]

svofski, а какие размеры получились у писателей? у тебя сохранились оригиналы, хочется прогнать через VQ алгоритм.
Пушкин был 1394 байта + 373 байта рисовалка, спасибо ivagor-у. Но это нельзя сравнивать. В моем алгоритме псевдослучайно блуждающая кисточка малюет картинку и фактически он пригоден только для очень крупных планов и высоко узнавабельных оригиналов. Скорость отображения очень низкая, это годится только как демо-эффект, но для этого надо сначала все разогнать раз в 10. Наверняка можно улучшить, но все равно на алгоритм для общего применения он никогда не потянет.

Оригинала картинок у меня не сохранилось, но если просто сравнить, тут ничего сложного. Берешь первый попавшийся портрет (не обязательно Пушкина на самом деле), обрезаешь его примерно вот так как у меня, и запускаешь.

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

Картинку типа img06 по-моему можно векторизовать и рисовать полигонами. Но это тоже вряд ли получится сделать очень быстро.

[parallelno]

Хочется услышать ваши мысли по поводу результатов. Все ли понятно из статистики? Какие вы видите плюсы и минусы. Может быть у вас есть идеи для улучшения?

[ivagor]

Абстрактные оценки в вакууме мало что дадут. Сколько свободной памяти и сколько картинок нужно разместить?

Если несколько больших (полноэкранных?) картинок, то использование upkr мне кажется жестоким по отношению к пользователю. Понимаю в деме предельных параметров распаковать 1-2 картинки, человек посмотрит ее один раз и успокоится. А если запускать игру несколько раз и там каждый раз upkr распаковывает картинки по 32 Кб, то терпение быстро иссякнет. Еще момент с местом под распаковку - при использовании "безбуферных" (выдающих полный результат) распаковщиков в сочетании с пикселями нужно дополнительно 32 Кб. Вместо этого можно использовать менее эффективные упаковщики, но с буферными (удобно на 256 байт) распаковщиками и потратить те 32 Кб на компенсацию меньшей степени сжатия. На мой взгляд приемлемыми компромиссами по скорости и степени сжатия являются rip и exomizer, плюс они умеют ограничивать длину и дальность ссылок, т.е. можно распаковывать в кольцевой буфер ограниченного размера.

Никогда всерьез не занимался сжатием палитровых картинок, но насколько я понял из прочитанного, сейчас самый модный вариант - предсказатели+оптимизация палитры для согласования+сжимаем арифметическим кодером. Но тут еще надо найти эти экспериментальные упаковщики, сделать для них распаковщик для вектора и получить скорость скорее всего хуже upkr.
Для полутоновых или нечто jpeg-подобное (с ДКП) или вейвлеты. Но тут сразу много вопросов - насколько приемлемы полутоновые картинки, устроит ли 8 оттенков желтого/зеленого/красного, распаковщик сложный и медленный. 16 отенков серого на ЧБ мониторе более интересны, но это специфическое решение. Кстати, для полутоновых векторное кодирование должно давать более приемлемые результаты, чем для палитровых. Еще можно вспомнить экзотику типа фрактальных, но это опять надо искать упаковщики и делать распаковщик.

Возвращаясь на землю, я бы скорее всего ориентировался на rip. Если сжимать байты, то распаковываем на экран. Если сжимаем пиксели, то распаковываем в кольцевой буфер. Пиксели сжимаются лучше, но ограничение длины и дальности ссылок ухудшает сжатие, поэтому надо смотреть конкретные примеры. Также использование буфера позволяет распаковывать картинки произвольного размера, а не на полный экран.

[parallelno]

ivagor, напиши пожалуйста что ты думаешь про упрощатель картинок. Напиши если можешь свои мысли по поводу соотношения качества изображения и размера. Вместо upkr может быть любой упаковщик.

[ivagor]

Про упрощатель у меня есть не особо оригинальная мысль:
1) делим картинку на квадратные или прямоугольные блоки
2) в рамках блока оставляем 2 или 4 цвета из 16
Тут несколько степеней свободы или точек приложения сил для экспериментов
1) какие размеры блоков выбрать
2) сколько цветов в рамках блока
3) как выбирать цвета (понятно, что тут с потерями) когда выбор неоднозначен
Из упаковщиков я бы, по крайней мере для начала, ориентировался на salvador. Он умеет сжимать под кольцевой буфер заданного размера и для буфера 256 байт есть готовый распаковщик zx0.
Для примера: пусть блоки 8x8, в блоках 4 цвета из 16. Картинка 256x256: 16 Кб пиксели, 2 Кб цвета блоков. Т.е. в примере из 32 Кб сократили до 18 и это еще без сжатия "обычным" упаковщиком. Другое дело, как будет выглядеть такая упрощенная картинка, возможно, что совершенно неприемлемо.
Вариант с блоками можно развить до иерархического, опять же надо пробовать, возможно это дурацкая идея, а может где-то хорошо подойдет.

[parallelno]

А что ты думаешь про результаты упрощателя которые я представил выше?

[ivagor]

Если сравнивать с беспотерьным вариантом, то результаты интересные. Но, как я ранее написал, считаю, что надо сравнивать с целевыми значениями (сколько места и сколько картинок требуется) и с использованием чего-то менее сурового, чем upkr.

[Improver]

Про упрощатель у меня есть не особо оригинальная мысль:
1) делим картинку на квадратные или прямоугольные блоки
2) в рамках блока оставляем 2 или 4 цвета из 16А что если картинку сначала разделить на четыре плоскости по цветам? А потом уже делить на монохромные блоки, при этом сплошная заливка областей картинки даст хорошее сжатие...

[ivagor]

В принципе одноцветные блоки должен дожимать упаковщик. Но есть другой вариант - если цветов на блок 4, то всего комбинаций 65536, а для картинки 256x256 будут востребованы максимум 1024. Часть комбинаций можно задействовать для индикации неких специфичных блоков, например одноцветных. Для палитровых картинок разбиение на плоскости в общем случае вряд ли много что даст, разве что в связке с оптимизацией палитры (перестановками).

[Improver]

Для палитровых картинок разбиение на плоскости в общем случае вряд ли много что дастТут надо просто поставить эксперимент, как будут сжиматься теми же упаковщиками те же картинки, но разбитые по плоскостям. А если будет последовательное заполнение 32кб, это может упростить (и ускорить) распаковщик?

[ivagor]

А если будет последовательное заполнение 32кб, это может упростить (и ускорить) распаковщик?
Конечно, просто распаковываем в экран распаковщиком общего назначения. Но по пикселям лучше сжимает.

[svofski]

Когда делал Бадап, столкнулся с тем, что надо как-то делать образ диска с файлами. Есть чудесная утилита SteinBlume (http://era-cg.su/steinblume/?lang=en) и плюгины к древним фарам, но все они интерактивные. А мне надо, чтобы все было терминально угрюмо и из командной строки. Поэтому я взял давно уже написанный код из vector06js и завернул его в отдельную утилиту, которая позволяет взять рыбу fdd по вкусу и положить в нее свои файлы.

Написано на js, для запуска нужна node (npm не нужен). exe можно сделать если будет спрос, но мне самому не нужно и пока никто не просил.

https://github.com/svofski/v06c-fddutil/

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

P.S. Это по-моему самая толковая тема про разработку для Вектора. Может быть можно сделать ее Важной?

[parallelno]

Добавил информацию про тайминги кадра.

[parallelno]

Добавил информацию о портах.