Topic: Firmware MT13x9: Log de Descobertas (Read 60575 times)

ronison · « **Reply #300 on:** February 07, 2008, 04:41:43 PM »

Quote from: doctorxyz on February 07, 2008, 11:33:10 AM

Legal Ronison,

Que bom que você já está conseguindo se virar com esta área.

Desabafo: Como ARM é bem mais complicado que 8051 hein!

Será que a gente conseguiria neste espaço alocar (no Philips 5965K/55) nomes longos a partir da USB + Word Wrap (algoritmo Danny Moroz) sem perder nenhuma funcionalidade (principalmente o HDMI)?

Bom, vou seguir a minha pesquisa sobre MtkArmResizer em paralelo, pode ser útil em algum momento para nós (ou para alguém da comunidade).

Estou querendo contribuir e documentar o Word Wrap com algoritmo Danny Moroz para a comunidade.

Temos, seguramente, 369 bytes de espaço nesta área. Existe uma área suspeita e o espaço pode aumentar para ~7,7K.

Não sei ainda o do USB, mas o algoritmo do wrodwrap usa 356 bytes.

Quote from: doctorxyz on February 07, 2008, 11:33:10 AM

Caso seu word wrap seja Danny Moroz, esteja pronto e você tenha tempo (e não seja um incômodo) poderia disponibilizar as dicas no tópico específico que abri para isso neste fórum, dentro da seção Philips 5965K/55?

Obrigado

Ainda não está ok. Assim que eu tiver um tempinho coloco aqui o estado atual.

Abraço,

Jefferson · « **Reply #301 on:** February 07, 2008, 06:43:08 PM »

Quote from: jmaraujo on February 07, 2008, 02:37:11 PM

O programa usa as células... O problema é que eu somente posso modificar as células visíveis. Eu chequei o firmware após usar o programa e todas as 20 cores tinham sido corretamente trocadas...

Ahhhhhhhhh...

Isso ocorre porque o NewAge programou a criação dinâmica das células em um loop baseado no número de cores. Ele não esperava por mais de 16 cores, mas o loop continua criando as células às cegas.

Quote from: jmaraujo on February 07, 2008, 02:37:11 PM

Por outro lado, tentei agrandar a janela com os dois programas sugeridos no tópico do MTK Patcher (ResourceHacker e XNResourceEditor), mas nenhúm deles funciona corretamente com o arquivo executável do MTK Windows.

O MTKWindows, assim como os meus programas, está comprimido com UPX. Antes de usar um resource editor qualquer você precisa descomprimir.

No caso, baixe o UPX e use o comando upx.exe -d mtkwindows.exe

Só que você vai encontrar um pequeno problema com o mtkWindows: aumentar o tamanho da janela não adianta. NewAge decide o tamanho da janela por programação, todas as vezes em que selecionamos a aba "Windows" do programa.

Mas existe um modo de contornar isso.

Abra o programa já descomprimido no Resource Hacker

Mude a palavra bsToolWindow, destacada em verde, para bsSizeToolWin Editado: Não adianta procurar no Help do programa. Para saber o que precisa ser mudado e pelo que, você precisa estar familiarizado com a VCL da Borland (Delphi, C++ Builder, etc).

Não adianta mudar ClientHeight e ClientWidth (em vermelho). Adiantaria, se New Age não estivesse definindo as dimensões da janela por programação.

Clique em Compile Script e salve

Execute o mtkWindows. Aparentemente, nada mudou. Mas mova o mouse sobre a borda da janela de palette e você irá poder redimensioná-la temporariamente para o tamanho que quiser.

Jefferson · « **Reply #302 on:** February 07, 2008, 07:12:24 PM »

Quando um executável Windows qualquer não funcionar com um Resource Editor, analise-o com o ExeInfo PE. Esse programa é capaz de identificar vários tipos de compressão e dá dicas de como lidar com elas.

jmaraujo · « **Reply #303 on:** February 07, 2008, 07:16:52 PM »

Obrigado. Agora ficou assim:

Na verdade, não sei nem para que servem estas mudanças (se é que funcionam). Agora, apos ter feito as mudanças, não acho muita utilidade em ter uma janela de 256 cores que vai ocupar 512 bytes que poderíam fazer falta no futuro.

ronison · « **Reply #304 on:** February 07, 2008, 07:23:23 PM »

jmaraujo,

Lembro que você falou sobre o uso de caracteres acentuados no filebrowser a um tempo atrás. Pois bem, estou com este problema. Caracteres especiais estão sendo substituídos por "_". Já vi muita coisa aqui e fiquei com uma dúvida: o UnicodeToCP (ARM) descrito no documento "Patching_HU3899_from_A_to_Z.txt" resolve este problema nos philips? Complementando, não encontrei na rotina Dir_FileNameFilter, no 8052, qualquer definição de limites dos caracteres possíveis.

PS: Infelizmente estou sem ter como testar pois meu player está na assistência.

Abraço,

Jefferson · « **Reply #305 on:** February 07, 2008, 07:25:05 PM »

Só para complementar, existe um modo, um tanto deselegante, de passar por cima da definição do tamanho da janela feita por New Age.

Mude os valores de ClientWidth e ClientHeight
Apague a linha OnShow = FormShow

Você verá que, antes de carregar qualquer firmware as duas novas dimensões são respeitadas, mas a altura é redefinida automaticamente quando é carregado um firmware. É possível que na sua versão experimental com mais células a altura acompanhe o número de células (eu acho difícil), mas isso é algo que você mesmo precisa testar.

jmaraujo · « **Reply #306 on:** February 07, 2008, 07:53:12 PM »

Quote from: ronison on February 07, 2008, 07:23:23 PM

Caracteres especiais estão sendo substituídos por "_". Já vi muita coisa aqui e fiquei com uma dúvida: o UnicodeToCP (ARM) descrito no documento "Patching_HU3899_from_A_to_Z.txt" resolve este problema nos philips?

O CP125x que eu estou usando é bem simplezinho, mas não é a solução ao seu problema. O meu patch o que faz e trocar os carateres 250-255 por 0-5 (Há uma explicação técnica do Mabreaker sobre o porqué os carateres 250-255 não são lidos, o que não vem ao caso).

