Ищу программера для помощи в модификации PSP-движка (Never7, Ever17, Remember11 и тп) - Страница 6

Yoti · 07.02.2015, 14:50

ErikPshat,
а как по мне, то нет =) Буду дома - проверю на консоли.

ErikPshat · 07.02.2015, 15:10

Ну вот, например в файле есть такого вида смещения. И я вижу в этих же позициях в файле EBOOT.BIN именно эти же записи значений.

2015-02-07_14-58-54.png

Последняя имеющаяся секция в файле = 0x0014D5D8. Там нет столько байт, как 0x08804000.
Вот так показывает его смещение:

2015-02-07_15-03-15.png

Хотя, по аналогии со всеми другими смещениями, должно отображаться loc_0011A38C, потому что именно по тому адресу в EBOOT.BIN он прописал кнопки.
Но не на loc_0891E38C. Хотя PSP видимо считывает и так и эдак.

**riku.kh3** · 07.02.2015, 15:48

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

Ну вот, например в файле есть такого вида смещения. И я вижу в этих же позициях в файле EBOOT.BIN именно эти же записи значений.

Вложение 10648

Последняя имеющаяся секция в файле = 0x0014D5D8. Там нет столько байт, как 0x08804000.
Вот так показывает его смещение:

Вложение 10649

Хотя, по аналогии со всеми другими смещениями, должно отображаться loc_0011A38C, потому что именно по тому адресу в EBOOT.BIN он прописал кнопки.
Но не на loc_0891E38C. Хотя PSP видимо считывает и так и эдак.

Да, как-то не гуд выглядит. Может с совместимостью проблемы потом возникнуть в каком-нибудь из эмуляторов. Может другим ассамблером попробовать этот опкод собрать?

ErikPshat · 07.02.2015, 16:06

riku.kh3, да в принципе лучше оставить, как есть. Работает замечательно.
А вот мой вариант я проверил, и не работает

У меня рассчёт на смещение вроде правильный, там прописывается адрес 4-байтными шагами на байт.
Просто номер функции MIPS видимо не такой. Но вроде верный.
Там 1-ый байт 0х08 берёт адресацию 0х00000000, если 0х09, то адресация 0х04000000, если 0х0A, то 0х08000000ю

**riku.kh3** · 07.02.2015, 16:20

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

riku.kh3, да в принципе лучше оставить, как есть. Работает замечательно.
А вот мой вариант я проверил, и не работает

У меня рассчёт на смещение вроде правильный, там прописывается адрес 4-байтными шагами на байт.
Просто номер функции MIPS видимо не такой. Но вроде верный.
Там 1-ый байт 0х08 берёт адресацию 0х00000000, если 0х09, то адресация 0х04000000, если 0х0A, то 0х08000000ю

простой джамп, видимо, не принято на psp использовать. jr и jal повсюду только вижу

насколько я понимаю, надо еще инструкцию добавлять и через регистр по правилам делать джамп, а места там нету

ErikPshat · 07.02.2015, 16:45

riku.kh3, да не, джампов там полно, они в конце все.

J

Сообщение от riku.kh3

насколько я понимаю, надо еще инструкцию добавлять и через регистр по правилам делать джамп, а места там нету

Scorpeg вроде всё нормально сделал, и инструкцию добавил и return на следующую функцию. Он всё это встроил вместо сообщения об ошибке и туда направил прыжок. Просто я не пойму, почему стандартный мой отсчёт не работает, хотя по всему файлу виден явный отсчёт без всяких прибавок 0х08804000.

**Scorpeg** · 07.02.2015, 16:59

Хакеры, вашу мать

Scorpeg добавил 07.02.2015 в 16:59

Сообщение от riku.kh3

Да, как-то не гуд выглядит. Может с совместимостью проблемы потом возникнуть в каком-нибудь из эмуляторов. Может другим ассамблером попробовать этот опкод собрать?

Это у Erik'а задвиг не туда. Всё четко у меня. Ты ж видишь что работает, нет?

Был бы косяк - оно бы не работало.

