Close Topic Options

Выложил у себя на страничке апдейт для Юндая и его брата-близнеца Вертекса.

За последние год и 2 месяца я впервые что-то выпускаю, да и то - с твоей подачи, Rvs. Думаю, что на этом всё и закончится, если только мне не подсунут ещё какое-нибудь полезное и готовое HOWTO для плейеров, которые у меня дома и ещё исправны

У меня сейчас другое увлечение - портирую эмулятор MSX (про школьные компьютеры Ямаха слышал небось ?) на rockbox. Это такая OS, которая бежит на iPod и других портативных плейерах. Прикольно играть в любимые с детства игры на экранчике, который помещается в нагрудный карман.

cax

Очень жаль терять проверенного бойца!!!
Сейчас я занимаюсь пересадкой USB на свою прошивку погляжу, что из этого выйдет.

Интересное направление, а сайт с наработками есть?

Ну, эмуляторов MSX есть вагон и маленькая тележка - blueMSX, openMSX, а fMSX - так тот вообще на десятки платформ перенесен. Если тебе интересно как я продвигаюсь, и компьютеры MSX вообще - можешь зайти в форум на http://ru.msx.org, где я переводчиком.

В этой ветке обсуждать MSX будет злостным офтопиком.

LDZ

Перекинул процедуру USB, но не заработало. Тогда залил прошивку от сильвера, тоже не фига. Вышли если можешь мне на почту ruslan(тузик)tiraet.com твою которая на XORO заработала.

Ушло. Ты мне обратным ходом намыль свою, залью посмотрю. Ты чем проверял?
ЗЫ. У меня 2 кардридера - один работает, второй не хочет.

Ну так что, никаких разъяснений насчет длинных имен на USB не последует? Меня New Age ничему учить, к сожалению, не хочет, а уж очень хочется сделать эту фичу для Philips 5960. Создается впечатление, что некоторые эксперты по тем или иным причинам не хотят делиться всеми своими наработками, либо считают, что если ты не идиот, то сам разберешься (крутым хакерам с "новичками" не интересно?). В какой-то мере это, наверное, справедливо: я вкалывал, а ты теперь хочешь бесплатно пожинать плоды моего труда? Но в результате просто теряется смысл - если моддеры не будут делиться знаниями, то в чем отличие моддера от профессионала, работающего на производителя плееров, который знает все, и мог бы добавить любую фичу за пару часов, имея доступ к исходникам всего кода, но не хочет ничего делать просто потому, что ему лень (или потому что начальство не требует)?

Кстати, пока так и не получилось собрать кабель для заливки. Такое впечатление, что что-то не работает на плате - уже 4 мобильниковских кабеля изгадил, и так и не удается ничего считать из памяти - ни MtkTool'ом, ни MtkCom. А очень бы пригодилось для отладки (не столько даже для перезаливки, сколько просто засунуть какое-нибудь число в память, и проверить, проходит ли код нужным путем).

This post has been edited by vboroda on 18-05-2007, 20:17

Мобильниковские кабели и мне не помогли. Паяльник я держать не умею, но кабель из одной микросхемы и 5 конденсаторов собрал за 3 часа.

vboroda

Знакомая ситуация Что то из него вытащить практически не реально. Скажу больше у меня сложилось впечатление что у него исходники были уже давно. К тому же он точно работал на XORO, писал для них прошивки, этот факт он не отрицает. Ну да ладно его проблемы...

Нам всем повезло, что сах и Andy007 не похож на NA, за что cax и Andy007 ОГРОМНОЕ СПАСИБО!!!!

Многие жаловались на кабели от мобильников, я себе спаял на 2-х транзисторах за полчаса, работает как часы, если нужна схема вышлю не проблема!!!

Меня этот вопрос мучает не меньше твоего, сейчас я добавил в свою прошивку процедуру поддержки USB, обкатаю её и займусь длинными именами. Думаю поговорить с Andy007, надеюсь получиться. А ты прямо спроси пусть даст ARM с длинными именами, на яше ты засветился, может он, может кто-то другой да выложит, а там уже методом сравнения с оригиналом вытащим их идею!!!

