Итак, я сделал патч для управления патчами непосредственно с телефона (Мастер-Патч) – мегареспекты avkiev’у.
Совместно с этим патчем будет работать «Вызов различных функций при залоченной клавиатуре v9» и «Продвинутый индикатор сети v1.0», без него работать НЕ БУДУТ!
Идея проста: вместо использования буфера настроек в прошивке мы заносим их в отдельный для каждого патча файл. Таким образом, чтобы изменить настройки патчей, нам теперь не нужно подключать телефон к компьютеру, все операции можно выполнить непосредственно с телефона*.

Для патчеров. Адаптация уже существующих патчей к Мастер-Патчу очень проста. В начале каждого патча просто вызываем встроенную в Мастер-Патч процедуру. На выходе в R6 получаем статус патча (0 – не работает, 1 – работает), а в R7 – указатель на буфер настроек. Сам же буфер надо прописать в hex-виде в файл *.ptc ПОСЛЕ 2 байт, обозначающих статус патча. Т.е. файл выглядит так:
01,00,буфер_настроек. Указатель в R7 дается СРАЗУ на буфер, так что add r7, #2 делать не надо.

* Теперь о проблемах.
1. Пока нет адаптированных патчей. Будут. Первым делом, как я уже говорил, - «Вызов различных функций при залоченной клавиатуре v9» и «Продвинутый индикатор сети v1.0».
2. Управление файлами с телефона. Тут мне нужна помощь. Т.к. стандартными средствами телефона 16-ричный файл не отредактировать, прошу кого-нибудь написать мидлет для редактирования 16-ричных файлов.

Патч можно взять для SK65 здесь.

Ну вот вроде и все. Надеюсь на вашу помощь в развитии проекта.

цитата:

---

Каков размер и формат ptc-файла? (размер - в ДинамикПровайдере, например, буфер оч.большой)

---

цитата:

---

1nvisible пишет: На выходе в R6 получаем статус патча (0 – не работает, 1 – работает), а в R7 – указатель на буфер настроек

---

Тогда в R0 положим статус, а в R1 ссылку на буфер? И на входе - в R0 - patchID?
Просто я руководствовался тем, что у тебя буфер идет в регистрах выше R3...

цитата: 1nvisible пишет: 2. Управление файлами с телефона. Тут мне нужна помощь. Т.к. стандартными средствами телефона 16-ричный файл не отредактировать, прошу кого-нибудь написать мидлет для редактирования 16-ричных файлов. Чем 16-ый файл отличается от текстового? Что-то я туплю.

____________________________

2 svasiliy:
Тем, что если мы откроем его как текстовый, то получим что-то вроде этого:
`яя.
Т.е. нужна аналогия WinHex на мобильнике.

P.S. Чтоб совсем понятно было - прикладываю скрин, показывающий, как выглядит ptc файл.

Список прикрепленных файлов

 hex.JPG  (9865 bytes)

цитата: 1nvisible пишет: 2 svasiliy: Тем, что если мы откроем его как текстовый, то получим что-то вроде этого: `яя. Т.е. нужна аналогия WinHex на мобильнике. P.S. Чтоб совсем понятно было - прикладываю скрин, показывающий, как выглядит ptc файл. Т.е. нужен редактор двоичных файлов- аналог WinHEX.

____________________________

2 svasiliy:
Да. Если что - сами файлы будут не очень большими (думаю, не больше 100 байт) - про 10 мегабайт - это я конечно пошутил

Жду пока рак свистнет с хекс редактороем, если не свитнет позвоню другому

Всем привет, может я конечно несовсем в тему, но все равно. Вопрос о мидлете, который редактирует файлы настроек патча, поднимался в теме JAVA мидлет для патча "Ежечасное событие и звуковые напоминания" (правда только для обного патча) Так вот, мне кажеться, что создание простого редактора 16-ричных файлов есть необходимо, но не достаточно. Достаточным будет создание мидлета с интуитивно понятным интерфейсом и с предустановленными туда настройками для патчей. Это конечно усложнит создание мидлета, но даст возможность более удобной настройки патчей. Получится, что просто поставил где надо галочки, а где не надо убрал и все. ЗЫ Я не лентяй, просто люблю, когда красиво!!! ЗЫЫ Давно бы сделал, если умел.

____________________________ C60->M55->M65->S65->M75->M81 (SW51+900mAh Li-Pol+Патчи+Эльфы+MultiSim) У моей M55->CF75-> SE W300i)

Это совсем другая тема, а именно патч.