O seu problema é o filtro dos caracteres, então o mais fácil é mudar esse filtro.

¿O que o tal filtro faz? Ele verifica se o caractere pasado ao Arm é menor do que '20' (espaço), ou maior do que '7E' (~). Se for menor do que 20, ou maior do que 7E, o caracter e sustituido por um '_'.

O que você tem que fazer e mudar o '20' por '00', e o '7E' por 'FF', desse jeito ele vai buscar por carateres menores que 00 ou maiores que FF, o que claro, não existem.

Procedimento: Busque no bloco ArmCode completo a seqüencia "7E 22 20 21". No meu firmware (os valores já foram trocados):

ROM:0000DCF4 FF 22                       MOV     R2, #0xFF
ROM:0000DCF6 00 21                       MOV     R1, #0

Isso é tudo.

Quote from: Jefferson on February 07, 2008, 07:25:05 PM

Só para complementar, existe um modo, um tanto deselegante, de passar por cima da definição do tamanho da janela feita por New Age.

Mude os valores de ClientWidth e ClientHeight
Apague a linha OnShow = FormShow

Você verá que, antes de carregar qualquer firmware as duas novas dimensões são respeitadas, mas a altura é redefinida automaticamente quando é carregado um firmware. É possível que na sua versão experimental com mais células a altura acompanhe o número de células (eu acho difícil), mas isso é algo que você mesmo precisa testar.

Não, as células seguem na mesma posição. Mas não se preocupe, estou desistindo de experimentar as mudanças no player...

ronison · « **Reply #307 on:** February 07, 2008, 08:05:20 PM »

Quote from: jmaraujo on February 07, 2008, 07:53:12 PM

Quote from: ronison on February 07, 2008, 07:23:23 PM
Caracteres especiais estão sendo substituídos por "_". Já vi muita coisa aqui e fiquei com uma dúvida: o UnicodeToCP (ARM) descrito no documento "Patching_HU3899_from_A_to_Z.txt" resolve este problema nos philips?
O CP125x que eu estou usando é bem simplezinho, mas não é a solução ao seu problema. O meu patch o que faz e trocar os carateres 250-255 por 0-5 (Há uma explicação técnica do Mabreaker sobre o porqué os carateres 250-255 não são lidos, o que não vem ao caso).

O seu problema é o filtro dos caracteres, então o mais fácil é mudar esse filtro.

¿O que o tal filtro faz? Ele verifica se o caractere pasado ao Arm é menor do que '20' (espaço), ou maior do que '7E' (~). Se for menor do que 20, ou maior do que 7E, o caracter e sustituido por um '_'.

O que você tem que fazer e mudar o '20' por '00', e o '7E' por 'FF', desse jeito ele vai buscar por carateres menores que 00 ou maiores que FF, o que claro, não existem.

Procedimento: Busque no bloco ArmCode completo a seqüencia "7E 22 20 21". No meu firmware (os valores já foram trocados):
ROM:0000DCF4 FF 22                       MOV     R2, #0xFF
ROM:0000DCF6 00 21                       MOV     R1, #0
Isso é tudo.

Isso tudo eu tinha entendido. Agora ficou meio confuso o que você falou. O filtro deve estar no 8052, certo? Pois bem, como eu falei não existe a definição dos limites (20 e 7E) neste código. Entretanto, você fala em buscar no ARM Code uma sequência? O filtro então estaria no ARM Code?

Abraço,

jmaraujo · « **Reply #308 on:** February 07, 2008, 08:15:00 PM »

Quote from: ronison on February 07, 2008, 08:05:20 PM

O filtro deve estar no 8052, certo? Pois bem, como eu falei não existe a definição dos limites (20 e 7E) neste código. Entretanto, você fala em buscar no ARM Code uma sequência? O filtro então estaria no ARM Code?

Não, você está confundindo. O filtro está no ArmCodes.

Os firmwares Philips não tem o filtro no 8032. Caso tivessem, voçê tería que fazer o patch nos dois lugares: ArmCode e 8032.

Se quiser estar seguro, busque no 8032 por "90 ? ? E0 FF 90 ? ? E0 FE C3 9F 50 05 C3 EF", mas -como eu disse- nos firmwares Philips não tem ese filtro.

Saudações!

PS: Se quiser checar o filtro nos meus ArmCodes, olhe no endereço ROM:DCF4.

ronison · « **Reply #309 on:** February 07, 2008, 08:20:12 PM »

Quote from: jmaraujo on February 07, 2008, 08:15:00 PM

O filtro está no ArmCodes.
Os firmwares Philips não tem o filtro no 8032.

Isso era tudo que eu precisava saber.

Dei uma investigada profunda nas rotinas DIR_DispFileList e Dir_FileNameFilter tentando identificar o filtro porém só encontrei vestígios

. Agora está tudo blz.

Valeu mesmo.

Jefferson · « **Reply #310 on:** February 08, 2008, 02:30:29 PM »

LG DK194g

Como reduzir o bloco OSD1 para ganhar tempo nos testes.

O grande número de bitmaps no firmware do DK194G atrapalha bastante o trabalho de quem faz experiências com o firmware. No meu caso (Semprom 2300+), a mais banal das mudanças com o mtkRemaker faz o software ficar aparentemente travado por cerca de 27s. Trocar 6 fontes, que leva uns 20-30 segundos em firmwares não-LG, leva 3 minutos no LG DK194G.

Um firmware MTK genérico relativamente complexo como o do DVP-858 tem 61 bitmaps. Um bloco de ícones da LG normalmente tem entre 320 e 330. No DK194G, por causa da função "game", são 1009.

Mas nem mtkRemaker nem mtkReplacer permitem a substituição do bloco "ícones" apenas. É preciso substituir o bloco OSD1 (fontes e ícones) inteiro. Apagar os ícones extras apenas não é viável, porque você só pode fazer um por um, e são centenas.

Eu comecei substituindo pelo bloco OSD1 do LG DV256K. Não deu certo e as evidências são de que os ícones de 0 a 321 do DV256K não seguem a mesma ordem usada no DK194G, porque fica uma bagunça:

