Dear all, I have made a small program that parses
Create Sub Map using Head Info .map files into legacy binary maps.
With this little tool, one can parse the said .map files into larger binary maps that is acceptable in DDI.
This enabled me me parse maps of Seagate,Samsung, Charger,Palmer to my beloved DDI and enabled me to image such drives with control over switching off heads/ switching to next heads and all the other functionality that exist.

I tried to add more information regarding average zone size, skip size, amount of size covered per head etc... that would help to image the faulty drives by setting the parameters as per the summary generated by the parser ( one needs to manually set in DDI 'available configuration' tab.

It is noted that it is very essential for your utility that generates sub map using heads info to create sum of length of chains equal to the final LBA/Size of the drive.

To use this file, unzip it to a location... add your map file in the inputmap folder. Use DevC++ and edit the name of input file as per your file name on line number 61 of the To_Upload.cpp code
I will try to upload a small video of how to do the above steps and compile.

Let me know how it works for all of you.
Thanks

Sin
PS: Thanks Serge for allowing me to put this freely and being supportive of my small pursuit of parsing the maps so I can day in day out use my DDI solely for creating quality images of drives that cant be traditionally headmapped.

Thanks to sourcerer for mentoring me and getting the best out of me to have the outputs presentable enough and giving great inputs in the journey (i would post outputs of how it looked earlier in initial stage of dev and you can see how it looks now with so much of more info that we both could think of.)

thanks ACE for allowing me to share my small parser.

and last but not the least: Thanks PEPE! YOU ARE MY MAN.. I demanded some reference file from him and he instantly gave it to me.

Also, use it at your own risk! just in case if i missed mentioning that.

video link https://youtu.be/EoTOXK3yyvc

Congratulations.

thanks!
Lastly, this was not coded by any of the mfgs.. They are gods...Gods don't code in such a messy way.... ok?


FYI
this is strictly a personal project for self learning....I no way take responsibility and all the mfgs stated are indemnified aswell
---

Is there any reason why you should use DDI to image the drive rather than DE? Or have you written this tool so that PC3K users don't need to purchase DE if they already have DDI?

_________________
A backup a day keeps DR away.

Hey, i am quite a novice DE user but an experienced DDI user. Apparently, this function of map interchangeability existed in the past till some point. How ever, the case is not the same any more.

One requires both the tools for parser to be useful.
I wrote it purely to have some fun and experiment. However, there is a serious research going on the conventional heads.map file which is far more complicated to parse. Won't say 'not possible' though.

The skill set gained just increases employ ability, i believe.

--

here you go : https://www.data-medics.com/forum/ddi-to-de-t2565.html

That makes sense. Thanks for the tool. Hopefully I'll learn something, too.

_________________
A backup a day keeps DR away.

you are so humble
<3
--

Just a couple of questions ...

There are sections of unicode text which you refer to as footers ("Head#n").

For example, this is "Head#1":


It would appear that the first word is a character count, ie 6. AIUI, your code assumes that the maximum head number is 9 ("Head#9"). I'm wondering what would happen if there were a case where the head count were 10 or greater. Would the 10th head become "Head#A" or "Head#10"? In the latter case, would the word count become 0x0800 rather than 6?

IIUC, the MAP file consists of a short header followed by fixed length records of size 0x2A.

Here is an excerpt form palmertest.MAP:


AFAICT from your code, this is the structure of these records:


Can you tell us what bytes 8 - F mean?

I notice that for other drives, eg Vinod.MAP, the first two parameters are always identical:

Are bytes 18 - 1B always 0? Do you know their meaning?

_________________
A backup a day keeps DR away.

You are very correct. I have limited the parsing to just 10 heads. Infact I do not have any hard drives right now with me that have 10 heads. (Usual drives for recovery in my place are of 160GB to 4TB capacity, 4TB being really rare)
I guess a 4tb palmer/charger would have 10 heads but sadly I do not have any donated pieces by customers for any experimentation (yes openly ask for a donation from the client once the recovery is done and the client has checked his data+ backed it up else where. Some people love us enough to donate it


Generic record size that I could set was of 2A length, you are correct



For heads more than 9, It should ideally go up in its count as in 3A to signify 10 heads.. and thats where the footer count should increase intuitively (bytes 1E - 29)


bytes 0 - 7 start LBA ------------------->Is repeated in the same 7 bytes fro 08 to 0F
bytes 8 - F ?? --------------------> examine the heads footer at end of file, you will see 0-7 == 8-F i believe

bytes 10 - 17 size in LBAs
bytes 18 - 1B always 0x00 ? yes atleast for the ones i checked uptill 4tb
bytes 1C - 1D number of unicode characters in "Head#n" footer
bytes 1E - 29 "Head#n" footer ....never paid attention...but seems legit, need more heads to really verify.

Are bytes 18 - 1B always 0? Do you know their meaning? so far yes, they are empty .....empty across quite a few maps i checked.

I ignored the header for now completely as most of the job was getting done for the capacities that I got without accounting for the header.

It will be cool if people can test it with drives larger than 4tb and share the submap here.

well wait a sec I was wrong.

Try to carve out a few segments from any mapfile

try below file

ISTM that the head number is an ASCII code, eg "1" = 0x31 ASCII. Therefore 0x3A would be the ASCII code for a colon ":". Instead I would expect to see 0x41 (the ASCII code for "A"), if the head numbers were hexadecimal.

Otherwise, in the case of decimal numbers, I would expect to see "Head#10" -> 0x48,0x00,0x65,0x00,0x61,0x00,0x64,0x00,0x23,0x00,0x31,0x00,0x30,0x00

As for bytes 8 - F, look at the Palmer example.

_________________
A backup a day keeps DR away.

So just take any length of any example .map file provided.

Just in the .H.E.A.D.#.XX area put 3A and the parser would parse it as 10 heads.


just increase the size of the arrays which are globally declared to account for more than 10 heads. WOULD WORK IF THEY ARE USING HEX TO STORE IT THIS WAY

float data_sum_of_length = 0 ;
float GB_TOTAL =0 ;
float head_lba[10] = {0}; this one
float head_lba_total[10] = {0}; this one
int enable_debug = 0;
int save_lba_log = 1;
int number_of_zone = 0;

--

Just try this..I have tried a hex value, it works..however not sure if thats how the company would store too
carve out a section...
however for more than 10 heads, you will need to increase the array sizes too for the code to work

but as fact of matter, i really do not have an idea what methodology ACE is using to store...can be hex, can be ascii.
Hex seems reasonable though

I don't think that is correct. I think the footer is a Unicode text string. It doesn't make sense to me any other way. I believe you are overthinking this parameter.

_________________
A backup a day keeps DR away.

Also, the palmer example provided is a 1tb drive...2heads. I guess. Sorry..many things have not been documented in the right way..i need to learn good documentation for sure.

correct, if it is unicode, which is reasonable too because they have it displayed in the ABOUT coloumn...parser wont work for more than 0x39 value.