OK, took a while but now I got it:
ID Register
The LED displays the A11 DRAM Processor/Display ID in hex: the
most significant nibble (4 bits) first and then the least significant
nibble.
Now I am more lost than before. For this to apply I would expect two hex nibbles
alternating (which would result in a 8 bit "A11 DRAM Processor/Display ID" -
whatever that is) but no ".L".
I have to admit that I don't understand the whole LED thing entirely. We have
Table 1–26: Troubleshooting Procedure For LED Display
and
Table 1–28: A11 DRAM Processor/Display LED (DS1)
which are almost identical apart from that funky "ID Register" in table 1-26 and
some additional stuff in table 1-28.
I think I will have to wait for the console adapter and see if this reveals anything...
Sorry but I still do not understand how you use then isolate the fault thanks to the S1001 switch, why choose 0000 0100 which does not corresponds to any know self-test choice.
When switch #3 is set to close (AFAIK the default), the device runs extensive diagnostics.
This not only makes the startup take significantly more time, it also displays some funky
stuff on the screen.
When switch #3 is set to open, these diagnostics will be skipped:
Table 1–27: DIP Switch Options
DIP Selection (8–1) Action
...
0100 0100 Do not execute diagnostics
...
I assume this was made to provide some kind of quick start when powering on the scope.
Again and again, as mentioned before you need to use the different S1001 testing positions
Well, this does not reveal anything. Which is not of surprise since all those tests apparently are
low level tests checking some basic stuff on the processor board (presumably beeing done by
the boot ROM).
Once the OS has kicked in, more diagnostics might be run (or not, depending on SW3). And these
can be observed on the console (using that brilliant adapter from that guy in Italy which arrived now).
With SW3 set to close (execute diagnostics) we get a rather detailed ouput with some interesting
parts:
...
calLibrarianDefaultCk .......... pass
dspForcedBus ................... pass
acqProcThermistor ..............ERRORID: 62 hardware error acq processor not responding
***FAIL***
..error details:
ERRORID: 151 diagnostic test failure acqProcThermistor
acq processor not responding
** acqProcInit(ACQ_DIAG): Acquisition processor problem
trigGtlRegisterDiag ............ERRORID: 62 hardware error acq processor not responding
i=0 temp=ffff mask = 7f
trigReg[i]=8a TRIGgtlAddr = 72c0800
***FAIL***
..error details:
ERRORID: 151 diagnostic test failure trigGtlRegisterDiag
acq processor not responding
RegNo: 0x72c0914
fpDiagConf ..................... pass
optDiagPM110Reg ................ pass
optDiagFloppyCacheMem .......... pass
optDiagFloppyControllerIO ......0x51ffea8 (tRootTask): duart portB write timeout, byte: a7
0x51ffea8 (tRootTask): duart portB write timeout, byte: 47
pass
optDiagFloppyDrive ............. pass
optRS232DuartIO ................ UNTESTED
...
Smalltalk/V Sun Version 1.12
Copyright (C) 1990 Object Technology International Inc.
ERRORID: 62 hardware error acq processor not responding
0x51efec0 (V main): duart portB write timeout, byte: a8
0x51efec0 (V main): duart portB write timeout, byte: 48
0x51efec0 (V main): duart portB write timeout, byte: a8
0x51efec0 (V main): duart portB write timeout, byte: 48
0x51efec0 (V main): duart portB write timeout, byte: a8
...
Thanks to the first error (acq processor) and that famous "component level diagnostics and repair manual"
the rest was simple: The RX line of the 68HC05 on the acq board was quiet while the corresponding TX
line of the UART on the cpu board was not. In the end it was a bad solder joint on that bus board which
connects the two PCBs (the whole area around pin 85 looked suspiciously). After fixing that, the scope
is up and running.
BTW, when setting SW3 to open (do NOT execute diagnostics), the error appears only at the end:
...
Smalltalk/V Sun Version 1.12
Copyright (C) 1990 Object Technology International Inc.
ERRORID: 62 hardware error acq processor not responding
0x51efec0 (V main): duart portB write timeout, byte: a8
0x51efec0 (V main): duart portB write timeout, byte: 48
0x51efec0 (V main): duart portB write timeout, byte: a8
0x51efec0 (V main): duart portB write timeout, byte: 48
0x51efec0 (V main): duart portB write timeout, byte: a8
...
So I can confirm what building (or buying) that console adapter is highly advisable and the
7-segment LED should be considered only for that very early low-level stuff. I got attracted
by that ".L", assuming it would represent any failure on the processor board, but I didn't
honour the fact that the OS was up and running already...
Then it would be more like something and thermistor.
To be exact, it _is_ more, see "ERRORID: 151 diagnostic test failure trigGtlRegisterDiag"
After fixing the problem, we can also see that diagnostic output has increased significantly.
Here is the diff:
...
calLibrarianDefaultCk .......... pass
dspForcedBus ................... pass
-acqProcThermistor ..............ERRORID: 62 hardware error acq processor not responding
- ***FAIL***
-..error details:
-ERRORID: 151 diagnostic test failure acqProcThermistor
-acq processor not responding
-** acqProcInit(ACQ_DIAG): Acquisition processor problem
-
-trigGtlRegisterDiag ............ERRORID: 62 hardware error acq processor not responding
- i=0 temp=ffff mask = 7f
- trigReg[i]=8a TRIGgtlAddr = 72c0800
- ***FAIL***
-..error details:
-ERRORID: 151 diagnostic test failure trigGtlRegisterDiag
-acq processor not responding
-RegNo: 0x72c0914
-
+acqProcThermistor .............. pass
+trigGtlRegisterDiag ............ pass
+trigBtlRegisterDiag ............ pass
+ch1LogicTypeComp ............... pass
+ch2LogicTypeComp ............... pass
+ch3LogicTypeComp ............... pass
+ch4LogicTypeComp ............... pass
+ch1EdgeTrigDiag ................ pass
+lineTrigDiag ................... pass
+dlyTrigDBETrigAfter ............ pass
+dlyTrigDBTRunsAfter ............ pass
+slewrateTrigDiag ............... pass
+trigAttenSerialReg ............. pass
+trigPreampSerialReg ............ pass
+trigDTCSerialReg ............... pass
+trigExtlSerialReg .............. pass
+trigDacSerialReg ............... pass
+TICountersDiag ................. pass
+gtlBigCountersDiag ............. pass
+trigBtlConfidenceDiag .......... pass
+trigGtlCompRamDiag ............. pass
+digRegisterConf ................ pass
+digSpecialRegisterConf ......... pass
+digPhaseLockLoopDiag ........... pass
+digSpeedMemConf ................ pass
+digAcqMemPatConf ............... pass
+digDataFormatConf .............. pass
+digAcqSubSampleConf ............ pass
+digAcqPeakDetectConf ........... pass
+digAcqHiResConf ................ pass
+digAcqMemDataConf .............. pass
+digAcqMemAddrConf .............. pass
+digInterruptConf ............... pass
+digA2DConnectsConf ............. pass
+digHFStepConf .................. pass
+digDspConf ..................... pass
+glitchTrigDiag ................. pass
+pulseWidthDiag ................. pass
+digPixelatorConf ............... pass
+trigNibDiag .................... pass
fpDiagConf ..................... pass
optDiagPM110Reg ................ pass
optDiagFloppyCacheMem .......... pass
-optDiagFloppyControllerIO ......0x51ffea8 (tRootTask): duart portB write timeout, byte: a7
-0x51ffea8 (tRootTask): duart portB write timeout, byte: 47
- pass
+optDiagFloppyControllerIO ...... pass
...
acqProcThermistor and trigGtlRegisterDiag are checked first and during this, the system detects
that it is a communication problem (the cpu does not answer at all), spits out an additional message
"acq processor not responding" and aborts the rest (as it would not make sense to go on).
With SW3 set to close, the scope now needs considerably more time to start. I wasn't aware of that
since I always had it in open position (so that all this diag is being skipped).