Pain of the Pocket Player

[forgotusername]

With the recent decoding of the NX-85's code scrambling, it occurred to me that the My Arcade "Pac-Man Pocket Player" handheld does a similar thing (though applying to the full data, not just graphics). That console is based on Sega Genesis/Mega Drive clone hardware, but features a newly-created Genesis port of Pac-Man; which as far as I know was never used anywhere else.

Out of curiosity, I analyzed the code of the Pocket Player, and found that the swapping method is quite simple. Using an extract of the Pac-Man ROM, I attempted to decode it using the EEPROM Pin Swapper tool used with the NX-85; but no matter what I input, I can't get it to unscramble correctly. I can get basically half of it to unscramble with the EEPROM tool; the rest I could logically do by hand, but I'd much rather do it by machine if that's a possibility.

Can anyone think of a way to decode this properly? The technical details are as follows. I have also attached the unaltered Pac-Man code if anyone wants to experiment with it.

Every line of code has its bytes flipped backwards, divided into sets of four sections. Pattern example:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F (standard)
03 02 01 00 07 06 05 04 0B 0A 09 08 0F 0E 0D 0C (pocket player)

By swapping pins A0 and A1 in the EEPROM Pin Swapper, the pattern is halfway fixed in a pattern like this:

03 01 02 00 07 05 06 04 0B 09 0A 08 0F 0D 0E 0C (a0-a1 pin swapper output)

Trying to swap pins A4 to A9, or any of the D pins, seems to screw the code up.

[Tygerbug]

Quietust writes:

The proper thing to do is to invert A0 and A1 - swapping the pins won't really help.
Or, if the file is being manipulated on disk, a 32-bit endian swap would fix it.
https://forums.nesdev.org/viewtopic.php?t=17331

Bavi_H writes:

Instead of swapping, you would need to invert the A0 and A1 bits.

When you see this kind of "backwards order" that suggests the thing that originally wrote the bytes and the thing that was used to read the bytes used a different "endianness". (One of them was "big endian" and the other one was "little endian".) There may be other tools to help swap the endianness of a data file.

https://en.wikipedia.org/wiki/Endianness

(A challenging example I figured out recently was one that was split to two different files [two separate dumped ROM chips] and swapped:)

CPU    file  offset
00000     L  0001
00001     L  0000
00002     K  0001
00003     K  0000
00004     L  0003
00005     L  0002
00006     K  0003
00007     K  0002
...

https://www.romhacking.net/forum/index.php?topic=35467.msg433294#msg433294

zz038 writes:

My program utftovlq can do that; use utftovlq wW to swap endianness of 16-bit words (you can also swap 32-bit words with utftovlq dD, but not 24-bit) (Windows executable is not provided, but you could compile it yourself)

Zutano writes:

You can do this pretty easily with Python (free and open source) with something like this for 16-bit words:

with open('input.bin', 'rb') as input_file, open('output.bin', 'wb') as output_file:
   data = input_file.read()
   for i in range(0, len(data), 2):
      high = data
      low = data[i + 1]
      output_file.write(low)
      output_file.write(high)

In fact, you can extend it to work with an arbitrary word size like this:

input_file_name = 'input.bin'
output_file_name = 'output.bin'
word_size = 2

with open(input_file_name, 'rb') as input_file, open(output_file_name, 'wb') as output_file:
    while True:
        word = input_file.read(word_size)
        if not word:
            break
        output_file.write(word[::-1])

Bavi_H writes:

I found an endianness swapping tool (from https://stackoverflow.com/a/19288235 ):

objcopy -I binary -O binary --reverse-bytes=4 inputfile.bin outputfile.bin

objcopy is available for Windows as part of MinGW. I found it in the "binutils" on this page https://osdn.net/projects/mingw/releases/

You can just extract the "objcopy.exe" from that binutils .tar.xz file, without needing to do a complete MinGW install.

The NX-85's code was fixed using D-pin swapping only (corresponding to bits 0-7, in binary format).

EEPROM Pin Swapper tool by Farid.
https://forums.nesdev.org/viewtopic.php?t=20122&start=15

Possible byte swap tools:
https://forums.nesdev.org/viewtopic.php?t=17331
https://osdn.net/projects/mingw/releases/


This reminds me that those mini-arcades had a unique NES version of Rampage, and I think Fix It Felix Jr.

[forgotusername]

Thank you so much for decoding it. I didn't really think about it being HEX as opposed to binary, that does explain why it worked differently.

Which of the programs worked to decode it? I'm kind of curious if the full menu can run on standard Genesis hardware, it might be worth putting the entire dump in there (it has lots of unused data etc., including unused [pirated] games and testing programs)

The Basic Fun arcades are a bizarre mixture of different hardware types; some are NES-based, some Sunplus, and a large majority are just handheld LCD fare (some even in black and white). Fix it Felix is one of the Sunplus types, I believe David Haywood has been working on emulating those (https://youtu.be/N_LBdoyQ0wQ). Most of the NES/VT ones aren't dumped yet, save for I think the Oregon Trail...

Edit: oddly testing it out further, the game seems to have considerable slowdown for some reason...I tried four different emulators, all with the same result. I wonder if it's expecting more power than a standard Genesis can output or something? I can't imagine it being due to the decoding process, it seems like it has issues at a hardware level

[Tygerbug]

 objcopy.exe was used to fix the BIN.

  I suppose it is slower than the Arcade Pac-Man.