RK8-E debugging

[thunter0512]

Here is a short video with OS/8 loaded via the now fixed RK8-E, BASIC started with "OLD,SPACWR", then compiled and running and waiting for input showing the typical shifting pattern in AC:

There is a lot of disk activity to get to this point. It is not quite the full "RK8E Drive Control Test", but the next best thing.

Over the next few days I will exercise the controller with multiple drives using maindec-08-dhrkb-e-pb and will report back how that goes.

For now I am glad that I managed to find all the failure causes and repair them with parts on hand.

 

[thunter0512]

I tried the "DHRKB RK8E Drive Control Test" maindec-08-dhrkb-e-pb with George Wiley's emulator. After about 25 minutes it reports:

STATUS REGISTER ERROR
PC:3450 GD:6000 ST:6002 CM:0000 DA:7106
CR:015061 ST:4002 DB:2525 CM:0000 DA:0006

The RK05 emulator is using the last firmware I got from George with some "enhancement" I made. Tomorrow I will be busy with other things, but Wednesday I will revert to the original firmware which I have tested thoroughly and where I have 100% confidence. I have seen occasional odd issues with the newer firmware which supports the new disk image format since I added my "enhancement".

 

[thunter0512]

...
I had a bunch of DS8640 (from China) which are meant to be compatible with the SP380 and only a small number of SP380, so I replaced E2 with a socket and tried the Chinese DS8640 first. I did superficially tested a few of these when I got them and they seemed to work. Anyway after running my diagnostics with the Chinese rubbish I saw now bits 0 - 3 all stuck high. I am glad I used a socket.

After replacing the DS8640 with a SP380 my mini diagnostic was perfectly happy, but more importantly the maindec-08-dhrka-e-pb run a bit further:

I have now tested all 4 NOR bus receivers of the Chinese DS8640 on a breadboard with the appropriate 180R pull-up to 5V and the 390R pull-down to GND on both inputs.

All 4 gates work as expected. I can't explain what I have seen in circuit (all 4 bits stuck high) vs what I observe on the breadboard.

The only difference is that I am testing the 4 gates sequentially not all 4 at the same time (so only 1 gate has the pull-up/down resistors applied to its two inputs).

Any ideas?

 

[thunter0512]

I tried the "DHRKB RK8E Drive Control Test" maindec-08-dhrkb-e-pb with George Wiley's emulator. After about 25 minutes it reports:

STATUS REGISTER ERROR
PC:3450 GD:6000 ST:6002 CM:0000 DA:7106
CR:015061 ST:4002 DB:2525 CM:0000 DA:0006

The RK05 emulator is using the last firmware I got from George with some "enhancement" I made. Tomorrow I will be busy with other things, but Wednesday I will revert to the original firmware which I have tested thoroughly and where I have 100% confidence. I have seen occasional odd issues with the newer firmware which supports the new disk image format since I added my "enhancement".

I get the exact same problem with George's original RK05 emulator FPGA firmware and Pico software as found on GitHub on 2024-07-07. I have tested this version thoroughly with the original RK8-E and know that it works reliably.

This means that there is still some obscure fault in my mostly repaired and somewhat working RK8-E.

Note that it runs OS/8 just fine.

 

[gwiley]

I have now tested all 4 NOR bus receivers of the Chinese DS8640 on a breadboard with the appropriate 180R pull-up to 5V and the 390R pull-down to GND on both inputs.

All 4 gates work as expected. I can't explain what I have seen in circuit (all 4 bits stuck high) vs what I observe on the breadboard.

The only difference is that I am testing the 4 gates sequentially not all 4 at the same time (so only 1 gate has the pull-up/down resistors applied to its two inputs).

Any ideas?

Possibly a marginal threshold issue with the Chinese parts, although I'd think there would be well-defined digital level in this circuit.
I had issues with Chinese counterfeit parts that had threshold voltages that were quite far off the mark. Maybe your parts have something like the Joyhot parts in the image below.
Here's an example: https://forum.vcfed.org/index.php?threads/restoring-a-pdp-8-l.1239827/post-1275821

