Preciso de exercicios em compressão de roms de qualquer sistema?

Iniciado por MachineMX, Novembro 16, 2016, 18:45:09 PM

tópico anterior - próximo tópico

0 Membros e 1 Visitante estão vendo este tópico.

Ondinha

Segundo o GBATEK, a ROM inicia em 0x8000000:

External Memory (Game Pak)
  08000000-09FFFFFF   Game Pak ROM/FlashROM (max 32MB) - Wait State 0
  0A000000-0BFFFFFF   Game Pak ROM/FlashROM (max 32MB) - Wait State 1
  0C000000-0DFFFFFF   Game Pak ROM/FlashROM (max 32MB) - Wait State 2
  0E000000-0E00FFFF   Game Pak SRAM    (max 64 KBytes) - 8bit Bus width
  0E010000-0FFFFFFF   Not used


Mas entenda: A imagem do jogo desconsidera o mapeamento da memória, logo, o endereço inicial da ROM é 0x0 e não 0x8000000, sendo assim, como o endereço capturado considera o mapeamento, já que foi capturado de um emulador, é necessário subtrair o valor para poder encontrar o endereço de fato e esse princípio é aplicável a qualquer sistema.

DiegoHH

Citação de: MachineMX online Novembro 18, 2016, 19:56:37 PM
Eu vou tenta olha aonde fica armazenado e  olha tudo quanto é canto nem que seja um pequeno tilemap da apresentação do jogo qualquer coisa. Valeu denim.

Um dos planos de romhacking que tenho GBA è o BOF2, sobre as rotinas da bios havia achado algum assunto a respeito
mas li o tópico que falava, provavel que seja responsável pelos registros.
Seu arquivo ele tá aqui no site ou no repositorio?, assim que acha eu vou olha, Valeu DiegoHH

Está no github: https://github.com/RHBR/lazynds ... Recomendo ir direto pra pasta "compression" e tentar rodar o código. Foi escrito em python, basta importá-lo. No pior dos casos, serve como referência. Ali você irá encontrar todas as compressões da bios do GBA/NDS (LZ, RLE e Huffman).

Caso queira ir um passo adiante, a versão de dev do no$gba está disponível free há algum tempo. É o melhor debugger que você irá encontrar pra essa plataforma (mas também o mais complexo).
http://problemkaputt.de/gba.htm

MachineMX

#17
Ondinha

Quando o emulador lê direto da rom o assembly ele mostra o mapeamento 0x80000000, diferente do editor binario que mostra sem nenhum mapeamento.
Subtrai é tira o 0x08 ficando 0x001eed50, com o 8 0x081eed50,
Existe algum truque de algum emulador que me dá detalhes do offset dos gráficos comprimido na memoria RAM ou Memoria ROM?

DiegoHH

Eu vou conferi o seu arquivo agora, pode ser qualquer exemplo gameboy advanced, qualquer sistema, é mais pra uma lição de aprendizado em programação, aceito algoritmos de qualquer linguagem de programação
Estudo e acompanho a página wikibooks e wikipedia sempre.

denim

Se quiser eu passo um código de lz77 para o snes, além do bloco de dados comprimido.

Ondinha

Citação de: MachineMX online Janeiro 03, 2017, 10:29:27 AM
Ondinha

Quando ele considera o mapeamento, quando entro dentro da ROM em funcionamento, que mostra 0x80000000, e se procuro fora da ROM, em um editor binário ele começo pelo 0x00, subtrai qe vc fala é tira o 8, 0x001eed50, com o 8 0x081eed50, existe algum truque em algum emulador que eu consigo ver os dados do gráfico comprimido em algum memória como RAM ou VRAM ?
Olá, voltando lá na imagem, sobre a compressão Huffman do "New Game", você verá a informação:
Código (VBA Log) Selecionar

HuffUnComp, 0x081eed50, 0x06000000, VCOUNT=175

Isso basicamente é como se fosse uma função de alto nível do tipo:
Código (Python) Selecionar

def HuffUnComp(source, destination)

O source é de onde a informação comprimida em Huffman está vindo da ROM e destination é para onde ela irá ser alocada após a descompressão. Logo:
Código (Python) Selecionar

def HuffUnComp(0x081eed50, 0x06000000)

Explicando: Descomprima Huffman pegando os dados na ROM no endereço: 0x081eed50 (Área da ROM - Cartucho) e envie os dados para o endereço 0x06000000 (Área da RAM de Vídeo - VRAM), ou seja, ele está efetuando uma descompressão direto pra VRAM.

Sobre os endereços, é isso, basta subtrair o 0x08000000 que você encontrará o endereço da ROM, 0x08000000 só faz sentido quando o cartucho está acoplado no console, porque ele será uma extensão de memória do mesmo.

MachineMX

#20
Denim

Se você puder e passa o código lz77 além de bloco comprimido eu agradeceria pode ser de qualquer exemplo em linguagem de programação, o bloco do código comprimido pode me ser util pra resolve um problema de um jogo aqui.
Valeu denim.

Ondinha

Consegui entender melhor o exemplo
HuffUncomp, 0x081eed50, 0x06000000, VCOUNT=175