Короче ликбез нумер два для Erik'a и сочувствующих.

Во второй раз говорю (как уже ранее я писал и недавно писал Yoti) в память PSP Eboot грузится по адресу 0x08804000. Не каждая программа, но в 99% случаев это так (там прописано в общем-то в ебуте куда грузить).

То есть eboot грузится по этому адресу в память PSP, принимай это как факт.

Что происходит далее? Далее происходит применение релоцируемых данных или как их там по научному зовут. Суть их в чем - существует где-то в ебут табличка, где отмечены адреса с переходами (джампами). После загрузки проги в память PSP пробегает по всем адресам и относительное смещение (вот это вот j 0x1111 которое вы видите в других джампах в PRXTool) преобразует в абсолютное (в j 0x8804000+то число).

Поэтому, если вы например вместо любой инструкции (кроме джампа) воткнете например j 0x33333 она у вас так и останется неправильно j 0x33333 потому что она отсутствует в таблицу-указателе на релоцируемые адреса.

Поэтому Erik пошел вообще не туда. У меня код не имеет релоцируемых адресов - поэтому там указывать надо абсолютные адреса для джампов.

**riku.kh3** · 07.02.2015, 17:04

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

Это у Erik'а задвиг не туда. Всё четко у меня.

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

**Scorpeg** · 07.02.2015, 17:17

Да потому что bne - это относительная инструкция. Там адрес считается в пределах +0xffff и -0xffff от КОМАНДЫ.

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

То есть на деле оно выглядит как "прыгни на адрес, который равен текущему + сколько-то (но не больше 65535)".

Ну или доку по мипсам прочитай, там ровно то же самое написано.

А джамп использует абсолютную адресацию, поэтому там пишется абсолютный адрес. Бранчем нельзя же адресовать больше 65535 байт вперед и назад, а у меня он явно дальше ушел.

Scorpeg добавил 07.02.2015 в 17:17

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

ErikPshat,
а как по мне, то нет =) Буду дома - проверю на консоли.

Можешь не проверять, на ней тоже работает

ErikPshat · 07.02.2015, 17:28

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

Поэтому Erik пошел вообще не туда. У меня код нерелоцируемый - поэтому там указывать надо абсолютные адреса.

Ну теперь-то понятно. Я так и понял, что у тебя адрес без релокации оказался, потому что новую функцию дебаггер не видит.

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

(но не больше 65535)

А это почему? Я вижу, что адресация кругом подсчитывается 3-мя байтами, не обязательно до FFFF. Вот примеры:

0x000B6270: 0x0802D866 'f...' - j          loc_000B6198
0x0011104C: 0x08044346 'FC..' - j          loc_00110D18

0x0802D866 --- loc_000B6198 = 745880 : 4 = 0х02D866
0x08044346 --- loc_00110D18 = 1117464 : 4 = 0x044346

Как бы больше, чем 65535. Первый байт 0х08 - указывает на функцию джумпа в 0х00000000.

ErikPshat · 07.02.2015, 18:09

Можешь проверить все смещения и этот алгоритм будет во всём файле применим.
Существует ещё правило, когда номера функций идут строго 2-байтные, то оставшиеся 2 байта значения пишутся младшими байтами(ессно до FFFF(65535)), а старшие байты просто отбрасываются.

**Scorpeg** · 07.02.2015, 19:05

Ты по диагонали чтоли прочитал? Я про команду branch (bne например), не про jump. У джампа 3 байта + 2 бита (26 бит) под адрес, у бранча - 2 байта под указатель смещения (16 бит). Еще раз отсылаю читать доку по mips, а не спорить ради спора. А лучше в Never7 разбираться

Scorpeg добавил 07.02.2015 в 19:05

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

Ну теперь-то понятно. Я так и понял, что у тебя адрес без релокации оказался, потому что новую функцию дебаггер не видит.

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

ErikPshat · 08.02.2015, 10:01

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

Я про команду branch (bne например), не про jump. У джампа 3 байта + 2 бита (26 бит) под адрес, у бранча - 2 байта под указатель смещения (16 бит). Еще раз отсылаю читать доку по mips, а не спорить ради спора.