This post has been edited by Rvs on 21-05-2007, 17:49

ARM с длинными именами (вернее, вся прошивка для Medion MD81290) у меня есть. Скачал с сайта New Age. Проблема в том, что там столько всего понапихано, что я просто затрахался пытаться выудить из этого какой-либо смысл.

Там есть довольно простая ф-ция (вернее, две), которые вытягивают сами длинные имена из структуры и записывают в массив, где хранится короткое имя, после этого самого короткого имени. Это я как бы понял. И это якобы был (согласно постингу NA в Яхе) весь секрет добычи длинных имен. Когда понадобится, дам адреса этих ф-ций.

А дальше начинается свистопляска с подстановкой строки по OSD команде 65. И команда эта, похоже, приходит с кучей параметров. Т.е. структура команды 65 мне пока не ясна (хотя ее, возможно, можно будет разобрать из исходников 8032), но главное, непонятно, куда пихать код и все эти жуткие массивы, которые NA аллокирует в нескольких разных местах. У меня в 5960 расширять ARM, похоже, некуда (во всяком случае, программа NA мне в этом не помогла), а свободного места в середине, вокруг USB мессиджей и C++ exceptions тоже не так много - ну, килобайтов 8 от силы. У меня сложилось впечатление, что NA копирует все файловые структуры в какой-то запасной массив (хотя я там не так уж хорошо разобрался, как это на самом деле происходит). В общем, драть его код напрямую я не хочу, без понимания, как и почему это работает. А вот этого самого понимания мне пока и не хватает.

Я думал сделать попроще: установить какой-нибудь флаг, если читаем FAT (USB), а потом посмотреть, нельзя ли в 8032 доступиться к этим же массивам (в которых длинное имя следует сразу за коротким), распечатывая имя файла в "файлобраузере". Но без кабеля я эти исследования пока отложил - боюсь убить устройство нафик.

This post has been edited by vboroda on 21-05-2007, 19:44

vboroda

Работу ты проделал не малую!!! Ну, давай по очереди:

1. Если ты нашел две процедуры которые заполняют массивы разве в них нет адреса самого массива???
2. В 8032 браузер только один, значит алгоритм вывода на экран названия папок и файлов тоже один, а самое главное адреса чтения из DRAM тоже один, отсюда следует, что NA заполняет туже самую структуру, что и при чтении FAT, а про неё мы знаем точно как она выглядит и где расположена. Значит можно глянуть, как выглядит массив в не правленом ARM-е и в правленом NA. Если разница есть, значит, ларчик просто открывался.
3. Я видел ARM увеличенный NA на 30Kb - 50Kb, так что я думаю, что не проблема увеличить ARM.
4. А ты не пробовал пересадить ARM NA в свою прошивку, интересно он все изменения сделал только в ARM-е или и в 8032?

Лучше сделай шнурок, а то закончиться плачевно...

USB LFN

1. Адрес массива безусловно есть. Если 8032 доступается к этому же самому массиву для доставания имен файлов в своей vFlMnDrawPage (ранее известной как DIR_FileBrowser), то дело должно быть совсем не хитрое. Но без шнурка я проверить не могу. А без конца жечь CD болванки мне тоже жаба не дает. 8032 получает массив пойнтеров. Куда эти пойнтеры пойнтают можно узнать только просмотрев память.

2. А вот здесь ты не совсем прав. Вернее, ARM заполняет структуру, да. Но для FAT она не та же, что для CD/DVD. Почему так по-идиотски сделано - ума не приложу. Может, им не достаточно памяти для полных paths длинными именами, а на CD/DVD структура директорий обычно упрощенная, и там особо много не требуется, в то время как на диске может быть 10 вложенных директорий? В общем, там для всего используется короткое 8.3 имя, а длинное имя может быть сохранено, но просто игнорируется. Трюк NA заключался в том, чтобы записать это имя в тот же 50-байтовый буфер, но по адресу 14. В итоге мы можем увидеть что-то ок. 34-35 символов вместо 8.3.

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

3. Я уверен, что увеличить 5960 ARM можно, я просто не знаю, как это сделать.

