Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Partner Mail VS R3.0 hard disk contents

Status
Not open for further replies.

cybertheque

Technical User
May 15, 2011
30
0
0
US
Surely someone out there has investigated the contents of the hard disk in various Partner Mail VS versions or has some knowledge of the operating software and data organization. I was surprised to find that the disk from a Partner Mail VS R3.0 (350MB Conner 2.5 inch) is formatted FAT16 under MSDOS 5.0 and contains a file system of numeric directories with one level numeric subdirectories which might contain some small files with numeric names, eg. 60\00\37

Except for the MBR area, there are no embedded strings anywhere else on the disk. The contents of the small files appear to be compressed as there are no repeating blocks of any character, especially '00' (consistent with a low datarate codec?). Even swapping bytes to account for the big-endian Motorola CPU doesn't make any difference.

The processor is an 8MHz M68000, and the board does not appear to have enough flash memory to contain the operating code, which also seems to be booted from the disk considering the time it takes to start and the activity of the status LEDs. There is 32k bytes of possible code between the MBR and the start of the FAT partition, no where near sufficient for the application.

The FAT16 partition occupies the rest of the drive:
(output of chkdsk)
The type of the file system is FAT.
Volume PARTR3-1-6 created 1/5/1996 4:02 AM
Volume Serial Number is 2856-0BCE
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problem.

349,691,904 bytes total disk space.
6,193,152 bytes in 756 folders.
71,041,024 bytes in 6,512 files.
272,457,728 bytes available on disk.

8,192 bytes in each allocation unit.
42,687 total allocation units on disk.
33,259 allocation units available on disk.

There are no hidden or 'system' files present.

This is quite a mystery. Where is the operating code? There are a few files of about 100k bytes in the filesystem, all of which have contents which look like the same sort of data in the little 1k byte files elsewhere. One could presume that all of this data is encoded audio absent any other evidence.
 
Processor resources according to R3 Programming Manual:

68000 microprocessor, 256Kbytes RAM, 512Kbytes ROM

Voice encoding method: Regular Pulse Excitation—Long Term Prediction (RPE—LTP) Linear Predictive Coder
Digital Signal Processor (DSP), 16 bit

Perhaps 512kB are sufficient to hold the application.
 
Maybe a clue is you can't put an r4 drive in an r3 mail. Each drive is version specific.
 
Been futzing with 'sox' trying to play some of the files on the drive assuming they are full-rate gsm (RPE—LTP) but getting
"result too large" errors. Guessing 16 bit precision. Tried little and big endian byte order. Sample rate isn't relevant to scaling but guessing 13kbps. It would be great if someone stumbles on a set of arguments that actually gets some sound out of them. Here are the contents of a directory "\02\21":

 
The audio file data does not conform to any of the containers for gsm according to RFCs and other authoritative sources, for example RFC 1890 and 3351 describe a frame of 33 octets each beginning with the upper nibble of the first octet having the value 0xd; example gsm sound files do indeed conform to this structure but the files from the partner vs do not, even after endianness conversion. It would appear that the data although RPE-LTP encoded is framed in a non-standard fashion.

It would seem likely that for forensic purposes or as a development tool, someone would have written code that can process this data. Anyone have info?
 
I don't know but one thought is that the data is not in a container. You can save space by making assumptions. If you assume that all audio is compressed to the same format then why put those headers for the format in the file.

That would make all of the data the audio.

Just a thought. That is the way some video games saved their audio and video data.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top