Então eu tentei com o OSD1 do DK8321N e funcionou sem bagunça no browser. Mas como o 8321N tem menos fontes que o DK194G, a bagunça ficou na exibição das legendas. Isso é bem mais simples de resolver, porque bastou trocar manualmente as fontes do DK8321N pelas do DK194g. Como o excesso de bitmaps já tinha sido removido, trocar as fontes e acrescentar o que faltava levou bem menos tempo do que tentar fazer o mesmo com os ícones.

Como vantagem adicional, o bloco OSD1 é reduzido em tamanho de 834KB para 355KB. Uma redução de quase meio megabyte certamente faz diferença na hora de gravar o firmware.

O bloco criado por mim (ícones do DK8321N e fontes do DK194G) está anexo, para você não ter esse trabalho todo.

Jefferson · « **Reply #311 on:** February 08, 2008, 02:41:14 PM »

LG DK 194G

Como reduzir o firmware para acelerar os testes, pela redução do tempo de upgrade.

Aviso: Isso vai matar a função game completamente. Antes de distribuir o firmware você deve lembrar de restaurar tudo.

O tempo normal de upgrade por cabo do LG DK194G é de cerca de 8 minutos. Com esse procedimento o tempo cai para pouco menos de 4 minutos.

Substitua o bloco OSD1 inteiro usando o processo explicado no post anterior.
Substitua o bloco SKIN inteiro pelo do LG DV256K. O Tamanho cai para 62KB;
Substitua o item Unknown (1) pelo item Unknown (5) do mesmo firmware, que tem apenas 4 bytes;

Ao final dessa operação o tamanho do firmware terá caido de 4003KB para 1844KB e o tempo de gravação de 8 minutos para pouco menos de 4 minutos. Além disso, com a redução do número de figuras o firmware vai abrir bem mais rápido no mtkRemaker.

Jefferson · « **Reply #312 on:** February 08, 2008, 04:12:42 PM »

Firmwares LG

Como localizar o bloco de paletes

Este procedimento também encontra os blocos em firmwares não-LG, mas só é realmente necessário quando o mtkWindows não consegue localizar as paletes, como é o caso dos aparelhos LG.

O "truque" se baseia no fato de que o "preto" em uma palete MTK geralmente é gravado como "0x12 0x10" no firmware, que esta é uma combinação relativamente incomum em assembly 8032 e que o preto ocorre várias vezes nas paletes.

Usando o IDA, procure por todas as ocorrências da string hexa "12 10". O maior bloco dentro de um único banco identificado como "byte" são as paletes.

O mtkWindows não consegue achar as paletes porque o endereço de cada uma delas não está na definição de cada janela, como ocorre em outros firmwares. Os dois bytes reservados para cada endereço são sempre "00 00" nos firmwares LG que olhei.

Por conta disso, mesmo encontrando o bloco é um tanto complicado definir exatamente onde começa e termina cada palete. Em geral as paletes tem 32 bytes (16 células) mas aparentemente há pelo menos uma palete de 8 bytes (4 células) nos firmwares LG, porque o total de bytes no bloco nos três firmwares indicados na figura acima é 8 mais um múltiplo de 32.

Eu já descobri como localizar, por análise, o início da maioria das paletes. Mas o método ainda é muito confuso.

Jefferson · « **Reply #313 on:** February 08, 2008, 05:21:21 PM »

Firmwares LG

Como localizar as rotinas que carregam as paletes

As rotinas apontam para o início de cada palete.

Procure por:

90 ? ? E0 FD 25 E0 24 ? f5 82 e4 34 ? f5 83

O resultado são várias ocorrências parecidas com isto:

B7:C31C             B7_C31C:                      ; CODE XREF: BankSw_455_B7_C2D8+1Aj
B7:C31C 90 FC 94    mov     DPTR, #XRAM_FC94
B7:C31F E0          movx    A, @DPTR
B7:C320 FD          mov     R5, A
B7:C321 25 E0       add     A, ACC                ; Accumulator
B7:C323 24 84       add     A, #0x84 ; 'ä'
B7:C325 F5 82       mov     DPL, A                ; Data Pointer, Low Byte
B7:C327 E4          clr     A
B7:C328 34 2B       addc    A, #0x2B ; '+'
B7:C32A F5 83       mov     DPH, A                ; Data Pointer, High Byte

Esta rotina carrega DPTR com o endereço base da palete, no mesmo banco. No caso acima, a palete começa em 0x2B84.

Nos meus testes, a string de busca só encontrou as rotinas realmente relacionadas com carga de paletes, mas não encontrou todas. Ainda existem paletes no bloco que ou não são usadas ou são carregadas de outra maneira.

E ainda falta descobrir como se faz a associação palete-janela.

jmaraujo · « **Reply #314 on:** February 08, 2008, 05:26:36 PM »

Jefferson, você tem idéia de como e feito o "hold & press" (como NA chama a função que controla as teclas do controle remoto quando apretadas por um par de segundos)?

O DVP5100 não tem tal função... Mas o "stop" funciona como "eject" se apertado por dois segundos... Ainda não achei como e feito essa mudança de "14" para "7E".

Já fiz uma busca de texto por "0x14" ou "0x7E", mas sem resultados conclusivos...

ronison · « **Reply #315 on:** February 08, 2008, 06:15:43 PM »

Quote from: jmaraujo on February 08, 2008, 05:26:36 PM

Jefferson, você tem idéia de como e feito o "hold & press" (como NA chama a função que controla as teclas do controle remoto quando apretadas por um par de segundos)?

O DVP5100 não tem tal função... Mas o "stop" funciona como "eject" se apertado por dois segundos... Ainda não achei como e feito essa mudança de "14" para "7E".

Já fiz uma busca de texto por "0x14" ou "0x7E", mas sem resultados conclusivos...

Sei que parece óbvio, mas você já tentou rastrear o fluxo de execução da tecla Stop?

Abraço,

jmaraujo · « **Reply #316 on:** February 08, 2008, 06:37:09 PM »

Quote from: ronison on February 08, 2008, 06:15:43 PM