4. Я ж не самоубийца - пересаживать чужой ARM в свою прошивку без кабеля. Думаю, что NA не просто хакер, а хакер со смыслом (почти программист ), так что вполне вероятно, что свои изменения для определенной фичи он старается вносить в одну сторону прошивки, а не в обе. Так ему легче переносить фичи с одного устройства на другое: взял ARM и перенес со всеми фичами сразу. Кому как не ему известны все аспекты разделения труда между ARM и 8032. Во всяком случае поддержка LFN вся сделана в ARM. В прошивке NA совершенно офигительное количество изменений 8032 (я сравнил со стандартной), но скорее всего они не имеют отношения к LFN.

Интересно, как изменилось мое личное понимание архитектуры MTK за те несколько недель, что я начал с нею знакомиться. Сначала мне казалось, что значительно легче понимать код ARM (THUMB), a 8032 - это тихий ужас. Но разобравшись более менее с исходниками 8032, я теперь на 180 градусов поменял свое мнение. Проблема в том, что в ARM очень трудно искать бинарные строки. Вот ты видишь, например, адрес какой-то переменной в Sh. Mem. - в 8032 все точки обращения к ней находятся элементарно. А в ARM... Совершенно неясно, что и где искать.

Ладно, черт с этими длинными именами файлов. Может быть кто-нибудь знает, как добавить DivX resume в ARM? Я вижу, что при нажатии кнопки Play во время загрузки диска 8032 пишет 2 команды в Sh. Mem.:
vSetSharedInfo (0x6E0, 0);
vSetSharedInfo (0x6FE, 0);
А далее непонятно. То ли он получает ответ от ARM, и затем просто инициирует прыжок на определенную точку проигрывания, то ли ARM прыгает самостоятельно, а 8032 только сообщает об успехе (показывает мессидж RESUME PLAY).

Мне кажется, очень полезная и нужная фича... Есть ли идеи?

This post has been edited by vboroda on 22-05-2007, 19:02

Лично меня устроила бы даже возможность не запоминания, а перехода на фиксированное время, скажем, выбираю я в меню "прыг на 30 минут от начала". Чертовски полезная вещь для портативных плейеров, у которых мало кнопок на корпусе, а таскать везде с собой пульт неудобно.

Но я не нашёл как программно сделать "прыг".

Что касается запоминания места - для стандартных DVD оно реализовано, осталось раскопать как и повторить для DivX.

vboroda

Ну вообще-то он и CD-RW понимает.

Согласен. Есть отдельный указатель на папки и отдельный на файлы. Но если я всё таки прав, что браузер один тогда как бы структуры не различались массив должен быть заполнен одинаково (иначе 8032 нарисует на экране всякий бред) примерно так:

Т.е. упрощёно есть две процедуры, которые преобразовывают, и загоняю в массив имена для 8032 из FAT или CD. Поэтому если верить тому же источнику всё должно выглядеть вот так:

Отсюда и не понятки что это за 50-байтовый буфер, и адрес 14 , уж не пустил ли NA нас по ложному следу. Исходя из этой инфы и я это точно видел у себя на плеере, должна заполняться структура и все имена в кучу. Исходя из того что NA сказал что вначале ARM сам пишет 8.3, а потом его процедура дописывает длинное, получается гон, файлы то идут в кучу промежутков то нет!!!

И да и нет, как то я раз пересадил ARM NA к себе, заработал он наполовину. Приглядевшись по внимательней я увидел, что он перепахал половину вызовов PS_A_ и PS_B_ процедур, т.е. получается он не только перековырял 8032 но и эти же процедуры в ARM –е. Что более и более склоняет меня в сторону того что у него есть исходники все. Как то помниться его кто-то спросил, почему он это сделал так, когда можно было иначе, на что он ответил типа: Это я делал в то время когда я пользовался только hex и IDA, а теперь я пользуюсь компилятором!!! и код у меня уже другой. Может поэтому он не может ни чего рассказать, он вносит копеечные изменения в исходники и всё работает, а как и что менять вручную ему уже не известно.

