OK, 23H45 time to stop working on the thing, back to work soon...
Spent time doing all sorts of tests on the vintage PC, swapping drives, floppies, cables, BIOS settings... I think I covered it all.
I am now starting to think that my earlier assumption that the straight floppy cable that came with the programmer, was bad.... was wrong.
Turns out that the problem is neither the drive nor its cable... nope. After countless experiments, it turns out believe it or not, that the problem is the old PC itself !
This IBM with proprietary PSU, motherboard and BIOS and cases and everything... which is already known to have compatibility issues with mundane stuff that worked just fine in every other PC under the sun of back in the day.... also does crazy shit with the floppy drives !
I now understand why this PC came with this strange floppy cable that's twisted YET has only one plug, it can only connect to a single drive.. yet it's twisted.
Turns out, the computer will NOT work if you try to use a straight cable with the drive set to be the primary drive ! Nope !
Does not matter if it's my DD drive, or the OEM IBM branded HD drive, or any of the jelly bean HD drives I have in my junk boxes...
If you use a straight cable, the computer fails to boot. The BIOS forces you to visit him, and there you will see that it decided to use the following settings :
Drive A = NOT INSTALLED !!!
Drive B = 1.2MB 5.25" !!!
It does that no matter what drive type I give it.
So then I rectify the settings by hand, so it looks like :
Drive A = 3.5" 1.44MB (the only option for 3.5" drives, but works fine for the DD drive as well no worries)
Drive B = NOT INSTALLED
So I save these settings and reboot and... nope, computer fails to boot again and again the BIOS resets the settings to the weird stuff I just described, it really insists.
So I insist as well : I force it to boot and load MS-DOS, but of course it does not work : drives no matter which one, cause IMD to hang / crash if you try to access the drive to do anything.
So this means I can not use the PC to test if the DD drive works fine with its straight cable as Drive A, so as to rule out a cable or drive selection issue within the drive itself.
So I need to get / buy a different vintage PC, one that's not a proprietary shit IBM... but rather one that uses standard PSU and motherboard and BIOS. More cost. I hope I can find a decent one for cheap locally.
Tried using the DD drive as drive B on the programmer but no joy, still beeps at me at power up.
ALSO
I read the user manual for the 5000. Turns out I don't have 3 different manuals in the end.... no, it's just one big manual, Word document, but they split it into 3 pieces. One of the 3 contains all the stuff about using the serial port remote control. Lots of good pornographic stuff in there, which confirms what we figured out so far.
My conclusion is that the two commands that caused problems and hung the programmer... should have been harmless.
First it hung when I ran the MECK command. This command let's the user calculate the CRC of a given block of data within the user RAM. So you are supposed to follow the command with start/end address parameters, then it will return the Checksum. So what the programmer was supposed to do is reply ERR #1 because the command was invalid since I failed to supply the required parameters.
Instead it just hung. Not normal.
Then the next problem was when I ran the TSDR command. The group of commands that start with TSxx is used to perform tests on the programmer's H/W, for diagnostics purposes.
There are 5 of these commands to test the DRAM, SRAM, CPU ROM, the removable test fixture where you plug the chip to be programmed, and another command to test some module I think you can plug instead of the test fixture.... whatever. None of these commands require parameters. You just type the command name, the programmer tests the DRAM (in my case) and once done it returns 00 to say that the DRAM tested OK (or not)... and it DID do that the first time I typed this command ! It's only the second time I issued it, that it started working on the floppy drive then crash, then fail to boot again and again and again....
Reading the description of some commands, at a quick glance, it looks like it IS possible to mess up the programmer if you use some commands the wrong way, or not in the right order.... so possibly I could have messed it up. HOWEVER it should all have cleared up upon power cycling it, as there is no non-volatile memory in this programmer that I can remember of !
And anyway, if the programmer CAN be rendered non-bootable just by typing some random crap on the serial port, WOW that's a crappy product !
So I don't believe that it is it...
I now think there is a genuine problem and that it's nothing to do with the drive or cable or floppy.
A while back when I started working on this programmer, I noticed that if I shorted the 5V rail, it would reboot itself. Not so surprising I hear you say...
So I think, maybe, that's what happened when I typed that TSDR command.... not because of the command itself, but just that as a coincidence, at the same time maybe some tantalum cap died and shorted the supply, causing the programmer to reboot... but it can't boot now because maybe the failed cap caused more damage around it when it died. Either that, or its absence (open circuit / no decoupling anymore) caused some issue with the integrity of some vital digital signal... most likely in the FDC board of course....
Now I remember it, on that French forum they said that the FDC board had a vital cap used for timing, that liked to fail and caused the FDC / boot to fail !
So I will just pull all 5 boards out of the programmer and inspect all the tantalum and alu cap I can find.... back to basics I say !
One other member with boot problems on that forum also said he had to replace a couple TTL chips, but didn't give any details....
Forgot to say : the manual gives a list / description of tons of error codes but of course does not cover the ones I get...
So maybe they are not "user level" codes, but more low level codes for debug purposes, destined to the engineers designing this thing.
This further reinforces the hypothesis of a board failure....
So for now that's my best guess, please cross all your fingers....