[TUHS] Codata restoration - day 1

[dave@horsfall.org (Dave Horsfall)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

On Fri, 10 Oct 2014, Engel, Michael wrote:

> After carefully examining the power supply and checking the generated 
> voltages, we were convinced that this wouldn't kill our Multibus boards. 
> Maybe some of you are interested in our progress, so I though I would 
> send you an update.

Yes please!  I long for the days when it was possible to understand the 
entire kernel source...

> After reconnecting the Multibus backplane, we started the system with 
> only a CPU board and a memory board. On one of our CPU boards the 
> smaller (P2) Multibus connector is masked with tape, I'll have to dig 
> deeper to find out what is deactivated by this…

The P2 bus is designated as "private" i.e. do whatever you want with it 
with your proprietary hardware.  I don't think the "standard" CPU board 
even looks at it.

> One of our two CPU boards is currently non functional (the one without 
> the masking take, this doesn't say a thing on the console UART, will 
> bring in the scope in Monday to check for details). The other one brings 
> up the monitor startup message and prompt on a connected serial terminal 
> (emulator) - however, we are unable to get any characters echoed back. 
> The serial cable is working, we tried all sorts of handshake 
> configurations. If we get any characters back (the system is running at 
> 9600 baud, I tried all combinations of 7/8 bit, none/even/odd/mark/space 
> parity and 1/2 stop bits), these are garbled and contain mostly "1" bits 
> (0xfc, 0xfe, 0xff or similar).

Have you tried speeds other than 9600?  They look to me like framing 
errors.

-- Dave