Ну так а я про джампы веду разговор. Это ты же читаешь мои посты про джампы, а отвечаешь про бранчи. Бранчи-то понятно, что там там другой алгоритм и математическая формула. Там 2 регистра и значение, где в значении указывается смещение, относительно места расположения этого самого значения и расчитывается по формуле: значение - offset : 4 - 1.
И по ходу дела, я смотрю структуру кода и сразу выписываю формулы, чтобы закрепить знания в постах. Тебе может это не надо, но другие люди тоже могут искать ответы на подобные вопросы и им может помочь информация, каким образом эти цифры появляются и генерируются в файлах.

Короче, я просто посмотрел твои формулы и заметил, что ты использовал абсолютные смещения, хотя в EBOOT.BIN кругом используются относительные внутренние смещения. Поэтому подумал, почему бы не воспользоваться стандартами по аналогии с файлом, и вынес этот вопрос на обсуждение. От тебя просто хотелось услышать пояснения, почему был избран такой путь, а не то, как "у Erik'а задвиг не туда" или всякие ликбезы.

Ладно, признаю, что я полный лох педальный.
За твою реализацию хитрого плана с кнопками, присваиваю тебе звание Про-Геймера

riku.kh3, почитал ещё раз твою ссылку: http://bbs.blacklabel-translations.c...?tid=35&pid=84
В первый раз как-то не так дошло и я не туда полез выполнять шаг 2. Сейчас наконец допёрло, что это относилось всё к тем же строкам. Там помимо смены $zero на регион, чтобы не было глюков, надо было ещё сменить функцию move на li. После первой правки было так, с move:

0x0000C7D0: 0x00002025 '% ..' - move       $a0, $zr
0x0000C7D4: 0x0C045016 '.P..' - jal        sceImposeSetLanguageMode
0x0000C7D8: 0x00002825 '%(..' - move       $a1, $zr

Чтобы сменить регистры, нужно поменять регистры move: 2025 и 2825 на li: 2404 и 2405 (для 10-тичного формата) или на 3404 и 3405 (для 16-ричного формата)

0x0000C7D0: 0x24040008 '...$' - li         $a0, 8
0x0000C7D4: 0x0C045016 '.P..' - jal        sceImposeSetLanguageMode
0x0000C7D8: 0x24050001 '...$' - li         $a1, 1

Я сделал смену языка в десятичном формате. Если в первой строке поставить 1, то будет надпись на английском языке, я поставил на 8 для русского языка. Готовый файл, с правками кнопок от Scorpeg, во вложении...

**riku.kh3** · 08.02.2015, 10:41

ErikPshat, это не то же самое?

**Scorpeg** · 08.02.2015, 12:05

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

Ну так а я про джампы веду разговор. Это ты же читаешь мои посты про джампы, а отвечаешь про бранчи. Бранчи-то понятно, что там там другой алгоритм и математическая формула. Там 2 регистра и значение, где в значении указывается смещение, относительно места расположения этого самого значения и расчитывается по формуле: значение - offset : 4 - 1.

Да в том и дело, что у тебя на скриншотах как раз бранчи и написаны https://www.pspx.ru/forum/attachment....8&d=1423310816. ruki и не понял, почему бранчи правильно показываются, а джамп нет. Я ему и объяснил, как это делается (там первая же фраза в сообщении "Да потому что bne - это относительная инструкция. Там адрес считается в пределах +0xffff и -0xffff от КОМАНДЫ." - то есть сразу понятно, что я не про джампы). А ты эту фразу не заметил или еще чего, начал спорить на пустом месте непонятно с чем

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

Вообще есть такая вещь как armips https://github.com/Kingcom/armips собственно ассемблер для мипсов (может кто не знал). Я в нем писал. Мож кому-то будет полезно. Kingcom правда загрузку ELF'а в нормальном виде не прикрутил, так что придётся как я писать пока что.

ErikPshat · 08.02.2015, 19:11

Сообщение от riku.kh3