Ну исходя из того что меня в институте натаскивали на Intel архитектуру старых процов, а 8032 = i8051, то тут бетон пошел сразу. А вот ARM плавит мозги до сих пор. Надо попытаться освоить метод moroz-а он пишет на нормальном языке, а потом компилит во что угодно, но это уже вопрос к cax-у. Да кстати у меня есть файлик с описанием асма ARM на русском, часть моих пробелов он заполнил.

Почему в ARM исходя из исходников поддержка запоминания места реализована в 8032, точнее если я не ошибаюсь управляет запоминаем ARM-a. И опять таки исходя из исходников запоминаться должно всё и DVD и Divx. Сейчас гляну исходники может что то нарою.

Rvs

Насчет того, что дла FAT информация о файлах запихивается в массив структур, в которых по 50 байт отведено под имя файла, я совершенно уверен. Зря, что ли, 2 недели пялился в NA код?

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

Например, патч cax по пвреводу имени файла из уникода в CP12XX относится только к ISO файлам, и ни коим образом не затрагивает FAT.

Насчет NA я, конечно, ничего не знаю и не ведаю, но есть у меня глубокие сомнения насчет того, что ему доступны исходники ARM. Более того, я даже подозреваю, что исходники ARM могут быть доступны только поставщикам SOC МТК. А производители плееров получают исходники 8032, которых более чем достаточно для того, чтобы кастомизировать их продукт. ARM отвечает, как тебе безусловно известно, за аспекты доступа к файловым системам и раскодирования видео и аудио потоков. Весь user interface обеспечивается 8032. Если бы исходники ARM были доступны производителям плееров, китаезы, у которых понятие об интеллектуальной собственности отсутствует просто на генетическом уровне, уже давно выложили бы их в открытый доступ.

Если сравнить ARM прошивки NA с официальной прошивкой, то разница хотя и огромная, но совершенно очевидно, что все его изменения сконцентрированны в нескольких четко ограниченных местах (поверх текстовых мессиджей поддержки FAT - до мессиджей C++ exceptions, и в конце, в месте "расширения"). Я думаю, что он действительно пишет свои патчи на С, а потом компиллирует, но при этом устанавливает их вручную.

Ассемблер ARM/THUMB (16-битный) меня не слишком угнетает, он как-раз довольно понятен. Проблема в другом: как искать что-то в бинарниках? Приходится пользоваться текстовым поиском, а это головная боль. Например, если ты знаешь, что тебе надо найти в 8032 место, где пишется Sh. Mem. position 0x06E0. Элементарно: ищешь код "7F E0 7E 06 12":

и находишь. А в ARM просто хрен знает как и что искать, если во всех командах immediate числа побитно сдвинуты между байтами.

Здесь ты не прав. Как я и написал, 8032 может только дать UOP команду запомнить, но сам он не отвечает за запоминание. Запоминает точку отключения ARM, причем делает это автоматически. Но где, в каком месте - ума не приложу. Я вообще не понимаю, как найти switch, который отвечает за исполнение UOP команд.

cax

Я вижу, ты серьезно переключился на свой новый проект, даже не следишь за группой на Яге.

Эта фича реализована в ARM, а поддержка GOTO в 8032 может быть открыта или закрыта. Открыть ее совсем не сложно. Я это сделал в Philips 5960, о чем ты можешь почитать в моем ЖЖ, если тебе интересно: http://vladboroda.livejournal.com/108825.html

Возможно в твоем случае вообще нужно будет всего лишь подменить код какой-нибудь кнопки на дистанционнике, как описано NA в его доке. Хотя я бы советовал воспользоваться моим методом, т.к. я для GOTO использую кнопку TITLE, которая при проигрывании ISO (всевозможных MPEG4) не задействована совсем. Это чуть сложнее, но результатом я доволен.

Совершенно верно. Но как его найти, а? Потом, не забудь, что ISO диски - это всего лишь коллекции файлов без какого-либо ID. А уж как там подобраться к FAT устройствам, я и вообще в непонятках. Я просто хотел бы реализации простейшего resume - если диск не вынимали, и плеер из сети не выключали, при нажатии кнопки Play во время демонстрации экрана Loading идти на последний проигрывавшийся файл в последнюю проигрывавшуюся точку. Наплевать мне на 5 последних дисков, сохраненных в EPROM.