Where do you think the executable code lives? about pyplaydia HOT 6 OPEN

Yeah the Toshiba was my guess too, on account of it having more RAM, just could never really disassemble it.

As for the "frame" splitting, that was me testing the theory of the F1/F2. Since somebody was nice enough to record the full longplay of DBZ on youtube, i use it as reference ; https://www.youtube.com/watch?v=1jR_ip2n1sY

Still no luck with decoding the format, but the "frame analysis" yielded interesting results, namely:

• identical frames seem to repeat, so we're not dealing with an adaptive codec (still think it's some king of mjpeg) for instance the first video track is basically a static image in the beginning (as seen in the reference) and the frames are identical
• using the the audio length, i can see that for instance, the first video track is exactly 10 seconds long and results in 100 frames (if my F1/F2 guess is right ofc) so that would mean 10fps

from pyplaydia.

Thank you for the ping! Very cool progress so far. I got distracted as my own Playdia hasn’t arrived yet. I would happily join a discord server if you put one up.

Treating magic bytes in the video stream as a sort of scripting language does make sense; I’ve seen that with other specialty consoles where the BIOS ROM is especially large (BBC bridge companion,) although there was still z80 executable code.

The data sheet for the NEC chip does explain how to dump the ROM out of it, but without the machine in front of me I’m not sure if I can do that with it still attached to the bus or if I will have to desolder it.

from pyplaydia.

Hello :)
First of all thanks for the interest, dunno how 2 people even found this repo, let alone found it useful.

To your question i have no idea myself, so far this has been guesswork. My splitting of "streams" is only based on the CDXA sector header. I thought i would be really lucky and that video streams would be flagged as such and data (code) streams as well.

Sadly i've only seen either audio streams or data streams (at least if my ISO9660 implementation is right) so indeed, the code must live somewhere in the data stream.

There are some constants in the data that could be a clue but again this is guesswork and i'm not even sure which of the 2 CPU executes game code : the TMP87C800F or the μPD78214GC. Tried loading a few streams in IDA, no luck so far.

If you extract the video streams with the ReadVideo function and open them in an hex editor, you'll see that each sector (0x800 bytes) of the stream starts with a F1, F2 or F3 value.

Now F1 seems to be an "open stream" flag and F2 a "close stream" but F3 is perhaps a code indicator.

As i said, pure guess work and i have no current means to decode the instructions anyway, let me know if you find anything :)

from pyplaydia.

I'm pretty confident in your ISO9660 implementation, and splitting based on the CDXA header seems reasonable to me as well, especially since you were able to get ADPCM audio out as a result.

I'm also not sure which chip runs the main game code. If I had to guess, I'd put my money on the Toshiba based on the fact that it connects directly to the CD drive on the motherboard while the NEC chip doesn't seem to. (The NEC chip does seem to connect to the AK8000, so I've considered the possibility that it's decompressing the video streams for the AK8000 or something like that.) Neither are supported by IDA, but I'm working on disassemblers for both.

I hadn't noticed the sector header bytes -- super interesting! I'll investigate along those lines as well and see if leads anywhere. I noticed you were doing work on treating each sector as a frame and decoding the video that way -- have you had any luck there?

from pyplaydia.

So having written disassemblers for both the NEC and Toshiba chips, I think I can be fairly confident that there isn't executable code compiled for either of those chips directly on the CDs.

• I've tried disassembling a lot of code with the NEC disassembler I wrote and consistently run into errors in places where code is likely to live (e.g., instructions referencing registers higher than the number of actual registers, etc.), which indicates that at least the code I've tried is not compiled for the NEC chip.
• The Toshiba chip is actually more clear cut imo. Looking at its datasheet, the vast majority of its instructions start with 0xEx, so you would expect a section with code compiled for it to be something like 25-35% 0xEx. I can't find any segment on the ROM higher than like 9% I think, so I can be pretty confident that there isn't any code compiled for it anywhere on the ROM.

I actually think the executable code might be what comes after the F2 entries. The F3 entries I've seen are all like two or three bytes long, so they don't seem likely to contain code; however, F2 entries sometimes have nothing but other times have quite long chunks of data after them, which is consistent with it being something like "execute this code while playing this video," perhaps (sometimes there would be no code to execute). My guess is that the code is some sort of compiled scripting language and that one of the microcontrollers (my guess is still the Toshiba) has an interpreter programmed into its ROM.

A coworker and I are going to try hooking the bad boy into a logic analyzer at some point and see if we can infer more about how the chips talk to each other. Will keep you in the loop on what we find.

cc/ @barbeque who I noticed is also doing work on this! Maybe we should make like a discord or something to coordinate?

from pyplaydia.

@barbeque Oooh, I've read through the datasheet but I'm not as familiar with microcontroller stuff so I didn't even notice that. That's fantastic though; if we can dump the BIOS for some of these chips we'd be making a bunch of progress.

Anyway, let's do this: https://discord.gg/t3amAWah

from pyplaydia.