Tabelas
De ROMHackingWiki
| Este artigo é somente um esboço e seu conteúdo ainda pode ser melhorado. Você pode ajudar a ROMHackingWiki melhorando-o. |
| Este é um artigo introdutório sobre o ROMHacking, leia-o com bastante atenção! |
Tabela de conteúdo |
Introdução
 |
Computadores, diferente de nós, não entendem caracteres ou letras dos nossos alfabetos, tudo o que eles entendem são bits. Em geral, os processadores só lidam mais com conjuntos de 8 bits, formando 1 byte. Um bit pode assumir dois valores, 0 ou 1. Um byte, por sua vez, pode assumir valores de 0 até 255. Por facilidade, e para manter o tamanho fixo de 2 dígitos, é usado o sistema hexadecimal para representar esses valores: 00h a FFh. Por conveniência, foram definidas tabelas padrões de caracteres e adotadas pelos sistemas mais usados. Esses padrões não fazem mais do que associar um valor a um caractere (letra) que possa ser lido ou que tenha alguma função especial. Como exemplo: A = 3Eh Neste exemplo, sempre que o computador souber que está lendo algum texto e achar o valor 3Eh ele irá exibir o caractere 'A' e assim por diante. |
Uma tabela de caracteres contém os valores de cada caractere da respectiva ROM.
O editor hexadecimal, precisa de um arquivo de tabela, que informe o que significa cada código, logo o jeito de entender o que tem na rom em forma de texto, é usando um arquivo de tabela.
O principal motivo da criação de uma tabela é para que possamos trabalhar com textos em uma ROM, ou seja, visualizá-los, editá-los ou até mesmo extraí-los e reinserí-los através de programa externo.
Aplicação no ROMHacking
A tabela usada no ROMHacking exerce a mesma função, porém, não há nenhum padrão específico definindo a tabela, geralmente a tabela varia de jogo para jogo dependendo apenas da forma como foi criado, e por isto, foi criado um padrão para a criação de tabelas de caracters em um arquivo de texto e que possa ser entendido por editores hexadecimais. Um arquivo de texto que siga esse padrão é chamado de tabela e possui a extensão .tbl;
Os dados estão organizados da seguinte maneira:
<valor do byte>=<caractere a ser representado>
Deve ser específicado uma entrada POR LINHA e o <valor do byte> DEVE ser específicado como hexadecimal, caso isso não seja feito, erros ocorrerão.
Por Exemplo:
01=A
02=B
...
Logo, onde aparecer byte 01h na ROM irá aparecer o caractere “A” na tela e de forma semelhante onde estiver o 02h aparecerá o caractere “B”. O principal motivo da criação de uma tabela é para que possamos trabalhar com textos em uma ROM usando um editor hexadecimal, ou seja, visualizá-los, editá-los ou até mesmo extraí-los e reinserí-los através de programa externo.
Em geral, os textos em jogos seguem o padrão de codificação: ASCII, mas existem muitos outros, tais como: ASCII Extendido, Unicode, EUC, JIS, iso-8859-1 e etc, mas também nada impede de que o fabricante do jogo faça a sua própria codificação. Caso o padrão da ROM seja o ASCII, será possível ver seus textos no editor hexadecimal sem a necessidade do uso de tabelas, caso contrário provavelmente você precisará criar uma.
Tipos de Tabela
Tabelas de 8 bits
São usados apenas dois dígitos hexadecimais para representar o valor da entrada, esses caracteres serão lidos como apenas 1 byte:
01=A
02=B
Aqui, o texto 01 será lido como 01h e o 02 como 02h, como cada entrada usa apenas 1 byte e um byte possui 8 bits, tabelas que contém somente este tipo de entrada é normalmente chamada de tabela de 8 bits. Quando somente o termo tabela é usado, geralmente é no sentido de que seja uma tabela comum de 8 bits.
Tabelas de 16 bits
Seguindo a mesma linha de pensamento das tabelas de 8 bits, a única diferença nas tabelas de 16 é que seus valores ao invés de serem representados por um byte são por 2:
0201=A
0203=B
0305=9
Aqui, o texto 0201 e os outros, serão lidos como dois bytes de valores 02h e 01h, sempre que esses dois bytes forem encontrados nessa seqüência na ROM, ela será substituida pelo valor que representa.
Tabelas Mistas
São tabelas que possuem ambos os tipos de entrada:
01=A
0201=1
0305=#
Sintaxe Padrão
Por influência de dois grandes editores hexadecimais, hoje existem alguns padrões usados em tabelas:
Thingy:
Caractere de nova linha: *XX Fim do bloco de texto: /XX
Hexposure:
Caractere de nova linha: *=XX Fim do bloco de texto: /=XX Fim de uma seqüência: \=XX
Codificações
Codificação ASCII
Enquanto a Microsoft utilizava, por exemplo, o código hexadecimal AF para representar o caractere "A", a IBM utilizava o FA, e isso gerava problema quando um software lia um documento gerado em outro software. Então, foi definido um padrão de caracteres para que todos pudessem se comunicar entre si sem problemas. A codificação ASCII foi feita para que os símbolos de comunicação (caracteres) tivessem um padrão nacional (nos Estados Unidos da América). Todo caractere é associado a um byte, ou seja, um número de 0 a 255 no sistema decimal. Esse número, obviamente, poderia ser representado em binário de 00000000 a 11111111, ou em hexadecimal de 00 a FF. Contudo, o padrão só definiu 128 deles.
Restrições do ASCII
Bem, como nem tudo é perfeito, o ASCII tinha problemas. Um problema foi justamente a sua deixa: os 128 caracteres inexistentes. Com o tempo, as empresas foram adicionando esses caracteres, mas cada uma por si. Esses caracteres novos ou eram letras que não existem em inglês, mas em outros idiomas (vogais acentuadas ou letras gregas, por exemplo), ou eram símbolos gráficos para auxiliar a confecção de interfaces gráficas em programas no console. Como exemplo da despadronização global, podemos tomar o [1] e o 850. O primeiro é também conhecido como ASCII extendido e foi usado no IBM DOS e OS/2; já o segundo foi usado no MS-DOS. Sendo ambos derivados do ASCII, mantém os mesmos 128 caracteres. O problema eram os 128 valores restantes (de 128 a 255). Um caso de diferença a citar é o byte com valor E0h, que no OEM-US representa o α (letra grega alfa), mas no OEM-850 representa Ó (letra o maiúsculo com acento agudo). Ou seja, pobre do programa que devia exibir o conteúdo do arquivo: ele tinha que saber qual era a codificação usada no arquivo para poder exibí-lo direito. Na época (e até hoje), contudo, a maioria dos softwares assumem um padrão e pronto: o exibem daquele jeito. É óbvio que isso causava erros. Quem nunca recebeu SMS de celular com coisas esquisitas quando alguém escrevia acentos?
Outro problema do ASCII é sua limitação: mesmo nas diferentes versões extendidas, 256 caracteres não era suficiente para todos os gráficos desejados e também não dava para representar as letras de outros idiomas. Imaginem o japonês: são três alfabetos, sendo um deles com mais de 6000 caracteres distintos. Claro que os japoneses utilizaram e utilizam uma codificação diferente para eles, mas mesmo assim não são poucas: JIS, Shift-JIS e EUC-JP são alguns exemplos. O MS-Windows japonês usa (ou usava?) Shift-Jis por padrão.
Codificação Unicode
Para compensar a restrição do número de caracteres representáveis, foi criado o Unicode.
Existem hoje alguns tipos de codificação UNICODE, como o UTF-8, o UTF-16 e o UTF-32.
- UTF-8: É a codificação que utiliza 8 bits, mas pode representar os demais caracteres através da formação de unidades de código com o tamanho de até 4 bytes.
- UTF-16: É a codificação que utiliza 16 bits de dados.
- UTF-32: É a codificação que utiliza 32 bits de dados
Considerações Finais
Mas, afinal, por que fazer tabelas? Essa é uma pergunta muito fácil de se responder. Bem, digamos que a ROM que você está traduzindo esteja com os seus caracteres codificados em ASCII. Até aí tudo bem, não há tanta necessidade assim de se fazer uma tabela porque quase todo romhacker e editor hexadecimal sabe a codificação ASCII, não é verdade? Mas aí vem um problema: e se a codificação da ROM estiver em outra forma? Bem, em ASCII até que com uma boa memória, é possivel guardar os valores, porque são exatamente 256 caracteres possíveis. Mas e se a codificação dos caracteres for feita pela fabricante do jogo? Você conseguiria advinhar quais seriam os caracteres? É por isso que existem as tabelas, para que elas possam auxiliar na localização e visualização dos caracteres das ROMs. Uma vez com uma tabela feita, é possível usá-la em editores hexadecimais para visualizar de forma legível os textos do jogo e não apenas conjuntos de bytes com valores diferenciados. Também com o conjunto editor hexadecimal e uma tabela é possivel extrair o que chamamos de scripts, onde o editor extrai os textos no formato padrão para ser lido em qualquer editor de textos.
