Buenas!.

Este tema me ha surgido viendo un vídeo en el cual el creador del vídeo le gustaba el antiguo juego "Donkey Kong" de la mítica consola Atari 2600 (imaginar!).
Tuvo la mala suerte que comprando el cartucho del juego por Ebay  pensó que era la versión para esta máquina y resultó que era para otro consola ( La Coleco ).

Si, los cartuchos eran similares pero no funcionaba. Entonces la idea de el fue  (ya entrando en algo más técnico) reprogramar un chip con una tarjeta que
permitiese usarse en la consola. Copiar el archivo binario del juego mediante un programador de eprom a una eprom y esta se encuentra en ese pequeño
circuito que funciona en la antigua consola. Esos cartuchos, su circuito impreso era sencilla, mayormente un chip que era una memoria eprom.

Y dije, ¿ y de donde saca ese binario ?. Pues de las imágenes que soportan los emuladores.
Entonces fui a una web donde puede encontrarse aquellos juegos. Iba a ponérosla, pero por si acaso incumple leyes, no puedo enlazarlas aquí.

Por otra parte ya tenía esos juegos perdidos por el disco. Con el paso anterior, comenzaba la comparación binaria.

Me encontré el problema más tonto. En aquella época, podías encontrar el juego para U.S.A y otro para Europa. Entonces cuando comparé el que bajé que era
la versión americana no coincidía con la europea, pero como tenía también la rom usa por ahí, fui a comprobarla y efectivamente, eran idénticas!.

Vamos al articulo de comparación de archivos binarios en Linux, que es bien largo y detallado. Tenemos una cantidad de herramientas, a cada cual mejor.

Cómo comparar archivos binarios en Linux

Lo primero que hice fue comparar con sha256sum.

Primero use la bajada de la web.

sha256sum Dk.bin

538e271407e649e18634d30d136b452ccbf6741fa800e7af8d46d4bdd57aead1  Dk.bin

Luego probé con la rom europea.

b76055b8d14a2a909ed0844cbb74423c4fba1dbe5b9eca6f8f104548eab9e09c  DONKEY_KONG__PAL_____.A26

Y para finalizar con una rom que tenía para USA.

sha256sum 'Donkey Kong (USA).a26

538e271407e649e18634d30d136b452ccbf6741fa800e7af8d46d4bdd57aead1  Donkey Kong (USA).a26

Idéntica.

Luego hice muchos pasos pero ya había averiguado el problema y lo que usaba el autor del vídeo.

Es interesante la mezcla del uso de hexdump y diff

Código:

diff <(hexdump binary_file1.so) <(hexdump binary_file2.so)

Luego lo intenté de otra forma: Probando con dos archivos binarios que eran lo mismo, solo que distinto nombre.

Código:

diff <(sha256sum Dk.bin) <(sha256sum 'Donkey Kong (USA).a26')

Su salida fue esta:

 
1c1
< 538e271407e649e18634d30d136b452ccbf6741fa800e7af8d46d4bdd57aead1  Dk.bin
---
> 538e271407e649e18634d30d136b452ccbf6741fa800e7af8d46d4bdd57aead1  Donkey Kong (USA).a26

Con el modo anterior no hubo salida. Lo dio por iguales.

Y para acabar os muestro el vídeo a los que os gusta estos temas de los chips.



Hubo un momento que se escuchan sonidos de campanillas.

Saludos

Puede que esto si sea el modo correcto si uso diff y sha256sum.

Código:

(awk '{print$1}' <(sha256sum Dk.bin))

Con awk y '{print$1}'  se obtiene la primera columna que crea sha256sum del archivo Dk.bin, que es solo el checksum sin el nombre del archivo.

Código:

diff <(awk '{print$1}' <(sha256sum Dk.bin)) <(awk '{print$1}' <(sha256sum 'Donkey Kong (USA).a26'))

No se obtiene salida, por lo que debería ser correcta. En cambio si comparo versión americana con europea.

Código:

diff <(awk '{print$1}' <(sha256sum Dk.bin)) <(awk '{print$1}' <(sha256sum DONKEY_KONG__PAL_____.A26))

La salida es parecida a lo que comentaba arriba, pero se ve claramente que el checksum no es el mismo: Vuelve a aparecer 1c1 y los signos < y  > junto con el --- supongo
que actúa de divisor.
 

 
1c1
< 538e271407e649e18634d30d136b452ccbf6741fa800e7af8d46d4bdd57aead1
---
> b76055b8d14a2a909ed0844cbb74423c4fba1dbe5b9eca6f8f104548eab9e09c