FORUM.RYAN.COM.BR
Video e Audio => DivX Players => Firmware Mediatek MT13x9 - Desenvolvimento => Tópico iniciado por: fl00de em Setembro 24, 2007, 04:38:55 am
-
Olá..
Acabei de extrair o firmware do meu dvd.. um LG DV256K
Na tela do modo de serviço lê-se:
MODEL: LG_DV_LV070B222030D
CHIP ID.: MT 1389 E
SERVO VER.: 0d54
MICOM VER.: V1.38
CHEKSUM: 44eb
PROM OPTION : 42 52 02 47 02 55 F6 00
Agora vou tentar mudar a fonte da legenda e a sua cor, na verdade vou ver como é que se faz isso primeiro =)..
Obrigado pelas informações
-
Legal.. já pude brincar um pouco, trocar legenda e imagens do browser. Quem sabe outra hora mexer um pouco mais.
De novo agradeço as informações
-
Amigo, também tenho um player lg dv 256k, mas sou um total novato, e estou doido para mudar a cor da legenda de branca para amarela, sem mudar a fonte dela e tal...mas não tenho a menor idéia de como fazer isso, e mesmo que
vc você me mandasse o firmware alterado eu não iria saber como fazer o tal upload pelo cd. Será que alguém pode me guiar ??? dei uma procurada nas paginas aqui do forum e do blog do ryan, mas n não encontrei os métodos certos para fazer essas operações.
Desde já agradeço,
Andrei Colli
-
Boa tarde!!!
Eu modifiquei a tela "MPEG 0" do firmware origiunal dque o Ryan disponibilizou para o DV256K w sauvei na pasta específica, conforme tutorial no site LG_DVD\FIRMWARE\UPGRADE\LG\lg_dv_lv070b222030d.mih O "MIH" eu apaguei o "BIN" e escrevi.
Quando gravo o CD e coloco no loader dá a mensagem de "ERRO DE DISCO" e não modifica.
O que estou fazendo de errado?
Desde já obrigado!!!
-
Olá..
Na verdade até agora só fiz o upload do firmware usando o cabo serial..
Nesse site deve haver o tutorial de como fazê-lo por disco (só não sei se o procedimento é o mesmo para todos os modelos da LG)
=)
-
Boa tarde Floode!!!
Obrigado, mas infelismente o procedimento que tem no site não funcionou para este modelo... Tentei mudar pa ".MIH", ".MIE" e nada...
Como vc você fez seu cabo? Foi usando o recomendado pelo Ryan?
Desde já muito obrigado!
-
Olá Maghu
O cabo eu já tinha.. uso pra configurar um monitor Sony.
É o mesmo tipo de cabo.. verifiquei antes as instruções aqui no forum.. foi bem tranqüilo, a única diferença é que ao invés de usar uma fonte externa de alimentação, usei +5V da própria placa do DVD.
=)
-
Boa tarde!!!
Eu modifiquei a tela "MPEG 0" do firmware origiunal dque o Ryan disponibilizou para o DV256K w sauvei na pasta específica, conforme tutorial no site LG_DVD\FIRMWARE\UPGRADE\LG\lg_dv_lv070b222030d.mih O "MIH" eu apaguei o "BIN" e escrevi.
Quando gravo o CD e coloco no loader dá a mensagem de "ERRO DE DISCO" e não modifica.
O que estou fazendo de errado?
Desde já obrigado!!!
Aparentemente, o DV256 é totalmente diferente.
Seguindo minha explicação que está aqui:
http://jefferson-ryan.blogspot.com/2007/07/lg-como-descobrir-o-nome-do-arquivo-de.html
Não é possível achar o caminho.
Analisando o firmware, me parece que o DV256K espera que o arquivo esteja na raiz do CD e tenha o nome:
LG_DV_LV070B222030DMIE.ROM
Eu não posso confirmar porque não tenho um aparelho desses.
-
Aparentemente, o DV256 é totalmente diferente.
Seguindo minha explicação que está aqui:
http://jefferson-ryan.blogspot.com/2007/07/lg-como-descobrir-o-nome-do-arquivo-de.html
Não é possível achar o caminho.
Analisando o firmware, me parece que o DV256K espera que o arquivo esteja na raiz do CD e tenha o nome:
LG_DV_LV070B222030DMIE.ROM
Eu não posso confirmar porque não tenho um aparelho desses.
Oi Ryan,
Você está totalmente certo. Acabei de fazer o upgrade do firmware do LG DV256K para corrigir o Subtitle Timing Bug, usei o nome que você sugeriu acima, gravei na raiz do CD, e funcionou perfeitamente.
Obrigado!
-
Olá, você conseguiu corrigir o problema do bug no tempo de duração da legenda?
Tem como você postar aqui ou mandar por e-mail?
Obrigado desde já.
-
Olá, você conseguiu corrigir o problema do bug no tempo de duração da legenda?
Tem como você postar aqui ou mandar por e-mail?
Obrigado desde já.
Estou enviando o firmware com a correção do Subtitle Timing Bug. Porém, cuidado, e siga as recomendações do Ryan para upgrade de firmwares:http://ryan.com.br/prod_dk8321n_firmware.htm (http://ryan.com.br/prod_dk8321n_firmware.htm)
-
Obrigadão, você mudou mais alguma coisa ou só o timing bug ou fez mais alguma melhora?
Abraço.
-
Obrigadão, você mudou mais alguma coisa ou só o timing bug ou fez mais alguma melhora?
Abraço.
Esse aí de cima só tem a correção do Subtiltle Timing Bug. Estou preparando outro com várias opções de legenda. Modificar o tipo da fonte e o tamanho está fácil. Estou tendo certa dificuldade para mudar a cor da legenda usando o MtkWindows.
-
Ok, obrigadão pelo firmware, ficou bem melhor, a legenda não pisca mais na tela.
Vou ver baixar o MtkWindows para começar a dar uma brincada, quem sabe sai alguma coisa legal.
Abraço.
-
Estou enviando um Firmware alternativo para o LG DV256K, com as seguintes modificações:
1- Correção do Subtitle Timing Bug (bug que faz com que as legendas com duração inferior a 1 segundo apenas “pisquem” na tela, e também faz com que as legendas apareçam com atraso ou adiantamento de fração de segundo em relação ao tempo em que deveriam aparecer).
2-Implementação de 9 tipos de fontes de legenda (.srt):
Para trocar o tipo de fonte, durante a exibição de um arquivo .avi com legenda .srt, pressione SUBTITLE por 3 segundos. Aparecerá no canto superior esquerdo da tela o seguinte:
<FONTEx> ; sendo x um número de 1 a 9
Usar as setas para esquerda ou direita para trocar as fontes.
Obs¹: No firmware original, pressionar SUBTITLE por 3 segundos permite trocar o conjunto de caracteres da fonte (ex: CP-1252,CP-1253,etc.), mantendo-se o tipo e tamanho da fonte. Já no firmware que estou enviando, é possível trocar as fontes (tipo/tamanho), sendo que todas elas apresentam o mesmo conjunto de caracteres, que é o CP-1252, compatível com os idiomas dos países da Europa Ocidental, os quais são os mais usados pelos usuários brasileiros (Português, Inglês, Espanhol, Francês, Italiano, etc.).
Caso alguém necessite usar legendas .srt em idiomas de outras regiões do mundo, aconselho a não utilizar este firmware.
Obs²: Por motivo que ainda não entendi, não consegui modificar a FONTE9 com sucesso. Minhas tentativas resultavam em legendas com palavras com acentuação errada e com caracteres estranhos. Portanto, preferi não modificá-la, deixando-a inalterada em relação ao firmware original. Aconsellho que não se utilize a FONTE9.
As fontes são as seguintes:
FONTE1: Original LG (CP-1252)
FONTE2: Franklin Gothic Medium Cond Bold 22
FONTE3: Franklin Gothic Medium Bold 22
FONTE4: Impact 22
FONTE5: Arial Bold 22
FONTE6: Arial Black 18
FONTE7: Tahoma Bold 20
FONTE8: Century Gothic Bold 22
FONTE9: Original LG (CP-1255) - não tem utilidade
Dispus as fontes acima em ordem crescente de largura, partindo das menores e mais compactas (FONTE1) chegando até as maiores e mais largas (FONTE8).
3-Modificação do tamanho e da posição da janela onde são exibidas as legendas, permitindo o uso de um maior número de caracteres por linha, e de até 4 linhas de legenda (mesmo para as fontes maiores que foram implementadas). A quebra de linha continua “burra”, como no firmware original, ou seja, não aproveita os espaços entre as palavras nem respeita a divisão silábica.
4-Modificação da cor das legendas (o que foi mais trabalhoso, devido as diferenças deste firmware em relação aos demais que já foram estudados/modificados):
Estou enviando uma opção do firmware com a legenda na cor branca, outra opção com a legenda na cor amarelo claro, e opção com a legenda amarelo ouro. Escolha a que preferir (veja fotos).
ATENÇÃO: Para atualizar o firmware, grave o arquivo direto na raiz do CD. Não modifique o nome do arquivo e não grave esse arquivo dentro de nenhuma pasta. Use CD-R ou CD-RW. Nesse CD não pode haver nenhum outro arquivo de firmware. Não grave CD multissessão. Além disso, CUIDADO, siga as recomendações do Ryan para atualização de Firmware:
http://ryan.com.br/prod_dk8321n_firmware.htm
Modificações interessantes que poderiam ser implementadas no futuro (que entretanto não estou preparado para realizar no momento):
1- Possibilidade de se escolher a cor da fonte através do menu.
2- Possibilidade de exibição do tempo restante, ou do tempo total de determinado arquivo (de áudio ou vídeo). No firmware original só é exibido o tempo decorrido.
Obs: Não sei se é possível fazer essa modificação (ainda não pesquisei o suficiente).
3- Possibilidade de modificar a FONTE9 (o que por enquanto não consegui), ou também, possibilidade de excluir a FONTE9 (caso não seja possível modificá-la).
Postarei no tópico Firmware MT13x9: Log de Descobertas, informações mais detalhadas sobre todas as modificações realizadas, sobre as descobertas e curiosidades que encontrei nesse firmware, e sobre as dúvidas e dificuldades em se implementar algumas modificações.
Agradeço ao fl00de, já que fiz essas modificações a partir do firmware original extraído por ele.
Agradeço ao Ryan, por ter criado este espaço, e pelo seu trabalho incessante nos últimos anos, sempre compartilhando as informações e descobertas, permitindo que os usuários possam conhecer com maior profundidade os produtos que possuem ou que pretendem adquirir, e além disso permitindo que possam ser feitas modificações e melhorias nesses aparelhos.
Abaixo estão algumas fotos e as 3 versões do firmware. Escolha a cor que preferir.
P.S. : Mais a frente, neste tópico, estou enviando versão na cor Amarelo Canário (que considero o tom ideal de amarelo para legendas).
-
zeurt,
Excelente trabalho!!
Acabei de testar o firmware com as legendas ouro e funcionou perfeitamente!! Ficaram ótimas as fontes!
Se você conseguir implementar as funcionalidades que esta pensando vai ficar melhor ainda! E muito parecido com o 9923N.
Parabéns!
[]'s
Ismael
-
Ryan ,venho desde ja te dar os parabens,pela sua pesquisa e ajuda a todos que querem optimizar suas "maquinas",e como noob que sou,perguntar como gravo este arquivo com o nero.e´so´gravar um cd de dados e adicionar este arquivo?abraço a todos
-
Parabéns, Zeurt!
Obs¹: No firmware original, pressionar SUBTITLE por 3 segundos permite trocar o conjunto de caracteres da fonte (ex: CP-1252,CP-1253,etc.), mantendo-se o tipo e tamanho da fonte.
Eu não sabia disso. Fui testar no LG DK194g e também funcionou. Após procurar no manual, vi que está claramente explicado na página 20.
Obrigado! Agora vários outros firmwares LG poderão ter seleção de fontes!
-
Ryan ,venho desde ja te dar os parabens,pela sua pesquisa e ajuda a todos que querem optimizar suas "maquinas",e como noob que sou,perguntar como gravo este arquivo com o nero.e´so´gravar um cd de dados e adicionar este arquivo?abraço a todos
As instruções de zeurt mais o link indicado por ele dizem tudo o que você precisa saber.
Sim, é um CD de dados.
-
.pus no cd e facilmente atualizei.zeurt parabens, a legenda dourada fica excelente.abraço
-
Galera , desculpe , mas é meu primeiro post e espero não quebrar nenhuma regra do fórum.
Possuo este aparelho faz um bom tempo e fico feliz pelo avanço que foi feito no firmware.
Ainda não testei , mas pretendo , pois o problema da velocidade das legendas é realmente irritante (principalmente quando vou na casa do meu cumpadre e vejo ele usando um ótimo firmware em seu Philips).
Somente gostaria de postar uma sugestão , não um pedido pois não me acho no direito disto :)
O 256 não possui zoom out.
Muitos irão se perguntar "para que zoom out?" , mas quem possui divx mais antigos (principalmente animes) sabem que as legendas eram embutidas (e com fontes de péssimo gosto por sinal) , o que o bendito do overscan acaba matando. Não sei se isto é passível de ser modificado , mas acho uma boa opção para uma futura (e quem sabe longínqua :) ) atualização.
Queria perguntar tb também se o posicionamento das legendas foi corrigido (percebi que no original elas são ligeiramente deslocadas para a esquerda).
Obrigado a todos e parabéns pelo avanço!
-
O 256 não possui zoom out.
Muitos irão se perguntar "para que zoom out?" , mas quem possui divx mais antigos (principalmente animes) sabem que as legendas eram embutidas (e com fontes de péssimo gosto por sinal) , o que o bendito do overscan acaba matando. Não sei se isto é passível de ser modificado , mas acho uma boa opção para uma futura (e quem sabe longínqua ) atualização.
Não sou capacitado para fazer essa modificação, e acho pouco provável que seja possível fazê-la.
Queria perguntar tb também se o posicionamento das legendas foi corrigido (percebi que no original elas são ligeiramente deslocadas para a esquerda).
Tentei corrigir isso da melhor maneira que pude. No firmware original, a margem esquerda da janela de exibição das legendas é 0, e a margem direita é 700 (o máximo seria 720). Portanto, ela realmente estava deslocada para esquerda. Após vários testes, cheguei a conclusão de que com a margem esquerda sendo 10 e a direita 715, as legendas ficam o mais centralizadas possível, não cortadas nas extremidades, e além disso ainda aumentamos a largura total de 700 para 705.
-
Muito bom, fiz o upgrade do meu player e ficou excelente.
Valeu mesmo!
-
Parabéns Zeurt , ficou show de bola!
Somente senti que aquela questão de estar mais para esquerda continua (bem pode ter sido impressão)
Bom trabalho
Uma pena a questão do zoom out , mas fazer o que né?
Abraço
-
Parabéns Zeurt , ficou show de bola!
Somente senti que aquela questão de estar mais para esquerda continua (bem pode ter sido impressão)
Bom trabalho
Uma pena a questão do zoom out , mas fazer o que né?
Abraço
Vou tentar explicar a questão da centralização através de um exemplo:
Supondo que caibam 20 caracteres em uma linha de legenda:
a- XXXXXXXXXXXXXXXXXXXX
b- XXXX XXXX
c- XXX XXXX
Esse aparelho centraliza da seguinte maneira: dependendo do número de caracteres de determinada linha de legenda, podem sobrar à esquerda e à direita um número igual ou diferente de caracteres. Se sobrar um número igual (como no item b do exemplo) a linha fica bem centralizada. Se sobrar um número diferente (como no item c do exemplo), há duas opções: deixar a linha deslocada para esquerda ou para direita. O aparelho sempre opta por deixar um caracter à esquerda (como mostrado acima). Por isso algumas linhas de legenda aparecem bem centralizadas e outras aparecem deslocadas um caracter para esquerda. A centralização é totalmente diferente da que estamos acostumados nos editores de texto do PC por exemplo.
Editado (07/05/2008): Tudo o que disse acima está errado. Ver a explicação correta em um post que enviei mais a frente.
-
Eu tenho a impressão de que essa diferença de centralização não é visível em outros aparelhos.
Ou eu simplesmente não notei, ou outros aparelhos usam centralização por pixel e não por caractere.
-
Eu tenho a impressão de que essa diferença de centralização não é visível em outros aparelhos.
Ou eu simplesmente não notei, ou outros aparelhos usam centralização por pixel e não por caractere.
Oi Ryan,
Eu dei uma olhada no seu review do LG DK194g (http://www.ryan.com.br/prod_dk194g_br.htm (http://www.ryan.com.br/prod_dk194g_br.htm)), e algumas linhas de legenda estão deslocadas para esquerda (discretamente):
1-
Os manifestantes foram se encontrar
com os esquadrões das forças (esta linha está deslocada para esquerda)
de defesa no centro do motim.
2-
Sabe todo mundo acha que astro
logia é um monte de bobagens. (esta linha está deslocada para esquerda)
E eu tenho que concordar em gê
nero, número e grau com eles!
Em uma das fotos das legendas do LG DV256K que postei acima (a com 3 linhas de legenda), isso fica nítido:
3-
Mas talvez você não (esta linha está deslocada para esquerda)
tenha visto ninguém
com uma deficiência muito engraçada
Com fontes maiores dá para perceber melhor. Nunca uma linha fica deslocada para direita em relação as demais. As únicas duas opções são: bem centralizada, ou um pouco deslocada para esquerda. À partir disso fiz a suposição que expliquei no outro post. É como se o aparelho não pudesse posicionar a linha de legenda em qualquer ponto. Dependendo da largura da linha de legenda, a posição possível é bem centralizada. Em outros casos a posição possível é deslocada para esquerda (parece nunca ultrapassar a largura de um caracter). Na verdade não depende do número de carcteres da linha de legenda, mas sim da largura total da linha (já que cada caracter tem uma largura diferente).
Editado (07/05/2008): Todas as explicações e suposições que fiz acima estão erradas. Ver mais a frente a descrição correta do Bug de Centralização das Legendas.
-
Tem razão.
Mas ainda estou em dúvida. Não sei se isso é generalizado. Pode ser algo específico dos LGs.
Ou eu realmente nunca notei.
O fato é que eu não uso o DK194g para assistir filmes. Meu melhor DivX player ainda é o LG 8321N, mas o firmware Br0max é tão fortemente customizado que se havia esse problema nele, Br0max pode ter corrigido.
Meu segundo aparelho é o Proview DVP858 e eu também não notei isso nele.
-
No meu dá diferença no alinhamento até mesmo quando as linhas são exatamente iguais...
Agora, mudando de assunto, é normal algumas vezes das umas falhas na imagem?
Geralmente ocorre quando há uma mudança de câmera, uma parte da imagem fica escura, ou mais clara, dependendo de como é a cena, e fica tudo quadriculado. O erro não acontece em todos os filmes e nem sempre ocorre no mesmo ponto do filme, isso é, se voltar e passar o trecho devolta não ocorre esse erro.
Isso é normal no aparelho de vocês também?
-
Creio que esse problema dos quadriculados é normal em aparelhos que usam Mediatek. Já notei isso várias vezes tanto no meu Proview 858 quanto no meu 816.
Agora, se é causado pelo chipset Mediatek durante o "decode" do vídeo ou se é causado pelo chip de desentrelaçamento(acho que a tradução é essa ;D), aí eu não sei dizer.
[]'s
Daniel
-
Algumas informações sobre o firmware:
Bloco de paletes começa exatamente em B4:25EC
Aparentemente, são 12 paletes com 16 células (32 bytes) e uma palete de 4 células (8 bytes).
As paletes que consegui identificar começam em:
1: B4:25EC (16 células)
2: B4:260C (16 células)
3: B4:262C (16 células)
4: B4:264C (16 células)
5: B4:266C (16 células)
6: B4:268C (16 células)
7: B4:26AC (16 células)
8: B4:26CC (16 células)
9: B4:26EC
...
10: B4:2754 (16 células)
Entre a palete "9" e a palete "10" há espaço para três paletes de 16 células e uma de 4 células. Não consegui determinar os limites neste trecho porque não encontrei os pontos de chamada no firmware.
O bloco de paletes termina em B4:2773
Imediatamente em seguida começam as estruturas das janelas, de B4:2774 a B4:2850
No LG as definições de janelas não contém endereços das respectivas paletes. Daí o problema para saber exatamente onde estão e qual palete é associada a que janela.
Em seguida, a OSDAddrTable, que vai de B4:2851 a B4:2877
Para saber qual palete é responsável pelas legendas, sobreeescreva uma por uma com FFFF. Quando você sobreescrever a certa, um monte de elementos da tela estarão na cor magenta, incluindo as legendas.
-
Creio que esse problema dos quadriculados é normal em aparelhos que usam Mediatek. Já notei isso várias vezes tanto no meu Proview 858 quanto no meu 816.
Agora, se é causado pelo chipset Mediatek durante o "decode" do vídeo ou se é causado pelo chip de desentrelaçamento(acho que a tradução é essa ;D), aí eu não sei dizer.
[]'s
Daniel
Sei do problema do quadriculado em cenas escuras. Se for isto, é causado não pelo aparelho e seu chipset, mas sim pelo algoritmo do DIVX. Confiram.
-
Para saber qual palete é responsável pelas legendas, sobreeescreva uma por uma com FFFF. Quando você sobreescrever a certa, um monte de elementos da tela estarão na cor magenta, incluindo as legendas.
Muito obrigado Ryan,
Hoje estou de saída, mas no final de semana farei os testes para tentar identificar a palete responsável pelas legendas.
-
Sabendo que a célula #05 é branca (EA10), e a célula #0B é preta (1210), tanto no LG256K como no LG194g, foi fácil encontar a palette responsável pela janela das legendas: é a número 5, que começa em B4266C.
Modifiquei o Firmware Amarelo claro que usa a célula #7 para as legendas, de D22B para DE40, no endereço B4267A. Deu certo.
Estou enviando o Firmware com as legendas na cor Amarelo Canário (que considero também o tom ideal de amarelo para legendas). Além disso aumentei o contorno (outline) das fontes 5, 7 e 8 de 1 para 2 (mantendo a largura dessas fontes). A fonte 6 já tinha contorno 2. Acho que assim elas ficaram melhores.
-
Ryan, algumas observações:
1- O amarelo ouro do LG256K é AA86, diferente do amarelo ouro do LG194g que é BE69 (ambos na célula #8).
2- No tópico do Firmware LG194g, você disse que estava usando as telas com cores verdes do LG256K. Porém o LG256K não tem telas verdes: são também todas azuis. Na verdade só são usadas as cores azul, cinza e amarelo (com diversos tons da cada) nas telas desse aparelho, além do branco e preto. Deve ter havido alguma coisa estranha.
3- Nas últimas vezes que venho fazendo atualização do firmware por CD tem aparecido uma mancha de cor magenta, de formato eliptico, mal definida (embassada), do lado direito da tela. Após concluída a atualização, a mancha vai desaparecendo aos poucos. Alguém já passou por isso?
-
Ryan, algumas observações:
1- O amarelo ouro do LG256K é AA86, diferente do amarelo ouro do LG194g que é BE69 (ambos na célula #8).
Isso não me surpreende. Com uma palete de 65536 cores nós temos sorte do "preto" ser sempre 1210
2- No tópico do Firmware LG194g, você disse que estava usando as telas com cores verdes do LG256K. Porém o LG256K não tem telas verdes: são também todas azuis. Na verdade só são usadas as cores azul, cinza e amarelo (com diversos tons da cada) nas telas desse aparelho, além do branco e preto. Deve ter havido alguma coisa estranha.
Eu acho que estamos falando de coisas diferentes.
Estou me referindo a isto:
LG DV256K (eu vejo isso como predominantemente verde)
(http://ryan.com.br/imagens/dvd_geral/LG_DV256K_MPEG0_320_50.jpg)
(http://ryan.com.br/imagens/dvd_geral/LG_DV256K_MPEG1_320_50.jpg)
(http://ryan.com.br/imagens/dvd_geral/LG_DV256K_MPEG2_320_50.jpg)
(http://ryan.com.br/imagens/dvd_geral/LG_DV256K_MPEG3_320_50.jpg)
LG DK194G (eu vejo isso como predominantemente azul)
(http://ryan.com.br/imagens/lg_dk194g/snapshots/LGDK194g_MPEG0_320_50.jpg)
(http://ryan.com.br/imagens/lg_dk194g/snapshots/LGDK194g_MPEG1_320_50.jpg)
(http://ryan.com.br/imagens/lg_dk194g/snapshots/LGDK194g_MPEG2_320_50.jpg)
-
Olá!
Acabei de testar o firmware com o amarelo canário e esta funcionando perfeitamente!
[]'s
Ismael
-
Isso não me surpreende. Com uma palete de 65536 cores nós temos sorte do "preto" ser sempre 1210
Entendi. É que, a princípio eu achei que as paletes das legendas eram exatamente as mesmas, tanto no 194 como no 256 (não tinha prestado tanta atenção nas telas do 194g do seu review). Realmente, por sorte o preto 1210 e o branco EA10 estavam nas mesmas células (#0B e #05), tanto no 194 como no 256, e por coincidencia um amarelo escuro (não o mesmo) estava na célula #8.
2- No tópico do Firmware LG194g, você disse que estava usando as telas com cores verdes do LG256K. Porém o LG256K não tem telas verdes: são também todas azuis. Na verdade só são usadas as cores azul, cinza e amarelo (com diversos tons da cada) nas telas desse aparelho, além do branco e preto. Deve ter havido alguma coisa estranha.
Eu acho que estamos falando de coisas diferentes.
Estou me referindo a isto:
LG DV256K (eu vejo isso como predominantemente verde)
LG DK194G (eu vejo isso como predominantemente azul)
No 256k eu vejo como azul acinzentado. No 194g eu vejo como azul cobalto. Que confusão... Será que um de nós tem algum tipo de Daltonismo? Essa questão de percepção individual é divertida...
-
No 256k eu vejo como azul acinzentado. No 194g eu vejo como azul cobalto. Que confusão... Será que um de nós tem algum tipo de Daltonismo? Essa questão de percepção individual é divertida...
Pode ser que seja eu. Esta é a segunda vez que eu discordo de alguém com relação a cores. E da outra vez também foi entre azul e verde.
Foi na fábrica. Uma grande estrutura de máquinas foi pintada e houve uma discussão divertida sobre a cor da tinta.
Mas se me recordo bem, eu insisitia que era azul.
-
No 256k eu vejo como azul acinzentado. No 194g eu vejo como azul cobalto. Que confusão... Será que um de nós tem algum tipo de Daltonismo? Essa questão de percepção individual é divertida...
Pode ser que seja eu. Esta é a segunda vez que eu discordo de alguém com relação a cores. E da outra vez também foi entre azul e verde.
Foi na fábrica. Uma grande estrutura de máquinas foi pintada e houve uma discussão divertida sobre a cor da tinta.
Mas se me recordo bem, eu insisitia que era azul.
Olá!!
Um simples teste de Daltonismo: http://www.toledo-bend.com/colorblind/Ishihara.html
E um mais elaborado: http://www.icb.ufmg.br/big/big623/newpage1.htm
[]'s
Ismael
-
Daltônico eu já vi que não sou, porque vi todos os números corretos.
-
Eu acabo de confirmar com um amigo da fábrica: As máquinas forma pintadas de uma cor que eles afirmavam ser azul e eu insistia que era verde.
Deve ser a mesma tonalidade.
Ontem eu instalei o firmware com as telas do DVP256K no aparelho da sala e testei: continuei percebendo como verde, mas todos já estavam dormindo e esperei para confirmar com a família hoje pela manhã.
Ao ligar o aparelho uma hora depois de ter acordado a minha percepção é de que a cor era azul. :blink: Chamei minha irmã para me dizer que cor era aquela, sem explicar nada antes, e ela disse algo como: "é azul... mas... um pouquinho puxado para o... verde"
Deve ser de família :laugh:
-
Eu também passei no teste do Daltonismo. Acertei os números... Eu tenho que concordar com a sua irmã: azul, puxando um pouco para o verde.
-
Olá!
Será que existe alguma forma de fazer esse DVD reconhecer itálico ou pelo menos ignorar as tags?
[]'s
Ismael
-
).
Olá!
Será que existe alguma forma de fazer esse DVD reconhecer itálico ou pelo menos ignorar as tags?
[]'s
Ismael
Pelo que sei, e pela tabela comparativa do Ryan, não há nenhum DivX player de mesa que tenha suporte a tags de legendas .srt (possibilitando exibição de caracteres em itálico, etc.).
Eu também torço muito para que alguém um dia consiga implementar essa melhoria.
Em alguma outra parte do forum cheguei a ler uma discussão sobre a importância dessa função. Alguns não achavam muito importante. Eu, como cinéfilo, e além disso meio detalhista, julgo a exibição em itálico, quando indicada (letras de músicas; quando alguém está pensando algo; quando alguém que não apareçe na tela está falando algo, etc.), muito importante. Como, por enquanto ainda não há esta possibildade, acho que é melhor exibir os caracteres <i> do que nada, pois assim pelo menos sabemos quando a legenda deveria aparecer em itálico (concordo com o Ryan nesse sentido).
-
Eu acabo de confirmar com um amigo da fábrica: As máquinas forma pintadas de uma cor que eles afirmavam ser azul e eu insistia que era verde.
Deve ser a mesma tonalidade.
Ontem eu instalei o firmware com as telas do DVP256K no aparelho da sala e testei: continuei percebendo como verde, mas todos já estavam dormindo e esperei para confirmar com a família hoje pela manhã.
Ao ligar o aparelho uma hora depois de ter acordado a minha percepção é de que a cor era azul. :blink: Chamei minha irmã para me dizer que cor era aquela, sem explicar nada antes, e ela disse algo como: "é azul... mas... um pouquinho puxado para o... verde"
Deve ser de família :laugh:
Jefferson, não se preocupe tanto, esse é um erro comum. Essa cor é azul, mas muitas pessoas, não só você, percebem como verde. O que ocorre é que esta cor ainda faz parte do espectro classificado como azul, mas já está bem próxima do espectro do verde. É a transição onde as duas cores (ou luzes), a faixa em que começam a se fundir. Mas para efeito de classificação, é considerado como um tom de azul. Em um material impresso, ou na tela de um computador ou tv, ela é percebida de forma mais diferente ainda conforme a incidência de luz no momento. Quanto mais escuro o ambiente, mais ela tende ao verde.
Não achei nenhuma roda de cores melhor pra postar aqui, mas essa pode dar uma idéia do conceito:
(http://upload.wikimedia.org/wikipedia/commons/d/d7/Byrcolorwheel.png)
Eu particularmente gosto bastante deste tom, mas evito ao máximo utilizá-lo em meus trabalhos. Além dessa confusão, que pode causar problemas mais sérios do que você imagina, qualquer tom de verde e muitos tons de azul são complicados para ser impresso, é a pior cor para a calibração de sistemas, e muito difícil de obter fidelidade em gráfica.
Pra finalizar, você deve ter tido um jogo de lápis de cor com trocentas cores, daquele que a caixinha abre. Olha lá, se não me engano (não sei onde enfiei o meu - sem gracinhas, por favor... - mas até pouco tempo atrás ainda tinha), acho que essa cor é o Azul Cobalto.
Abçs,
-
Daltônico eu já vi que não sou, porque vi todos os números corretos.
Até aonde eu sei (tenho dois amigos daltônicos - um inclusive é designer gráfico também :blink:), a forma mais comum de daltonismo não diz respeito a trocar cores. O que ocorre é que fica tudo tendendo para o marrom.
-
).Olá!
Será que existe alguma forma de fazer esse DVD reconhecer itálico ou pelo menos ignorar as tags?
[]'s
Ismael
Pelo que sei, e pela tabela comparativa do Ryan, não há nenhum DivX player de mesa que tenha suporte a tags de legendas .srt (possibilitando exibição de caracteres em itálico, etc.).
Eu também torço muito para que alguém um dia consiga implementar essa melhoria.
Em alguma outra parte do forum cheguei a ler uma discussão sobre a importância dessa função. Alguns não achavam muito importante. Eu, como cinéfilo, e além disso meio detalhista, julgo a exibição em itálico, quando indicada (letras de músicas; quando alguém está pensando algo; quando alguém que não apareçe na tela está falando algo, etc.), muito importante. Como, por enquanto ainda não há esta possibildade, acho que é melhor exibir os caracteres <i> do que nada, pois assim pelo menos sabemos quando a legenda deveria aparecer em itálico (concordo com o Ryan nesse sentido).
Eu não tinha pensado por esse lado, da importância do itálico para identificar o que é. Acho que iria sentir falta se não tivesse.
E mudar a cor quando for itálico, será que é possível.
[]'s
Ismael
-
No meu dá diferença no alinhamento até mesmo quando as linhas são exatamente iguais...
A principio achei estranha essa afirmação do Bhuda. Porém, resolvi fazer uns testes e acabei descobrindo que o que ele disse é verdade, e que tudo o que eu havia dito até agora a respeito da centralização das linhas de legendas nesse player está completamente errado. :dashhead1:
Na realidade, o aparelho apresenta um bug na centralização das legendas quando há mais de uma linha de legenda (2, 3 ou 4). Nesses casos, a primeira linha da legenda fica um pouco deslocada para esquerda, enquanto todas as demais ficam centralizadas corretamente. Pude comprovar isso fazendo um teste, criando 1, 2, 3 e 4 linhas de legendas idênticas conforme pode ser visto nas fotos anexas.
Obs1: Esse bug ocorre no LG DV256K e no LG DK194g (encontrei um para testar) com os firmwares originais, e também com os firmwares alternativos criados por mim. Nos firmwares alternativos eu havia mudado o tamanho (altura e largura) e também a posição da janela de exibição das legendas. Portanto, concluo que esses fatores não influem nesse bug. Além disso, o problema se manteve inalterado independente da fonte utilizada (testei com as 9 fontes dos firmwares alternativos).
Obs2: Fiz uma medição e cheguei a conclusão que quando só há uma linha de legenda, esta fica centralizada na posição normal (não deslocada para esquerda). A primeira linha só fica deslocada para esquerda quando há 2, 3, ou 4 linhas.
Finalmente, devo dizer que não tenho a menor idéia se é possivel corrigir esse bug.
-
Primeiramente gostaria de parabenizar ao esforço de todos do fórum em tentar resolver os problemas com seus players.
Hoje confirmando o falecimento do meu dvp 5100, após ler a avaliação feita por vocês aqui do LG 256K resolvi adquirir um exemplar por 179,00 na loja ponto frio.
Achei o player muito bom, a primeira coisa que percebi foi o timing bug, logo já atualizei para a versão do firmware sem o bug (fico muito grato pela correção!). Já assisti 2 filmes e 2 eps de séries nele hoje, e achei realmente um player muito bom, gostei do tamanho das legendas, do contorno (bem legíveis). Enfim fiquei muito satisfeito pela compra e agradeço a todos vocês que alimentam este fórum com informações muito úteis pra quem já tem um player e pra quem pensa em comprar um.
-
Estou tentando implementar Caracteres Acentuados no FileBrowser seguindo as orientações de jmaraujo sobre Conversão Unicode para 125x daqui: http://ryan.com.br/smf/index.php?topic=179.msg9172150#msg9172150 (http://ryan.com.br/smf/index.php?topic=179.msg9172150#msg9172150)
Rotina de conversão Unicode to CP125x
Eneris: Busque os seguintes dois pontos nos ArmCodes:
Lugar 1:
ROM:00025132 loc_25132
ROM:00025132 02 98 LDR R0, [SP,#0x30+var_28]
ROM:00025134 01 99 LDR R1, [SP,#0x30+var_2C]
ROM:00025136 80 19 ADD R0, R0, R6
ROM:00025138 41 18 ADD R1, R0, R1
ROM:0002513A 10 39 SUB R1, #0x10
ROM:0002513C C9 7B LDRB R1, [R1,#0xF]
Lugar 2:
ROM:00025166 loc_25166
ROM:00025166 A8 19 ADD R0, R5, R6
ROM:00025168 01 99 LDR R1, [SP,#0x30+var_2C]
ROM:0002516A 05 06 LSL R5, R0, #0x18
ROM:0002516C 41 18 ADD R1, R0, R1
ROM:0002516E 10 39 SUB R1, #0x10
ROM:00025170 C9 7B LDRB R1, [R1,#0xF]
Modificações:
Lugar a modificar 1:
ROM:00025132 loc_25132
ROM:00025132 02 98 LDR R0, [SP,#0x30+var_28]
ROM:00025134 01 99 LDR R1, [SP,#0x30+var_2C]
ROM:00025136 80 19 ADD R0, R0, R6
ROM:00025138 41 18 ADD R1, R0, R1
ROM:0002513A 50 F0 F9 F8 BL CP_conversion_routine
Lugar a modificar 2:
ROM:00025166 loc_25166
ROM:00025166 A8 19 ADD R0, R5, R6
ROM:00025168 01 99 LDR R1, [SP,#0x30+var_2C]
ROM:0002516A 05 06 LSL R5, R0, #0x18
ROM:0002516C 41 18 ADD R1, R0, R1
ROM:0002516E 50 F0 DF F8 BL CP_conversion_routine
Nova rotina: (exemplo com o firmware jmaraujo 1.x - RISC do Philips DVP5140)
ROM:00075330 CP_conversion_routine
ROM:00075330 10 39 SUB R1, #0x10
ROM:00075332 02 B4 PUSH {R1}
ROM:00075334 89 7B LDRB R1, [R1,#0xE]
ROM:00075336 01 29 CMP R1, #1
ROM:00075338 02 BC POP {R1}
ROM:0007533A C9 7B LDRB R1, [R1,#0xF]
ROM:0007533C 03 D1 BNE loc_75346
ROM:0007533E 01 B4 PUSH {R0}
ROM:00075340 08 48 LDR R0, =unk_75368
ROM:00075342 41 5C LDRB R1, [R0,R1]
ROM:00075344 01 BC POP {R0}
ROM:00075346
ROM:00075346 loc_75346
ROM:00075346 C0 46 NOP
ROM:00075348 F9 29 CMP R1, #0xF9 ; '¨'
ROM:0007534A 00 D9 BLS locret_7534E
ROM:0007534C FA 39 SUB R1, #0xFA ; '·'
ROM:0007534E
ROM:0007534E locret_7534E
ROM:0007534E 70 47 BX LR
A nova rotina pode ser escrita por cima das mensagems de erros de C+, ou como no meu caso, após ampliar o RISC.
Para calcular os saltos BL, use o utilitario BCalc do grupo MT13x9.
Já encontrei o lugar 1 (25CB2), o lugar 2 (25CE6), e também o trecho com mensagens de erro de C+ (de 27100 até 27178), onde pretendo sobrescrever a nova rotina.
Porém, estou com uma dúvida de principiante: a nova rotina (convert unicode to 125x) irá ocupar os endereços de 27100 até 2711F. O que eu devo fazer com os endereços de 27120 até 27178 (onde está o restante das mensagens de erro). Posso simplemente deixar como está, ou devo deletar esse trecho com o editor hexadecimal, ou devo substituir com alguma outra coisa?
-
Faça como preferir. Se tiver dúvidas, zere tudo (com cuidado para zerar somente as mensagems de erro). Caso contrario deixe tudo como está.
-
Obrigado jmaraujo! Já resolvi o problema. Eu estava colocando a rotina num local inadequado (27100). Mudei para o endereço 2711A e deu certinho:
ROM:0002711A
ROM:0002711A ; =============== S U B R O U T I N E =======================================
ROM:0002711A
ROM:0002711A
ROM:0002711A sub_2711A ; CODE XREF: sub_25B8C+12Ep
ROM:0002711A ; sub_25B8C+162p
ROM:0002711A SUBS R1, #0x10
ROM:0002711C PUSH {R1}
ROM:0002711E LDRB R1, [R1,#0xE]
ROM:00027120 CMP R1, #1
ROM:00027122 POP {R1}
ROM:00027124 LDRB R1, [R1,#0xF]
ROM:00027126 BNE loc_27130
ROM:00027126 ; End of function sub_2711A
ROM:00027126
ROM:00027128
ROM:00027128 ; =============== S U B R O U T I N E =======================================
ROM:00027128
ROM:00027128
ROM:00027128 sub_27128 ; DATA XREF: sub_27060+30o
ROM:00027128 PUSH {R0}
ROM:0002712A LDR R0, =loc_746C
ROM:0002712C LDRB R1, [R0,R1]
ROM:0002712E POP {R0}
ROM:00027130
ROM:00027130 loc_27130 ; CODE XREF: sub_2711A+Cj
ROM:00027130 NOP
ROM:00027132 CMP R1, #0xF9 ; '¨'
ROM:00027134
ROM:00027134 loc_27134 ; DATA XREF: sub_27060+38o
ROM:00027134 BLS locret_27138
ROM:00027136 SUBS R1, #0xFA ; '·'
ROM:00027138
ROM:00027138 locret_27138 ; CODE XREF: sub_27128:loc_27134j
ROM:00027138 BX LR
ROM:00027138 ; End of function sub_27128
ROM:00027138
ROM:00027138 ; ---------------------------------------------------------------------------
Agora, estou com um novo e mais complicado problema. :( Fiz o patch da Rotina Convert Unicode to 125x (alterando corretamente os pontos 1 e 2), criei as fontes adequadas (colocando os caracteres 250-255 nos locais 0-5), porém o aparelho continuou não mostrando os caracteres acentuados e especiais (mostra o caracter "_" no lugar). Eu já havia lido o documento Patching...A to Z, que mencionava um outro patch, desta vez no 8032, que deveria ser aplicado em conjunto com o do ARM (em alguns players):
==================================================================
3) Show cyrillics in file browser instead of '_' chars.
This patch works together with corresponding patch in ARM section - so you need to apply
both of them to see the result.
To see all chars in filebrowser patch the following bytes:
12DA4: 20 => 00
12DAA: 7E => FE
15EEC: 20 => 00
15EF2: 7E => FE
7F 06 02 05 9B
----------------------------------------------------------------
Howto:
In 8032 code look for ("XX" is a wildcard char):
90 XX XX E0 FF 90 XX XX E0 FE C3 9F 50 05 C3 EF (I found it at 15E9E).
Then skip until the following section of code and patch #0x20 and #0x7E:
ROM:00015EEB 94 20 subb A, #0x20
ROM:00015EED 40 06 jc ROM_5EF5
ROM:00015EEF E0 movx A, @DPTR
ROM:00015EF0 D3 setb C
ROM:00015EF1 94 7E subb A, #0x7E
ROM:00015EF3 40 10 jc ROM_5F05
This code appears twice:
first time for current directory,
second time for names of files in the file browser
Note: it can be your firmware doesn't check the char boundaries.
In this case you cannot and don't need to apply this patch.
===============================================
Eu encontrei 2 sequencias assim: 90 XX XX E0 FF 90 XX XX E0 FE C3 9F 50 05 (os 2 últimos bytes da sequencia - C3 EF - não coincidiram). Estão nos endereços 7B82 e 7D8A. Transcrevo os trechos:
B0:7B82 ; ---------------------------------------------------------------------------
B0:7B82
B0:7B82 B0_7B82: ; CODE XREF: B0_79F6+166j
B0:7B82 ; B0_79F6+172j
B0:7B82 mov DPTR, #XRAM_FDF1
B0:7B85 movx A, @DPTR
B0:7B86 mov R7, A
B0:7B87 mov DPTR, #XRAM_FDF0
B0:7B8A movx A, @DPTR
B0:7B8B mov R6, A
B0:7B8C clr C
B0:7B8D subb A, R7
B0:7B8E jnc B0_7B95
B0:7B90 mov DPTR, #XRAM_FDF1
B0:7B93 mov A, R6
B0:7B94 movx @DPTR, A
B0:7B95
B0:7B95 B0_7B95: ; CODE XREF: B0_79F6+198j
B0:7B95 mov DPTR, #XRAM_FDF2
B0:7B98 movx A, @DPTR
B0:7B99 mov R7, A
B0:7B9A mov A, R6
B0:7B9B setb C
B0:7B9C subb A, R7
B0:7B9D jc B0_7BA1
B0:7B9F mov A, R6
B0:7BA0 movx @DPTR, A
B0:7BA1
B0:7BA1 B0_7BA1: ; CODE XREF: B0_79F6+12Dj
B0:7BA1 ; B0_79F6+1A7j
B0:7BA1 mov DPTR, #XRAM_FDF0
B0:7BA4 movx A, @DPTR
B0:7BA5 mov DPTR, #XRAM_FDF4
B0:7BA8 movx @DPTR, A
B0:7BA9 ljmp B0_7ADB
B0:7BAC ; ---------------------------------------------------------------------------
B0:7D8A ; ---------------------------------------------------------------------------
B0:7D8A
B0:7D8A B0_7D8A: ; CODE XREF: B0_7BFE+166j
B0:7D8A ; B0_7BFE+172j
B0:7D8A mov DPTR, #XRAM_FDF1
B0:7D8D movx A, @DPTR
B0:7D8E mov R7, A
B0:7D8F mov DPTR, #XRAM_FDF0
B0:7D92 movx A, @DPTR
B0:7D93 mov R6, A
B0:7D94 clr C
B0:7D95 subb A, R7
B0:7D96 jnc B0_7D9D
B0:7D98 mov DPTR, #XRAM_FDF1
B0:7D9B mov A, R6
B0:7D9C movx @DPTR, A
B0:7D9D
B0:7D9D B0_7D9D: ; CODE XREF: B0_7BFE+198j
B0:7D9D mov DPTR, #XRAM_FDF2
B0:7DA0 movx A, @DPTR
B0:7DA1 mov R7, A
B0:7DA2 mov A, R6
B0:7DA3 setb C
B0:7DA4 subb A, R7
B0:7DA5 jc B0_7DA9
B0:7DA7 mov A, R6
B0:7DA8 movx @DPTR, A
B0:7DA9
B0:7DA9 B0_7DA9: ; CODE XREF: B0_7BFE+12Dj
B0:7DA9 ; B0_7BFE+1A7j
B0:7DA9 mov DPTR, #XRAM_FDF0
B0:7DAC movx A, @DPTR
B0:7DAD mov DPTR, #XRAM_FDF4
B0:7DB0 movx @DPTR, A
B0:7DB1 ljmp B0_7CE3
B0:7DB4 ; ---------------------------------------------------------------------------
O problema é: esses trechos tem algumas semelhanças, mas não apresentam os pontos que deveriam ser trocados facilmente como descrito no documento. Meus limitadíssimos conhecimentos de Assembly 8052 estão me impedindo de avançar na tentativa de fazer patches nesses trechos, que sejam equivalentes ao descrito no documento Patching...A to Z. Aguardo a ajuda dos Mestres aqui do Forum. Enquanto isso vou tentando aprender um pouco mais sobre o assunto. Obrigado! :)
-
Pode postar de novo os mesmos trechos, mas com os opcodes (http://ryan.com.br/smf/index.php?topic=179.msg9171925#msg9171925)?
-
Não estou conseguindo configurar o IDA pro para exibir os opcodes junto com as instruções. :dashhead1:
Não sei se assim ajuda muito, mas estou enviando:
Trecho de 7B82 até 7BAB:
90 FD F1 E0 FF 90 FD F0 E0 FE C3 9F 50 05 90 FD F1 EE F0 90 FD F2 E0 FF EE D3 9F 40 02 EE F0 90 FD F0 E0 90 FD F4 F0 02 7A DB
Trecho de 7D8A até 7DB3:
90 FD F1 E0 FF 90 FD F0 E0 FE C3 9F 50 05 90 FD F1 EE F0 90 FD F2 E0 FF EE D3 9F 40 02 EE F0 90 FD F0 E0 90 FD F4 F0 02 7C E3
Editado: jmaraujo, só agora eu vi que voce enviou o link explicando como exibir os opcodes :dashhead1:
Amanhã (quer dizer hoje, mais tarde) enviarei finalmente os trechos com os opcodes...
-
Pode postar de novo os mesmos trechos, mas com os opcodes (http://ryan.com.br/smf/index.php?topic=179.msg9171925#msg9171925)?
Aqui estão os 2 trechos com os opcodes:
B0:7B82 B0_7B82: ; CODE XREF: B0_79F6+166j
B0:7B82 ; B0_79F6+172j
B0:7B82 90 FD F1 mov DPTR, #XRAM_FDF1
B0:7B85 E0 movx A, @DPTR
B0:7B86 FF mov R7, A
B0:7B87 90 FD F0 mov DPTR, #XRAM_FDF0
B0:7B8A E0 movx A, @DPTR
B0:7B8B FE mov R6, A
B0:7B8C C3 clr C
B0:7B8D 9F subb A, R7
B0:7B8E 50 05 jnc B0_7B95
B0:7B90 90 FD F1 mov DPTR, #XRAM_FDF1
B0:7B93 EE mov A, R6
B0:7B94 F0 movx @DPTR, A
B0:7B95
B0:7B95 B0_7B95: ; CODE XREF: B0_79F6+198j
B0:7B95 90 FD F2 mov DPTR, #XRAM_FDF2
B0:7B98 E0 movx A, @DPTR
B0:7B99 FF mov R7, A
B0:7B9A EE mov A, R6
B0:7B9B D3 setb C
B0:7B9C 9F subb A, R7
B0:7B9D 40 02 jc B0_7BA1
B0:7B9F EE mov A, R6
B0:7BA0 F0 movx @DPTR, A
B0:7BA1
B0:7BA1 B0_7BA1: ; CODE XREF: B0_79F6+12Dj
B0:7BA1 ; B0_79F6+1A7j
B0:7BA1 90 FD F0 mov DPTR, #XRAM_FDF0
B0:7BA4 E0 movx A, @DPTR
B0:7BA5 90 FD F4 mov DPTR, #XRAM_FDF4
B0:7BA8 F0 movx @DPTR, A
B0:7BA9 02 7A DB ljmp B0_7ADB
B0:7D8A ; ---------------------------------------------------------------------------
B0:7D8A
B0:7D8A B0_7D8A: ; CODE XREF: B0_7BFE+166j
B0:7D8A ; B0_7BFE+172j
B0:7D8A 90 FD F1 mov DPTR, #XRAM_FDF1
B0:7D8D E0 movx A, @DPTR
B0:7D8E FF mov R7, A
B0:7D8F 90 FD F0 mov DPTR, #XRAM_FDF0
B0:7D92 E0 movx A, @DPTR
B0:7D93 FE mov R6, A
B0:7D94 C3 clr C
B0:7D95 9F subb A, R7
B0:7D96 50 05 jnc B0_7D9D
B0:7D98 90 FD F1 mov DPTR, #XRAM_FDF1
B0:7D9B EE mov A, R6
B0:7D9C F0 movx @DPTR, A
B0:7D9D
B0:7D9D B0_7D9D: ; CODE XREF: B0_7BFE+198j
B0:7D9D 90 FD F2 mov DPTR, #XRAM_FDF2
B0:7DA0 E0 movx A, @DPTR
B0:7DA1 FF mov R7, A
B0:7DA2 EE mov A, R6
B0:7DA3 D3 setb C
B0:7DA4 9F subb A, R7
B0:7DA5 40 02 jc B0_7DA9
B0:7DA7 EE mov A, R6
B0:7DA8 F0 movx @DPTR, A
B0:7DA9
B0:7DA9 B0_7DA9: ; CODE XREF: B0_7BFE+12Dj
B0:7DA9 ; B0_7BFE+1A7j
B0:7DA9 90 FD F0 mov DPTR, #XRAM_FDF0
B0:7DAC E0 movx A, @DPTR
B0:7DAD 90 FD F4 mov DPTR, #XRAM_FDF4
B0:7DB0 F0 movx @DPTR, A
B0:7DB1 02 7C E3 ljmp B0_7CE3
-
Exquisito... No meu firmware essa rotina corresponde ao servo (fgAinAdj)...
Você trocou o filtro no ARM?
ROM:0000DCF4 Is_R0_Between_0x20_and_0x7E
ROM:0000DCF4 7E 22 MOV R2, #0x7E
ROM:0000DCF6 20 21 MOV R1, #20
ROM:0000DCF8 F4 E7 B Is_R0_Between_R1_and_R2
R0 é filtrado se for menor que 20 ou maior que 7E.
(http://img225.imageshack.us/img225/4733/filtrodk5.png)
(todos os caracteres com fundo branco são filtrados)
Para "remover" o filtro procure por "7E 22 20 21", e troque 7E->FF e 20->00.
ROM:0000DCF4 Is_R0_Between_0x20_and_0x7E
ROM:0000DCF4 FF 22 MOV R2, #0xFF
ROM:0000DCF6 00 21 MOV R1, #0
ROM:0000DCF8 F4 E7 B Is_R0_Between_R1_and_R2
-
Eu não sabia desse filtro...
Encontrei essa sequencia 7 vezes no ARM code. Em 6 delas existe alguma instrução entre MOV R1,#0x20 e BL...
Apenas uma é bem semelhante a que você descreveu:
ROM:000117BA 07 1C ADDS R7, R0, #0
ROM:000117BC 7E 22 MOVS R2, #0x7E ; '~'
ROM:000117BE 20 21 MOVS R1, #0x20 ; ' '
ROM:000117C0 FE F7 81 FB BL sub_FEC6
Será que é essa mesmo? Pode haver mais de uma?
-
Substitui 7E e 20 por FF 00 na sequencia acima e não funcionou. Continua exibindo apenas "_" nos lugar dos carcteres acentuados. Estou pensando em fazer a substituição nas outras 6 sequências...
-
Substitui 7E e 20 por FF 00 na sequencia acima e não funcionou. Continua exibindo apenas "_" nos lugar dos carcteres acentuados. Estou pensando em fazer a substituição nas outras 6 sequências...
Troquei os 2 bytes nas 7 sequencias que encontrei e não funcionou... :(
Parece que está ficando sem saída... Vou dar um tempo, tentar rever todas as modificações que fiz até agora para ver se não cometi nenhuma falha. Qualquer novidade eu posto aqui...
-
Depois de muito penar nessas últimas semanas, tentando achar uma solução, acabei conseguindo implementar Caracteres Especiais (e Acentuados) no File Browser e nas ID3 Tags. :yahoo!: Descobri que realmente existe um filtro no 8032 que tinha que ser alterado. Estava dificil achar, pois os limites não eram 20 e 7E (como em outros firmwares), mas sim 20 e 5F. Vou fazer mais uns testes para ver se está tudo certo e depois detalharei tudo no Log de Descobertas, já que isso poderá ser útil para os novo LGs também. Observação: os trechos que tiveram que ser alterados são praticamente idênticos aos dos LGs 8XXX e 9XXX.
B3:99F0 ; ---------------------------------------------------------------------------
B3:99F0
B3:99F0 B3_99F0: ; CODE XREF: B3_9982+69j
B3:99F0 90 FB DA mov DPTR, #XRAM_FBDA
B3:99F3 E0 movx A, @DPTR
B3:99F4 FF mov R7, A
B3:99F5 A3 inc DPTR
B3:99F6 E0 movx A, @DPTR
B3:99F7 FC mov R4, A
B3:99F8 A3 inc DPTR
B3:99F9 E0 movx A, @DPTR
B3:99FA FD mov R5, A
B3:99FB 12 05 C5 lcall B3_BS_122_B0_ECF2
B3:99FE 90 FB D5 mov DPTR, #XRAM_FBD5
B3:9A01 EF mov A, R7
B3:9A02 F0 movx @DPTR, A
B3:9A03 90 FB D8 mov DPTR, #XRAM_FBD8
B3:9A06 E0 movx A, @DPTR
B3:9A07 60 15 jz B3_9A1E
B3:9A09 90 FB D6 mov DPTR, #XRAM_FBD6
B3:9A0C E0 movx A, @DPTR
B3:9A0D 90 30 24 mov DPTR, #B3_3024
B3:9A10 93 movc A, @A+DPTR
B3:9A11 FF mov R7, A
B3:9A12 90 FB D5 mov DPTR, #XRAM_FBD5
B3:9A15 E0 movx A, @DPTR
B3:9A16 6F xrl A, R7
B3:9A17 60 05 jz B3_9A1E
B3:9A19 E4 clr A
B3:9A1A 90 FB D8 mov DPTR, #XRAM_FBD8
B3:9A1D F0 movx @DPTR, A
B3:9A1E
B3:9A1E B3_9A1E: ; CODE XREF: B3_9982+85j
B3:9A1E ; B3_9982+95j
B3:9A1E 90 FB D5 mov DPTR, #XRAM_FBD5
B3:9A21 E0 movx A, @DPTR
B3:9A22 FF mov R7, A
B3:9A23 64 20 xrl A, #0x20
B3:9A25 60 36 jz B3_9A5D
B3:9A27 EF mov A, R7
B3:9A28 64 5F xrl A,#0x5F
B3:9A2A 60 31 jz B3_9A5D
B3:9A2C EF mov A, R7
B3:9A2D D3 setb C
B3:9A2E 94 2B subb A, #0x2B ; '+'
B3:9A30 40 05 jc B3_9A37
B3:9A32 EF mov A, R7
B3:9A33 94 3A subb A, #0x3A ; ':'
B3:9A35 40 26 jc B3_9A5D
B3:9A37
B3:9A37 B3_9A37: ; CODE XREF: B3_9982+AEj
B3:9A37 EF mov A, R7
B3:9A38 D3 setb C
B3:9A39 94 40 subb A, #0x40 ; '@'
B3:9A3B 40 05 jc B3_9A42
B3:9A3D EF mov A, R7
B3:9A3E 94 5B subb A, #0x5B ; '['
B3:9A40 40 1B jc B3_9A5D
B3:9A42
B3:9A42 B3_9A42: ; CODE XREF: B3_9982+B9j
B3:9A42 EF mov A, R7
B3:9A43 D3 setb C
B3:9A44 94 60 subb A, #0x60 ; '`'
B3:9A46 40 05 jc B3_9A4D
B3:9A48 EF mov A, R7
B3:9A49 94 7B subb A, #0x7B ; '{'
B3:9A4B 40 10 jc B3_9A5D
B3:9A4D
B3:9A4D B3_9A4D: ; CODE XREF: B3_9982+C4j
B3:9A4D 90 FB DA mov DPTR, #XRAM_FBDA
B3:9A50 E0 movx A, @DPTR
B3:9A51 FF mov R7, A
B3:9A52 A3 inc DPTR
B3:9A53 E0 movx A, @DPTR
B3:9A54 FC mov R4, A
B3:9A55 A3 inc DPTR
B3:9A56 E0 movx A, @DPTR
B3:9A57 FD mov R5, A
B3:9A58 7B 5F mov R3, #0x5F ; '_'
B3:9A5A 12 0B EF lcall B3_BS_385_B0_F304
B3:9A5D
B3:9A5D B3_9A5D: ; CODE XREF: B3_9982+A3j
B3:9A5D ; B3_9982+A8j ...
B3:9A5D 90 FB D6 mov DPTR, #XRAM_FBD6
B3:9A60 E0 movx A, @DPTR
B3:9A61 04 inc A
B3:9A62 F0 movx @DPTR, A
B3:9A63 90 FB D9 mov DPTR, #XRAM_FBD9
B3:9A66 E0 movx A, @DPTR
B3:9A67 FC mov R4, A
B3:9A68 A3 inc DPTR
B3:9A69 E0 movx A, @DPTR
B3:9A6A FD mov R5, A
B3:9A6B A3 inc DPTR
B3:9A6C E0 movx A, @DPTR
B3:9A6D FE mov R6, A
B3:9A6E A3 inc DPTR
B3:9A6F E0 movx A, @DPTR
B3:9A70 24 01 add A, #1
B3:9A72 FF mov R7, A
B3:9A73 E4 clr A
B3:9A74 3E addc A, R6
B3:9A75 FE mov R6, A
B3:9A76 E4 clr A
B3:9A77 3D addc A, R5
B3:9A78 FD mov R5, A
B3:9A79 E4 clr A
B3:9A7A 3C addc A, R4
B3:9A7B FC mov R4, A
B3:9A7C 90 FB D9 mov DPTR, #XRAM_FBD9
B3:9A7F 12 21 06 lcall B3_?C?LSTXDATA
B3:9A82 02 99 E0 ljmp B3_99E0
B3:9A85 ; ------------------------------------------------------------------------
B3:DB18 ; ---------------------------------------------------------------------------
B3:DB18
B3:DB18 B3_DB18: ; CODE XREF: B3_DAF0+23j
B3:DB18 90 FB C7 mov DPTR, #XRAM_FBC7
B3:DB1B F0 movx @DPTR, A
B3:DB1C
B3:DB1C B3_DB1C: ; CODE XREF: B3_DAF0+A5j
B3:DB1C 90 FB C6 mov DPTR, #XRAM_FBC6
B3:DB1F E0 movx A, @DPTR
B3:DB20 FF mov R7, A
B3:DB21 A3 inc DPTR
B3:DB22 E0 movx A, @DPTR
B3:DB23 C3 clr C
B3:DB24 9F subb A, R7
B3:DB25 50 70 jnc B3_DB97
B3:DB27 90 FB C9 mov DPTR, #XRAM_FBC9
B3:DB2A E0 movx A, @DPTR
B3:DB2B FF mov R7, A
B3:DB2C A3 inc DPTR
B3:DB2D E0 movx A, @DPTR
B3:DB2E FC mov R4, A
B3:DB2F A3 inc DPTR
B3:DB30 E0 movx A, @DPTR
B3:DB31 FD mov R5, A
B3:DB32 12 05 C5 lcall B3_BS_122_B0_ECF2
B3:DB35 EF mov A, R7
B3:DB36 64 20 xrl A, #0x20
B3:DB38 60 38 jz B3_DB72
B3:DB3A EF mov A, R7
B3:DB3B 64 5F xrl A, #0x5F
B3:DB3D 60 33 jz B3_DB72
B3:DB3F EF mov A, R7
B3:DB40 60 30 jz B3_DB72
B3:DB42 D3 setb C
B3:DB43 94 2B subb A, #0x2B ; '+'
B3:DB45 40 05 jc B3_DB4C
B3:DB47 EF mov A, R7
B3:DB48 94 3A subb A, #0x3A ; ':'
B3:DB4A 40 26 jc B3_DB72
B3:DB4C
B3:DB4C B3_DB4C: ; CODE XREF: B3_DAF0+55j
B3:DB4C EF mov A, R7
B3:DB4D D3 setb C
B3:DB4E 94 40 subb A, #0x40 ; '@'
B3:DB50 40 05 jc B3_DB57
B3:DB52 EF mov A, R7
B3:DB53 94 5B subb A, #0x5B ; '['
B3:DB55 40 1B jc B3_DB72
B3:DB57
B3:DB57 B3_DB57: ; CODE XREF: B3_DAF0+60j
B3:DB57 EF mov A, R7
B3:DB58 D3 setb C
B3:DB59 94 60 subb A, #0x60 ; '`'
B3:DB5B 40 05 jc B3_DB62
B3:DB5D EF mov A, R7
B3:DB5E 94 7B subb A, #0x7B ; '{'
B3:DB60 40 10 jc B3_DB72
B3:DB62
B3:DB62 B3_DB62: ; CODE XREF: B3_DAF0+6Bj
B3:DB62 90 FB C9 mov DPTR, #XRAM_FBC9
B3:DB65 E0 movx A, @DPTR
B3:DB66 FF mov R7, A
B3:DB67 A3 inc DPTR
B3:DB68 E0 movx A, @DPTR
B3:DB69 FC mov R4, A
B3:DB6A A3 inc DPTR
B3:DB6B E0 movx A, @DPTR
B3:DB6C FD mov R5, A
B3:DB6D 7B 5F mov R3, #0x5F ; '_'
B3:DB6F 12 0B EF lcall B3_BS_385_B0_F304
B3:DB72
B3:DB72 B3_DB72: ; CODE XREF: B3_DAF0+48j
B3:DB72 ; B3_DAF0+4Dj ...
B3:DB72 90 FB C7 mov DPTR, #XRAM_FBC7
B3:DB75 E0 movx A, @DPTR
B3:DB76 04 inc A
B3:DB77 F0 movx @DPTR, A
B3:DB78 A3 inc DPTR
B3:DB79 E0 movx A, @DPTR
B3:DB7A FC mov R4, A
B3:DB7B A3 inc DPTR
B3:DB7C E0 movx A, @DPTR
B3:DB7D FD mov R5, A
B3:DB7E A3 inc DPTR
B3:DB7F E0 movx A, @DPTR
B3:DB80 FE mov R6, A
B3:DB81 A3 inc DPTR
B3:DB82 E0 movx A, @DPTR
B3:DB83 24 01 add A, #1
B3:DB85 FF mov R7, A
B3:DB86 E4 clr A
B3:DB87 3E addc A, R6
B3:DB88 FE mov R6, A
B3:DB89 E4 clr A
B3:DB8A 3D addc A, R5
B3:DB8B FD mov R5, A
B3:DB8C E4 clr A
B3:DB8D 3C addc A, R4
B3:DB8E FC mov R4, A
B3:DB8F 90 FB C8 mov DPTR, #XRAM_FBC8
B3:DB92 12 21 06 lcall B3_?C?LSTXDATA
B3:DB95 80 85 sjmp B3_DB1C
B3:DB97 ; ---------------------------------------------------------------------------
Ryan, você que tem o LG8XXX com firmware brOMax, poderia me confirmar se, além de exibir os caracteres especiais no File Browser (Pastas e Arquivos) e também nas ID3 Tags (ao se pressionar DISPLAY), ele também exibe os dados referentes ao arquivo em execução corretamente, ou assim:
Ex: Oswaldo Montenegro/Millenium/20- Drops de Hortel_.mp3
Caso exiba corretamente terei que pesquisar como fazer isso (deve ter outro filtro...)
Após concluir todos os testes enviarei nova versão do firmware para quem tiver interesse.
-
Muito bom, parabéms! :yahoo!:
Sinto muito não ter podido ajudar mais. Fui checar agora e o meu firmware não tem esse código...
-
Sinto muito não ter podido ajudar mais. Fui checar agora e o meu firmware não tem esse código...
Não tem problema jmaraujo, muito obrigado pela ajuda!
-
Como alterar a região do DVD através do Firmware
Para alterar a Região do DVD do LG DV256K, deve-se alterar apenas 1 byte. A opção default é armazenada no endereço EEPROM correspondente de maneira diferente, em relação a outros players (Philips, Proview, etc.). A opção não é armazenada numa estrutura de menu.
É assim:
B2:53E9 90 FB BA mov DPTR, #XRAM_FBBA
B2:53EC E0 movx A, @DPTR
B2:53ED B4 04 1E cjne A, #4, B2_540E
B2:53F0 7D 04 mov R5, #4
B2:53F2 7F 2A mov R7, #0x2A ; '*'
B2:53F4 7E 00 mov R6, #0
B2:53F6 12 08 E9 lcall B2_BS_256_B1_B2D1
B2:540E B2_540E: ; CODE XREF: BankSw_428_B2_5350+9Dj
B2:540E 90 FB BA mov DPTR, #XRAM_FBBA
B2:5411 E0 movx A, @DPTR
B2:5412 64 02 xrl A, #2
B2:5414 70 33 jnz B2_5449
B2:5416 7D 04 mov R5, #4
B2:5418 7F 2A mov R7, #0x2A ; '*'
B2:541A FE mov R6, A
B2:541B 12 08 E9 lcall B2_BS_256_B1_B2D1
B2:08E9 ; =============== S U B R O U T I N E =======================================
B2:08E9
B2:08E9
B2:08E9 B2_BS_256_B1_B2D1: ; CODE XREF: B2_1952+7Dp
B2:08E9 ; B2_1952+89p ...
B2:08E9 90 B2 D1 mov DPTR, #PREF_SetChar
B2:08EC 02 02 40 ljmp B2_Bank_1
B2:08EC ; End of function B2_BS_256_B1_B2D1
B2:08EC
B2:08EF
Deve-se alterar o byte em 253F1 de 04 para o número da região desejada (00, no caso de Region Free)
Isso funciona da mesma maneira para o LG9XXX e para o LGDK194g, inclusive é usado o mesmo endereço EEPROM (2A). Para outros LGs existem diferenças. Pretendo estudar um pouco mais e dar detalhes no Log de Descobertas.
Além disso, as próximas versões do Firmware Alternativo poderão já vir com a região desbloqueada.
-
Aqui está a rotina de seleção das fontes de legendas no DV256K (encontrei essa rotina por semelhança com a rotina descrita pelo rictad no tópico do DV397H):
B4:E337 ; =============== S U B R O U T I N E =======================================
B4:E337
B4:E337
B4:E337 BankSw_229_B4_E337: ; DATA XREF: B0:B0_BS_229_B4_E337o
B4:E337 ; B1:B1_BS_229_B4_E337o ...
B4:E337 90 FB 00 mov DPTR, #XRAM_FB00
B4:E33A E0 movx A, @DPTR
B4:E33B 24 F2 add A, #0xF2 ; '='
B4:E33D 60 20 jz B4_E35F
B4:E33F 14 dec A
B4:E340 60 33 jz B4_E375
B4:E342 24 E6 add A, #0xE6 ; 'µ'
B4:E344 60 2F jz B4_E375
B4:E346 24 C8 add A, #0xC8 ; '+'
B4:E348 60 10 jz B4_E35A
B4:E34A 14 dec A
B4:E34B 60 0D jz B4_E35A
B4:E34D 24 BC add A, #0xBC ; '+'
B4:E34F 60 04 jz B4_E355
B4:E351 24 95 add A, #0x95 ; 'ò'
B4:E353 70 35 jnz B4_E38A
B4:E355
B4:E355 B4_E355: ; CODE XREF: BankSw_229_B4_E337+18j
B4:E355 12 04 FF lcall B4_BS_89_B2_FC64
B4:E358 D3 setb C
B4:E359 22 ret
B4:E35A ; ---------------------------------------------------------------------------
B4:E35A
B4:E35A B4_E35A: ; CODE XREF: BankSw_229_B4_E337+11j
B4:E35A ; BankSw_229_B4_E337+14j
B4:E35A 12 04 FF lcall B4_BS_89_B2_FC64
B4:E35D C3 clr C
B4:E35E 22 ret
B4:E35F ; ---------------------------------------------------------------------------
B4:E35F
B4:E35F B4_E35F: ; CODE XREF: BankSw_229_B4_E337+6j
B4:E35F 90 FD B6 mov DPTR, #XRAM_FDB6
B4:E362 E0 movx A, @DPTR
B4:E363 D3 setb C
B4:E364 94 00 subb A, #0
B4:E366 40 05 jc B4_E36D
B4:E368 E0 movx A, @DPTR
B4:E369 14 dec A
B4:E36A F0 movx @DPTR, A
B4:E36B 80 1F sjmp B4_E38C
B4:E36D ; ---------------------------------------------------------------------------
B4:E36D
B4:E36D B4_E36D: ; CODE XREF: BankSw_229_B4_E337+2Fj
B4:E36D 90 FD B6 mov DPTR, #XRAM_FDB6
B4:E370 74 08 mov A, #8
B4:E372 F0 movx @DPTR, A
B4:E373 80 17 sjmp B4_E38C
B4:E375 ; ---------------------------------------------------------------------------
B4:E375
B4:E375 B4_E375: ; CODE XREF: BankSw_229_B4_E337+9j
B4:E375 ; BankSw_229_B4_E337+Dj
B4:E375 90 FD B6 mov DPTR, #XRAM_FDB6
B4:E378 E0 movx A, @DPTR
B4:E379 C3 clr C
B4:E37A 94 08 subb A, #8
B4:E37C 50 05 jnc B4_E383
B4:E37E E0 movx A, @DPTR
B4:E37F 04 inc A
B4:E380 F0 movx @DPTR, A
B4:E381 80 09 sjmp B4_E38C
B4:E383 ; ---------------------------------------------------------------------------
B4:E383
B4:E383 B4_E383: ; CODE XREF: BankSw_229_B4_E337+45j
B4:E383 E4 clr A
B4:E384 90 FD B6 mov DPTR, #XRAM_FDB6
B4:E387 F0 movx @DPTR, A
B4:E388 80 02 sjmp B4_E38C
B4:E38A ; ---------------------------------------------------------------------------
B4:E38A
B4:E38A B4_E38A: ; CODE XREF: BankSw_229_B4_E337+1Cj
B4:E38A D3 setb C
B4:E38B 22 ret
B4:E38C ; ---------------------------------------------------------------------------
B4:E38C
B4:E38C B4_E38C: ; CODE XREF: BankSw_229_B4_E337+34j
B4:E38C ; BankSw_229_B4_E337+3Cj ...
B4:E38C 90 FD B6 mov DPTR, #XRAM_FDB6
B4:E38F E0 movx A, @DPTR
B4:E390 25 E0 add A, ACC ; Accumulator
B4:E392 24 08 add A, #8
B4:E394 FF mov R7, A
B4:E395 12 EF F9 lcall BankSw_395_B4_EFF9
B4:E398 90 FD B6 mov DPTR, #XRAM_FDB6
B4:E39B E0 movx A, @DPTR
B4:E39C FF mov R7, A
B4:E39D 12 E7 2C lcall B4_E72C
B4:E3A0 D3 setb C
B4:E3A1 22 ret
B4:E3A1 ; End of function BankSw_229_B4_E337
B4:E3A1
No DV256K a fonte 13 do firmware, que é a CP1255, apresenta o seguinte problema: mesmo colocando uma fonte CP1252 no lugar, os caracteres acentuados aparecem de maneira errada e estranha. Portanto, concluo que existe um processamento especial em relação a essa fonte.
Inicialmente pensei que reduzindo o número de fontes de 9 para 8, e eliminando a fonte 13, isso se resolveria. Fiz isso, e percebi que estava errado: não adiantou nada, pois a fonte 14 passou a ocupar o lugar da fonte 13 e o problema com os caracteres acentuados passaram a ocorrer com essa fonte.
As fontes do DV256K são as seguintes:
No player: No firmware:
CP1250 8
CP1251 9
CP1252 10
CP1253 11
CP1254 12
CP1255 13
8859-2 14
8859-5 15
KOI8-R 16
Para não ter mais problema com isso, eu teria que reduzir o número de fontes de 9 para 5. Só assim, a fonte 13 não participaria mais da seleção (apenas as fontes de 8 a 12). Porém, acho essa solução meio radical: seria melhor deixar do jeito que está (com uma fonte não funcionando), do que ter que eliminar 4 fontes (para ficar com todas funcionando).
Tentei entender a rotina, buscando onde o processamento extra da fonte 13 poderia ocorrer, mas estou meio perdido... :dashhead1: Rictad, como foi você que descobriu essa rotina (e outras relacionadas), você teria alguma idéia a respeito de uma possível correção para esse problema? Obrigado!
-
Interessante é que no final não há nenhuma verificação seletiva para escolher a fonte (como no DV397H). A escolha é feita pelo caminho direto. Veja:
B4:E390 25 E0 add A, ACC ; Accumulator
B4:E392 24 08 add A, #8
....
Ele dobra o valor da escolha (add A, ACC = A+A) e depois soma 8. Isso é feito sempre, para todas as opções. No 397H, dobra-se e soma 10 para as 5 primeiras. Para as outras duas (inclusive a repetida) faz-se outra operação.
Bom, voltando ao 256K, parece que o problema é que a fonte 13 não é a última. Assim, você terá que colocar uma espécie de "if then" no meio do código para pular a fonte 13. Segundo a sua tabela, a seleção dela ocorre quando o acumulador atinge o valor 5 nos seguintes trechos:
B4:E368 E0 movx A, @DPTR
B4:E369 14 dec A
B4:E36A F0 movx @DPTR, A
B4:E36B 80 1F sjmp B4_E38C
...
B4:E37E E0 movx A, @DPTR
B4:E37F 04 inc A
B4:E380 F0 movx @DPTR, A
B4:E381 80 09 sjmp B4_E38C
...
Em cada um, faça um desvio para uma verificação (de comparação). No primeiro, no dec, verifique se A=5. Se for, decremente mais uma vez (para 4). No segundo, se A=5, incremente mais uma vez. Assim, você terá a seguinte tabela:
No player: No firmware:
CP1250 8
CP1251 9
CP1252 10
CP1253 11
CP1254 12
8859-2 14
8859-5 15
KOI8-R 16
A verificação no decremento pode ser feita com algo do tipo:
B4 05 01 cjne A, #5, YYYY
14 dec A
YYYY: 22 ret
E no incremento, de forma análoga.
EDIT: Se 5 não corresponder à fonte 13, outra será "removida". Então vai testando outros valores.
-
'Brigadão rictad! :)
Eu cheguei a imaginar que talvez tivesse que "pular" a fonte 13 com algum "if then", mas não tinha conseguido identificar os pontos para fazer isso. Vou testar e depois comento os resultados.
-
Depois de alguns ajustes no trecho de verificação "if then" para pular a fonte 13, consegui eliminar essa fonte. Na parte que incrementa é necessário por #4 (a fonte anterior a que queremos eliminar, de baixo para cima), e na parte que decrementa é necessário por #6 (a fonte anterior a que queremos eliminar, de cima para baixo).
Obrigado novamente rictad! :)
E368 02 F4 A3 LJMP F4A3
E37E 02 F4 C0 LJMP F4C0
F4A3 E0 MOVX A, @DPTR
F4A4 B4 06 01 CJNE A, #06, F4A8
F4A7 14 DEC A
F4A8 14 DEC A
F4A9 F0 MOVX @DPTR, A
F4AA 02 E3 6B LJMP E36B
F4C0 E0 MOVX A, @DPTR
F4C1 B4 04 01 CJNE A, #04, F4C5
F4C4 04 INC A
F4C5 04 INC A
F4C6 F0 MOVX @DPTR, A
F4C7 02 E3 81 LJMP E381
-
Depois de alguns ajustes no trecho de verificação "if then" para pular a fonte 13, consegui eliminar essa fonte. Na parte que incrementa é necessário por #4 (a fonte anterior a que queremos eliminar, de baixo para cima), e na parte que decrementa é necessário por #6 (a fonte anterior a que queremos eliminar, de cima para baixo).
Obrigado novamente rictad! :)
De nada zeurt! É isso aí! Para deixar o #5 na comparação, deve-se colocar o jump após o dec inicial (ou inc) e o outro dec (ou inc) somente depois do desvio. Por exemplo, para o dec:
E368 E0 movx A, @DPTR
E369 14 dec A
E36A 02 F4 A3 ljmp B4_F4A3
F4A3 B4 05 01 cjne A, #05, F4A7
F4A6 14 dec A
F4A7 F0 movx @DPTR, A
F4A8 02 E3 8C ljmp B4_E38C
Acabei não deixando claro isso antes, mas você implementou de um jeito equivalente. :clapping:
-
Finalmente, depois de longo intervalo, estou enviando uma nova versão do meu Firmware Alternativo para o LG DV256K! :yahoo!:
Tenho feito as modificações aos poucos, e sempre tenho adiado para enviar uma nova versão, aguardando para enviar algo mais completo. Mudei de idéia. Acho melhor já postar o que fiz, e a medida que for complementando, vou mandando novas versões.
Firmware Alternativo para LG DV256K zeurt v0.4
Novos itens:
-Seleção de Tempo Corrente, Restante, ou Total (para DivX apenas): deve-se pressionar DISPLAY, ir até a função GOTO (<-:--:-->) e, com as setas, selecionar o tipo de Tempo desejado.
-Seleção da Cor da Fonte das Legendas (Amarela Canário ou Branca) pelo Menu Outros (Others).
-Suporte a Caracteres Acentuados e Especiais no FileBrowser e nas ID3 Tags.
-Desbloqueio da Região do DVD: caso não tenha desbloqueado o player ainda, e se desejar desbloqueá-lo, é só entrar na página de serviço (http://ryan.com.br/prod_dk194g_br.htm#service) (com isso, se volta as configurações de fábrica, sendo que nesta versão do firmware alternativo deixei a Região do DVD default como 0-Free, e não mais 4 como no firmware original).
-Novas Fontes, com redução do espaçamento entre os caracteres (que nas versões anteriores era exagerado), e com Outline (Contorno) 2 em todas elas. Para trocar a fonte, deve-se pressionar SUBTITLE por 3 segundos durante a exibição de um arquivo .avi, escolher a fonte desejada com as setas, e pressionar ENTER.
Fonte 1: Original LG (CP-1252)
Fonte 2: Franklin Gothic Medium Cond Bold 22 (CP-1252)
Fonte 3: Arial Narrow Bold 23 (CP-1252)
Fonte 4: HelveticaNeue LT 57 Cn Bold 23 (CP-1252)
Fonte 5: Arial Bold 20 (CP-1252)
Fonte 6: Arial Rounded MT Bold Bold 20 (CP-1252)
Fonte 7: Tahoma Bold 20 (CP-1252)
Fonte 8: Koblenz-Serial DB Bold 21 (CP-1252)
-Eliminação da Fonte 9 (que não tinha utilidade)
-Ajustes na posição e no tamanho da janela das legendas, possibilitando a exibição de até 4 linhas de legendas com todas as 8 fontes, sem cortes em nenhuma delas.
Em relação a versão anterior (v0.3), mantive a Correção do Subtitle Timing Bug.
ATENÇÃO: Para atualizar o firmware, grave o arquivo direto na raiz do CD. Não modifique o nome do arquivo e não grave esse arquivo dentro de nenhuma pasta. Use CD-R ou CD-RW. Nesse CD não pode haver nenhum outro arquivo de firmware. Não grave CD multissessão. Além disso, CUIDADO, siga as recomendações do Ryan para atualização de Firmware:
http://ryan.com.br/prod_dk8321n_firmware.htm (http://ryan.com.br/prod_dk8321n_firmware.htm)
Ainda pretendo implementar (não sei quando... ;D):
-Tempo Restante/Total também para DVD/VCD.
-Seleção da Posição Vertical e se possível Tipo de Alinhamento Vertical das Legendas.
-Possibilidade de Carregar Legendas SRT com nomes diferentes dos arquivos AVI.
-Seleção da Palete de Cores das Legendas .idx/.sub (RGB ou YUV).
-Implementação do tão sonhado suporte a <i> tags.
-Melhorias na quebra de linha das legendas SRT.
-Melhorias na função ZOOM.
Agradecimentos ao jmaraujo por sua disponibilidade em sempre ajudar.
Agradecimentos a br0max e xypro, pois tenho aprendido muitas coisas fazendo a análise dos firmwares dos LG séries 8xxx e 9xxx modificados por eles (devo a eles a modificação de seleção da cor da fonte das legendas).
Agradecimentos especiais ao rictad, já que a implementação de Tempo Restante/Total foi totalmente desenvolvida por ele para o LG DV397H(apenas adaptei para o LG DV256K). Além disso, contei com grande ajuda dele para a eliminação da Fonte 9. Sem contar a sua generosidade em compartilhar de maneira didática todas as suas descobertas.
Mais uma vez, agradecimentos ao Ryan pela manutenção do seu Forum, que permite um acúmulo crescente de informações a respeito do tema Modificações de Firmwares de DVD/Divx players Mediatek.
-
zeurt, acho que encontrei as rotinas do ARM do DV397H de chip M que devem ser alteradas para implementar o itálico. Depois, procurando no ARM do DV256k, achei as mesmas, que são similares ou mesmo idênticas. Acho que será facil fazer o itálico no seu player. Seguem os pontos do DV256k:
Rotinas:
Provável exibição das legendas: sub_113FE.
Provável leitura dos caracteres da legenda (lê buffer secundário): sub_11C12.
Provável rotina de centralização horizontal da legenda: sub_10E56.
Provável rotina que lê buffer primário da legenda e preenche o secundário: sub_6DD10.
Endereços:
Provável endereço inicial do buffer primário da legenda: #865F0
Provável endereço inicial do buffer secundário da legenda: #85FF4
Provável endereço inicial que guarda as opções de legenda: #800C8
Um teste:
Tente adicionar uma das fontes usadas no meu firmware com os caracteres itálicos e altere a rotina sub_11C12 fazendo algum desvio após o 00011C26 80 78 LDRB R0, [R0,#2] para adicionar um offset de #DF ao registrador R0. Se a legenda ficar toda em itálico, então o método funcionará. Para o teste, acho que você pode aproveitar o espaço nesta mesma rotina que parece ser reponsável por processar a fonte repetida que você já eliminou no 8032. O espaço é o seguinte:
ROM:00011C1C 08 49 LDR R1, =unk_800D4
ROM:00011C1E 08 5C LDRB R0, [R1,R0]
ROM:00011C20 70 47 BX LR
-
Obrigado, rictad! Você me poupou todo esse trabalho! :)
Essa semana farei esse teste e também tentarei começar a implementar um Itálico light para o LG DV256K. ;D
-
Beleza! Qualquer coisa é só perguntar.
Para o teste, envio uma alteração para a rotina que lê os caracteres:
11C1A 00 00 "pseudo" NOP ; nao precisamos do trecho que trata a fonte repetida
11C1C 08 4A LDR R1, =unk_85FF4 ; aumentei de #49 a #4A para saltar exatamente
; 1 palavra na tabela que fica logo abaixo da rotina
11C1E 08 18 ADDS R0, R1, R0
11C20 80 78 LDRB R0, [R0,#2]
11C22 DF 30 ADDS R0, #0xDF ; adiciona offset ao código do caractere
11C24 70 47 BX LR
Antes de atualizar o firmware, faz o teste no IDA para ver se as instruções estão certas. Principalmente o LDR R1, =unk_85FF4 em #11C1C, pois essas tabelas de palavras costumam enganar. Mas acho que está certo.
-
Na verdade, em 11C1C tinha que aumentar de 08 49 para 09 49 (e não para 08 4A) para saltar 1 palavra.
Fazendo isso, deu certo o teste! Quer dizer, mais ou menos certo: tudo ficou em itálico, porém os espaços entre as palavras (" ") foram substituídos por "ÿ", e vírgulas seguidas de espaço (", ") foram substituídas por ",ìé". Não entendi. :dashhead1:
Rictad, talvez você já tenha visto algo parecido. Tendo resolvido isso, partirei para os próximos passos.
Obs: Para o teste eu troquei a minha fonte Arial Narrow pela sua fonte Arial Narrow com os itálicos.
-
Na verdade, em 11C1C tinha que aumentar de 08 49 para 09 49 (e não para 08 4A) para saltar 1 palavra.
Fazendo isso, deu certo o teste! Quer dizer, mais ou menos certo: tudo ficou em itálico, porém os espaços entre as palavras (" ") foram substituídos por "ÿ", e vírgulas seguidas de espaço (", ") foram substituídas por ",ìé". Não entendi. :dashhead1:
Rictad, talvez você já tenha visto algo parecido. Tendo resolvido isso, partirei para os próximos passos.
Obs: Para o teste eu troquei a minha fonte Arial Narrow pela sua fonte Arial Narrow com os itálicos.
Normal. Na parte itálica eu excluí os caracteres abaixo de #20 (por isso se soma #DF e não #FF). Daí, quando aplico o itálico, só somo #DF se R0 for maior que #20. E, neste caso, a gente somou a todos os caracteres. O importante é que funcionou!
-
Proposta de Implementação de Itálico Light: para LG DV256K e LG DV397H Chip M:
Primeiro passo: Ao ler os caracteres do buffer (primário ou secundário?), filtrar <i>, mudando o código de caractere para #3 e setando o bit 7, e filtrar </i>,mudando o código de caractere para #4 e resetando o bit 7. Como esses players não filtram as tags, pode-se filtrá-las tanto no buffer primário como no secundário, estou certo? Não sei qual opção é melhor ou mais fácil.
Segundo passo: Mais a frente, se o caractere lido não for #3 ou #4, for maior que #20, e o bit 7 estiver setado, adicionar offset de #DF (223) ao caractere lido.
Terceiro passo: Adicionar os trechos que cancelam o itálico no início de cada quadro (para resolver o problema das linhas que não tem </i>).
Quarto passo: Corrigir a centralização (essa parte ainda não entendi completamente).
É claro que antes de tudo isso devemos trocar as fontes (usando aquelas criadas pelo rictad depois de tanto trabalho).
Essa proposta é light pois não há opções no menu (nem mesmo para ligar/desligar o itálico), não há necessidade de mexer nos 2 buffers, e talvez as áreas de erros sejam suficientes.
Caso tudo isso funcione, considero que o resultado será bem satisfatório: sempre que houverem tags de itálico, o trecho será exibido corretamente em itálico.
Obs: Fiz essa proposta light, pois por enquanto, todo esse trabalho é para mim como falar uma língua que não tenho fluência. Cada frase, palavra, e até sílaba, eu tenho que parar duas vezes para pensar antes de falar. ;D Então, demora, etc.
Num outro momento, talvez possa implementar o Itálico Completo.
Fonte de Informações: Explicações sobre a Implementação do Itálico no tópico do Firmware do LG DV397H, por rictad.
-
A idéia do itálico light é boa, mas temos que verificar algumas coisas.
Se der para fazer a interpretação das tags no buffer secundário, então não precisa trocar pelo caractere 03 ou 04. Basta ignorar a tag e setar (ou resetar) a flag. Aí, ao dar o código final do caractere, só precisamos saber se é maior que #20 e se a flag está setada. Setar a flag quando se lê o buffer primário não dá, pois ele é lido antes da rotina que exibe a legenda ser executada. Então dá um certo atraso. Mas no meu player eu precisei alterar esse trecho, pois ele filtrava as tags. Daí, tive que fazer as duas operações. Mas no DV256k e no DV397H M não há filtro. Então talvez seja mais fácil e só precise setar ou resetar a flag.
Ainda assim, acho que ao menos uma opção de ligar ou desligar o itálico é importante. E temos que saber em qual posição guardaremos a flag. Eu sugiro que você teste alterar o byte de posição horizontal da legenda para ver se podemos usar 1 ou 2 bits dele. Teste os valores #00, #01, #02, #03, #80, #81, #82, #83, #C0, #C1, #C2, #C3, #C4 para o alinhamento horizontal. Não precisa nem ser isso tudo (talvez só 00, 01, #80, #81, #C0 e #C1). Só temos que saber se os bits 6 e 7 do byte fazem diferença. Se não fizerem, serão de grande ajuda na implementação. Os do alinhamento vertical também podem ser testados. Para testar mais facilmente, você pode criar opções "virtuais" no menu, com esses valores.
-
Eu tava olhando as rotinas e acho que talvez tenha sim que mexer no buffer primário. Um outro motivo de eu ter mexido no meu foi que aquela rotina tem um contador próprio da posição dos caracteres no buffer.
Veja só, a rotina que lê o buffer secundário da legenda e retorna o código do caractere não possui um contador próprio. Ela recebe a posição no registrador R0 e faz o seguinte:
O ponteiro do buffer unk_85FF4 é guardado em R1: LDR R1, =unk_85FF4;
Depois, soma-se R1 a R0 (atualiza posição do buffer) e guarda a nova posição em R0: ADDS R0, R1, R0;
Por último, a valor do caractere é lido da posição atualizada + 2 (os caracteres do buffer começam de fato em #85FF4+2, pois na posição #85FF4+1 temos um byte para indicar a quantidade de caracteres e, provavelmente, em #85FF4 há alguma outra informação) e colocado no próprio R0, o que apaga o valor da posição: LDRB R0, [R0,#2].
O contador de posição fica a cargo das rotinas que chamam essa rotina (a rotina centraliza, o trecho da rotina de exibição responsável por calcular as quebras de linha da legenda etc.). E pode ser usado um registrador diferente, que tem seu valor passado a R0, antes de cada chamada.
Assim, para ignorarmos as tags ou trocá-las por algum código, teríamos que atualizar esse contador em cada chamada, o que é muito difícil de fazer. Por exemplo, se a gente acha a sequência [unk_85FF4+2]="<", [unk_85FF4+3]="i" e [unk_85FF4+4]=">", que significa a tag "<i>" encontrada no buffer a partir de [unk_85FF4+2], temos que atualizar o contador de caracteres para que aponte a [unk_85FF4+5] e "salte" os outros caracteres da tag. Mas este contador está fora da rotina que lê o buffer secundário e, potencialmente, pode ser qualquer registrador da rotina chamadora.
Por outro lado, a rotina que lê o buffer primário tem seu próprio contador em R5 (ao que parece). No caso de DV256k ela não fica em um ARM code escondido. Então deve ser fácil modificá-la. Se você puder, gostaria que fizesse o seguinte teste para sabermos se de fato ela é a rotina do buffer primário:
6DD58 61 21 MOVS R1, #61
Isso irá trocar qualquer caractere lido do buffer primário (menos as quebras de linha, #0D) por #61 (código de "a") antes de colocá-lo no buffer secundário. Se suas legendas ficarem apenas com a letra "a" aparecendo, então está é a rotina certa.
E se funcionar, peço ainda que desfaça a alteração anterior e faça as seguintes modificações:
6DD66 09 2C CMP R4, #9
......
6DD6E 09 2C CMP R4, #9
......
6DD76 09 20 MOVS R0, #9
Ao que parece, o buffer primário é lido de 8 em 8. Se isso for verdade, então ele é pequeno e só cabem 8 caracteres. Com as alterações fazemos com que ele seja lido de 9 em 9. Caso as legendas fiquem com falhas de 8 em 8 caracteres, então realmente ele é pequeno e teremos que levar isso em consideração ao modificá-lo. No DV397H de chipset S ele é lido de 32 em 32. Mas isso não atrapalhará em nada a modificação, só será diferente.
-
Oi rictad, já fiz os testes:
Teste 1: As legendas ficaram apenas com a letra "a", como era esperado.
Aproveitei para testar o alinhamento horizontal - #00: ficou alinhado a esquerda, porém de um jeito meio louco; a primeira linha ficava a esquerda corretamente, enquanto que a segunda linha às vezes estava correta (à esquerda) e às vezes estava posicionada nos mais variados locais: no meio da tela, mais à direita, etc. Assim:
Ex1:
aaaaaaaaa
aaaaaaaaaaaaaaaa
Ex2:
aaaa
aaaaaaaa
Ex3:
aaaaaaaa
aaa aaaaaaaaaaaaaa (nesse caso, a segunda linha começou no meio da tela e "atravessou" para o outro lado, terminando na parte esquerda da tela)
Teste 2: Mudando os locais que você orientou (de #8 para #9), não houve nenhuma alteração perceptível: não houve falha a cada 8 caracteres, etc. Em resumo, ficou como se não tivesse sido mudado nada.
Aproveitei para testar o alinhamento horizontal - #01: ficou centralizado, sem alterações (igual ao valor padrão (#81). Falta testar #80, #C0 e #C1.
-
Teste 1: As legendas ficaram apenas com a letra "a", como era esperado.
Aproveitei para testar o alinhamento horizontal - #00: ficou alinhado a esquerda, porém de um jeito meio louco; a primeira linha ficava a esquerda corretamente, enquanto que a segunda linha às vezes estava correta (à esquerda) e às vezes estava posicionada nos mais variados locais: no meio da tela, mais à direita, etc.
O seu firmware tem opção de alinhamento à esquerda? Se não, talvez #00 (e possivelmente #80 e #C0) sejam alinhamentos à esquerda defeituosos. Eu pensei que você já usava o #80 para isso. Se não tem alinhamento à esquerda e #C0 também centralizar, já temos nossos 2 bits disponíveis (e provavelmente um terceiro, se #E0 e #E1 seguirem o padrão ;)).
-
Isso, o meu firmware não tem alinhamento a esquerda (e ele deve ser defeituoso mesmo).
-
Então vai ficar ainda mais fácil implementar o itálico light, pois não terá que se preocupar com outro valor para o alinhamento horizontal. E será bem simples adicionar no futuro ao menos uma opção de habilitar/desabilitar o itálico no menu, ou mesmo mais uma outra para eliminar/mostrar as tags. Você já pensou como vai fazer com as outras tags? Quando o itálico estiver habilitado, como vai fazer com as tags de negrito, por exemplo? Vai mostrá-las ou eliminá-las?
-
Eu cheguei a pensar rapidamente sobre as outras tags (negrito,etc.), e acabei chegando a conclusão que eu as deixaria sem alterações (ou seja, seriam exibidas como já são atualmente) no Plano Itálico Light, já que essas outras tags são bem mais raras. Porém, se não for muito difícil, talvez seria legal filtrá-las e desprezá-las (ou seja, não exibí-las).
-
Oi rictad,
Depois de estudar bastante as suas modificações já pude fazer um esboço do Itálico Light para o LG DV256K. Fiz apenas o básico: falta as partes que corrigem a centralização e que cancelam o itálico no início de cada quadro. Porém, ainda tenho dúvidas, como:
1- Não entendi como você fez o artifício contra a problema do limite de tamaho do buffer primário. Assim, acho que no meu esboço falta isso.
2- Ainda não sei se poderei usar as áreas de erro para colocar a nova rotina do buffer primário. Isso porque o buffer primário fica no ARM code 2, e as áreas de erro no ARM code 1. Farei um teste rápido (desvio do buffer primário para área de erro, para legendas ficarem só com "aaaaaaaaaaa..." ;D ), porém hoje não estou em casa e não posso fazer ainda.
Aqui vão os esboços das modificações:
Rotina do Buffer Primário Original (com o possível ponto para o desvio para nova rotina que filtra as tags de itálico)
ROM:0006DD10 ; =============== S U B R O U T I N E =======================================
ROM:0006DD10
ROM:0006DD10
ROM:0006DD10 sub_6DD10 ; CODE XREF: sub_6DE6C+52p
ROM:0006DD10 ; sub_6DE6C+62p
ROM:0006DD10 F8 B5 PUSH {R3-R7,LR}
ROM:0006DD12 00 26 MOVS R6, #0
ROM:0006DD14 00 25 MOVS R5, #0
ROM:0006DD16 00 20 MOVS R0, #0
ROM:0006DD18 F2 F7 56 F8 BL sub_5FDC8
ROM:0006DD1C 85 4F LDR R7, =unk_85FF4
ROM:0006DD1E
ROM:0006DD1E loc_6DD1E ; CODE XREF: sub_6DD10+7Ej
ROM:0006DD1E 00 24 MOVS R4, #0
ROM:0006DD20 23 E0 B loc_6DD6A
ROM:0006DD22 ; ---------------------------------------------------------------------------
ROM:0006DD22
ROM:0006DD22 loc_6DD22 ; CODE XREF: sub_6DD10+5Cj
ROM:0006DD22 80 48 LDR R0, =unk_865F0
ROM:0006DD24 00 5D LDRB R0, [R0,R4] ; COLOCAR O DESVIO PARA FILTROS DE ITALICO AQUI
ROM:0006DD26 0D 28 CMP R0, #0xD
ROM:0006DD28 16 D1 BNE loc_6DD58
ROM:0006DD2A 00 22 MOVS R2, #0
ROM:0006DD2C 01 21 MOVS R1, #1
ROM:0006DD2E 20 1C ADDS R0, R4, #0
ROM:0006DD30 F2 F7 20 F8 BL sub_5FD74
ROM:0006DD34 FF F7 5D FF BL sub_6DBF2
ROM:0006DD38 00 28 CMP R0, #0
ROM:0006DD3A 13 D0 BEQ loc_6DD64
ROM:0006DD3C 01 36 ADDS R6, #1
ROM:0006DD3E 01 2E CMP R6, #1
ROM:0006DD40 15 D1 BNE loc_6DD6E
ROM:0006DD42 B2 2D CMP R5, #0xB2 ; '¦'
ROM:0006DD44 13 D2 BCS loc_6DD6E
ROM:0006DD46 EA 19 ADDS R2, R5, R7
ROM:0006DD48 0D 21 MOVS R1, #0xD
ROM:0006DD4A 91 70 STRB R1, [R2,#2]
ROM:0006DD4C 68 1C ADDS R0, R5, #1
ROM:0006DD4E 45 1C ADDS R5, R0, #1
ROM:0006DD50 0A 21 MOVS R1, #0xA
ROM:0006DD52 C0 19 ADDS R0, R0, R7
ROM:0006DD54 81 70 STRB R1, [R0,#2]
ROM:0006DD56 0A E0 B loc_6DD6E
ROM:0006DD58 ; ---------------------------------------------------------------------------
ROM:0006DD58
ROM:0006DD58 loc_6DD58 ; CODE XREF: sub_6DD10+18j
ROM:0006DD58 01 1C ADDS R1, R0, #0
ROM:0006DD5A 28 1C ADDS R0, R5, #0
ROM:0006DD5C 01 35 ADDS R5, #1
ROM:0006DD5E C0 19 ADDS R0, R0, R7
ROM:0006DD60 81 70 STRB R1, [R0,#2]
ROM:0006DD62 00 26 MOVS R6, #0
ROM:0006DD64
ROM:0006DD64 loc_6DD64 ; CODE XREF: sub_6DD10+2Aj
ROM:0006DD64 01 34 ADDS R4, #1
ROM:0006DD66 08 2C CMP R4, #8
ROM:0006DD68 01 D2 BCS loc_6DD6E
ROM:0006DD6A
ROM:0006DD6A loc_6DD6A ; CODE XREF: sub_6DD10+10j
ROM:0006DD6A B4 2D CMP R5, #0xB4 ; '¦'
ROM:0006DD6C D9 D3 BCC loc_6DD22
ROM:0006DD6E
ROM:0006DD6E loc_6DD6E ; CODE XREF: sub_6DD10+30j
ROM:0006DD6E ; sub_6DD10+34j ...
ROM:0006DD6E 08 2C CMP R4, #8
ROM:0006DD70 04 D1 BNE loc_6DD7C
ROM:0006DD72 00 22 MOVS R2, #0
ROM:0006DD74 01 21 MOVS R1, #1
ROM:0006DD76 08 20 MOVS R0, #8
ROM:0006DD78 F1 F7 FC FF BL sub_5FD74
ROM:0006DD7C
ROM:0006DD7C loc_6DD7C ; CODE XREF: sub_6DD10+60j
ROM:0006DD7C 00 20 MOVS R0, #0
ROM:0006DD7E F2 F7 23 F8 BL sub_5FDC8
ROM:0006DD82 02 2E CMP R6, #2
ROM:0006DD84 02 D1 BNE loc_6DD8C
ROM:0006DD86 28 1C ADDS R0, R5, #0
ROM:0006DD88 FE 30 ADDS R0, #0xFE ; '¦'
ROM:0006DD8A 02 E0 B loc_6DD92
ROM:0006DD8C ; ---------------------------------------------------------------------------
ROM:0006DD8C
ROM:0006DD8C loc_6DD8C ; CODE XREF: sub_6DD10+74j
ROM:0006DD8C B4 2D CMP R5, #0xB4 ; '¦'
ROM:0006DD8E C6 D3 BCC loc_6DD1E
ROM:0006DD90 B4 20 MOVS R0, #0xB4 ; '¦'
ROM:0006DD92
ROM:0006DD92 loc_6DD92 ; CODE XREF: sub_6DD10+7Aj
ROM:0006DD92 78 70 STRB R0, [R7,#1]
ROM:0006DD94 61 49 LDR R1, =unk_86E2C
ROM:0006DD96 00 20 MOVS R0, #0
ROM:0006DD98 14 39 SUBS R1, #0x14
ROM:0006DD9A 08 60 STR R0, [R1]
ROM:0006DD9C F8 BC POP {R3-R7}
ROM:0006DD9E 08 BC POP {R3}
ROM:0006DDA0 18 47 BX R3
ROM:0006DDA0 ; End of function sub_6DD10
Nova Rotina, que filtra as tags de itálico:
12 B4 INICIO PUSH {R1,R4}
03 5D LDRB R3, [R0,R4]
3C 2B CMP R3, #0x3C ; '<'
XX D1 BNE FIM1
61 1C ADDS R1, R4, #1
43 5C LDRB R3, [R0,R1]
69 2B CMP R3, #0x69 ; 'i'
XX D1 BNE VERIFBARRA
01 31 ADDS R1, #1
43 5C LDRB R3, [R0,R1]
3E 2B CMP R3, #0x3E ; '>'
XX D1 BNE FIM1
03 20 MOVS R0, #3
0A E0 B FIM2
2F 2B VERIFBARRA CMP R3, #0x2F ; '/'
XX D1 BNE FIM1
01 31 ADDS R1, #1
43 5C LDRB R3, [R0,R1]
69 2B CMP R3, #0x69 ; 'i'
XX D1 BNE FIM1
01 31 ADDS R1, #1
43 5C LDRB R3, [R0,R1]
3E 2B CMP R3, #0x3E ; '>'
XX D1 BNE FIM1
04 20 MOVS R0, #4
0C 1C FIM2 ADDS R4, R1, #0
22 BC POP {R1,R4}
XX XX XX XX BL 6DD26 ; continua rotina anterior
00 5D FIM1 LDRB R0, [R0,R4] ; retorna sem mudar nada
12 BC POP {R1,R4}
XX XX XX XX BL 6DD26 ; continua rotina anterior
Rotinas do buffer secundário, ocupando o mesmo espaço da rotina original, e depois as áreas de erro:
; =============== S U B R O U T I N E =======================================
XX XX LDR R1, =unk_85FF4 ; end. inicial buffer secundario
08 18 ADDS R0, R1, R0
80 78 LDRB R0, [R0,#2]
70 47 BX LR
No espaço que sobra logo a seguir da rotina acima:
; =============== S U B R O U T I N E =======================================
XX XX LDR R1, =unk_85FF4
08 18 ADDS R0, R1, R0
XX XX LDR R2, =unk_800C8 ; end. que guarda opcoes da legenda
80 78 LDRB R0, [R0,#2]
D1 79 LDRB R1, [R2,#7] ; no DV256K o Alin. Horiz. fica em 800C8 + #7
00 B5 PUSH {LR}
XX XX XX XX BL NOVA ROTINA
08 BC POP {R3}
18 47 BX R3
Na área de erros:
; =============== S U B R O U T I N E =======================================
03 28 NOVA ROTINA CMP R0, #3
03 D1 BNE PARTE2
80 23 MOVS R3, #0x80
19 43 ORRS R1, R3 ; seta bit 7 do alin. horiz.
D1 71 STRB R1, [R2,#7]
70 47 BX LR
04 28 PARTE2 CMP R0, #4
03 D1 BNE PARTE3
7F 23 MOVS R3, #0x7F
19 40 ANDS R1, R3 ; reseta bit 7 do alin. horiz.
D1 71 STRB R1, [R2,#7]
70 47 BX LR
20 28 PARTE3 CMP R0, #0x20
09 D9 BLS FIM
D1 79 LDRB R1, [R2,#7]
70 22 MOVS R2, #0x70 ; retirar essas 4 linhas (checam se italico esta habilitado pelo menu)
0A 40 ANDS R2, R1 ; (idem)
50 2A CMP R2, #0x50 ; (idem)
04 D1 BNE FIM ; (idem)
80 22 MOVS R2, #0x80
0A 40 ANDS R2, R1
80 2A CMP R2, #0x80 ; checa se bit 7 esta setado
00 D1 BNE FIM
DF 30 ADDS R0, #0xDF
70 47 FIM BX LR
Rictad, se você detectar alguma coisa errada, avise. :) Obrigado! Nesse fim-de-semana pretendo testar na prática...
-
Que legal! Olhando bem rapidamente, parece tudo certo. Gostei do jeito que você filtrou as tags. Legal que tenha achado o endereço do alinhamento horizontal. Acho que vai funcionar direitinho! Mas amanhã vou olhar com mais calma, qualquer coisa te aviso.
Com relação ao teste de salto na rotina do buffer primário para a área de erros, basta fazer o seguinte:
use um BL para área de erros;
na área de erros ponha apenas as 2 instruções que foram ocupadas pelos 4 bytes do BL seguidas do BX LR para retornar.
Se o player não travar quando exibir as legendas, o salto funcionou. Se travar ou exibir as legendas com erro, você vai ter que aumentar o ARM code 2. É simples, sei que você já viu: basta extrair apenas o ARM code 2 no MTKRemaker, adicionar alguns bytes (256 bytes dão e sobram) com um HEX editor e substituir no firmware com o MTKReplacer (o MTKRemaker costuma dar erro e não aceitar a substituição). Aí você abre novamente no MTKRemaker para corrigir o checksum e verificar se o firmware ainda aparece corretamente, com todos os trechos de antes.
-
Descobri um problema, pois esqueçi que o salto BL ocupa 4 bytes. Então tive que fazer as seguintes mudanças na rotina que le o buffer primario e no fim da nova rotina que filtra as tags:
Rotina que le buffer primario (original):
ROM:0006DD22 80 48 LDR R0, =unk_865F0
ROM:0006DD24 00 5D LDRB R0, [R0,R4] ; ESQUEÇI QUE O DESVIO QUE COLOCARIA AQUI OCUPA 4 BYTES
ROM:0006DD26 0D 28 CMP R0, #0xD
ROM:0006DD28 16 D1 BNE loc_6DD58
Ficaria Assim:
ROM:0006DD22 80 48 LDR R0, =unk_865F0
ROM:0006DD24 XX XX XX XX BL NOVA ROTINA
ROM:0006DD26 XX XX NOP
Então, teria que mudar o FIM (1 e 2) da NOVA ROTINA:
Como eu tinha feito antes:
0C 1C FIM2 ADDS R4, R1, #0
12 BC POP {R1,R4}
XX XX XX XX BL 6DD26 ; continua rotina anterior
00 5D FIM1 LDRB R0, [R0,R4] ; retorna sem mudar nada
12 BC POP {R1,R4}
XX XX XX XX BL 6DD26 ; continua rotina anterior
Como deve ser feito agora:
0C 1C FIM2 ADDS R4, R1, #0
00 5D LDRB R0, [R0,R4]
0D 28 CMP R0, #0xD
XX XX XX XX BLNE loc_6DD58
12 BC POP {R1,R4}
XX XX BX LR ; continua rotina anterior
00 5D FIM1 LDRB R0, [R0,R4] ; retorna sem mudar nada
0D 28 CMP R0, #0xD
XX XX XX XX BLNE loc_6DD58
12 BC POP {R1,R4}
XX XX BX LR ; continua rotina anterior
Obs: Mesmo assim, não sei se ainda tem algum erro (isso porque eu ainda me confundo com os PUSH/POP... preciso estudar mais ;) ).
-
Os PUSH/POP parecem certos. Você só precisa preservar R1 e R4 mesmo. R3 não precisa, pois na rotina de origem (como geralmente ocorre na maioria dessas rotinas) só é usado para retornos com BX. R0 será devolvido com o valor lido. E você retorna os valores a R1 e a R4 em ambos os possíveis fins da rotina.
Eu nem conhecia o BLNE. Já aprendi coisa nova! ;D
Mas não daria para você deixar o BNE original no lugar do NOP na rotina de origem? Se você fizer isso economiza alguns bytes. Se bem que eu não sei qual o comportamento da flag Z depois de um BX, o que pode invalidar o BNE. Mas eu tenho uma "intuição" de que ela não é alterada. Outra saída, que pode ficar legal, é você fazer o salto em #6DD22 mesmo. Aí você carrega o código do caractere no próprio filtro e o devolve para a rotina principal em R0. Mas para isso precisará fazer uma tabela com a palavra F0 65 08 00 (para o endereço #865F0 ser lido) no final. Mas enfim, isso tudo que escrevi é só perfumaria. O seu código está excelente! E se não funcionar, é por algum detalhe ainda não reparado por nós.
E dá para ver como você se dedicou ao assunto. Já está sabendo praticamente tudo! :clapping:
-
Acabei de descobrir que eu inventei o BLNE. :dashhead1:
Vou trocar por alguma das outras alternativas. Obrigado, rictad! :)
P.S.: Vou ficar com essa alternativa. Ficou meio feio, mas pelo menos ocupa o mesmo número de bytes que a anterior (errada).
0C 1C FIM2 ADDS R4, R1, #0
00 5D LDRB R0, [R0,R4]
0D 28 CMP R0, #0xD
XX XX BNE COMPLEMENTO
12 BC POP {R1,R4}
70 47 BX LR ; continua rotina anterior
00 5D FIM1 LDRB R0, [R0,R4] ; retorna sem mudar nada
0D 28 CMP R0, #0xD
XX XX BNE COMPLEMENTO
12 BC POP {R1,R4}
70 47 BX LR ; continua rotina anterior
XX XX XX XX COMPLEMENTO BL loc_6DD58
-
Acabei de descobrir que eu inventei o BLNE. :dashhead1:
Não, ela realmente existe. Mas só no modo ARM, fui ver agora :(.
-
1- Não entendi como você fez o artifício contra a problema do limite de tamaho do buffer primário. Assim, acho que no meu esboço falta isso.
Pois é, temos que ver isso. Você fez aquele teste, mudando os 3 trechos para 9 e não aconteceu nada. Talvez 8 seja um valor "de segurança" e caiba mais alguma coisa. Se couber mais 3 caracteres não precisaremos do artifício. Imagine que o primeiro caractere da tag, que é "<", esteja na posição 8 (vamos considerá-la como última do buffer). Quando você buscar pelo próximo caractere da tag, que pode ser o "i" ou a barra, irá somar 1 ao contador e tentará ler algo na posição 9, que estará fora do buffer (e poderá ser qualquer caractere que estiver na memória naquela posição). Assim, a rotina, muito provavelmente, "perderá" essa tag, a qual somente terá o próximo caractere carregado na primeira posição do buffer após o novo preenchimento.
Mas, pelo teste, parece que o buffer tem ao menos 9 posições. Para o pior caso, que é quando a maior tag (tag </i>) estiver começando na posição 8 do buffer, teríamos que ter pelo menos mais 3 posições para garantir a leitura. 8+3 = 11 = #B. Teste com o valor #B naquelas 3 posições para ver se perdem-se caracteres da legenda (ou se são adicionados caracteres estranhos). Caso não aconteça nada, só para tirar uma dúvida sobre o tamanho do buffer, teste valores maiores, como #20 ou #40.
Caso dê problemas com #B, tente o valor #A. Depois de descobir o valor máximo do buffer, você poderá deixar que ele seja lido até o valor máximo - 3 (para garantir a tag </i>). Por exemplo, se for 9, o máximo até agora testado, então deixe aqueles valores somente até 6 (9-3).
Mas caso nada disso dê algum resultado prático, deixe em 8 mesmo. Se após o itálico ser implementado tivermos problemas com algumas tags não sendo reconhecidas, então o limitador do buffer estará em outro lugar. Depois descobriremos. :)
-
Sinto avisar que o projeto do itálico light está temporariamente suspenso. :(
Isso porque eu "matei" o meu LG DV256K na última atualização que fiz. Não sei se cometi algum erro que afetou alguma área crítica do ARM, etc. O DVD player está "funcionalmente morto", ou seja, não reconhece mais nenhum disco, e assim não posso mais atualizá-lo por CD.
Inicia-se então mais uma saga de um ignorante em eletrônica, se enrolando com conversores RS-232/CMOS, conectores de 4 pinos, flat cables, etc., para tentar fazer uns malabarismos e recussitar o aparelho sem soldar o cabo ou o conector na porta serial (já que não tenho a menor condição de fazer isso). :laugh:
-
Que coisa mais chata, zeurt. :(
Você sabe se isso está relacionado com as alterações no buffer primário ou com a inclusão de mais fontes de 479 caracteres? Ou foi outra coisa?
(...) para tentar fazer uns malabarismos e recussitar o aparelho sem soldar o cabo ou o conector na porta serial (já que não tenho a menor condição de fazer isso). :laugh:
Como? Sua FLASH é socketada?
Com ajuda de um conhecido que trabalhe com eletrônica, você consegue fazer o cabo. Ou mesmo sozinho, pois você tem condições de sobra para aprender. ;)
-
Que coisa mais chata, zeurt. :(
Você sabe se isso está relacionado com as alterações no buffer primário ou com a inclusão de mais fontes de 479 caracteres? Ou foi outra coisa?
Acho que deve ter sido outra coisa. A fonte não é, pois só usei uma fonte de 479 caracteres e não tinha dado problema antes. Estou desconfiado da área de erros. Acho que tinha algo lá no meio que não podia ter alterado... Ou então foi alguma distração, etc. De qualquer modo, valeu pela força, rictad!
-
Que péssima notícia, estava ansioso e acompanhando o site toda semana. Espero que você consiga ressucitar o player.