ErikPshat, это не то же самое?

У-ха-ха, да, именно тоже самое

Я чёта не допёр сразу. Это вчера только боги спустились с небес и мне во сне объяснили что к чему.

Только в тот раз я move не трогал, а просто сменил zero на 1 и у меня высвечивалось по-русски. В этот раз я поменял на li и всё стало по-английски, пришлось поменять 1 на 8. Но ты конечно изначально уже всё это сделал. Бывают у меня заскоки, когда глаза видят одно, а мозги вычисляют по другому. Просто когда до мозгов сразу не доходит, то они думают как-то иначе

ErikPshat · 08.02.2015, 19:25

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

Да в том и дело, что у тебя на скриншотах как раз бранчи и написаны https://www.pspx.ru/forum/attachment....8&d=1423310816

Ну так опять же, это был только пример, где я хотел показать, что оффсеты указываются без прибавки 08804000. Где относительные смещения указываются относительно самого файла. Только и всего.

А за армированные мипсы спасибо. Было дело я когда-то в Mars-e умудрился написать программку на асме, где на кубике Yoti что-то там плавало. Да там собсно не С++ писать, это как батники рисовать, просто смотришь спецификацию и рисуешь. Но конечно в асме и мипсах я ничерта не шарю, всё держится только на логическом обосновании.

**Scorpeg** · 08.02.2015, 22:56

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

Ну так опять же, это был только пример, где я хотел показать, что оффсеты указываются без прибавки 08804000. Где относительные смещения указываются относительно самого файла. Только и всего.

Так и я не тебе, а riku отвечал. И ты опять путаешься в показаниях, до этого говорил, что ты про джампы, теперь ты про оффсеты заговорил, хотя оффсеты только у бранчей, а у джампов - прямые ссылки. Короче замнем это, не суть, а то можно долго докапываться, кто чего хотел сказать

И ты может начнешь уже Never7? Я тебе даже план уже написал, тулзы тут есть (вообще почти все тулзы подойдут отсюда, и формат графики тоже наверное). Осталось только скрипты повыдирать и присоединить. Ну и init.bin разватрушить (я не осилил пока что его целиком, только 75% гыгы)

**Scorpeg** · 03.04.2015, 11:26

Кстати по поводу картинок. Всё не так

Это просто такие удачные картинки попались с одной колонкой.

А на самом деле оно выглядит так: http://psp4real.ru/_tr/kb_0.png

И где-то там, в хедере, находится информация, как из этих квадратиков собрать нормальную картинку.

dreambottle · 18.02.2016, 20:39

Всем привет. Проект еще жив? На неделе разбирал ресурсы Remember11, пытаясь адаптировать перевод (заодно узнал что psp сцена почти умерла

). И столкнулся с некоторыми трудностями. Возможно, здесь мне кто-нибудь сможет помочь. И, конечно, готов поделиться всем, что обнаружил сам, если это окажется полезным.

Я, по возможности, реюзаю код комманды из tlwiki, которые занимались pc версией, попутно допиливая нужные изменения.
С картинками много не заморачивался, т.к. пользы от этого мало. Зато разобрался со шрифтами, осталось только нормальный конвертор в bmp/png и обратно написать.

Набросал скрипты для распаковки iso, распаковки AFS, декомпресии упакованных lzss-ом ресурсов, и переупаковки всего этого добра(или зла - зависит от восприятия) обратно.
Ресурсы пока не модифицирую, не считая некоторой работы с BOOT.BIN руками, т.к. для начала хочу убедиться, что все правильно пакуется и сжимается.

Все работает, с одним досадным исключением: если разжать и сжать обратно init.bin, то игра будет крешиться при загрузке. Через эмулятор тоже крешится, при чем сам эмулятор. А разжимать файл надо, т.к. туда вбита большая часть текста. Кто-нибудь сталкивался с такой проблемой? и как ее решили?

Подскажите, можно ли как-то "дебажить ассемблер"? Подключить gdb к запущенному iso не знаю как, но мне нужно как-то определить где оно вылетает.