Polar Instruments DDT Disk drive tester - Firmware needed !

[pedrocelli]

Since many years I'm using a Polar DDT Disk drive tester for function test of 3.5, 5 1/4 and 8 inch floppy disk drives.
The tester was made about 1989 by Polar Instruments Ltd (founder Doug Campbell).

The tester has become unreliable during startup, as it shows a checksum error, and occasionally it does not startup at all. Sometimes it works. Checking the internal ROMs showed, that bits of the firmware are not stable, others may have changed already.

I would like to program a new ROM, but need a working firmware file for it.
Attached a picture of the unit and the current dump of the firmware. The software version is V2.2 on a 32kB Eprom.


In first place, I've contacted Polar customer service, which have kindly responded, but no firmware or a device could be found anymore.

So, my hope is, that someone else owns this unit and could make a copy of the standard 32k internal Eprom.

[aeg]

Maybe try reading the ROM at reduced Vcc. This lowers the threshold, so it might make the flaky bits read OK.

[pedrocelli]

My initial attempt was to heat up the Eprom during the read operation of the prommer. A few bits changed and it seems to better match to the disassembly program flow. But burning this data into a new Eprom didn`t let to a working system.

As you suggested, I lowered VCC of the Eprom by 0,3 and 0,6 volt, but unfortunately in both cases, the binary data just became more flaky during every read operation and reduced VCC.  In my opinion, VCC variation does not compensate the data degradation.

Hopefully someone else owns a POLAR DDT to get the problem solved.

[aeg]

It looks like the loop at 1675 to 1697 calculates the ROM checksum by mod-256 addition and the code at 169a wants the sum to be zero. But the sum of POLAR_DDT.bin is 254. It could just be one flipped bit in the second LSB position? (Or it could be 254 flipped bits...)

If it reads worse at reduced Vcc, maybe it would read better at increased Vcc? Normally it should read worse at increased Vcc, but maybe some extra charge ended up on unprogrammed bits, rather than charge leaking from programmed bits.

[pedrocelli]

Your analysis on the checksum routine is very helpful. I simulated the routine and it ends up with 254, as you mentioned.
The POLAR_DDT.bin file already had some corrections, based on the temperature treatment and Disassembly (see in the attached text file)
Based on these corrections, it is fair to say, that Eprom values flip on bit zero and on uneven addresses. Therefore address 0009 might be another good candidate and just one bit left ;-)

Including all corrections in a new Eprom, the tester only gets to the boot prompt and stops at "P" of "POLAR DDT". That is strange but could be an indicator, where during the startup phase, the program gets stuck.

The mentioned increase of VCC, I have done during the VCC reduction test. Up to 6V, there was no difference compared to 5V nominal.

[aeg]

Is your EPROM reader scriptable? Maybe you could read the ROM 100 times and see if one of the reads reveals the last wrong bit.

[Fraser]

Have you tried contacting POLAR Instruments. They may surprise you with their helpfulness They have always helped me with vintage Polar equipment when I contacted them. Some smaller companies keep the firmware for their obsolete kit on a server for ‘just in case’ reasons.

Fraser

[pedrocelli]

During the voltage variation test, I read ten or twenty times each to investigate the bit changes. When the voltage was lower, many bit changes showed up randomly, in case of nominal and above, the output was always identical (just by pressing verify). Only in case of temperatur increase, bits changed on specific places. These have been incorporated in the uploaded binary. The "one" or ebentually more broken bits seems to stuck all the time.

[pedrocelli]

Initially, I've contacted POLAR Instruments Sales and Support and I can confirm, they are supportive and help customers with older equipment.
The feedback after a few days from development was, that unfortunately the firmware of the DDT is no longer available and a check for any old device in storage also was unsuccessful. That's when I placed this post to the forum.

[aeg]

Sometimes the unit works. So I think if you read the EPROM 100 or 1,000 or 10,000 times, the bad bit will eventually change.

[pedrocelli]

The existing Eprom always shows a CRC error. In some cases, pressing OK will allow to continue, but most of the time it stuck.
Using the corrected binary and burn it into an Eprom will not show a CRC error (as it has been compensated in the binary) but it always stuck, even earlier in the boot-up sequence compared the original Eprom. So in both cases, some bits have changed.
I also suspect, that reading at processor speed also gives different data compared to reading with a much slower Programmer. Still hope someone else owns this DDT Tester.

[pedrocelli]

Finally I was able to fix the ROM code.
Using Ghidra, a software reverse engineering tool, helped a lot to find the flipped bits in the ROM binary (Ghidra V 11.1.2 was used).
Attached the exported XML project including source code listing and corrected binary image file.

Ghidra provides a powerfull disassembler that highlights strange calls or data refrences.
The best feature is the simply click and jump to calls or data elemnts and the code previwe window feature.
Within a few hours checking calls and strings, the suspiecous fipped bit was found (probaly 50% by luck).

If you want to dissassemble any code from old 8bit up to modern ARM CPU's, Ghidra is my recommendation. 

[tv84]

Finally I was able to fix the ROM code.

Well done. 

[coromonadalix]

 


send it to Polar ...

[tv84]

send it to Polar ...

I don't think they have an active support contract with him...   

[pedrocelli]

Probably it's better placed here on the EEVblog for other to find ... as long Dave keeps the Blog alive 

[coromonadalix]

send it to other hosting  like k4obb   or else ...