V.Disc Analysis

I finally got around to prying open that V.Flash V.Disc cartridge. All it required was a screwdriver acting as a chisel, a hammer, and a blood sacrifice (technical veterans will recognize that last item as a mainstay of computer repair methodology). I have to give VTech proper credit for the strength of the cartridges. Sega could have learned something from VTech when they manufactured their flimsy, oversized Sega CD and Sega Saturn jewel cases. Anyway, it is confirmed: The V.Disc is a simple CD-ROM.


V.Flash V-Disc, separated from cartridge

The particular title I have, The Amazing Spider-Man: Countdown To Doom, contains around 313 MB of data. The largest directories on the disc are labeled kw01/, kw02/, and kw03/. They contain combinations of files bearing the extensions .mjp, .ptx, and .snd. I strongly suspect that these are Motion JPEG, raw picture, and pure audio files, respectively. Various other directories on the disc also contain .mjp files with ‘cutscene’ in the filenames.

The .mjp files begin with a MIAV signature and draw influence from the AVI format in that media chunks are denoted variously by ’00dc’, ’01wb’, and ’02wb’ FourCCs. The chunk format is FourCC – chunk number within stream – chunk length – payload. The 00dc chunks contain what resemble JPEG chunks. But something seems off about them. My first clue is a FourCC ‘FJFI’. Then it comes into focus– it’s byteswapped JPEG data (the usual signature here is ‘JFIF’). In fact, the first chunk begins with the bytes 0xD8 0xFF 0xE0 0xFF– byteswapped from the standard marker bytes 0xFF 0xD8 0xFF 0xE0. The 01wb and 02wb streams, I would guess, represent 2 separate audio tracks. Perhaps this disc can be played in 2 different languages? Or perhaps there is a director’s commentary track? I think I like my first hypothesis better. I didn’t see anything on the box or cartridge to indicate that the game has more than one language. But it could be that the same media is marketed in a different region with different printed materials. If that were true, it would indicate that the game could query the region of the V.Flash to know which language it should present to the player.

I am not sure what format the audio data takes. It could be low-volume, 16-bit, little endian PCM (mono or stereo), it could be 8-bit stereo PCM that’s dominant only on one channel, or it could be some other unusual encoding. The .snd files might provide a little more insight. The .snd files turn out to be straight-up WAV files.

The .ptx files are all 262188 bytes, which is (44 + 218) bytes, so I suspect that these files have a 44-byte header followed by 218 bytes of raw image data. The first byte in the file is 0x2C = 44, so that’s a good validation sign. I’m trying to decide what the dimensions and color resolution could possibly be. The square root of 218 = 29 = 512. A 512×512 image would not make sense for a television screen. But that would assume 8-bit palettized data anyway. However, if the data was 15- or 16-bit RGB, then the image might be 512×256 which is plausible. The header encodes the number 480, which is a common image height, but does not divide evenly into 218. Plus, there is no sane parameter encoded in the area around 480 to indicate height, so I have to assume that 480 is a coincidence. Hey, Robert and Reynaldo: is that RGB recovery utility ready yet?

For program code, the disc contains a file called 0system/boot.bin. I think Ian Farquhar called it when he speculated that the V.Flash uses an ARM processor. Running ‘strings’ on this binary reveals “MORE v4.0 SDK ARM9T version”. The binary format itself I am unfamiliar with, but it is a chunked FourCC format that contains such FourCCs as ‘BOOT’, ‘REL\0’, and ‘DBG\0’. A clue regarding the toolchain, however: “GNU AS 2.13”. The string “OggSRIFFdV” also shows up.

Update: Here are some samples of the .mjp and .ptx files (the .snd files are just straight PCM WAV files).

16 thoughts on “V.Disc Analysis”

  3. Multimedia Mike Post author

    Sorry for the delay in sample uploading. I have updated the post with a link to some representative samples.

  4. Ian Farquhar

    A quick Google search on “MORE v4.0 SDK ARM9T version” turns up this:

    http://www.access-company.com/products/embedded/ultron.html

    Interestingly, they mention no ARM9 version (although there is an ARM7 version).

    Anyway, the above means that the V.Smile et al are basically running a variant of the embedded real-time OS ITRON:

    http://www.sakamura-lab.org/TRON/ITRON/

    The above might be useful if you wish to explore that binary executable format a bit more.

    I presume V.Tech used this to avoid rolling their own SDK (which increases time-to-market), but why they’d use ITRON – which isn’t well-known outside Japan – over any other embedded OS isn’t clear to me. It might have simply come down to financials, or pre-existing corporate experience with that product.

  5. CDoty

    _113KW_PIC.ptx is a 512×128 pixel image with 4 bytes per pixel. Opening it as a raw in photoshop with these settings shows 3 small pictures, and a black picture. The colors aren’t correct, but the image is clear, and photoshop wants to treat them a CMYK files.

    The file probably needs to be endian swapped, and the first 44 bytes is probably a header.

    These appear to be the textures used in the Knowledge World part of the game.

    The mjp files also need to be endian swapped. The beginning text is AVIM, and there is an IFFJ chunk a little ways down the file.

  7. CDoty

    The actual format is:
    1024 x 128 15 bit pixels (xBBBBBGGGGGRRRRR), with a 44 byte header. On a PC the bytes need to be swapped, and then converted to 24 bit.

    Here’s the code that I use:

    WORD *Buffer = 16 bit Image data without the header

    BYTE *OutBuffer = 24 bit output buffer, holds 3 8 bit values per pixel.

    for (DWORD Loop = 0; Loop > 10) > 5)

  8. CDoty

    {
    WORD Value = Buffer[Loop];

    // Ugly way to swap bytes in a word
    BYTE *SwapVal = (BYTE *)&Buffer[Loop];

    BYTE Temp = *(SwapVal + 1);
    *(SwapVal + 1) = *(SwapVal);
    *(SwapVal) = Temp;

    // Extract BGR data (from 555 16 bit pixel data)
    BYTE Blue = ((Value & 0x7C00) >> 10) > 5)

  11. CDoty

    // Write data to buffer
    OutBuffer[Loop * 3] = Red;
    OutBuffer[Loop * 3 + 1] = Green;
    OutBuffer[Loop * 3 + 2] = Blue;
    }

    This is for the PTX files.

  13. CDoty

    The MJP file will show ‘something’ in the VLC player. You have to byte swap the file, and clip everything up to ÿØÿà in the file (offset 76). This shows some rainbow colored screen for the 101kw_movie.mjp. 102kw_movie.mjp is corrupt, and 104kw_movie.mjp shows nothing. This is most likely a problem with VLC, since it also plays this video poorly:

    http://img.ferra.ru/for_articles/26004/video1.mjp

  15. sam

    I’ve a surveillance camera movie file with format of MJP. I tried several palyers to open and play it. But only VLC player shows a balnk gray color picture for the whole lenght of the play time. Can any one help me with this to how open and play this damn file?

    thanks

  16. Multimedia Mike Post author

    Your security camera probably outputs a slightly customized variant of motion JPEG.

Comments are closed.