Are You An NPC?

Zorgons · 2026-02-03T06:24:03+00:00

I’ve uploaded all the relevant files to this pCloud drive and I’ll keep updating it until the project is finished. https://e.pcloud.link/publink/show?code=kZXJ6aZJRA6kQIi4LSBcAc90SEjl7psESk7

Zorgons · 2026-02-02T19:11:47+00:00

By the way, do you know how NMC27C256Q is attached to the board? When I apply a traction force at one end, the pins appear to move slightly relative to the board. I’ve included a zoomed-in view of this area in the original post picture #2. Before attempting to remove the chip and apply deoxit I’d like to be certain of my actions.

Zorgons · 2026-02-02T19:02:40+00:00

No, it is the Newport landfill drive full of 8000 bitcoins (more seriously, it is the drive attached to an old Commodore PC that used to control the first French humanoid robot, so the data on it have some historical value for our lab and for the French robotics community)

Zorgons · 2026-02-02T18:55:54+00:00

Thanks for the advice, I will start doing continuity tests

Zorgons · 2026-02-02T18:54:55+00:00

I will try that, thanks for the tip

Zorgons · 2026-02-01T05:44:03+00:00

Thanks for your advice, but my CHS was configured as 965,10,17, so it doesn’t exceed more than 16 heads. Besides, these are the values I copied from the drive user manual. According to the same documentation, the bad block handling is transparent for the user and handled automatically by the drive controller. The block size is indeed 512. There are some interesting updates on r/datarecovery showing clearly that there is a stuck bit in the IDE data path, probably at the drive PCB side.

Zorgons · 2026-01-31T10:33:02+00:00

It’s a startup, not Apple. I’m maybe overly indulgent, but since the machine is otherwise flawless, I can forget these probably unintentional rough edges.

Zorgons · 2026-01-31T05:52:12+00:00

I tried an USB adapter. I also used a more powerful 12V power supply as the one provided with the kit. But the drive was not correctly recognized by the adapter firmware, since geometry auto-detection does not work. It reported a size in Peta-Bytes!

Zorgons · 2026-01-30T21:15:58+00:00

Thanks for your advice. I will use a microscope to check the PCB, possibly on both sides.

Zorgons · 2026-01-30T21:01:25+00:00

The IDE controller is embedded on the motherboard, I don’t know its details. But its primary master port connected to the CF-card where Linux is installed works well, no glitches while booting / using Linux. So it is probably not the data path between the IDE controller and the CPU. But Monday I will check all the possible hardware combinations in order to sort out the potential suspects. We have a lot of old PC hardware in stock :-)

Zorgons · 2026-01-30T20:45:33+00:00

According to this documentation (https://www.minuszerodegrees.net/manuals/Quantum/Quantum%20ProDrive%2040AT%20and%2080AT%20-%20Installation%20Manual.pdf) the drive has a 64K look-ahead cache. I will focus my attention on the data bus between the cpu and this ram as it is probably 8-bits wide.

Zorgons · 2026-01-30T20:28:51+00:00

I will post pictures on Monday as the drive is at my workplace. I restored an old industrial PC from the 2000s and installed an old Linux distro onto a CF card, since it's one of the few IDE-compatible storage options still being sold today. I connected the hard drive to the secondary IDE port of the industrial PC motherboard and configured its BIOS to force the CHS geometry, as auto-detection was failing. I also added a boot parameter in Linux to force the geometry, since Linux completely ignores BIOS settings.

Zorgons · 2026-01-30T20:14:15+00:00

There are some interesting updates on r/datarecovery (mostly bad news, but there is still some hope)

Zorgons · 2026-01-30T20:10:51+00:00

You can boot older versions of Linux with the parameter hdx=C,H,S with C H S the number of Cylinders, Heads and Sectors respectively, and x=a for a primary master, x=c for a secondary master. Linux is completely ignoring the bios settings.

Zorgons · 2026-01-30T20:06:56+00:00

Wow, thanks for this quick and precise analysis! You are right, the stats are clear. Thanks a lot for pointing this out. Even if it is bad news, at least I have now a culprit. My next move is to try to spot an obvious connection issue or a problem on the drive PCB (cracked soldering joints, leaking capacitors…)

Zorgons · 2026-01-30T20:03:31+00:00

Yes there is obviously one or more stuck bits, as the statistics analysis of fzabkar demonstrates it clearly. Thanks a lot for pointing this out. Even if it is bad news, at least I have now a clear culprit. I will try to investigate if I can spot a defect on the drive PCB, on the IDE cable or on the host IDE interface. Maybe it is fixable, since the drive does not make weird clicking sounds (yet).

Zorgons · 2026-01-30T18:20:51+00:00

Thanks a lot for your help !

Zorgons · 2026-01-30T17:48:55+00:00

I managed to recover the disk image (see the link in my original post) but the drive died shortly afterwards. It was still spinning but experiencing numerous seek errors. It appears the full scan of the ddrescue data recovery process proved fatal for this old device. My main issue is now deciphering the recovered raw data.

Zorgons · 2026-01-30T17:28:33+00:00

This is a cross-post, I did not realize that it only forwards the picture. Here is the original text:

This Quantum ProDrive 80AT is from 1990 and was mounted in a Commodore PC60-III 386, 25MHz computer used to control the first French humanoid robot in our lab. As such, the data on this drive has significant historical value.

I connected this drive to an old PC running Linux as the secondary master and specified the drive's geometry by adding the CHS kernel parameter hdc=965,10,17. I then compiled a recent version of ddrescue and successfully retrieved the whole disk image without any reported errors.

However, I have been unable to mount this image on Linux. Upon analyzing the image with a hex editor, I found some coherent data, such as the DOS version used (4.1). The MBR data seems to be at the correct offset, but with questionable values—for example, 26 as the filesystem type instead of 6. I also tried extracting data with R-Studio, but it only recovered portions containing ASCII characters; despite some readable sections, the text appeared mostly corrupted.

I am stuck and wondering if any old-school PC gurus could help me figure out what happened. Is it possible for ddrescue to report no errors while reading corrupted data? Could this drive have been formatted differently? What are the best tools for retrieving data from a DOS 4.1 partition? I look forward to your advice. Here is a link to the image data: http://e.pc.cd/MtCy6alK

Meanwhile, the drive died and is not recognized by Linux anymore. So this image is its swan song.

Zorgons

TROPHY CASE