Preciso de ajuda com exercícios e um pouco teórico com exemplos de compressão LZW, Run Lenght Encoding ou
HuffMan seja qual for o sistema pra fins de estudos e conhecer o básico pra dá início nessa área do romhacking.
Pode tentar com os jogos da série megaman do snes... Todos eles usam o mesmo padrão de compressão, do tipo LZ e bem simples.
Eu acredito que gba seja a plataforma mais fácil para aprender compressão. Veja bem: algumas rotinas fazem parte da bios e são bem documentadas no gbatek.
Se baixar o código fonte do lazynds, escrito por mim a muito tempo atrás, vai achar a implementação dessas rotinas (lz, rle e Huffman) em python. Basta porta-las para C.
Abraço!
Eu vou ver onde que fica armazenado o ponteiro tilemap nem que encontre um pequeno gráfico 16x16, qualquer detalhe que não vou deixa passado, encontra gráficos com algum dado de compressão.
Valeu Denim.
Um dos planos que tenho é o Breath of Fire sou do GBA, falando sobre as rotinas da bios, havia achado informação da bios e outros texto relacionado ao porcessador ARM. seu arquivo tá hospedado em qual repositorio, ou site do forum.
Assim que acha eu vou olha e estuda elas.
Valeu 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
MachineMX não sei se você quer mexer no BOF2 para estudo ou fazer uma versão sua. Por que a tradução já foi feita pelo Kampello da NBR.
Link da Tradução (http://romhackers.org/modules/PDdownloads/singlefile.php?cid=31&lid=1084)
L-Slayer
Eu pretendo para estudos do romhacking, aprender sobre compressão como solução de algumas roms que não consegue espaço em certos lugares e conseguir em caso de fonte gráficas, salta o bit pra x00 sem compressão em vez 0x01 estudando asm, entender o funcionamento do que carrega o tilemap ou dados gráficos, hackear o item shop, armor shop. :huh:
Legal, se eu fosse você eu tentaria entrar em contato com o Kampello atraves do forum da NBR (http://romhacking.forumbrasil.net/), por que ele destrinchou todo esse jogo, você pode pegar dicas valiosas. Ele anda meio sumido pra falar a verdade, mas acho que a tentativa é válida.
Muito Obrigado L-Slayer
Legal se ele puder me passa algumas dicas eu agradeceria muito e me dá detalhes do jogo, vc tem o contato de email? Eu vou da olhada na Nintendo Br.
:parabens:
Lembro muito dele e assisto o canal do Kamppello no youtube.
Edit:
Eu tentei procura contato com o Kamppello pra gente conversa sobre o Breath of Fire não consegui, mas logo que ele entra aqui no forum eu entro em contato com ele, um abração a Todos
BOF2 de GBA não vai ser um exercício muito bom, não lembro de ter muita coisa (se alguma) comprimida relevante. Sugiro algum Fire Emblem, Golden Sun ou jogos da Nintendo em geral.
Se quiser começar pelo simples, o Master System tem esquemas de compressão oficiais bem documentados, lá no SMSPower, e o NES tem vários jogos famosos usando alguma forma, como os Final Fantasies, Kirby, Megami Tensei (se não me engano)...
Eu posso começa com o Dragon Warrior 2 ele usa uma compressão mais fácil que é Fixed Bit Length Encoding
https://wiki.nesdev.com/w/index.php/Fixed_Bit_Length_Encoding, ele parece ser mais fácil que ouras compressões, mas vc acha que o Master System pode ser melhor pra começa que no Nintendo ?
Eu entro direto no smspower, adoro os arquivos de programação.
Essas duas roms apresenta mais dificuldade tratando em compressão Fire Emblem, Golden Sun ?, achei bem legal estrategia com rpg.
Acho que se for meramente para estudar compressão de dados para algum curso e etc, você pode estudar e criar os CoDec's para qualquer tipo de arquivo e algoritmo para texto/imagem ou outra coisa, é até mais fácil que trabalhar com ROM's, basta estudar a teoria e aplicar.
O único motivo de trabalhar diretamente com ROM, é você, por si próprio, entender a rotina através de depuração e criar o algoritmo do CoDec, ou seja, é mais trabalhoso e complicado. Se você não conseguir cumprir essa etapa, escrever um CoDec pura e simplesmente não impressiona, principalmente os já extensamente documentados.
Agora, se sua motivação é usar isso em ROM Hacking, é válido estudar a teoria e prática como proposto acima e mais o assembly da plataforma que deseja trabalhar, além de entender como utilizar os emuladores com bons depuradores, aí você vai estar com o arsenal completo do ROM Hacker.
Citação de: MachineMX online Dezembro 26, 2016, 12:03:42 PM
Eu posso começa com o Dragon Warrior 2 ele usa uma compressão mais fácil que é Fixed Bit Length Encoding
https://wiki.nesdev.com/w/index.php/Fixed_Bit_Length_Encoding, ele me parece ser mais fácil que outras formatos de compressões, mas vc acha que o Master System pode ser melhor pra começa que no Nintendo ?
O caso é que Master System, assim como GBA, possui formatos oficiais e não "oficiosos", mas em se tratando de facilidade, tanto faz.
Os Dragon Warrior também são ótimos.
Valeu Macaco Ancião, valeu pelas dica, O codec para texto e imagem pode ser uma boa opção, mais minha paixão é o RomHacking, tenho um pouco conhecimento como entrada e saída dos imagem e som, entendo como um Rom inicia ou entra um estado de espera, conheço sobre as condições de salto, instruções de deslocamento que é mostrado no link acima, há pouco tempo aprendi sobre a pilha escrevendo arquivos com o SMW.
Tenho interesse em desenvolve ferramentas pra extrair e comprimir de volta o gráfico. Editores de Texto como diálogos na rom.
Valeu tvtoon pelas dicas, vou olhar melhor isso, e sem pressa os arquivos em detalhes em proramação do 6502, mais ainda assim começando com otimização de código, conheço alguns truques como dribla rotina com dados gráficos, e conheço muito bem diferencia as instrucões de salto, mais ouvi dizer que o master system é mais fácil por ser mais limitado que o Nintendo, pode ser uma opção.
Beleza, pelo teu texto, achei que era para algum curso e tal.
Bom para iniciar pode ser GBA, é de longe o mais simples de todos, pois a maioria esmagadora dos jogos tem compressão baseada na API do BIOS, que são 3: RLE, LZ77 e Huffman, está bem documentado aqui: http://problemkaputt.de/gbatek.htm#biosfunctions em Bios Decompression Functions.
Para encontrar no jogo, também não é nada complicado, basta usar um emulador que faça log das chamadas do BIOS, elas são feitas com a instrução SWI, então fica fácil, por exemplo, no VisualBoyAdvance, você vai em "Tools > Log" e marca SWI e você vai ter algo assim:
(https://cdn.discordapp.com/attachments/89646072086929408/263814981164859393/gbaswi.png)
Explicando. Mandei logar as instruções SWI, assim quando eu pressionei o botão para aparecer "New Game" ele detectou uma chamada SWI 0x13 que indica descompressão Huffman do BIOS no endereço 0x081eed50, conforme está selecionado na imagem.
Logo, a rotina está explicadinha ali no documento, só criar o descompressor e depois o compressor, inserindo no endereço correto (sem extrapolar o tamanho ou alterando o ponteiro da imagem), veja que a imagem está em 0x081eed50, mas isso é um endereço do mapeamento de memória do GBA, onde a ROM começa em 0x08000000, logo, você precisa subtrair esse valor para achar o endereço no PC, o que é simples: 0x001eed50, lá está o dado comprimido.
Para testar com LZ77 que é uma compressão mais simples, jogos como Advance Wars, já RLE não lembro de nenhum.
Pense que há jogos que são comprimidos com rotinas próprias, logo essa dica do log de SWI não funciona, não tenho certeza, mas creio que Golden Sun é um desses jogos que não fazem uso de rotinas da API do BIOS.
Por isso, GBA é mais fácil, pois não é, a priori, necessário nenhum grande conhecimento de Assembly de ARM para começar a fazer coisas "avançadas" com os jogos.
Aqui tem um código-fonte em Python 2 que eu escrevi para rotinas LZ77, já vem configurado para descomprimir vários gráficos de Advance Wars: http://www.romhacking.net/utilities/430/
Valeu Ondinha.
:torico:
Belíssimo Tutorial de captura gráfica, não tinha a menor ideia que o emulador Visual Advanced apresentava essa função de captura de dados dos três formatos mencionados RLE,LZ77 e Huffman, isso facilita e muito vida de programador RomHacker muito interessante, não é como muita gente faz no snes, esperando um frame antes e não dá detalhes de qual formato é o da saída gráfica.
Mais esse VisualAdvanced parece ser mais fácil, falando sobre o endereço do mapeamento da memória ROM em geral é 0x81 é o que aparece na janela,o endereço do PC acima 0x01eed50 onde fica o dado gráfico.
Muito Obrigado pelo exemplo LZ77
:chegamais:
Finalmente achei um emulador sem problema, havia pegado alguns defeituosos.
(https://s23.postimg.org/ry3s4q6bv/image.png) (https://postimg.org/image/bn3o8ettz/)upload photos (https://postimage.org/)
Vou ler o documento completo logo que alguma dúvida surgi volta aqui. Um abração ao Todos, que postaram e contribuiram com a sua ajuda valeu.
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.
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
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.
Se quiser eu passo um código de lz77 para o snes, além do bloco de dados comprimido.
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:
HuffUnComp, 0x081eed50, 0x06000000, VCOUNT=175
Isso basicamente é como se fosse uma função de alto nível do tipo:
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:
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.
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.
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.
(https://cdn.discordapp.com/attachments/89646072086929408/265941912148639744/unknown.png)
É 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.
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:
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)
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 (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.
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
O bloco comprimido tem tamanho $aa7, conforme eu disse antes. Logo, termina em beefb+aa7=0xBF9A2
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.
Quer um desafio de verdade? estou precisando descomprimir e re-comprimir alguns arquivos que estão em um .BIN de nintendo WII.
quer tentar?
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?
Denim
Actraiser
Todo arquivo que trabalhei existe uma variavel escrita em assembly claro, sobre o controle de bits,(um ciclo de oito bits) que é encontrado em muitas roms, mais nessa tá me pegando vc sabe me dize se ele tem? Outra coisa em afim de aprendizado vou descobrir por conta propria e coloca o algoritmo aqui. Provavelmente ele usa o loop infinito do tipo True, pelo tanto que sei.