Всё прочитал, не понял нах надо ? Ну да ладно

____________________________ CX65 - Never the same...

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

А не ты ли, SiNgle, мне минус влепил?!?

цитата: 1nvisible пишет: А не ты ли, SiNgle, мне минус влепил?!? Я тебе ищо ничо не ставил. Но переписывать все патчи под одну гребенку... Но всё равно держи +

____________________________ CX65 - Never the same...

* Мастер-Патч + АвтоЗагрузчик v1.1 ** Master-Patch + AutoLoader v1.1 *
Исправлены некоторые баги.

Версия для SK65.

Вышел первый адаптированный патч - * Вызов различных функций при залоченной клавиатуре v9 ** Running some functions while keyboard locked v9 *.

А SiNgl'у ® и + за CallAfterTimer.

Это все, конечно, хорошо, но:
- не все "мощные" патчи имеют буфер настроек
- некоторые патчи имеют несколько областей настроек, какие из них считать буфером ? Эта концепция не дает полного управления над патчем
- без комментариев я не помню как настраивать даже свои патчи, не говоря уже о чужих. Что делать с 16-ричным файлом , состоящим из нескольких десятков байт, формат которого ты забудешь через пару дней ?
- необходимо переписывать патч для того, чтобы соблюсти концепцию мастер-патча.
- необходим хекс-редактор на жабе.

И это только те проблемы, которые лежат на поверхности. Идея мастер-патча, конечно, интересная, прогрессивная, но я бы посоветовал немного изменить концепцию и двигаться в одном из следующих направлений:
1. Создание PatchAPI. То есть все команды чтения памяти мы заменяем на вызов процедуры GetWord(Patch,Address), где Patch - уникальный идентификатор патча, Address - адрес слова. PatchAPI каким то образом общается с еще ненаписанным мидлетом, который красиво и юзер-френдли предоставляет весь интерфейс по настройке каждого конкретного патча.
2. Расширение меню. Создается меню "Patches", в котором каждый патч имеет свое подменю, в которое в свою очередь вынесены все настройки патча.
3. Мастер-патч каким то образом эмулирует обращение к памяти конкретного патча обращением к своему собственному буферу этого патча, в этом случае не придется переделывать старые патчи, да и использование мастер-патча будет абсолютно прозрачным.

Первый путь - проще, второй - перспективнее. Третий - пожалуй слишком навороченный.

Это так, мысли вслух, может кого то на что-то натолкнет...