Sei que parece óbvio, mas você já tentou rastrear o fluxo de execução da tecla Stop?

Não. Como faço isso? :oops:

Jefferson · « **Reply #317 on:** February 08, 2008, 11:49:58 PM »

Firmwares LG

Como é feita a associação janela-palete

Procure pela seguinte string hexa:

B4 xx 00 40 03 02 ? ? 90 ? ? F8 28 28 73

Onde xx é o número da última janela do firmware, como visto no mtkWindows.

Em alguns casos você vai encontrar mais de uma ocorrência, mas apenas uma delas é a correta. O resultado é parecido com isto (LG DK194G):

B7:14B8             B7_14B8:                      ; CODE XREF: BankSw_64_B7_13FC+37j
B7:14B8 90 FC BC    mov     DPTR, #XRAM_FCBC      ; NUM_Janela?
B7:14BB E0          movx    A, @DPTR
B7:14BC 14          dec     A
B7:14BD B4 12 00    cjne    A, #0x12, B7_14C0
B7:14C0
B7:14C0             B7_14C0:
B7:14C0 40 03       jc      EscolhePalete
B7:14C0
B7:14C2 02 19 E8    ljmp    RET
B7:14C2
B7:14C5             ; ---------------------------------------------------------------------------
B7:14C5
B7:14C5             EscolhePalete:                ; CODE XREF: BankSw_64_B7_13FC:B7_14C0j
B7:14C5 90 14 CC    mov     DPTR, #0x14CC
B7:14C8 F8          mov     R0, A                 ; Aqui o conteúdo de A deve ser de 0 a 17 (0 a 0x11)
B7:14C9 28          add     A, R0
B7:14CA 28          add     A, R0                 ; Ao chegar aqui, o conteúdo do acumulador foi multiplicado por três
B7:14CB 73          jmp     @A+DPTR
B7:14CB
B7:14CC             ; ---------------------------------------------------------------------------
B7:14CC 02 15 7A    ljmp    CarregaPalete02
B7:14CC
B7:14CF             ; ---------------------------------------------------------------------------
B7:14CF 02 15 02    ljmp    CarregaPalete01
B7:14CF
B7:14D2             ; ---------------------------------------------------------------------------
B7:14D2 02 15 E4    ljmp    CarregaPalete03
B7:14D2
B7:14D5             ; ---------------------------------------------------------------------------
B7:14D5 02 17 22    ljmp    CarregaPalete07
B7:14D5
B7:14D8             ; ---------------------------------------------------------------------------
B7:14D8 02 17 45    ljmp    CarregaPalete08
B7:14D8
B7:14DB             ; ---------------------------------------------------------------------------
B7:14DB 02 19 07    ljmp    CarregaPalete19
B7:14DB
B7:14DE             ; ---------------------------------------------------------------------------
B7:14DE 02 18 E4    ljmp    CarregaPalete15
B7:14DE
B7:14E1             ; ---------------------------------------------------------------------------
B7:14E1 02 19 61    ljmp    CarregaPalete04
B7:14E1
B7:14E4             ; ---------------------------------------------------------------------------
B7:14E4 02 18 7E    ljmp    CarregaPalete05_2
B7:14E4
B7:14E7             ; ---------------------------------------------------------------------------
B7:14E7 02 16 1B    ljmp    CarregaPalete05_1
B7:14E7
B7:14EA             ; ---------------------------------------------------------------------------
B7:14EA 02 16 EB    ljmp    CarregaPalete06
B7:14EA
B7:14ED             ; ---------------------------------------------------------------------------
B7:14ED 02 16 85    ljmp    CarregaPalete05_3
B7:14ED
B7:14F0             ; ---------------------------------------------------------------------------
B7:14F0 02 17 AC    ljmp    CarregaPalete09
B7:14F0
B7:14F3             ; ---------------------------------------------------------------------------
B7:14F3 02 17 CF    ljmp    CarregaPalete12
B7:14F3
B7:14F6             ; ---------------------------------------------------------------------------
B7:14F6 02 17 F2    ljmp    CarregaPalete11
B7:14F6
B7:14F9             ; ---------------------------------------------------------------------------
B7:14F9 02 18 15    ljmp    CarregaPalete13
B7:14F9
B7:14FC             ; ---------------------------------------------------------------------------
B7:14FC 02 18 38    ljmp    CarregaPalete10
B7:14FC
B7:14FF             ; ---------------------------------------------------------------------------
B7:14FF 02 18 5B    ljmp    CarregaPalete14
B7:14FF
B7:1502             ; ---------------------------------------------------------------------------
B7:1502

Os nomes CarregaPaleteXX foram atribuídos por mim por análise manual do firmware.

No exemplo acima, se a janela for 8, 9 ou 11 é a palete 5 que é usada, por meio de três rotinas diferentes, que não vou mostrar aqui por enquanto.

A numeração das paletes é minha, atribuída de acordo com a posição da palete no bloco.

ronison · « **Reply #318 on:** February 10, 2008, 03:26:01 AM »

Quote from: jmaraujo on February 08, 2008, 06:37:09 PM

Não. Como faço isso? :oops:

Seria seguir o fluxo de execução desde a decodificação da tecla Stop até a execução da rotina de tratamento. Fiz um ensaio e encontrei um local bem suspeito de ser o que você está procurando. Pelo fluxo que segui, chega um ponto onde ele decide se vai repassar o código 5 (P&H + 1) ou o código 15 (Stop + 1) para o tratamento. A decisão é tomada baseando-se num valor lido 3 vezes num único endereço (acredito que este valor seja o tempo de pressionamento da tecla).

O que fiz:

1. Fui numa tabela de tratamento de códigos do RC (aquela usada no Auto Load).
2. Peguei o código #14 (Stop) e segui o fluxo.

Depois eu posto o código aqui, caso haja interesse.

jmaraujo · « **Reply #319 on:** February 10, 2008, 02:19:00 PM »

Quote from: ronison on February 08, 2008, 06:15:43 PM

Sei que parece óbvio, mas você já tentou rastrear o fluxo de execução da tecla Stop?

Acho que agora entendí o que você quis dizer...

