Correção nos caracteres no filebrowser e nas tags ID3:O grande problema dos caracteres é que eles parecem ser lidos no padrão Unicode, enquanto as fontes são CP Windows. Então daí a ideia daquela tabela. Resumindo de forma grosseira:
Todos esses padrões de codificação de caracteres, sejam eles ISO 8859, UTF/Unicode ou CP Windows, têm em comum, ao menos, o núcleo do antigo ASCII, que são os caracteres de #20 a #7F. Os caracteres Unicode são muito mais que 255. O padrão CP Windows pega esses caracteres Unicode extras e os distribui entre o pequeno espaço dos caracteres de controle que existe no meio do ISO 8859. Assim, criam-se vários CPs (1250, 1251, 1252...) com partes do Unicode misturadas ao ISO.
O que aquela rotina faz é verificar se o caracter lido no nome do arquivo ou nas tags ID3 é maior que 255 (ou seja, Unicode) para então modificar o seu valor com base na tabela Unicode -> CP1252, caso ele exista na CP1252. Se for um caracter Unicode que estiver na CP1253, por exemplo, nada acontecerá. Assim, a tabela vai depender da fonte utilizada no firmware. Não basta copiar a rotina no ARM. Se for o caso, deve-se também adaptar a tabela. Além disso, há uma limitação que faz com que os caracteres a partir de 250 não sejam exibidos. Isso é uma limitação de firmware, não de hardware. A solução dada no texto do mt13x9 Group é modificar a fonte de exibição, colocando os caracteres 250 a 255 no lugar dos caracteres 0 a 5, e incluir isso na tabela de conversão. 250-0, 251-1, e assim por diante.
No caso do DV397H, tive muito sorte, pois nada disso precisou ser feito! A fonte para nomes de arquivos é a de número 14. Inicialmente, essa fonte era muito limitada em termos de caracteres. Uma mistura de caracteres latinos com cirílicos, eu acho. Como não era CP1252 (e nem possuía qualquer acento) a tabela de conversão não serviria de nada. Quando a troquei pela fonte que está na posição 1, começaram a aparecer os caracteres acentuados nas ID3 tags imediatamente, mas não nos nomes de arquivos. Aí, como relatei num post anterior, modifiquei aquele filtro diferente no ARM (que limitava acima de #80, trocando por #FE = 254) e achei que tudo estava certo...
Até o allanzin relatar que o "ú" não aparecia. Verifiquei que nos nomes de arquivos, todos os caracteres a partir de 250 não eram exibidos. Mas nas tags ID3, somente o 250 não era (de 251 a 254 eram). A nova fonte 14 (igual a fonte 1), não é CP1252, mas é compatível com ISO 8859-1. No lugar dos caracteres de controle, foram repetidos alguns caracteres do próprio ISO. Além disso, possui caracteres acima de 255 (mas inúteis até agora).
Então fui verificar no ARM aquela rotina do filtro e vi que já havia uma tentativa mal sucedida de converter os caracteres Unicode e de exibir os acima de 250.
ROM:0002C53E ; processa nomes de arquivos no filebrowser
ROM:0002C53E
ROM:0002C53E sub_2C53E ; CODE XREF: sub_297F0+38E_p
ROM:0002C53E ; sub_297F0+41C_p ...
ROM:0002C53E F8 B5 PUSH {R3-R7,LR}
ROM:0002C540 0C 1C ADDS R4, R1, #0
ROM:0002C542 8D 49 LDR R1, =SHAREMEM_ADDR
ROM:0002C544 15 1C ADDS R5, R2, #0
ROM:0002C546 5D 22 MOVS R2, #0x5D ; ']'
ROM:0002C548 09 68 LDR R1, [R1]
ROM:0002C54A 92 01 LSLS R2, R2, #6
(..............................)
(..............................)
(..............................)
ROM:0002C584
ROM:0002C584 loc_2C584 ; CODE XREF: sub_2C53E+2C_j
ROM:0002C584 ; sub_2C53E+38_j
ROM:0002C584 01 0A LSRS R1, R0, #8
ROM:0002C586 03 D1 BNE loc_2C590
ROM:0002C588 80 28 CMP R0, #0x80 ; 'Ç' ; filtro caracteres acima de #80 (certeza)
ROM:0002C588 ; trocar por #FF
ROM:0002C58A F7 D3 BCC loc_2C57C ; alterar para BLS loc_2C59E (08 D9)
ROM:0002C58C 13 1C ADDS R3, R2, #0
ROM:0002C58E 7C E0 B loc_2C68A
ROM:0002C590 ; ---------------------------------------------------------------------------
ROM:0002C590
ROM:0002C590 loc_2C590 ; CODE XREF: sub_2C53E+48_j
ROM:0002C590 FC F7 98 FA BL sub_28AC4
ROM:0002C594 00 04 LSLS R0, R0, #0x10
ROM:0002C596 00 0C LSRS R0, R0, #0x10
ROM:0002C598 01 D1 BNE loc_2C59E
ROM:0002C59A 5F 20 MOVS R0, #0x5F ; '_'
ROM:0002C59C 01 E0 B loc_2C5A2
ROM:0002C59E ; ---------------------------------------------------------------------------
ROM:0002C59E
ROM:0002C59E loc_2C59E ; CODE XREF: sub_2C53E+5A_j
ROM:0002C59E FA 28 CMP R0, #0xFA ; '·' Tratar caracteres a partir de 250
ROM:0002C5A0 03 D2 BCS loc_2C5AA
ROM:0002C5A2
ROM:0002C5A2 loc_2C5A2 ; CODE XREF: sub_2C53E+5E_j
ROM:0002C5A2 ; sub_2C53E+82_j
ROM:0002C5A2 33 78 LDRB R3, [R6]
(........................)
(........................)
(........................)
Em #2C59E, há um tratamento para caracteres a partir de 250 (ou seja, não é uma limitação de hardware, é erro de programação do firmware mesmo e aqui temos uma tentativa de correção feita de "fábrica"), mas essa chamada só era realizada em certas condições (outras fontes, outros CPs, não sei ao certo). Então eu desviei para esse tratamento a partir do filtro, em #2C588, caso o caracter seja igual ou menor que 255. Pronto! Funcionou. Como a nova fonte 14, até a posição 255, é compatível com o ISO 8859-1 (e não CP1252), alguns poucos caracteres esquisitos ficaram de fora, mas nada que atrapalhe a acentuação em português ou espanhol. Ainda tentei deixar passar todos os caracteres para ver se eram mostrados, mas nada é exibido, apesar da fonte ter mais que 255 caracteres. Isso poderia ser feito, se entendêssemos mais a parte do ARM que manipula as fontes, o que seria útil para implementar o itálico (como o ARM tem 32 bits, o conteúdo de seus registradores não são bytes, mas palavras de 4 bytes; um caracter Unicode tem seu código carregado normalmente em R0 no trecho #2C588; é possível fazer, por exemplo, CMP R0, #0x3000).
Com as tags ID3, foi ainda mais fácil. Já estava funcionando quase 100%. Só o "ú" não era mostrado. Além disso, os caracteres Uncode presentes no CP1252 eram convertidos, conforme as convenções usuais, segundo a Wikipedia. Por exemplo, o raro caracter francês "Œ" é usualmente convertido para "OE" quando se trabalha com 8859-1. Mas e o "ú"? O "ú" não era exibido por causa de um bug na rotina responsável pela exibição das ID3 tags (e também dos nomes no filebrowser, já que ela chama a rotina anterior).
ROM:0003D7C6 ; exibe nome de arquivos filebrowser e ID3 tags
ROM:0003D7C6
ROM:0003D7C6 sub_3D7C6 ; CODE XREF: sub_29CE2+302_p
ROM:0003D7C6
ROM:0003D7C6 var_38 = -0x38
ROM:0003D7C6 var_34 = -0x34
ROM:0003D7C6 var_30 = -0x30
ROM:0003D7C6 var_2C = -0x2C
ROM:0003D7C6 var_28 = -0x28
ROM:0003D7C6 var_24 = -0x24
ROM:0003D7C6 var_20 = -0x20
ROM:0003D7C6 var_1C = -0x1C
ROM:0003D7C6 var_18 = -0x18
ROM:0003D7C6
ROM:0003D7C6 F0 B5 PUSH {R4-R7,LR}
ROM:0003D7C8 81 78 LDRB R1, [R0,#2]
ROM:0003D7CA 89 B0 SUB SP, SP, #0x24
ROM:0003D7CC 00 AB ADD R3, SP, #0x38+var_38
ROM:0003D7CE 46 78 LDRB R6, [R0,#1]
ROM:0003D7D0 19 76 STRB R1, [R3,#0x38+var_20]
ROM:0003D7D2 C1 78 LDRB R1, [R0,#3]
ROM:0003D7D4 59 76 STRB R1, [R3,#0x38+var_20+1]
ROM:0003D7D6 01 79 LDRB R1, [R0,#4]
ROM:0003D7D8 99 76 STRB R1, [R3,#0x38+var_20+2]
ROM:0003D7DA 41 79 LDRB R1, [R0,#5]
ROM:0003D7DC D9 76 STRB R1, [R3,#0x38+var_20+3]
(..................)
(..................)
(..................)
ROM:0003D86E
ROM:0003D86E loc_3D86E ; CODE XREF: sub_3D7C6+96_j
ROM:0003D86E ; sub_3D7C6+A0_j
ROM:0003D86E 20 78 LDRB R0, [R4]
ROM:0003D870 FA 28 CMP R0, #0xFA ; '·' ; pequeno bug na exibicao de caracteres
ROM:0003D870 ; nas id3 tags, que impede mostrar "ú"
ROM:0003D870 ; deve ser #F9 e nao #FA!
ROM:0003D872 06 D9 BLS loc_3D882
ROM:0003D874 1C 49 LDR R1, =unk_9AE61
ROM:0003D876 FA 38 SUBS R0, #0xFA ; '·'
ROM:0003D878 0B 78 LDRB R3, [R1]
ROM:0003D87A 00 04 LSLS R0, R0, #0x10
ROM:0003D87C 00 0C LSRS R0, R0, #0x10
(...................)
(...................)
(...................)
Oras, em #3D870, só se fazia o tratamento dos caracteres se não fossem menores ou
iguais a #FA (250) = "ú". Assim, o "ú" não entrava. Ou tinha que ser menor que #FA ou menor e igual a #F9!
Essas rotinas são idênticas nos dois modelos de DV397H. Assim, a exibição dos caracteres no filebrowser e nas tags ID3 foi melhorada nos dois.
Correções no alinhamentoEu ainda não verifiquei as rotinas do DV397H com chip MT1389M, e acho que são diferentes. Mas talvez, nessa parte, sejam semelhantes em alguma coisa.
Bom, o DV397H MT1389S já é capaz de exibir, originalmente, até 4 linhas de legenda. Mas isso é feito por uma rotina que é capaz de exibir 1 ou 2 linhas de legendas e mais 2 remendos que adicionam a terceira e a quarta linha. Sim, "remendos", porque tudo indica que, inicialmente, só eram exibidas até 2 linhas e, aí, remendaram de "fábrica", e 2 vezes! O resultado foi que, em cada uma dessas partes, o alinhamento era calculado com um argumento diferente. E ainda, na parte principal, no núcleo, digamos assim, a posição da primeira linha variava conforme tivéssemos 1 ou 2 linhas. Ou seja, era um carnaval de linhas dançantes para cima e para baixo, fazendo alinhamentos meio esquisitos. Podíamos classificar o alinhamento apenas como mais ou menos inferior e mais ou menos superior. Nem mesmo middle-top e middle-bottom serviam para classificá-lo corretamente, pois com 4 linhas as coisas mudavam.
ROM:00040348 ; =============== S U B R O U T I N E =======================================
ROM:00040348
ROM:00040348 ;exibe legendas
ROM:00040348
ROM:00040348 sub_40348 ; CODE XREF: sub_408FC:loc_4092E_p
ROM:00040348
ROM:00040348 var_68 = -0x68
ROM:00040348 var_64 = -0x64
ROM:00040348 var_60 = -0x60
ROM:00040348 var_5C = -0x5C
ROM:00040348 var_58 = -0x58
ROM:00040348 var_54 = -0x54
ROM:00040348 var_4C = -0x4C
ROM:00040348 var_48 = -0x48
ROM:00040348 var_44 = -0x44
ROM:00040348 var_42 = -0x42
ROM:00040348 var_40 = -0x40
ROM:00040348 var_3C = -0x3C
ROM:00040348 var_38 = -0x38
ROM:00040348 var_34 = -0x34
ROM:00040348 var_30 = -0x30
ROM:00040348 var_2C = -0x2C
ROM:00040348 var_28 = -0x28
ROM:00040348 var_24 = -0x24
ROM:00040348 var_20 = -0x20
ROM:00040348 var_1C = -0x1C
ROM:00040348 var_18 = -0x18
ROM:00040348
ROM:00040348 35 48 LDR R0, =unk_9AE62
ROM:0004034A F0 B5 PUSH {R4-R7,LR}
ROM:0004034C 03 78 LDRB R3, [R0]
ROM:0004034E 95 B0 SUB SP, SP, #0x54
ROM:00040350 34 49 LDR R1, =SHAREMEM_ADDR
ROM:00040352 02 93 STR R3, [SP,#0x68+var_60]
ROM:00040354 08 68 LDR R0, [R1]
ROM:00040356 BB 22 52 01 MOVLS R2, 0x1760
ROM:0004035A 82 18 ADDS R2, R0, R2
ROM:0004035C 12 78 LDRB R2, [R2]
ROM:0004035E 00 2A CMP R2, #0
ROM:00040360 01 D1 BNE loc_40366
ROM:00040362 04 22 MOVS R2, #4
ROM:00040364 00 E0 B loc_40368
(......................)
(......................)
(......................)
ROM:000404F0
ROM:000404F0 loc_404F0 ; CODE XREF: sub_40348+12C_j
ROM:000404F0 ; sub_40348+136_j
ROM:000404F0 00 2E CMP R6, #0 ; alterando para 01 2E, última linha fica deslocada
ROM:000404F0 ; (igual outros LGs?)
ROM:000404F2 3E D0 BEQ loc_40572
(.............................)
(.............................)
(.............................)
ROM:0004067A
ROM:0004067A loc_4067A ; CODE XREF: sub_40348+304_j
ROM:0004067A 73 4D LDR R5, =unk_9EB88
ROM:0004067C 00 AB ADD R3, SP, #0x68+var_68
ROM:0004067E 28 88 LDRH R0, [R5]
ROM:00040680 03 99 LDR R1, [SP,#0x68+var_5C]
ROM:00040682 75 4E LDR R6, =unk_9E614
ROM:00040684 40 18 ADDS R0, R0, R1
ROM:00040686 98 84 STRH R0, [R3,#0x68+var_44]
ROM:00040688 F0 78 LDRB R0, [R6,#3]
ROM:0004068A 01 28 CMP R0, #1 ; 2 linhas?
ROM:0004068C 0E D8 BHI loc_406AC ; se maior
ROM:0004068E 73 48 LDR R0, =SHAREMEM_ADDR
ROM:00040690 BB 21 MOVS R1, #0xBB ; '+'
ROM:00040692 00 68 LDR R0, [R0]
ROM:00040694 49 01 LSLS R1, R1, #5
ROM:00040696 40 18 ADDS R0, R0, R1
ROM:00040698 00 78 LDRB R0, [R0]
ROM:0004069A 01 28 CMP R0, #1
ROM:0004069C 02 D1 BNE loc_406A4
ROM:0004069E D8 8C LDRH R0, [R3,#0x68+var_42]
ROM:000406A0 38 30 ADDS R0, #0x38 ; '8' ; deslocamento legenda 1 e 2 linhas
ROM:000406A2 14 E0 B loc_406CE
ROM:000406A4 ; ---------------------------------------------------------------------------
ROM:000406A4
ROM:000406A4 loc_406A4 ; CODE XREF: sub_40348+354_j
ROM:000406A4 00 AB ADD R3, SP, #0x68+var_68
ROM:000406A6 D8 8C LDRH R0, [R3,#0x68+var_42]
ROM:000406A8 30 30 ADDS R0, #0x30 ; '0'
ROM:000406AA 10 E0 B loc_406CE
ROM:000406AC ; ---------------------------------------------------------------------------
ROM:000406AC
ROM:000406AC loc_406AC ; CODE XREF: sub_40348+344_j
ROM:000406AC 02 28 CMP R0, #2 ; 3 linhas?
ROM:000406AE 10 D1 BNE loc_406D2 ; se não
ROM:000406B0 6A 48 LDR R0, =SHAREMEM_ADDR
ROM:000406B2 BB 21 MOVS R1, #0xBB ; '+'
ROM:000406B4 00 68 LDR R0, [R0]
ROM:000406B6 49 01 LSLS R1, R1, #5
ROM:000406B8 40 18 ADDS R0, R0, R1
ROM:000406BA 00 78 LDRB R0, [R0]
ROM:000406BC 01 28 CMP R0, #1
ROM:000406BE 03 D1 BNE loc_406C8
ROM:000406C0 00 AB ADD R3, SP, #0x68+var_68
ROM:000406C2 D8 8C LDRH R0, [R3,#0x68+var_42]
ROM:000406C4 1C 30 ADDS R0, #0x1C ; deslocamento legenda 3 linhas
ROM:000406C6 02 E0 B loc_406CE
ROM:000406C8 ; ---------------------------------------------------------------------------
ROM:000406C8
ROM:000406C8 loc_406C8 ; CODE XREF: sub_40348+376_j
ROM:000406C8 00 AB ADD R3, SP, #0x68+var_68
ROM:000406CA D8 8C LDRH R0, [R3,#0x68+var_42]
ROM:000406CC 18 30 ADDS R0, #0x18
ROM:000406CE
ROM:000406CE loc_406CE ; CODE XREF: sub_40348+35A_j
ROM:000406CE ; sub_40348+362_j ...
ROM:000406CE 00 AB ADD R3, SP, #0x68+var_68
ROM:000406D0 D8 84 STRH R0, [R3,#0x68+var_42]
ROM:000406D2
ROM:000406D2 loc_406D2 ; CODE XREF: sub_40348+366_j
ROM:000406D2 20 1C ADDS R0, R4, #0
ROM:000406D4 FF 30 ADDS R0, #0xFF
ROM:000406D6 04 9A LDR R2, [SP,#0x68+var_58]
ROM:000406D8 00 06 LSLS R0, R0, #0x18
ROM:000406DA 00 0E LSRS R0, R0, #0x18
ROM:000406DC 02 9B LDR R3, [SP,#0x68+var_60]
ROM:000406DE 1E 32 ADDS R2, #0x1E ; distancia entre linhas
ROM:000406E0 00 25 MOVS R5, #0
ROM:000406E2 5F 49 LDR R1, =unk_9E868
ROM:000406E4 01 33 ADDS R3, #1
ROM:000406E6 0F 93 STR R3, [SP,#0x68+var_2C]
ROM:000406E8 11 92 STR R2, [SP,#0x68+var_24]
ROM:000406EA 10 90 STR R0, [SP,#0x68+var_28]
ROM:000406EC 0E 91 STR R1, [SP,#0x68+var_30]
ROM:000406EE C1 E0 B loc_40874
ROM:000406F0 ; ---------------------------------------------------------------------------
ROM:000406F0
ROM:000406F0 loc_406F0 ; CODE XREF: sub_40348+5AA_j
ROM:000406F0 59 48 LDR R0, =unk_9E614
ROM:000406F2 59 4A LDR R2, =unk_9E614
ROM:000406F4 00 79 LDRB R0, [R0,#4]
ROM:000406F6 0C 32 ADDS R2, #0xC
ROM:000406F8 11 5C LDRB R1, [R2,R0]
ROM:000406FA A9 42 CMP R1, R5
ROM:000406FC 4F D1 BNE loc_4079E
ROM:000406FE 0E 99 LDR R1, [SP,#0x68+var_30]
ROM:00040700 00 AB ADD R3, SP, #0x68+var_68
ROM:00040702 49 78 LDRB R1, [R1,#1]
ROM:00040704 50 4E LDR R6, =unk_9EB88
ROM:00040706 D9 8C LDRH R1, [R3,#0x68+var_42] ; posicao linha anterior
ROM:00040708 11 9A LDR R2, [SP,#0x68+var_24] ; distancia entre linhas
ROM:0004070A 89 18 ADDS R1, R1, R2 ; atualiza posicao
ROM:0004070C D9 84 STRH R1, [R3,#0x68+var_42]
ROM:0004070E D9 8C LDRH R1, [R3,#0x68+var_42]
ROM:00040710 F2 88 LDRH R2, [R6,#6]
ROM:00040712 1D 31 ADDS R1, #0x1D
ROM:00040714 91 42 CMP R1, R2
ROM:00040716 71 DC BGT loc_407FC
ROM:00040718 71 7A LDRB R1, [R6,#9]
ROM:0004071A C9 07 LSLS R1, R1, #0x1F
ROM:0004071C 35 D5 BPL loc_4078A
ROM:0004071E 4E 4E LDR R6, =unk_9E614
ROM:00040720 F1 78 LDRB R1, [R6,#3]
ROM:00040722 01 39 SUBS R1, #1
ROM:00040724 88 42 CMP R0, R1
ROM:00040726 15 DA BGE loc_40754
(.........................)
(.........................)
(.........................)
Primeiro, ressalto que deixei aparecendo um trecho em que alterei o valor do CMP e as linhas da legenda ficaram horizontalmente deslocadas, como acontece na maioria dos LGs. De repente, naqueles modelos podemos ter um bug desse tipo que precisa ser corrigido. Verifiquem.
Em #4068A, é verificado se a legenda tem mais de duas linhas (CMP R0, #1). Se não tiver, impõe-se um deslocamento de #38 (#406A0 ADDS R0, #0x38) ou #30 (#406A8 ADDS R0, #0x30), devido a uma condição ainda obscura (na verdade, depois de vários testes, aparentemente o lado do deslocamento de #30 nunca é executado). Caso contrário, se for mais de 2 linhas, calculam-se deslocamentos diferentes, dependendo de ter ou não mais de 3 linhas, o que é verificado em #406AC.
Vai ser um pouco difícil de explicar agora. A melhor forma de entender é seguir no IDA as modificações que eu fiz no código ARM. Tentei ir acertando os valores (se forem iguais, não resolve) dos casos em que temos 1 linha e em que temos 3 linhas, até visualmente ficarem alinhados ao caso com 4 linhas (eu alinhei a exibição de 1 linha com a exibição de 4 linhas e depois a exibição de 3 linhas com a exibição de 4 linhas também, deixando tudo alinhado, primeiro superiormente). Fiz vários testes até conseguir. Além disso, tem que se ter deslocamentos diferentes para quando o alinhamento é inferior e para quando é superior. Então, depois tive que fazer novamente o acerto do deslocamento, mas para o alinhamento inferior. Anotei os valores de ambos, pois iria precisar fazer um condicional para cada tipo de alinhamento.
Para resolver isso, cavei espaço dentro do próprio código da rotina. Usando a condição obscura relatada anteriormente. Por exemplo, para até 2 linhas, tínhamos o seguinte:
ROM:0004069A 01 28 CMP R0, #1 ; condicao nao identificada
ROM:0004069C 02 D1 BNE loc_406A4
ROM:0004069E D8 8C LDRH R0, [R3,#0x68+var_42]
ROM:000406A0 38 30 ADDS R0, #0x38 ; '8' ; deslocamento legenda 1 e 2 linhas
ROM:000406A2 14 E0 B loc_406CE
ROM:000406A4 ; ---------------------------------------------------------------------------
ROM:000406A4
ROM:000406A4 loc_406A4 ; CODE XREF: sub_40348+354_j
ROM:000406A4 00 AB ADD R3, SP, #0x68+var_68
ROM:000406A6 D8 8C LDRH R0, [R3,#0x68+var_42]
ROM:000406A8 30 30 ADDS R0, #0x30 ; '0'
ROM:000406AA 10 E0 B loc_406CE
Assim, aproveitei essa parte para modificá-la e fazer a condição do alinhamento: se for inferior, segue um lado, se for superior, segue o outro (verificar no IDA como ficou o novo código). E depois de fazer a mesma modificação na parte que trata a legenda com 3 linhas, ficou quase tudo certo. Só restava um pequeno problema no alinhamento inferior, para os casos em que tínhamos 1 linha ou 2 linhas (no alinhamento superior ficava tudo certo, mas no inferior, somente quando havia 2 linhas, desalinhava um pouco, apesar de 1 linha ficar alinhada). A parte responsável por dividir a legenda em 1 ou 2 linhas é outra, como disse antes. Ela está na rotina que identifiquei como sendo a SUB_CalcStartPosY relatada nos documentos do mt13x9 Group e fazia um deslocamento estranho quando tínhamos o alinhamento inferior. Quando havia 2 linhas, deslocava a posição da primeira linha em meia linha acima, dando um ar de centralizado (quando tínhamos apenas uma linha, esta era exibida exatamente no centro de quando tínhamos 2 linhas). Identifiquei o trecho responsável por esse pequeno deslocamento e o eliminei:
ROM:0003FDA4 SUB_CalcStartPosY__sub_3FDA4 ; CODE XREF: sub_40348+23E_p
ROM:0003FDA4 F8 B5 PUSH {R3-R7,LR}
ROM:0003FDA6 AD 49 LDR R1, =unk_9EB88
ROM:0003FDA8 4E 88 LDRH R6, [R1,#2]
ROM:0003FDAA 89 7A LDRB R1, [R1,#0xA] ; opcao de alinhamento
ROM:0003FDAC C9 07 LSLS R1, R1, #0x1F
ROM:0003FDAE 44 D5 BPL loc_3FE3A
ROM:0003FDB0 04 1C ADDS R4, R0, #0
ROM:0003FDB2 01 25 MOVS R5, #1
ROM:0003FDB4 A8 4F LDR R7, =unk_A4E70
ROM:0003FDB6 16 E0 B loc_3FDE6
(......................)
(......................)
(......................)
ROM:0003FE1C 47 88 LDRH R7, [R0,#2]
ROM:0003FE1E C0 7A LDRB R0, [R0,#0xB] ; alterar para valor fixo que seja suficiente,
ROM:0003FE1E ; exemplo, MOV R0, #0x1A (posicao primeira linha alinhamento inferior)
ROM:0003FE20 C9 1B SUBS R1, R1, R7
ROM:0003FE22 00 19 ADDS R0, R0, R4
ROM:0003FE24 11 F0 62 FD BL sdiv
ROM:0003FE28 00 06 LSLS R0, R0, #0x18
ROM:0003FE2A 00 0E LSRS R0, R0, #0x18
ROM:0003FE2C A8 42 CMP R0, R5
ROM:0003FE2E 04 D9 BLS loc_3FE3A
ROM:0003FE30 40 1B SUBS R0, R0, R5 ; deslocamento incorreto
ROM:0003FE30 ; alinhamento inferior: substituir por 00 00 (NOP)
ROM:0003FE32 60 43 MULS R0, R4
Eu cheguei a falar, em posts anteriores, do bug que impedia a seleção do alinhamento inferior. Como a distância entre linhas não era repassada pelo 8032, então o valor da posição inicial (primeira linha) estava bugado. É isso o que está comentado em #3FE1E. Além disso, a rotina só é executada no caso da opção de alinhamento ser inferior, devido ao salto em #3FDAE, no início da rotina, que é executado se o alinhamento for superior. Seguindo a rotina, o bug do deslocamento no alinhamento inferior está em #3FE30.
E, para fechar, o bug da fonte 13.A fonte 13 é a fonte que ficava duplicada anteriormente, pois as duas últimas escolhas de código de caracteres compartilhavam a mesma fonte. No 8032, eu eliminei a última escolha. Mas essa fonte deveria receber um tratamento diferente, dependendo do código de caracteres escolhido. Olhando no ARM, descobri onde isso é feito. Depois, ao testar a legenda, verifiquei que nem todos os caracteres realmente estavem sendo exibidos na fonte que deixei.
Zeurt, verifica isso também, pois pode acontecer o mesmo no DV256K.
ROM:0003FB56 ; le caracteres da legenda (jah processados)
ROM:0003FB56
ROM:0003FB56 sub_3FB56 ; CODE XREF: sub_3FB7A+20_p
ROM:0003FB56 ; sub_3FB7A+36_p ...
ROM:0003FB56 42 49 LDR R1, =unk_9AE62
ROM:0003FB58 09 78 LDRB R1, [R1]
ROM:0003FB5A 14 29 CMP R1, #0x14 ; se fonte 13, tratamento especial
ROM:0003FB5C 09 D1 BNE loc_3FB72 ; trocar por 09 E0 (B)
ROM:0003FB5E 41 49 LDR R1, =SHAREMEM_ADDR
ROM:0003FB60 41 4A LDR R2, =loc_1770
ROM:0003FB62 09 68 LDR R1, [R1]
ROM:0003FB64 89 18 ADDS R1, R1, R2
ROM:0003FB66 89 7B LDRB R1, [R1,#0xE]
ROM:0003FB68 01 29 CMP R1, #1
ROM:0003FB6A 02 D1 BNE loc_3FB72
ROM:0003FB6C 3F 49 LDR R1, =unk_9E624
ROM:0003FB6E 08 5C LDRB R0, [R1,R0]
ROM:0003FB70 70 47 BX LR
ROM:0003FB72 ; ---------------------------------------------------------------------------
(................)
(................)
(................)
É só trocar #09 #D1 por #09 #E0 em #3FB5C (trocar o BNE por B normal) que tudo se resolve. Essa é a rotina que lê o buffer onde estão guardados os caracteres do trecho atual da legenda. Eu cheguei nela pois estou procurando uma forma de exibir os itálicos. Esse buffer, aparentemente, já está com as tags itálicas cortadas. Isso quer dizer que outra rotina é que processa isso antes. Mas ainda não consegui achar nada que preencha esse buffer ainda.
Usando esse endereço de memória que guarda o valor da fonte, cheguei a fazer um trecho que alterava o espaçamento entre linhas de acordo com a fonte escolhida. Assim, pude diminuir o espaçamento da legenda original para o seu valor default. Porém, depois que encontrei os trechos responsáveis pelos alinhamentos das linhas, vi que iria precisar fazer mais uma condição para acertar cada alinhamento (dependendo não só do tipo de alinhamento, mas também da fonte, os deslocamentos seriam outros). Aí, preferi eliminar de vez a fonte original.
E em pensar que tudo isso foi fruto da busca pelo itálico....
