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...