Firmware do LG DV256k

[zeurt]

Finalmente, depois de longo intervalo, estou enviando uma nova versão do meu Firmware Alternativo para o LG DV256K! 
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 (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

Ainda pretendo implementar (não sei quando...  ):
-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.

[rictad]

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:

Código: [Selecionar]

ROM:00011C1C 08 49                       LDR     R1, =unk_800D4
ROM:00011C1E 08 5C                       LDRB    R0, [R1,R0]
ROM:00011C20 70 47                       BX      LR

[zeurt]

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.

[rictad]

Beleza! Qualquer coisa é só perguntar.

Para o teste, envio uma alteração para a rotina que lê os caracteres:

Código: [Selecionar]

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.

[zeurt]

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.  
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.

[rictad]

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.  
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!

[zeurt]

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.   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.

[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.

[rictad]

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:

Código: [Selecionar]

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:

Código: [Selecionar]

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.

[zeurt]

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.