>- не все "мощные" патчи имеют буфер настроек
Не имеют - так не имеют, смысл тогда ИХ настраивать (можно только сделать проверку, как с 7 профилем, а в ptc вбить 1 байт - 00 или 01).
>- некоторые патчи имеют несколько областей настроек, какие из них считать буфером ? Эта концепция не дает полного управления над патчем
Все просто. Мы получаем ссылку на область памяти. С нее мы и читаем все настройки. Если несколько областей - размещаем их одну за другой.
>- без комментариев я не помню как настраивать даже свои патчи, не говоря уже о чужих. Что делать с 16-ричным файлом , состоящим из нескольких десятков байт, формат которого ты забудешь через пару дней ?
Согласен - проблема серьезная. К меня пока по этому поводу идей нет. Точнее есть одна - сделать что-то вроде ini файла, но как реализовать - не знаю.
>- необходимо переписывать патч для того, чтобы соблюсти концепцию мастер-патча.
Переписать надо 1 строку (AdrReg N, aBuffer на BL MP_AllocateRAM) + еще после этого добавить (cmp r0, #1; bne ExitPatch). Не так уж и сложно.
>- необходим хекс-редактор на жабе.
Основная и пока не решенная окончательно проблема - формат файлов конфигурации. Надо над ним подумать, т.к. сдается мне, что на жабе че-нить выпустят нескоро.
>1. Создание PatchAPI.
А он уже есть В виде одной функции - MP_AllocateRAM(PatchID). Возвращает в R0 статус, в R1 - указатель на раму с настройками под этот патч.
>2. Расширение меню. Создается меню "Patches", в котором каждый патч имеет свое подменю, в которое в свою очередь вынесены все настройки патча.
А вот об этом я уже задумывался, только тебя спросить забыл. КАК создать новое меню? Вроде такого еще никто не делал (а на x55 было).
>3. Мастер-патч каким то образом эмулирует обращение к памяти конкретного патча обращением к своему собственному буферу этого патча, в этом случае не придется переделывать старые патчи, да и использование мастер-патча будет абсолютно прозрачным.
По-моему это нереально...

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

Я это к тому, что сейчас нет смысла бросаться и переделывать все патчи. Сначала обдумать надо.

Как мне это видится:
Создается мидлет. Все (!) настройки каждого патча описываются в файле abc.ini, лежащем в каталоге этого мидлета (где abc-имя патча). Нужно продумать синтаксис этого файла. Будет выглядеть примерно так:
[code]Name=ABC
Description=Sound Alerts After Missing Events
ID=123
Enable=Y
...
Buffer1=03,00,00,00,00,00,00,00,03,03,01,01,01,01,01,01,01,01,03,03,03,03,03,03
Buffer2=03,00,00,00,00,00,00,00,03,03,01,01,01,01,01,01,01,01,03,03,03,03,03,03
...
Byte1=33,Ringtone for Hourly Beep
Byte2=DF,Ringtone for Missed Alarm
...
Bool1=N,Вибрировать даже если вибра отключенна
Bool2=Y,Don't play Ringtone for Full Battery if charging via cable
...
Word1=A8000000,RAM
...
Str1="0:\\Java\\jam\\Applications\\HourlyEvent\\HourlyEvent.jar",Путь к мидлету[/code]
При запуске мидлета появляется меню, каждый элемент которого соответствует ini-файлу. При проваливании в это подменю показывается форма, на которой можно поменять все эти байты, флаги, буферы и слова. После чего все это сохраняется в бинарный файл (пусть будет abc.ptc).

Далее пишется PatchAPI с примерно такими функциями:
int OpenOptions(id)
bool IfEnabled(id)
byte GetByte(id, number)
bool GetBool(id, number)
word GetWord(id, number)
char *GetString(id, number)
char *GetUnicode(id, number)
int CloseOptions(id),
которое читает содержимое файла abc.ptc и возвращает соответствующие значения.

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

>Я это к тому, что сейчас нет смысла бросаться и переделывать все патчи. Сначала обдумать надо.
Полностью согласен. Формат пока просто ужасный
>Все (!) настройки каждого патча описываются в файле abc.ini
Да, я вчера тоже про ini думал и даже почти придумал, как реализовать. НО! Есть одна маааленькая проблема. Я не хочу, чтобы каждый раз обращения от патча шли в файл, поэтому я его копирую в раму. Так вот, если накопировать много таких (как описывал avkiev) файлов, то просто рамы свободной не хватит, боюсь.
>После чего все это сохраняется в бинарный файл (пусть будет abc.ptc).
Тогда будет очень сложно реализовать API. Надо все операции проделывать с одним файлом.

На данный момент я могу сделать так.
Для каждого патча создается ini файл. В нем пишется название, версия - все это для мидлета.
Далее в нем идут строки такого вида:
[code]
Enabled=01
Buffer1=03,00,00,00,00,00,00,00,03,03,01,01,01,01,01,01,01,01,03,03,03,03,03,03
RingToneForHourlyBeep=05
[/code]
При обновлении настроек (т.е. при вызове мастер-патча) каждый ини файл читается, и в раму заносятся только двоичные данные, причем ПОДРЯД. Т.е. в раме будет:
01 03 00 00 00 00 00 00 00 03 03 01 01 01 01 01 01 01 01 03 03 03 03 03 03 05.
Отсюда - проблемы с реализацией API - в раме описания байт не лежат, поэтому ссылки на какие-то данные надо реализовывать в самом патче.
>Если будет какое то продвижение в написании мидлета, то эту идею можно развивать, но без мидлета, имхо, ничего полезного не получится...
Ну почему? Мне лично и MicroReader сойдет.

цитата:

---

1nvisible пишет: НО! Есть одна маааленькая проблема. Я не хочу, чтобы каждый раз обращения от патча шли в файл, поэтому я его копирую в раму. Так вот, если накопировать много таких (как описывал avkiev) файлов, то просто рамы свободной не хватит, боюсь.

---

цитата:

---

почему бы каждый раз не перечитывать конфиг из файлов? Боишься, что будет нестабильно работать?

---

цитата:

---

1nvisible пишет:
Потому что:
1. будет долго;
2. будет хуже для флешки;
3. будет быстрее садится батарея.

---

цитата:

---

Ну а в МиниЖПС сделано и нормально...

---

Сделал * Мастер-Патч + АвтоЗагрузчик v1.5 ** Master-Patch + AutoLoader v1.5 *
Изменен формат фалов. Теперь это ini файлы.
Пример (файл rsfwkl.ini - для патча "Вызов... v9.1"):
[code]
[Description]
Name="Running Some Functions While Keyboard Locked"
Version="9.1"
[General]
Enabled=01
UnlockOnDoublePress#=00
[KeyBindings]
LeftSoftKey=02,06
RightSoftKey=FF,07
RedButton=FF,02
GreenButton=02,02
VolumeDown=E0,06
VolumeUp=01,00
JoystickDown=95,01
JoystickUp=91,01
JoystickRight=D0,07
JoystickLeft=FF,00
JoystickPress=E1,06
Asterisk=E2,06
[/code]
Все, что стоит в кавычках, патчем игнорируется, так же, как и все описания. Все необходимые данные должны быть БЕЗ кавычек. Патч считает данными то, что находится МЕЖДУ символами ‘=’ и символом ‘0x0D,0x0A’ (return).
Первые 2 байта имеют специальное назначение, поэтому ссылка дается сразу на настройки (в данном случае KeyBindings).
Пока нет мидлета, файлы можно редактировать MicroReader’ом.
ВНИМАНИЕ!
Файлы конфигурации должны быть написаны в ANSI-кодировке.

Версия для SK65.

* Мастер-Патч + АвтоЗагрузчик v1.6 ** Master-Patch + AutoLoader v1.6 *
Исправлен баг с системой проверки коллизий.
Можно установить обновление с v1.5 или весь патч целиком.

Версия для SK65.

Адаптировал патч * Вибра в момент начала разговора ** Vibrate shortly after connection * + переписал его в Thumb'е и отрубил проверку на АвтоИндикацию (теперь настраивать можно в ini-файле).

Портировал Мастер-Патч на CX65. Респект 1nvisible - за помощь и за сам патч. Для практического использования (пока RSFWKL 9.1 для CX не сделан) - адаптировал * Переключатель режима подсветки клавиатуры ** Keypadlight trigger * (c) benj9, (p) AsteriX. Вроде работает.
ВНИМАНИЕ: Файлы настроек rsfwkl.ini и vsac.ini тоже должны присутствовать, несмотря на отсутствие этих патчей под CX (специфика работы Мастер-Патча)
Убирать их из настроек не хотел, т.к. считаю более правильным соблюдать идентичную последовательность патчей (PatchID в Мастер-Патче) на всей линейке x65 (надеюсь, он будет портирован на все модели).

цитата: ~Jhellico пишет: Портировал Мастер-Патч на CX65. Респект 1nvisible - за помощь и за сам патч. Спасибо! Так-с, вот значит все протестил, очень трудное описание патча , но все работает и есть вопрос: У меня автозапуск не срабатывает. Стоит Native Menu и при заходе в Remote Sync туда и заходит. Но если повесить в My Menu или в блоке 5425 на клавишу ELSE_REMOTESYNC то запускается - пишет EXECUTED и потом все ок. При смене на FlexMenu автозапуск опять же не срабатывает но при заходе в Remote Sync уже пишет EXECUTED. Как работает автозагрузчик (в смысле я не понял как мне его заставить работать)? Я тут пока все снес и вернул нормальный keylight trigger 0.9, ждем rsfwkl для cx65, и возникли у меня вопросы (про будущее патча). Пока мидлет не написан редактирование ini микроридером меня тоже вполне устраивает, но в ini нет никаких комментариев и поэтому нестройки особо по-памяти не изменишь, как насчет их? И прочитав тему я опять же непонял как вообще будет влиять теперь размеры и кол-во ini-файлов на работу тела. Если я там накоментирую как надо и каждый ini будет по килобайту это не страшно?

____________________________ cx65_sw50_14.74mb (продал)

цитата:

---

Корюу пишет:
У меня автозапуск не срабатывает. Стоит Native Menu и при заходе в Remote Sync туда и заходит.

---

цитата:

---

ждем rsfwkl для cx65

---

цитата:

---

в ini нет никаких комментариев и поэтому нестройки особо по-памяти не изменишь, как насчет их?

---

цитата:

---

И прочитав тему я опять же непонял как вообще будет влиять теперь размеры и кол-во ini-файлов на работу тела. Если я там накоментирую как надо и каждый ini будет по килобайту это не страшно?

---

цитата:

---

очень трудное описание патча

---

цитата:

---

в ini нет никаких комментариев и поэтому нестройки особо по-памяти не изменишь, как насчет их?

---

цитата:

---

прочитав тему я опять же непонял как вообще будет влиять теперь размеры и кол-во ini-файлов на работу тела. Если я там накоментирую как надо и каждый ini будет по килобайту это не страшно?

---