The Vout vs Vin was measured using a variable power supply connected to one input and a voltmeter on the output.

 

[thunter0512]

I tried the "DHRKB RK8E Drive Control Test" maindec-08-dhrkb-e-pb with George Wiley's emulator. After about 25 minutes it reports:

STATUS REGISTER ERROR
PC:3450 GD:6000 ST:6002 CM:0000 DA:7106
CR:015061 ST:4002 DB:2525 CM:0000 DA:0006
...

I have now toggled SR0 to 1 and toggled CONT. This enters a scope loop which allows me to nicely observe what is happening on the cable between the RK05 emulator and the RK8-E.

The first thing I noticed is that the RK05 emulator reports an invalid cylinder address to the controller. The cylinder address on the cable at the time of the address strobe is indeed an invalid 226 decimal. The valid range is 0 - 202.

@gwiley I will talk to you offline about some interesting timing details.

What is really interesting is that the maindec-08-dhrkb-e-pb firmware is actually trying to seek to a different and valid cylinder number not what I see on the cable. The address bits are active low, so I inverted them to arrive at the address, but it is definitely out-of-range. The cylinder address and drive select comes out of the CRC register. It almost looks like some bits are stuck there, but the previous "DHRKA RK8E Diskless Control Test" maindec-08-dhrka-e-pb verified the CRC register as good. Also too much works for the CRC register to have a fault.

As I am writing this I just realised that the CRC register is indeed storing the out-of-range cylinder address of 226 (decimal):

Here is the current error reported by maindec-08-dhrkb-e-pb:

STATUS REGISTER ERROR
PC:3450 GD:6000 ST:4002 CM:0000 DA:2021
CR:016126 ST:4002 DB:2525 CM:0000 DA:0021

Right shift the current CRC 16126 by 5 bits and you get 342 which is 226 decimal matching my fault address as observed on the cable. The software tries to address a different cylinder

The original error was:

STATUS REGISTER ERROR
PC:3450 GD:6000 ST:6002 CM:0000 DA:7106
CR:015061 ST:4002 DB:2525 CM:0000 DA:0006

Right shift the original CRC 15061 by 5 and you get 321 or decimal 209 which too is out of range.

I will hook up the logic analyser to the relevant bits of the CRC register and the control lines to see what is going on.

It is well past midnight - time for bed.

 

[gwiley]

I have now toggled SR0 to 1 and toggled CONT. This enters a scope loop which allows me to nicely observe what is happening on the cable between the RK05 emulator and the RK8-E.

The first thing I noticed is that the RK05 emulator reports an invalid cylinder address to the controller. The cylinder address on the cable at the time of the address strobe is indeed an invalid 226 decimal. The valid range is 0 - 202.

Interesting fault given that so much other stuff seems functional. Is this the wrong cylinder address repeatable every time through the scope loop?

@gwiley I will talk to you offline about some interesting timing details.

Thanks for sending the timing details. I can create a seek loop sequence to cylinder 226 in the RK05 tester to observe the bus signals.

What is really interesting is that the maindec-08-dhrkb-e-pb firmware is actually trying to seek to a different and valid cylinder number not what I see on the cable.

Very interested to learn what the RK8E is doing to output the wrong cylinder address.

 

[thunter0512]

...
As I am writing this I just realised that the CRC register is indeed storing the out-of-range cylinder address of 226 (decimal):

Here is the current error reported by maindec-08-dhrkb-e-pb:

STATUS REGISTER ERROR
PC:3450 GD:6000 ST:4002 CM:0000 DA:2021
CR:016126 ST:4002 DB:2525 CM:0000 DA:0021

Success at last running maindec-08-dhrkb-e-pb on my now fully repaired new RK8-E:

RK8E DRIVE CONTROL TEST PASS COMPLETE
RK8E DRIVE CONTROL TEST PASS COMPLETE
RK8E DRIVE CONTROL TEST PASS COMPLETE

To get here I replaced the occasionally glitching IDLE flip-flop E18 on the M7106, but it was not causing the "STATUS REGISTER ERROR - PC:3450" problem. As it was behaving strangely while probing I replaced it with a new one:



The real problem was that during the DCLR IOT with AC containing 0002 used to recalibrate the RK05 to cylinder zero, the emulated RK05 drive took the cylinder address on the cable and checked it to be valid. Unfortunately in this context the cylinder address on the cable is just left over garbage (a previous CRC) from the CRC register which also serves as the cylinder address register before the actual Read/Write data transfer.

This meant that depending on the CRC register contents sometimes the DCLR IOT caused status register bit 0002 to become set which caused the diagnostics to fail.

The emulated RK05 drive did actually attempt to ignore the cylinder address in the recalibrate context, but there was a small bug in the implementation which has now been fixed.

 

[thunter0512]

Here is a small diagnostic program I wrote to exercise the failing RK8-E DCLR IOT with AC containing 0002 used to recalibrate the RK05 to cylinder zero:

   1               / RK05 DIAGNOSTIC
   2                       DSKP=6741
   3                       DCLR=6742
   4                       DLAG=6743
   5                       DLCA=6744
   6                       DRST=6745
   7                       DLDC=6746
   8                       DMAN=6747
   9               
  10                       *20
  11 000020  0200  K0200,  0200
  12 000021  4000  K4000,  4000
  13 000022  7001  KINIT,  7001   
  14               
  15                       *200
  16 000200  7301  START,  CLA CLL IAC     / CLEAR AC AND CONTROLLER
  17 000201  6742          DCLR            / ...
  18 000202  1022          TAD KINIT       / UNUSED FUNCTION + EXTENDED CYLINDER BIT COMMAND REGISTER
  19 000203  6746          DLDC            / ...       
  20 000204  7240          CLA CMA         / DISK ADDRESS REGISTER = 7777
  21 000205  6743          DLAG            / ...
  22               
  23               / NOW RECALIBRATE
  24 000206  7300  AGAIN,  CLA CLL         / CLEAR AC AND STATUS
  25 000207  6742          DCLR            / ...
  26 000210  7326          CLA CLL CML RTL / RECALIBRATE
  27 000211  6742          DCLR            / ...
  28 000212  6741          DSKP            / SKIP ON DONE OR ERROR
  29 000213  5212          JMP .-1         / WAIT FOR IT
  30 000214  1020          TAD K0200       / ENABLE DONE BIN IN COMMAND REGISTER
  31 000215  6746          DLDC            / ...
  32 000216  6741          DSKP            / SKIP ON DONE OR ERROR       
  33 000217  5216          JMP .-1         / WAIT FOR IT       
  34 000220  6745          DRST            / READ STATUS
  35               //        CIA             / COMPARE TO EXPECTED VALUE
  36               //        TAD K4000       / ...
  37               //        SZA             / SKIP HLT IF AS EXPECTED
  38               //        HLT             / ERROR
  39 000221  5206          JMP AGAIN       / REPEAT
  40 000222  7402  FINISH, HLT             / Normal good halt
  41 000223  5200          JMP START
  42                       $

 

[thunter0512]

Now that my new RK8-E is fully repaired and working with all diagnostics and OS/8, I though I show the collection of 6 "bad boys" who challenged me during this repair adventure:



Without mercy I chopped their legs off and replaced them with their well behaved twins.

No passives were harmed during the debugging and repairs.

 

[ftcnet]

Did all three M710n modules have bad IC's? I suppose I could figure it out from your posts, but I'd be interested in which boards had which faulty chips?

 

[thunter0512]

@ftcnet all three boards (M7105/5/6) had faulty ICs. Debugging is tricky because the logic is somewhat spread out over all three boards despite the names in the schematics like "Data Buf & Status", "Major Registers" and "Control" which imply nice partitioning. The hand-drawn schematics are messy and hard to read too. Vince's redrawn Eagle schematics are very helpful. Thanks @vrs42 !

To figure out which ICs were replaced on which boards please refer back to my posts.

 

[vrs42]

Vince's redrawn Eagle schematics are very helpful. Thanks @vrs42 !

You're welcome. I'm glad to see them being useful!