Deconstructing Pokémon glitches?

(Peço desculpas se este é o lugar errado para perguntar isso. Acho que é definitivamente relacionado à programação, embora se isso pertence a algum outro site, por favor me avise)

Eu cresci jogando Pokémon Red e Blue, jogos que eram muito divertidos, mas são notórios por terem várias falhas exploráveis (por exemplo, consulte este ridículo speedrun do jogoue usa corrupção de memória para transformar a tela do item em um editor hexadecimal

Recentemente, encontrei uma velocidade interessante do jogo que usa uma falha chamada "falha ZZAZZ" para corromper importantes localizações de memória e permitir que o jogador ganhe quase imediatamente o jogo. De acordo com a descrição do autor do speedrun, a falha do ZZAZZ funciona da seguinte maneira:

Para iniciar uma batalha de treinador, o jogo precisa carregar muitos dados, como o [...] dinheiro que ele concederá se for derrotado. Quando carrega o dinheiro, é onde as coisas podem ficar realmente feias. Por razões que estão além de mim, o dinheiro é armazenado de uma maneira completamente diferente, o jogo usa uma estrutura de dados de três bytes e, em vez de converter o valor em binário, ele o armazena na representação "humana". Por exemplo, $ 123456 seriam armazenados como 0x123456 em vez de 0x01E240, a conversão adequada.

[Algumas entradas inválidas na tabela Trainer] apontam para um local com dados monetários inválidos. Quando o jogo tenta executar aritmética com esses dados na referida estrutura, ele fica louco e começa a substituir grandes porções de RAM. Mais especificamente, para cada bloco de três bytes, dois deles conterão 0x9999 (a quantia máxima de dinheiro que um treinador poderia dar). Esse padrão se repete muitas vezes através da RAM. Para ver melhor, recomendo pausar o vídeo no emulador depois que o treinador do ZZAZZ for enfrentado e defina o visualizador de memória do VBA como 0xD07

Esta análise faz sentido, mas como programador não posso deixar de me perguntar como diabos os programadores escreveram o código que tornaria isso possível. Nenhuma abordagem que eu possa pensar para escrever uma função que converte um número decimal codificado em hexadecimal em decimal jamais começaria a preencher blocos aleatórios de memória com 0x9999 se a entrada não fosse um número decimal codificado em hexadecimal válido.

minha pergunta é - sem projetar especificamente o algoritmo para falhar dessa maneirxiste uma implementação direta de uma conversão de decimal codificado em hexadecimal em decimal que pode resultar nesse tipo de corrupção de memória quando alimentado com um valor inválid

Novamente, se isso estiver fora de tópico, minhas desculpas. Penso que outros programadores neste site também podem ter crescido jogando este jogo, e parece um exercício interessante de engenharia reversa tentar descobrir como uma falha como essa pode ser possíve

questionAnswers(3)

yourAnswerToTheQuestion