Pengo PopCorn ROMs needed for repair

Biltronix

New member
Joined
Jan 8, 2006
Messages
933
Reaction score
57
Location
Chatham, Ontario, Canada
I don't know if anyone can help me with this because I'm not sure the files exists, but I have an original Pengo board that needs a new set of eproms.

It had an unencrypted set 2, which didn't play the Popcorn music and was a more difficult version of the game.

I'd like to install the first "set1 revc" which is easier and plays the Popcorn music. Unfortunately, the file copy that I have is encrypted and I do not have an original Z80A-custom chip that would work with this file.

I read online that there's a "rare unencrypted ver1" out there somewhere.

Does anyone have the ROM files that I'm looking for?

I know that it's sort of taboo to ask for ROM files on the forum, but I need this for a legitimate board repair and I just can't find the file.

Also, I have a working bootleg board that plays Popcorn but its EPROMs do not work in the original board even with a standard Z80A.

Has anyone ever created a PC program that can decrypt encrypted Z80 ROM files? If yes, then I could use it to decrypt the ver1 files that I already have. If anyone knows the encryption scheme and can provide that info, I can write a converter program that I'll share with everyone.

Please help, much appreciated !



Bill Boucher
 
Has anyone ever created a PC program that can decrypt encrypted Z80 ROM files?
MAME
If anyone knows the encryption scheme and can provide that info, I can write a converter program that I'll share with everyone.
MAME

Seriously though... MAME ;) . All the info should be in the MAME source, though the easiest way would probably be to run it in debug and dump the ROM segment after it's running (I'm pretty sure it decrypts the ROM ahead of time, then just runs).

I really should get some sleep since I gotta be up in about 2 hours, but I could probably help tomorrow night, or you can give it a shot. It shouldn't take more than a couple minutes if you have a MAME debug build and a hex editor.

DogP
 
MAME

MAME

Seriously though... MAME ;) . All the info should be in the MAME source, though the easiest way would probably be to run it in debug and dump the ROM segment after it's running (I'm pretty sure it decrypts the ROM ahead of time, then just runs).

I really should get some sleep since I gotta be up in about 2 hours, but I could probably help tomorrow night, or you can give it a shot. It shouldn't take more than a couple minutes if you have a MAME debug build and a hex editor.

DogP

Wow DogP, that's a really slick idea and makes perfect sense. Obviously MAME can read the encrypted files so the information on how to decode the data is in there somewhere. There was likely an original datasheet for the special Z80A custom to work with or else maybe someone had a little program or even an old hardwired encoder circuit that was used to create the original encrypted ROMs. Maybe the compiler that Sega used was special in that it created the encrypted files directly. Oops, I'm rambling, sorry.

I have never installed MAME on my PC (!! I know eh?) so I sure don't know how to use the debug mode yet. I don't know if the dump would create a set of files, 1 for each EPROM, or if it would produce one long file. I assume the latter, hence the need for the HEX editor to split the file into the pieces required for the real chips. Anyway, I could give it a try but I'm afraid that it would take me a month or more just to get the hang of it.

Anyway, if you really think that you could do the job in just a few minutes, then I sure would appreciate you doing that for me. Maybe there is something that I could do to return the favor? For someone with such a large collection, I have to wonder how I could be of any use to you, but maybe there is something.

I imagine there are quite a few original Pengo boards out there that people would like to switch to the original version with Popcorn music without using the encrypted Z80A which they have already lost and is difficult (maybe all but impossible) to replace.

Thanks DogP !! :)
 
Well, I decided to do some of my homework so I downloaded and installed MAME 0.149 on my PC as DogP suggested. I ran the ROM files for Pengo "set 1 rev c" and it played the Popcorn version as expected. I then dug into the C source files looking for the decryption code. In a file called "segacrpt.c", there are two C functions called

Code:
static void sega_decode(running_machine *machine, const char *cputag, const UINT8 convtable[32][4])
and
Code:
void pengo_decode(running_machine *machine, const char *cputag)

The "pengo_decode" function has a 32x4 byte array that provides the decoded output for a given input. The C text is a little beyond me. I'm used to programming in C but I'm no pro, but I'm getting the gist. I believe that a relatively short C program could be written that sequentially reads a ROM file byte by byte, passes the bytes through these two functions, and writes the decrypted bytes into a new file. Anyone reading the segacrpt.c file will immediately see that the decoding tables are present for lots of other Sega games. Someone who is good at writing C projects would likely be able to include this entire file as part of their new project and call the functions needed for all of the games supported. Once done, decrypted ROM files for all of those games would be easily produced. I only have use presently for the Pengo files but I see the potential here to benefit the other games too.

I will probably take a crack at running MAME in debug mode too. If I can get it to dump the decrypted ROM data, that'll work for me too. I have absolutely no idea how to do it yet.

