Прога разбивает загрузчик на системы, системы на модули, модули на блоки:
В блоках, типа APL распарсивает таблицы изображений:
Пока не могу понять как осуществляется адресация внутри блоков, поэтому начало таблиц изображений указано явно, но внутри таблиц с адресацией все в порядке.
Некоторые изображения (как на скрине) лежат в формате BMP, и с ними проблем нет. но большинство в каком-то сжатом BMP, с расширением bmp.s2 . Как их расжать и увидеть в нармальном виде - я пока не знаю. HEX представление этих изображений представлены чуть ниже.
В блоках типа FNT распарсивает таблицы шрифтов и отображает их:
Тут с адресацией внутри блока тоже все плохо и начала таблиц шрифтов указаны так же вручную. Внутри таблиц адресация нормальная.
Из всего этого созревают несколько вопросов.
1. Как осуществляется адресация внутри блоков?
2. Что за сжатие у изображений в формате bmp.s2?
Больше, конечно интересует адресация, может кто-нибудь в курсе.
И еще. В модуле LDM есть стартовые изображения, несколько штук. они в нормальном виде bmp. Но с адресацией на них тоже все плохо. Просто искать их по сигнатуре BM - это не наш метод.
_________________
Ваз2105 - Audi 80 - Audi A6/C4 q - Audi A3/8L - Audi A4/B7 q
Зная поделки компании AISIN (я в хор смысле слова!)
где-то должна быть таблица со всем этим делом!...
А если тупо искать адреса смещений по лоадеру? не находятся?
должна быть таблица! (мое имхо)
да картинки пожаты по словарю(таблица) нужен этот словарь для распаковки!
До этого переводил игры, и писал распаковщики к ним ...думаю здесь все тоже!
Программеры ведь ленивые люди и что-то новое редко используют
crash_rider писал(а): А если тупо искать адреса смещений по лоадеру? не находятся?
Не мог найти. Искал и от начала модуля и от начала блока и не явное смещение, делённое на 2, на 4, на 8 и т.д.
crash_rider писал(а): картинки пожаты по словарю(таблица) нужен этот словарь для распаковки!
Спасибо! Буду искать.
crash_rider писал(а): Программеры ведь ленивые люди и что-то новое редко используют
Это точно. Подблоки шрифтов, например, которые называются v168 и v167, используются не только в нашей прошивке, в других тоже встречал. Пихают их везде одинаковые, хотя часть шрифтом там вообще не используются.
_________________
Ваз2105 - Audi 80 - Audi A6/C4 q - Audi A3/8L - Audi A4/B7 q
А как вам такая идея?
А что, если объединить усилия всех желающих в одном проекте?
Я понимаю, что начинать с нуля очень сложно. Сам ещё не знаю, как это объединить и кому это интересно. Понимаю, что время движется вперед и через 5 лет, это уже совсем никому не будет нужно. Но очень хочется до конца разобраться с этим чёртовым КИВИ. Тем более, что большая часть пути уже пройдена). Готов поделится всеми исходными кодами своей программы, если найдутся желающие развивать проект дальше.
Присоединяюсь к идее " объединить усилия всех желающих в одном проекте? "
maxx_18 - вот мой редактор растровых фонтов типа *.bmf от loading.kwi Mitsubishi и Volvo
solk.org.ua/JMBFEditor.jar
Для старта: могу добавить туда редакцию растровых фонтов из блоков типа FNT (AISIN)
Если согласен: вышли мне плз.:
- один такой FNT, и как в нем найти описание, например, латинской буквы "A"
Я пока плохо знаю инсрументарий на Вашем сайте, со временм научусь....
Это сообщение написал с пятого раза, все время для правки вылетаю не туда и все затирается
Посему не серчайте, если сразу не увижу сообщение для меня. Лучше, конечно, дубль в личку
Я думаю не программу делать всем вместе, а типа документации, с описанием форматов,полей, смещений и т.д. Но только желательно на русском языке, а то у меня с английским не очень
А пока приведу выкладку по растровым шрифтам модуля aisin.
Шрифтов в модуле очень много, есть даже греческий шрифт, кириллица и иероглифы:
Весь блок шрифтов делится на несколько подблоков,которые дополняются нулями до какого-нибудь адекватного смещения. Можно выделить подблоки каких-то значков, иероглифов, и т.д. Но наиболее адекватными являются 3 подблока, в которых есть четкая адресация на шрифты. Разберем первый подблок, который начинается со смещения 7E000 в блоке FNT V220062A. Вот сам подблок: yadi.sk/d/oxdRoCmtkjfuB .
Начало подблока выглядит так:
Первые 4 байта в символьном выражении ".FNT" - это определения блока, т.е. указание на то, что это блок шрифтов.
Следующие 4 байта "00 00 00 01" - видимо означает количество еще каких-то подподблоков, но это не так важно.
Следующие 4 байта "00 09 06 CA" - это размер данного подблока, 591562 байт.
Следующие 4 байта в символьном выражении "V168"- название подблока
Следующие 2 байта - "01 42" - размер заголовка описания шрифтов вместе с этими 2 байтами (ну или смещение до следущего заголовка). На скрине выделен первый блок описания шрифтов:
Дальше каждые 8 байт описывают характеристики одного шрифта. Т.е. можно узнать сколько всего шрифтов: (322-2)/8 = 64. Те подблок описывает 64 шрифта. Но на самом деле больше половины из них пустые, поэтому реально их 19, в чем сейчас и убедимся.
Вот первые 8 байт после размера заголовка: "00 00 00 00 00 00 00 00" . Они все нули, поэтому шрифт не реализован этот. Такая же ситуация и со вторым и с третьим и т.д.
Первый реальный шрифт выделен на рисунке:
Вот строка, описывающая шрифт: "01 11 10 10 77 22 7A 60".
Здесь абсолютной уверенности нет, но первые 2 байта связаны с битностью данного шрифта (а шрифты в данном блоке бывают 1 битные и 4 битные). 3 и 4 байт - это размер шрифта (те его ширина в пикселях), в данном случае размер равен 10. Иногда эти байты не совпадают и берется 4 байт, вместо 3. 5,6 байт - это код первого символа шрифта (7722). 7,8 - это соответственно последний символ шрифта.
Таким образом опиваются все шрифты. Далее идет еще одно описание этих же самых шриов, но эже другие характристики. Второй заголовок выделен:
Здесь также первые 2 байта - размер заголовка "01 42", а далее по 8 байт описание каждого шрифта. Рассмотри сразу первый реальный шрифт, который рассматривали в первом заголовке.
Вот его описание: "00 00 02 94 00 DC 00 22"
Здесь первые 4 байта "00 00 02 94" - это смещение, указывающее на начало шрифта.
Далее 2 байта "00 DC" - количество символов в шрифте. В данном случае DC, те 220 символов.
Далее 2 байта "00 22" - количество байт на описание одного символа. Как далее убедимся, каждый символ помимо графической информации содержит еще свой код, то на графику остается 20 байт, что в случае, когда битность изображение равна 1 (те каждый байт кодирует 8 пикселей), означает размер изображения 256 пикселей. Знаем, что размер символа равен 10, те 16 в десятичной, значит каждый символ - это изображение 16х16 пикселей в данном случае.
Аналогично для всех других шрифтов. Сейчас же переместимся на начало нашего первого шрифта. Как помним смещение было равно "00 00 02 94". Переходим по этому смещению:
Здесь выделены первые 2 байта из шрифта, означающие количество символов и первый символ.
Первые 2 байта: "00 DC" - количество символов.
Далее 2 байта "77 22" - код символа, а далее идет описание графической информации в однобитовом представлении.
Мы знаем, что ширина шрифта равна 16, поэтому на одну строку нужно 2 байта. Первые 2 байта: "00 00". Значит самая верхняя строка незакрашена. Следующие 2 байта "18 00", что в двоичном представлении: 0001100000000000. Те во второй строке изображения закрашены 4 и 5 пиксели. Таким образом переведем все байты в двоичные значения и получим растровую картинку:
00000000000000000000
00011000000000000000
00011000000000000000
00111100000000000000
00111100000000000000
01111110000000000000
01111110000000000000
11111111000000000000
11111111000000000000
11111111000000000000
01111110000000000000
01111110000000000000
00111100000000000000
00111100000000000000
00011000000000000000
00011000000000000000
Видно что это какой-то ромб. Вот в моей программе как он выглядит:
В случае, когда изображение имеет цветность в 4 бита (16 оттенков серого) - каждый байт определяет 2 пикселя. И каждый пиксель может иметь один из 16 оттенков серого. Те первая часть байта определяет оттенок одного пикселя, а вторая - другого. Например байт "39" означает 2 пикселя, первый светло серый, второй потемнее. Вот как выглядят 4-битные шрифты:
Таким образом определяются все шрифты из подблока v168. Аналогично из подблока v167. А вот дальше есть еще один подблок шрифтов, именуемый "draw 642.01". У него принцип адресации немного отличается. Кому будет интересно - расскажу.
Но это еще не все. Чтобы шрифты отображались корректно, программе надо знать ширину каждого символа, иначе между символами будут неоправданные разрывы. Что само интересное,таблица ширины всех шрифтов из всех подблоков находится в одном месте, в самом начале модуля V220062A. Вот так выглядит начало таблицы:
Выделен заголовок таблиц ширины. Сразу после выделения начинается таблица ширины первого шрифта, где каждый байт обозначает ширину отдельного символа по-порядку. Можно заметить, что присутствуют целые последовательности байт типа "FF FF FF". Это означает, что в шрифте данные символы пропущены. Как осуществляется адресация здесь и где связь шрифтов и соответствующих таблиц ширины, я не знаю. Догадываюсь, что где-то в начале блока шрифтов, но распарсить пока не получилось, к сожалению. Всем спасибо, будут мысли - пишите.
_________________
Ваз2105 - Audi 80 - Audi A6/C4 q - Audi A3/8L - Audi A4/B7 q
Т.к. все пишут на разных языках программирования, предлагаю разделиться по областям!
Один кто-то пишет редактор шрифтов, другой распаковщик, третий ковертилку графики. Эт я к прмеру написал.
Нам нужно определиться, как будет это все работать...
Это будет много разных проектов на разных языках программирования или один но большой т.е. пишем плагины - библиотеки DLL или OCX и к ним API с описанием.
Тогда, нужно выработать стандарт какой-то для этих API и потом будем вызывать эти библиотеки
Думаю, должно получиться!
А так из одного исходника переделывать под свой язык гимор
Как я вижу это (мое имхо сильно не пинайте)
1. Распаковываем KIWI (denso aisin) (денсо распаковщик почти готов,
с айсин воюем! времени бы по больше
loadind.kwi
Во что нарыл
Modules
0x0000-0x007f header
0x0080-end section
header
0x0000-0x006f name module
0x0070- DW адрес загрузки в RAM
0x0074- DW длина для расчета Checksum (начинается Checksum с 0x0080)
0x0078- DW Checksum
2. Работаем с распакованными модулями
(по AISIN не могу найти таблицу ! но она должна быть , или придется в рукопашную создавать файл со смещениями под каждую прошивку)
2 8maxx_18 ну это я уже пробовал ... не тяну один! как и другие тут пробовали!
Только объединив усилия можно что-то сделать!
Не хочешь делиться исходниками делай библотеку(плагин) dll, ocx
А капать одно и тоже, но разным людям - это как толочь воду в ступе!
Про перевод.
Без изменеия таблицы ширины символа все надписи на японских мафонах это тихий ужас!
Японский иероглиф норм смотрться, но вот Восп Нзд Впр - это пи.... не нашел таблицу тоже в яповских.
Но если и переводят, то переводят картинки (jpg, png) а часть переденного текста ужас получается, если он не картинкой сделан!
пока забил...
Бошка и моник от grs200 валется на столе - для экспериментов но полноценно перевести не получается времени и знаний видно не хватает
Мож голосовалку замутить? кто за много маленьких проектов и кто за один с доп плагинами
crash_rider писал(а): Не хочешь делиться исходниками делай библотеку(плагин) dll, ocx
Да я могу и исходниками поделиться, но они на Делфи 2009 и код немного через одно место, тк на Делфи мало опыта программирования.
crash_rider писал(а): Без изменеия таблицы ширины символа все надписи на японских мафонах это тихий ужас!
Где эти таблицы находятся - это известно, можно и подредактировать их, опытным путем вычислить необходимую таблицу и подправить ее в соответствии с новыми значениями ширины переделанного шрифта. Это не проблема и сделано уже давно (внедрен русский шрифт вместо кракозябр). Сейчас хочется научного подхода )).
Вот очень интересные места в начале каждого блока:
crash_rider писал(а): 0x0070- DW адрес загрузки в RAM
Я думаю, надо здесь немного покапать. В начале каждого модуля идет набор каких-то смещений, начало которых совпадает с этим адресом загрузки в РАМ.
_________________
Ваз2105 - Audi 80 - Audi A6/C4 q - Audi A3/8L - Audi A4/B7 q
гы во дела? что все на дельфи пишут? я тоже люблю дельфи за скорость компилятора и работу программ хоть на 98 винде, хоть на 2012 сервере!!! а vc++ кучу библиотек с собой таскать, да и просто не поставишь их (привет windows 9!
Но иногда просят и на vc++ и на asm всавки для скорости
Моя поделка тоже на дельфи!
Так у нас тогда все почти готово!
crash_rider писал(а): Моя поделка тоже на дельфи!
Так у нас тогда все почти готово!
Привет!
Вот потихоньку въезжаю в Вашу тему.
Поделись плз. инфой по DENSO, можно просто ввиде кода, на любом языке, я разберусь или просто словами.
Если код здесь не к месту, можно вот здесь:
madlord.info/ml...m/viewtopic.php?f=8&t=19
или мне в личку или мой email: nick@avalr.com.ua
Вопрос:
1) В headers loading.kwi есть только offset и soze для module? - или я что-то не увидел?
2) Полученый offset module из headers loading.kwi мы переводим так: offset * 0x800?
- А size? тоже надо умножать или остается таким же?
или я ошибся и здесь другая формула работает?
В loading.kwi от Mitsubishi, например - offset * 2
2) Какое выравнивание ты применяешь при сборке module?
3) Есть инфа?: как читать раздел code для DENSO? Сама структура?
В митсу там все на базе WinCe 3.0-6.0. И все форматы b000ff - давно описаны.
Может дать ссылку на описание формата DENSO? - язык значения не имеет
или выложи плз. где нибудь.... свой вариант