Em Remote_General não ha código de execução para "Stop".

Sim há em Remote_DVDPlayback e Remote_DivXPlayback, posso estar errado mas não quis olhar em essas rotinas porque o "press and hold" é feito sempre, e não somente em modo DVD ou ISO.

Agora vou dar uma olhada nas rotinas Remote_03 a Remote_08. (Remote_01 e Remote_02 nunca conseguí achar no meu firmware...)

Quote from: ronison on February 10, 2008, 03:26:01 AM

Seria seguir o fluxo de execução desde a decodificação da tecla Stop até a execução da rotina de tratamento. Fiz um ensaio e encontrei um local bem suspeito de ser o que você está procurando. Pelo fluxo que segui, chega um ponto onde ele decide se vai repassar o código 5 (P&H + 1) ou o código 15 (Stop + 1) para o tratamento. A decisão é tomada baseando-se num valor lido 3 vezes num único endereço (acredito que este valor seja o tempo de pressionamento da tecla).

O que fiz:

1. Fui numa tabela de tratamento de códigos do RC (aquela usada no Auto Load).
2. Peguei o código #14 (Stop) e segui o fluxo.

Depois eu posto o código aqui, caso haja interesse.

Legal, obrigado ronison.

rafalibrenz · « **Reply #320 on:** February 13, 2008, 08:55:39 AM »

Quote from: jmaraujo on February 07, 2008, 07:53:12 PM

O que você tem que fazer e mudar o '20' por '00', e o '7E' por 'FF', desse jeito ele vai buscar por carateres menores que 00 ou maiores que FF, o que claro, não existem.

Procedimento: Busque no bloco ArmCode completo a seqüencia "7E 22 20 21". [...] Isso é tudo.

Jmaraujo!

Eu tinha lido isso que você tinha falado, mas por algum descuido acabei esquecendo. Só depois que você me perguntou se eu tinha tentado isso é que eu tentei.

Mudou alguma coisa, mas não deu muito certo.

Vou te contar tim tim por tim tim o que eu fiz.

1. Abri o firmware (JE+RL v0.32a) no MtkReMaker, cliquei no "+" do RISC, botão direito em "Arm Codes", "Save". Perguntou se eu queria descompactar e eu disse SIM;
2. Abri o arquivo BIN no editor hexadecimal (Xvi32), procurei por "7E 22 20 21" e encontrei. Procurei novamente para ver se tinha mais uma vez e NÃO TINHA;
3. Alterei 7E para FF e 20 para 00. Ficou "FF 22 00 21". Salvei;
4. Voltei ao MtkRemaker, botão direito em "ArmCodes", "Replace" e peguei o arquivo BIN modificado;
5. Salvei o firmware e instalei no player.

Não sei se eu fiz algo de errado, mas pelo que eu entendi era isso.

Fui testar no player. Coloquei um DVD.

O que era pra ser "Ação" ficou assim:

"Invisível" ficou assim:

"Premonições" ficou assim.

Testei também via USB. Criei uma pasta chamada "ÇÔÁÃóã" (lindo nome, não?) no meu pendrive e ela apareceu assim:

Vale lembrar que o firmware está usando a fonte número 10 para exibir os nomes de arquivos e pastas no browser. Talvez seja esse o problema.

P.S.: Não estou conseguindo entrar no forodvp5100.com.ar! O Firefox está me dizendo que "A conexão atingiu o tempo limite".

rafalibrenz · « **Reply #321 on:** February 13, 2008, 09:14:15 AM »

Mestre Jmaraujo!

Deu certo sim!

Era a fonte o problema. Aquela fonte não tinha acentos. Coloquei uma que eu fiz e deu certo!!!

Lendo um DVD:

Mas lendo um USB não deu muito certo, apesar de estar melhor que antes.
Os nomes das pastas eram para ser: "ÇÔÁÃóã", "Ação" e "Visível" (tudo sem aspas, claro), e ficou assim:

Agora vou tentar colocar contorno nessa fonte (não tem jeito do contorno aparecer, mas se eu não conseguir vou explicar bem o meu problema e pedir ajuda depois) e publicar uma nova versão do firmware.

jmaraujo · « **Reply #322 on:** February 13, 2008, 03:23:41 PM »

Que bom que tenha funcionado, Rafa!

1) Com o problema do filtro "não funcionar" em USB, não posso ajudar pois o meu RISC não tem suporte a USB e por mais que eu tente achar as referencias a função do filtro, não vou achar nada porque "não ha nada para achar", he-he!...

2) Na fotografía estou vendo que o problema está no nome das pastas... Em algums firmwares existe um filtro no 8032 também.

Por exemplo, Ronison confirmou que no DVP5965 esse filtro não existe. Também não existe no DVP5100. Mas em players de outras marcas é comúm ver o filtro, e como a v43 do firmware do 5980 é um pouco diferente, quem sabe ela tenha o tal filtro...

rafalibrenz · « **Reply #323 on:** February 14, 2008, 06:45:20 AM »

Quote from: jmaraujo on February 13, 2008, 03:23:41 PM

Em algums firmwares existe um filtro no 8032 também. [...] e como a v43 do firmware do 5980 é um pouco diferente, quem sabe ela tenha o tal filtro...

Jmaraujo,

Com certeza o problema não é o tal filtro no 8032.

Peguei o firmware em que os acentos apareceram no browser lendo disco e substituí o RISC pelo RISC do firmware do DVP5160.

Este firmware é aquele que faz o player perder a saída HDMI, mas dá a capacidade de ler mais caracteres (em torno de 23) via USB.

E para minha surpresa, os caracteres acentuados apareceram perfeitamente via USB, inclusive a pasta "ÇÔÁÃóã".

Conclusão: O problema dos nomes USB deve estar no ARM mesmo.

Muito obrigado pela ajuda, Jmaraujo!

doctorxyz · « **Reply #324 on:** February 15, 2008, 06:56:13 PM »

Ronison,

Caso sobre um tempo, dê uma olhadinha em

Nomes Longos a Partir da USB (Philips DVP5965K/55) -> http://ryan.com.br/smf/index.php?topic=319.0

