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.

[forgotusername]

No idea why I haven't done this until now (maybe objcopy was confusing me...), but I was able to rip all of the games/programs from the original Pac-Man Pocket Player. As mentioned in MAME's source code, the console bizarrely features pirated Mega Drive/Genesis games unused in the code, such as Space Invaders 90 (which has the Pac-Man selection menu cheaply applied over blank code spots). The properly-used Pac-Panic and Pac-Mania ROMs also contain some differences compared to the original Mega Drive ports.

Perhaps the most intriguing thing here is located at address 240000, which MAME states is a portion of a 202-in-1 menu (resembling the one on the 145-in-1 plug & play and some PXP3 models). While it doesn't fully function via this extract, its header reads "MAKE BY ZYX-zhengyaxin_8bit@yahoo.com.cn". I've discussed zhengyaxin here before (http://bootleg.games/BGC_Forum/index.php?topic=3228), as he was seemingly connected to the bootleg plug & play industry, including Mega Drive clones; and this confirms his involvement without a doubt.

[forgotusername]

As a further note, a few of the newer "Pocket Player Pro" units were recently added to MAME (Pac-Man, Ms. Pac-Man, and Tetris). Descrambling the ROMs was trivial (its reversed byte order is 2 rather than 4), though I cannot get the games to run properly. Fusion is able to glitchily load the opening My Arcade intros, but nothing past that.

Oddly, the headers for the Pocket Player Pro consoles credit DMC and RedKid; the game titles are labeled as "sample" and "demonstration programs". I'm not sure if this indicates the consoles are Firecore-based, or if they just lazily hijacked the header from a Firecore test program; MAME source still labels these systems as being Radica hardware. I did attempt to run the games on an AtGames Firecore handheld via the SD card slot, but they didn't seem to run on that either.

Downloads for the decoded ROMs are below. Ms. Pac-Man appears to be an 8MB overdump in MAME (with duplicated data), so it has been reduced here.

[SF-Human]

Great work! I took the liberty to rip the Tetris ROM from it. Don't know if someone did that before.
Also I found this in Tetris Pocket Player's ROM:

Code: [Select]

RISTAR
PACMAN
VIRTUA FIGHTER 2
GOLDEN AXE 2
070.GAUDTLET4
SUPER MARIO 2
KLAX
WHERE IN TIME
This is probably leftover from one of the Sega Genesis-based Plug 'n Plays or handhelds.

[SF-Human]

Also ripped a few more ROMs from the set. The above text I posted is present on all three "new" Pocket Players. PacMan.bin and Galaxian.bin was ripped from Pac-Man unit and MsPacMan.bin and Galaxian2.bin was ripped from Ms. Pac-Man unit. These ROMs might be an overdump because I don't know exactly what the ROM size for these games are, I just searched for Sega Genesis headers in the ROM and trimmed everything before it.

[forgotusername]

All of the extracts look good, thank you for ripping them. Pac-Man does not seem to suffer from slowdown here in emulation, as was the case for the original Pocket Player extract. Both Pac-Man and Ms. Pac-Man can be played in horizontal resolution if the player holds A and C amidst the faux-bootup screen (this was vice-versa for the original Pocket Player).

Galaxian is actually an unused game across both Pac-Man systems; I was unaware that it was inside of the code. They're identical in coding between both systems (the proper file size is only 64k). I'm guessing that the Pac-Man and Ms. Pac-Man ROMs are actually underdumps rather than overdumps, and used Galaxian as padding for whatever reason. Also of note is that the Galaxian ROM is headered "A1UP 2019.SEP"; presumably referring to Arcade1UP, who used the game on the "Pac-Man Collectorcade" system prior to the My Arcade consoles.

It's not of much benefit, but I attached the trimmed version of Galaxian and the intentionally-overdumped copies of the Pac-Man games below. The Space Invaders and Galaga units were also dumped the other day, so I will look into those as well.

[forgotusername]

Here are the Space Invaders and Galaga Pocket Player Pro extracts. Space Invaders also features the unused Galaxian code as padding; annoyingly, it faces 180 degrees opposite of the others in orientation. The Galaga system does actually use Galaxian as a selectable game, but it's a different revision in code. The Galaga port is genuinely very impressive here; if I didn't know any better, I would think it was arcade emulation with cruddy sound.