FORUM.RYAN.COM.BR

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

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

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

Philips DVP5980 - Como é definido o sub-modelo

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

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

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

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

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

Testes com firmware V43

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

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

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

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

Vejam exemplos:

Região 4 ou D

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

Região 2 ou B

LG9843 (Europeu): LV9E12203B.MIH

Região 0

DV397H (Firmware que enviei): LG_DV_LV81F33B400MSMIS.ROM

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

Estamos manejando duas hipóteses:

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

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

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

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

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

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

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

Como funciona o esquema de bancos nos novos firmwares

Isso é só um rascunho.

Recapitulando:

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

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



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

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


E ainda é mais complicado do que parece:

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

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

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


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

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

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

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

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

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

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

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



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

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

Ronison,

Caso sobre um tempo, dê uma olhadinha em

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

Ao que parece, falta pouco!

Saudações,
doctorxyz