Ao que parece, falta pouco!

Saudações,
doctorxyz

Jefferson · « **Reply #325 on:** March 03, 2008, 10:21:01 PM »

Entendendo como os textos são armazenados no bloco Languages.

Ontem eu apanhei pela segunda vez com isso, por isso vou deixar a parte confusa documentada aqui. O básico sobre como localizar os textos está explicado no documento !Primeros_pasos_MT1389_v0_3b.rtf de Cachirulo. (evite tradução porca para o inglês de Mabreaker: Info - MT1389 v0.3b English.rtf, porque traduzir "IDA Pro" como "GOING Pro" é dose...), mas o que vou explicar aqui não está lá. Você só entende isso depois de fuçar com o MTK Lang Creator, o MTK Lang Editor e o próprio MTK Remaker.

Vou usar o MTK Remaker para mostrar como funciona:

Note que "\2dX" tem apenas quatro caracteres, mas na imagem eu digo que são cinco. Repare que existe um espaço antes da barra, que é o quinto caractere.

A lógica 8032 deve entender essa string mais ou menos assim:

Reserve um buffer de 6 caracteres;
Selecione a fonte 09 e pegue o seguinte (um) caractere;
Selecione a fonte 00 e pegue os seguintes (cinco) caracteres.

Jefferson · « **Reply #326 on:** March 03, 2008, 11:49:13 PM »

Como saber que células da palete corrente um determinado ícone usa.

Depois que você sabe como a coisa funciona, percebe que é isso que o MTK Remaker mostra, na aba MEMO:

As letras que você vê compondo a imagem do ícone não são escolhidas ao acaso. Cada uma delas é o númro em hexadecimal da cor na palete, de 0 a F. Assim como você pode ver, o fundo do ícone está na cor 0x0 (que é geralmente tratada como transparente na exibição) e a maior parte do corpo do cadeado está na cor 0xE. Que cor realmente será essa depende da palete em vigor onde o ícone é exibido.

Toda a explicação necessária para entender como o "bitmap" do ícone é armazenado está no documento !Primeros_pasos_MT1389_v0_3b.rtf de Cachirulo. Com base nessas informações eu já consegui fazer rotinas em Delphi que desenham ícones Mediatek e pretendo usar isso em uma futura versão do MTK Patcher.

jmaraujo · « **Reply #327 on:** September 03, 2008, 02:36:29 PM »

Como mover os tags mp3 e jpg preview para parte de baixo da tela:

Bem, a primeira parte (mover os tags mp3) Jefferson já explicou muito claramente como é que se faz.

Para mover o jpeg preview tem de se trocar as coordenadas absolutas (a diferença dos tags, que usam coordenadas relativas) da imagem...

Buscar a seqüencia "7D ? 7F 9A 7E 02 12 ? ? 7D ? 7F 9B 7E 02 12 ? ? 7D ? 7F 9C 7E 02 12 ? ? 7D ? 7F 9D 7E 02 12 ? ? 7D ? 7F 9E 7E 02 12 ? ? ", para achar uma parte onde ArmPutChar (WriteSInfo) é chamado cinco vezes com os valores 0x029A, 0x029B, 0x029C, 0x029D e 0x029E.

Deslize a rotina para cima até o começo e de nome a função: fgFlMnInit.

Voltem novamente até a parte da seqüencia achada. Se quiser podem colocar um nome local nesta parte da rotina. Aquí é definido o tamanho e posição da miniatura jpeg:

ROM:4FF8 fgFlMnInit: (...) ROM:50D4 Jpg_preview ROM:50D4 7D 01 mov R5, #1 ; Mostrar jpg preview (1=Sim 0=não) ROM:50D6 7F 9A mov R7, #0x9A ; 'Ü' ROM:50D8 7E 02 mov R6, #2 ROM:50DA 12 05 F5 lcall WriteSInfo ; Arm_PutChar ROM:50DA ROM:50DD 7D 78 mov R5, #0x78 ; 'x' ; Preview JPG posX / 5 (coord. absoluta) ROM:50DF 7F 9B mov R7, #0x9B ; 'ø' ROM:50E1 7E 02 mov R6, #2 ROM:50E3 12 05 F5 lcall WriteSInfo ; Arm_PutChar ROM:50E3 ROM:50E6 7D 4F mov R5, #0x4F ; 'O' ; Preview JPG posY / 4 (coord. absoluta) ROM:50E8 7F 9C mov R7, #0x9C ; '£' ROM:50EA 7E 02 mov R6, #2 ROM:50EC 12 05 F5 lcall WriteSInfo ; Arm_PutChar ROM:50EC ROM:50EF 7D 23 mov R5, #0x23 ; '#' ; Preview JPG Largura / 5 ROM:50F1 7F 9D mov R7, #0x9D ; 'Ø' ROM:50F3 7E 02 mov R6, #2 ROM:50F5 12 05 F5 lcall WriteSInfo ; Arm_PutChar ROM:50F5 ROM:50F8 7D 14 mov R5, #0x14 ; Preview JPG Altura / 4 ROM:50FA 7F 9E mov R7, #0x9E ; '×' ROM:50FC 7E 02 mov R6, #2 ROM:50FE 12 05 F5 lcall WriteSInfo ; Arm_PutChar

Troque os valores em vermelho para mudar posição e tamanho do jpeg preview.

Notem que os valores a insertar tem que ser divididos entre 4 ou 5. Ou seja, se quiser uma largura de 200px, tem que fazer 200 / 5 = 40, é depois convertir o resultado de hexadecimal em decimal 40 => 28.

Jefferson · « **Reply #328 on:** September 03, 2008, 11:02:18 PM »

Como funciona o esquema de bancos nos novos firmwares

Isso é só um rascunho.

Recapitulando:

A arquitetura 8051 só suporta 64K de memória;
O truque que permite ao MT1389 usar um código 8032 maior que 64K, divide o código em segmentos de 64KB chamados de bancos e requer o uso de Bank Switch Tables (BSTs) idênticas em cada banco para que seja possível que um banco possa chamar rotinas que estão gravadas em outro.