0x081eed50 lugar onde a informação comrimida está, no caso New Game(tinha me esquecido lá trás)
0x06000000 endereço o destino do dada descomprimido
0x081eed50  = A informação comprimida esta na Area Rom, o cartucho dentro do emulador, pra então a caminho do destino 0x06000000 o dado descomprmido se aloca na memória Ram Area de Video - VRAM
muito bem explicado Ondinha.
Sobre os endereço basta subtrair 0x08000000, mais só quando funcionando em cartucho no console, ou quando estiver dentro do jogo

Voce tinha declarado em uma função do python
def HuffUncomp, 0x081eed50, 0x06000000.

É possivel ve a informação alocada na saída em algum emulador?
Ex: o New Game em gráfico.

Ondinha

A subtração do endereço deve ser feita para visualizar a informação no PC, ou seja, quando NÃO estiver rodando no emulador/console, porque o mapeamento de memória só faz sentido lá.

Se o emulador tiver um Visualizador de VRAM (como o No$GBA), é possível ver a saída perfeitamente, no caso do Bomberman Tournament, são os Tiles OBJ que estão comprimidos em Huffman, então, quando você descomprime, provavelmente não virá apenas o "New Game", mas todo o tileset.



É fato porque o tile superior esquerdo é o equivalente ao início da VRAM: 0x06000000, logo, quando você descomprime o dado ele preenche a memória de vídeo com toda essa informação da imagem.

MachineMX

#22
Valeu Ondinha.
:torico:

Agora eu posso vê o destino dos dados da rom Family Addams Values, nesse dia eu mudei o valor de propriedade de atributos YXPCCCT onde X e Y responsável pela posição, paleta de cores,
CCC = significa bits de cores e enfim T
T = significa numero do tile, eu tentava muda o texto do new game da Family Addams Value, e consegui muda pro topo da tela, vou me empenha mais nos estudos dos ponteiros que é maior dificuldade de quem programa assembly.

Falando no seu exemplo:
Agora sim faz sentido o local aonde se aloca a informação descomprimida, eu me perdia com objeto e tilemap
Ex: a imagem que logo inicia o super mario world o tilemap Nintendo.

Agora sim bateu com o endereço no canto superior esquerdo = 0x06000000  :toligado:

denim

Bom, separei um exemplo de compressão lz77 encontrado no SNES. O jogo é o Actraiser.

Isolei a rotina de descompressão no arquivo .log, para facilitar o entendimento.

O bloco lido pelo jogo inicia em $17ecfb e possui tamanho de $0aa7 bytes. Coloquei ele aqui como anexo, chamdo gfx_17ecfb-comp.bin. A saída após a descompressão é uma imagem, postada aqui no formato binário (gfx_17ecfb.bin) e em png para rápida visualização.

Só para deixar mais claro, a leitura dos dados descomprimidos é via ponteiro $a5, ex: LDA [$A5] e a imagem descomprimida é salva no endereço $7e2000, via ponteiro $af, ex: STA ($AF)

MachineMX

#24
Valeu Denim
:torico:

Vou conferi os ponteiros que postou aqui,
LDA [$A5] ponteiro de leitura dos dados descomprimidos
STA ($AF) ponteiro que salva os dados descomprimidos
De acordo com que eu sei do exemplo MMX 3 SFC
Como sou novo nessa área com ajuda dos mestres anciões, logo que elabora coloca aqui, sou bem familiarizado com o Dev C++, mais tenho bom conhecimento de lógica de programação.

Edit: Achei um site bem interessante a parte da programação, o que vcs acham?
https://github.com/PeterLemon/SNES/blob/master/Compress/LZ77/LZ77WRAMGFX/LZ77WRAMGFX.asm

A respeito de uma duvida que surgiu funciona com um arquivo RLE escrito em C, no caso se eu encontro rotinas com compressão de dados de texto, posso acha algo como isso numa rom do super mario world
No editor HxD funcionaria assim:
texto orginal Draggoooonnnnnt.
dado encriptado D1r1g2o4n5t1.

Será que na rom do SMW que funciona RLE, aparece dessa forma em uma rotina gráfica ou texto. [/b] Logo eu consigo tira o algoritmo do Actraiser, consegui entender muito a instrução LDY.

MachineMX

#25
Denim

Bom Cara

O ponteiro gráfico começa em 0xbeefb em pc address, no valor 0x1000, ele termina aonde?
Bom só isso, enquanto eu tento descobri aonde termina, só me falta isso pra termina o algoritmo, muito obrigado pelo exemplo, agora que as coisas estão batendo

denim

O bloco comprimido tem tamanho $aa7, conforme eu disse antes. Logo, termina em beefb+aa7=0xBF9A2

MachineMX

#27
Valeu Denim
Agora que entendi eu tinha que te feito a soma  :huh: beefb+aa7=0xBF9A2
Mas agora só me faltava essa informação :bomba: Logo que termina eu vou publica o código em C que é de fácil entendimento.   

yusukke

Quer um desafio de verdade?  estou precisando descomprimir e re-comprimir alguns arquivos que estão em um .BIN  de nintendo WII.
quer tentar?
Não conheci o Romhacko por querer!

MachineMX

#29
Eu não posso aceita o desafio porque eu to em fase de aprendizado, aprendendo sobre algoritmo em C, lendo alguns arquivos de engenharia reversa de roms do snes escrita em C e outras em C++, eu acho que me falta muito pra chega ao nivel do Nintendo Wii e jogos dessa geração de console.
De que rom que se trata o jogo do Nintendo Wii?