Thanks for the replies. I don't have any pro data recovery tools. I can bit bang the ATA bus, though.
I have a lot of ideas about the G-list. Aside from translating them into physical locations so I can find out more about the media damage, I would like to see if large operations involving a G-list spot can be made faster by growing the G-list, by defecting all cylinders in an entire physical track instead of just one hard sector.
And reading data hidden by the G-list (it's probably not wiped with SECURE ERASE) is interesting too, I wonder if I have to take them out of the G-list or if there is a special read sector command that will allow direct addressing without going through the translation/mapping routines in the disk firmware.
So. I'm wondering about how to find the vendor specific commands. I identified 29 command bytes that are possibly implemented as vendor specific. Surely, not all of them are. Probably, Maxtor uses a group of opcodes that are next to each other. Maybe 0x8x is a good place to start.
In the case that some of the vendor commands work like ie. the SMART (0xB0) command where the feature byte is used along with the command byte to complete the command, this could take a long time to figure out.
So I'm thinking of scanning these for results with only the command byte set and all other bytes cleared to 00 (feature, address.) Maybe, I will get lucky, and if I stumble on some kind of write command, it won't do anything bad to write 0 sectors to LBA 0. Maybe I will not be so lucky and will format the SA by looking for commands.

I will have to look at the results very carefully to see if any hints are returned in the status register to help determine if a command byte deserves further investigation. Probably, an unimplemented command will come back with ABRT high. If I send a "supported" command with bad arguments, I hope something else will happen, like another error bit, so these can be differentiated.
I have found other 'undocumented' commands in protocols by pushing the object through IDA. A tool like that makes it pretty easy to find the branching structure of the command processor. Since the device responds to the ATA bus in safe mode, the bootloader must have a command processor. I wonder if this ARDENT chip, obviously an ASIC/SoC, uses a "common" processor core...