O código 8032 é agora organizado das duas maneiras a seguir:

Eu não tenho certeza ainda, mas aparentemente no novo formato a BST tem um tamanho fixo de 12K e o espaço para o código de cada banco é fixo em 52K.

O esquema antigo produz um desperdício natural com a repetição da BST em cada banco. O novo esquema tem o objetivo de reclamar esse espaço desperdiçado, mas tenha em mente que nem um byte é ganho no espaço do código 8032 para patches. Um banco que só teria 100 bytes livres no esquema antigo continua com 100 bytes livres no esquema novo. Todo o espaço economizado com o novo esquema pode ser aproveitado basicamente com mais fontes e imagens.

E ainda é mais complicado do que parece:

A arquitetura 8051 requer que, pelo menos na memória RAM, o truque de bank switching seja implementado da forma tradicional: BST + banco 0 + BST + banco 1 + BST + banco 2, então apesar do chip MT1389L estar programado para carregar apenas uma BST, ele precisa gravar o código 8032 na memória da mesma forma que o chip tradicional MT1389. Todo o endereçamento das rotinas considera (e precisa ser dessa forma) que as BSTs estão lá, no início de cada banco. Por conta disso você não pode mais simplesmente carregar a parte 8032 do código no IDA ou num editor hexadecimal e fazer patches, porque não sendo no banco zero, vai dar tudo errado.

Para ter um bloco 8032 normal a partir de um bloco 8032 "L" de três bancos basta fazer o seguinte:

copy /b BST+bloco0+BST+bloco1+BST+bloco2 8032_normal.bin

Se você analisar com um comparador binário, é exatamente isso que New Age faz com o novo MtkExtract:

8032__normal.bin -> É o bloco 8032 do jeito que vai para a memória.
8032__flash.bin -> É o bloco 8032 do jeito que está no firmware.

Note que New Age chama de "common code" o que eu chamo de BST.

Então, para analisar no IDA PRO, você precisa usar 8032__normal.bin

Porém um problema permanece. Após a análise no IDA, você precisa fazer as edições tembém em 8032__normal.bin (não é mais possível editar diretamente o firmware, porque os endereços vistos no IDA só vão corresponder para o banco zero). Depois 8032__normal.bin precisa ser "recortado" e "remontado" como um novo 8032__flash.bin, para só então substituir no firmware.

Esse é mais um motivo para que as ferramentas existentes não tenham condição de lidar com os firmwares novos. Muita coisa precisa ser adaptada para lidar com as duas situações.

jmaraujo · « **Reply #329 on:** September 08, 2008, 07:50:59 AM »

Como ter uma selection bar "colorida" nos firmwares Philips

Estas são as instruções que passei para o pauloturij em maio deste ano.

Pessoalmente não gosto da barra de seleção desse jeito (também não gosto do scrollbar), por tanto não incluí -nem penso incluir- as mudanças no meu firmware. Mas acredito que muita gente prefira assim... por tanto aquí estão as mudanças:

ROM:50AA 02 -> 03

ROM:5AFC 7B -> E4
ROM:5AFD 03 -> FB

ROM:5F35 7B -> E4
ROM:5F36 03 -> FB

ROM:6178 7B -> E4
ROM:6179 03 -> FB

ROM:6EF7 7B -> E4
ROM:6EF8 03 -> FB
ROM:6FA1 7B -> E4
ROM:6FA2 03 -> FB

ROM:885C 7B -> E4
ROM:885D 03 -> E4
ROM:885E E4 -> FB

ROM:9E2A 02 -> 03

(Todos os endereços correspondem ao Banco 1 do firmware do DVP5100 v0E.0A)

zeurt · « **Reply #330 on:** October 15, 2008, 08:44:29 PM »

Quote from: jmaraujo on February 06, 2008, 02:41:46 PM

Estamos manejando duas hipóteses:

- A sugerida por ele usa o mesmo método do patch Unicode.

Criase uma fonte extendida com carateres normais nas posições normais, e carateres em itálico nas posições extendidas. Quando o Arm detecta a apertura do tag, soma-se um valor X ao valor de cada caratere, coincidindo com o mesmo caracter em itálico. Quando o Arm detecta o fechamento do tag, usa-se os carateres normais.

Se entendí bem, o sugerido por ele é o mesmo que o sugerido por você.

- O que eu sugerí foi: Criar quatro fontes normais e as quatro correspondentes em itálico. E no menu por somente escolha de quatro fontes (as fontes "normais": 1, 3, 5 e 7).

Exemplo:
Fonte 1: Fonte 1 normal
Fonte 2: Fonte 1 itálico
Fonte 3: Fonte 2 normal
Fonte 4: Fonte 2 itálico
Fonte 5: Fonte 3 normal
Fonte 6: Fonte 3 itálico
Fonte 7: Fonte 4 normal
Fonte 8: Fonte 4 itálico
Quando o Arm detecta a apertura do tag, soma 1 ao valor da fonte em uso. Quando detecta o fechamento do tag, resta (sustraí?) 1 ao valor da fonte...

Por enqüanto é tudo em teoría...

Oi, jmaraujo. Alguma novidade na tentativa de implementação do suporte a <i> tag em legendas .srt?

jmaraujo · « **Reply #331 on:** October 15, 2008, 09:41:33 PM »

Todo mundo que participou nesse tópico sugeriu alguma coisa (sempre em hipótese), mas o Jor-El, que é programador, sumiu e o tópico ficou esquecido...

Na teoría foi um tópico muito interessante, mas na prática não sei se é possivel...

zeurt · « **Reply #332 on:** January 01, 2009, 09:27:45 PM »

Como descobrir a Região do DVD dos Firmwares LGs, analisando os nomes dos arquivos de upgrade por CD

Descobri que a Região do DVD desses Firmwares fica a nossa disposição, nos nomes dos arquivos de upgrade por CD.
Na verdade, as regiões são representadas por letras e não por números (as letras de A a F correspondem as regiões de 1 a 6, enquanto que Region Free (0) é representada por 0 mesmo).
O local dessa letra pode variar um pouco, mas normalmente antecede imediatamente 3 letras como MIE, MIH, MIS, etc.