Bill B.
 
I'm not making good progress with the MAME debugger. I can't even start it! :(

When I start it at the cmd prompt using >mamed pengo, it just starts the game. There's no debugger interface or anything so there's no way to enter commands, see disassembled code, step through it, or anything. What gives? I have searched the internet and I have found lists of the commands and screenshots showing debugger screens, but not a shread of instruction on how to launch the darn thing.

Help? :eek:

Bill B.
 
I'm not making good progress with the MAME debugger. I can't even start it! :(

When I start it at the cmd prompt using >mamed pengo, it just starts the game. There's no debugger interface or anything so there's no way to enter commands, see disassembled code, step through it, or anything. What gives? I have searched the internet and I have found lists of the commands and screenshots showing debugger screens, but not a shread of instruction on how to launch the darn thing.

Help? :eek:

Bill B.

You need to run mamed -debug pengo . Then once in debug, type help... there's a dump memory command somewhere, just dump the entire ROM location, then split it into files according the order shown in pengo.c . Of course you should verify that it's not just the exact same thing as the original ROMs... in that case, it's not stored decrypted, and you may need to actually look at the encryption algorithm in the source.

If you don't get it, I'll take a look at it later tonight.

DogP
 
I would recommend you get one of these:

http://www.jrok.com/hardware/pengo_epack/pengo_epack.html

Then you have both versions of the ROM, Free Play and Saving of the top 10 scores for each game...

Worth every penny.

I agree. I almost bought one about 2 years ago but I was falling on difficult financial times so I wasn't buying hardly anything arcade related. I finally tried to order one from Arcadeshop last week and they are all out of them unfortunately. On a side note, they were also out of Tempest CP and marquee overlays so my Tempest project is on hold.

Bill B.
 
You need to run mamed -debug pengo . Then once in debug, type help... there's a dump memory command somewhere, just dump the entire ROM location, then split it into files according the order shown in pengo.c . Of course you should verify that it's not just the exact same thing as the original ROMs... in that case, it's not stored decrypted, and you may need to actually look at the encryption algorithm in the source.

If you don't get it, I'll take a look at it later tonight.

DogP

Thanks again Mr. Dog (the bounty hunter?)(sorry, just had to say it once;)) Once again, very helpful. I ran the MAME debugger and got the Pengo code listed in the disassembly window. Oddly, it won't display the entire program all at once in the list but rather just a section at a time. However, it didn't matter. I used the dump and save commands to save the program to files. I viewed the files and I can read all sorts of ascii text inside the program (screen text messages, designers names, more) so I am positive that we have a winning solution here, that is unless only the op-codes are encrypted and not the data. I can check this easily by comparing the on-screen disassembly with the values inside the dump file. I'll do that later.

All I have to do is figure out how to split the binary file up into 8 sections for programming the EPROMs. I do not know if the data from the (video?) two 2764 eproms is also in there or if it's just the game code. The two 2764 eproms I think may be separate but I'm not sure. I don't think that they are in there because their files are the same for all versions, encrypted or not. Anyway, I think that if I perform the exact same process on an already unencrypted rom set, say "set 2" and then I can compare the big binary file to the little ones and see how/where they are split and which section goes to which of the 8 chips. Once I figure that out, I can apply the same logic to the "set 1" version and then attempt to program and test a new set of chips.

If this experiment works and anyone wishes to have a copy of the resulting files for their Sega board to play the popcorn version with a standard Z80A chip, just email me a request. I don't want to post the files anywhere online but I'll email them to you.

Bill B.
 
Actually, I just took a look at it... it appears that code and data are encrypted differently, so this may be a more complex problem. You can see this by looking at a disassembly window and a memory window in MAME... they show different values.

Doing a memory dump gives valid data (which is why you can read text), but gives invalid code... and doing a disassembly gives valid code, but invalid data. I actually tried running both sets, and they don't work. Looking at the source ( http://maws.mameworld.info/maws/mamesrc/src/mame/drivers/pengo.c ), I see why:
/* decode the ROM data */
rom[A] = src ^ data_xortable[j];
/* now decode the opcodes */
/* pick the translation table from bits 4, 8 and 12 of the address */
i = ((A >> 4) & 1) + (((A >> 8) & 1) << 1) + (((A >> 12) & 1) << 2);
decrypt[A] = src ^ opcode_xortable[j];

So basically, you'd need a way to tell whether something is code or data, which is obviously hard without actually running the code and determining this. You may want to message jrok (regular on this forum) and see if he'd be willing to share the decrypted set 1 ROMs with you (assuming his hacked ROMs have each game's ROM set untethered from the rest of the hack).

FYI, about the ROM map, look at the bottom of the code, under ROM_START( pengo ). That tells you which ROMs are at which address, and what size.

DogP
 
Hmmmm.... I need to keep tabs on this as I bought a Pengo Cocktail (conversion) years ago for my daughter because it was a "cute" game. A friggin' hard game is was it turned out to be, never thought to look into different versions of it. It's kinda buried right now so I can't open it and look to see what's in it. But it would be nice to put an easier version in there.

Think any of this might help ?
http://www.jrok.com/sohs/pengo/pengo.html
It's from JROK, appears to be unencrypted already, not sure which version, and I don't know if you "have" to do the dallas sram change or not to actually run it though.
 
Think any of this might help ?
http://www.jrok.com/sohs/pengo/pengo.html
It's from JROK, appears to be unencrypted already, not sure which version, and I don't know if you "have" to do the dallas sram change or not to actually run it though.


Good idea, but no help there. I just tricked MAME into playing it and it is not the Popcorn version. It might make sense to just ask JROK nicely, but he doesn't know me so I feel a little weird asking for the favor, especially since he went to the trouble of figuring it all out already for his dual-game high-score-save module a few years ago. I'm sure that it must have been a ton of work.

Bill B.
 
Actually, I just took a look at it... it appears that code and data are encrypted differently, so this may be a more complex problem. You can see this by looking at a disassembly window and a memory window in MAME... they show different values.

Doing a memory dump gives valid data (which is why you can read text), but gives invalid code... and doing a disassembly gives valid code, but invalid data. I actually tried running both sets, and they don't work. Looking at the source ( http://maws.mameworld.info/maws/mamesrc/src/mame/drivers/pengo.c ), I see why:
/* decode the ROM data */
rom[A] = src ^ data_xortable[j];
/* now decode the opcodes */
/* pick the translation table from bits 4, 8 and 12 of the address */
i = ((A >> 4) & 1) + (((A >> 8) & 1) << 1) + (((A >> 12) & 1) << 2);
decrypt[A] = src ^ opcode_xortable[j];

So basically, you'd need a way to tell whether something is code or data, which is obviously hard without actually running the code and determining this. You may want to message jrok (regular on this forum) and see if he'd be willing to share the decrypted set 1 ROMs with you (assuming his hacked ROMs have each game's ROM set untethered from the rest of the hack).

FYI, about the ROM map, look at the bottom of the code, under ROM_START( pengo ). That tells you which ROMs are at which address, and what size.

DogP


I agree. I looked at the source that you linked to, and looked at the disassembly listing and the memory dumps too. It gets worse I think. As far as I can see, the disassembly listing in the MAME debug screen is totally garbage. When you toggle between "encrypted opcodes" and "raw opcodes", the display changes the hex values shown for the data but not for the opcodes. The first few addresses show correct opcodes and data, but soon it goes to heck. I believe that the disassembler ends up decoding data as if it were opcodes and vice versa. This makes the listing gibberish and worth nothing. When MAME is running, it probably knows at all times whether it is fetching an opcode or data because the machine emulation would require that information to execute code. If it needs the next opcode, it fetches from decrypt[A]. If it wants the next data, it fetches from rom[A].

I do not think that it is safe to assume that the memory dump contains all correct data and incorrect opcodes because there is some text that is readable. Otherwise, MAME would not have to decode the data into the array rom[A]. There are a lot of incomplete words too and I don't think that makes sense. Also, there are large sections of code loaded with repeating complete phrases that are 16 bytes long (looks nice in a hex editor right?) so I believe that those regions were edited to contain those phrases after the program was assembled (into an encrypted version) because the designers knew that those regions would contain no valid code and that way they could stick their credits into the program there.

Like it was said before, the trick would be to think of a way to decrypt opcodes and data each with its own algorithm and that requires knowing in all cases which is which. I think this would require a runtime decoder that knows what it is fetching from each address. It would then have to decrypt it (or read from the proper array variable that was initialized at startup like MAME does) and then save that new byte into a target array at the same address. As the program runs, it would build the new decrypted target array data that could be saved and later used as the decrypted binary. The problem with this method is that the new array would only contain data from code that was actually executed at runtime and not necessarily all of it.

It would be better to have some sort of disassembler that could distinguish between opcodes and data and process the entire file. One interesting thing here, with respect to how the MAME disassembly listing is full of garbage, such a disassembler would try to disassemble unused code areas that are full of readable credits and it would just mess them up. That wouldn't matter however because those addresses would never be executed anyway. One could always copy and paste those sections back into the new decrypted binary file if they wanted to keep them intact.

I thought that I had thought of a way to separate opcodes and data but then I got stuck wondering what to do with lookup tables that contain no opcodes.

I have to believe that there's a sensible way around this problem. I'll keep giving it some thought and see if I can work something out eventually.

Bill B.
 
Back
Top Bottom