Vejam exemplos:

Região 4 ou D

DK8321N (extraído pelo Ryan): LV8B3220D.MIH
DK194g (extraído pelo Ryan): LVLV10B02207D.MIE
DV256K: LG_DV_LV070B222030DMIE.ROM
DV397H (Brasileiro, baseado na tela de versão relatada por 2 usuários): LG_DV_LV81F33B40DMSMIS.ROM

Região 2 ou B

LG9843 (Europeu): LV9E12203B.MIH

Região 0

DV397H (Firmware que enviei): LG_DV_LV81F33B400MSMIS.ROM

Destaquei em verde MS, pois foge um pouco dos nomes anteriores. Acho que tem haver com o Chipset MT1389S, já que o Firmware do DV383, que também é recente e tem Firmware MT1389L apresenta ML no lugar.

Jefferson · « **Reply #333 on:** September 26, 2009, 08:36:44 AM »

Philips DVP5980K/55 - O conteúdo da EEPROM

Eu arrumei disposição hoje para dessoldar o chip de um dos meus DVP5980 e ler no meu Willem.

Antes de dessoldar o chip eu dei um comando de RESET no setup do DVP5980 para carregar os valores default.

Depois de obtido o arquivo (anexo) eu dei uma olhada aleatória em alguns endereços e os valores armazenados correspondem ao default, por isso acredito que a leitura tenha sido um sucesso.

Notem o seguinte:

*Nenhum endereço a partir de 0x1F0 é usado.
*Todos os endereços com conteúdo FF são potencialmente endereços livres. E existe um monte deles mesmo na faixa de 0-255.

Próximo passo: descobrir qual byte é responsável pela identificação do sub-modelo.

Jefferson · « **Reply #334 on:** September 27, 2009, 08:58:25 AM »

Philips DVP5980 - Como é definido o sub-modelo

As posições de EEPROM que definem o sub-modelo são 0x04 e 0x05. A correspondência é esta:

00 FF = DVP5982_37
01 FE = DVP5980K_55 (default)
02 FD = DVP5980K_75
03 FC = DVP5986K_98
04 FB = DVP5986K_51
05 FA = DVP5986K_96
06 F9 = DVP5980K_78

Adicionalmente, qualquer outro par de valores faz o aparelho se identificar como DVP5980K_78. Isso faz algum sentido pois já que o DVP5980K_78 é o último da lista a rotina de identificação deve ser do tipo "se nenhuma opção confere, é o útimo".

É bom também tomar cuidado com as posições 0x01, 0x02 e 0x03. Mudar qualquer um dos valores nessas posições faz com que o aparelho execute uma espécie de RESET onde dezenas de bytes são alterados e as posições 0x04 e 0x05 recebem os valores correspondentes ao DVP5980K_78.

Em resumo, para configurar o sub-modelo é preciso alterar corretamente as posições de 0x01 a 0x05 da EEPROM.

Testes com firmware V43

Existem duas rotinas que lêem essas posições de EEPROM: B3:7CC7 e B5:A68E
Existe uma rotina que grava o sub-modelo em B4:A59C

É bom lembrar que o firmware tem uma função oculta que permite escolher o modelo. Isso é sugerido pela string "!PLS INPUT MODEL CODE:" (B3:39CC). Então não dá para saber se a rotina que grava o sub-modelo é chamada por esta rotina ou pela de RESET.

Jefferson · « **Reply #335 on:** September 27, 2009, 09:19:43 AM »

Philips DVP5980 - Experiências com o conteúdo da EEPROM

Eu coloquei um soquete no DVP5980 para permitir ficar mudando valores na EEPROM usando meu gravador Willem.

Se a EEPROM não estiver respondendo o aparelho trava exibindo "PHILIPS" no display.

Se você mudar todos os valores da EEPROM para zero, ao ligar pela primeira vez o conteúdo da EEPROM é refeito. Tudo fica de tal forma que o aparelho se identifica como um DVP5980K_55. A porta HDMI continua funcionando normalmente após isso, com um detalhe: se na primeira vez que o aparelho for ligado houver um disco dentro, a imagem pela HDMI fica bagunçada, mas basta apertar o botão HD UPSCALE para consertar imediatamente. Se não houver disco a imagem já aparece certa. Não entendi a razão.

Aparentemente o endereço 0xB7 guarda algum tipo de status do aparelho. O valor armazenado alterna entre 0x3E e 0x6E aparentemente dependendo de se a bandeja estava aberta ou fechada quando o aparelho perdeu a energia.

Jefferson · « **Reply #336 on:** September 28, 2009, 06:54:03 AM »

Quote from: Jefferson on September 27, 2009, 08:58:25 AM

É bom também tomar cuidado com as posições 0x01, 0x02 e 0x03. Mudar qualquer um dos valores nessas posições faz com que o aparelho execute uma espécie de RESET onde dezenas de bytes são alterados e as posições 0x04 e 0x05 recebem os valores correspondentes ao DVP5980K_78.

A explicação para isso está em um documento de Cachirulo chamado "Eeprom-Info-1Nov2004". Os quatro primeiro bytes da EEPROM são um HEADER que o player verifica para validar seu conteúdo através da função "EPR_CheckHeader()". Segundo Cachirulo esses quatro primeiros bytes tem a string "MT37", mas isso deve ser coisa de versões antigas. Notem que os bytes 0x03 e 0x04 do DVP5980 formam a string "39".

Eu ainda estou tentando descobrir como se lê o conteúdo da EEPROM diretamente na shared memory. Até agora eu não consegui acertar a localização, pois os valores de offset como 0x1999 simplesmente não conferem.
http://ryan.com.br/smf/index.php?topic=179.msg9171930#msg9171930

Jefferson · « **Reply #337 on:** September 28, 2009, 08:20:38 AM »

Mais fontes de informação (não estão na lista do primeiro post):

Site de VB6ROCOD (não deixe de ver o fórum)
http://vb6rocod.euracks.com/

Site de HEJ456 (não deixe de ver o fórum)
http://hej456.com/

News:

Author Topic: Firmware MT13x9: Log de Descobertas (Read 60575 times)