[TUHS] Codata restoration - day 1

[TUHS] Codata restoration - day 1

[Engel, Michael]

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


Hi,

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.

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…

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

The UART itself seems to work (exchanged it with the one from the non
working board - same result), so now I suspect the AM26LS32 RS423
driver to be the culprit.

I uploaded some pictures to 
http://s1372.photobucket.com/user/michaelengel/library/Codata?sort=3&page=1
- there you can see that this machine is far from being in any sort of 
original condition. Nevertheless, it's great to see it come alive again!

Btw., current versions of MAME/MESS include a rudimentary Codata
simulator. This doesn't do very much so far, but it can successfully run 
the firmware ROM code (picture also uploaded to photobucket).

Best wishes,
    Michael

[TUHS] Codata restoration - day 1

[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

[TUHS] Codata restoration - day 1

[Engel, Michael]

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


On 10 Oct 2014, at 19:00, Dave Horsfall <dave at horsfall.org> wrote:

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

Thanks, Dave! Unfortunately, I haven't heard back from Unisoft so far, 
but I have tried something else last night. A few months ago, ragge
(of NetBSD/VAX and pcc fame) added a 68k backend to (modern) 
pcc. With this, I was able to (cross-)compile more than half of the files of 
the PDP11 v7 kernel without changes (but the compiler still seems to have
some problems, I'll try to generate a useful error report over the weekend).

So, a new 7th Edition Unix port to Sun 100U-derived boards seems to
be possible, perhaps also incorporating pieces from System III or early
BSDs. Another alternative would be a port of RetroBSD, the 2.11 BSD
port which currently runs on the PIC32 MIPS microcontroller cores in
just 128kB RAM. One of these systems will also be the basis for my
upcoming operating systems course :-).

Nevertheless, I will first try to get the existing installation to work, maybe
there are some interesting sources on the disks (and we have also found
a number of 1600bpi 9-track backup tapes and 5.25" backup floppies...).

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

That's what I also thought. Do you know if there were systems which used
P2 to connect to memory boards?

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

The terminal emulator (screen and minicom behave identically) receives 
the output from the console perfectly - otherwise, I would have also 
suspected an incorrect baudrate. And different baudrates for RX and TX
would be highly unusual (I have only seen these in German BTX dialup
systems in the 1980s, which used 1200/75 baud modems).

Luckily, the driver chip for the UART RX line is an AM26LS32. While
this chip is no longer available, I can get an AM26LS32A here at Farnell
(which is just around the corner from my house :-)). Does anyone know
the difference between the 26LS32 and the 26LS32A? I only found a
page at TI that didn't list specific differences...

-- Michael

[TUHS] Codata restoration - day 1

[Dave Horsfall]

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

> > 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.
> 
> That's what I also thought. Do you know if there were systems which used 
> P2 to connect to memory boards?

I think (and this is going back to the early 80s) that some WICAT models 
did.  I've used the 150, 160, and 200, but never saw a 220.  The smaller 
models were Multibus, and the 200 on had something loosely based on it and 
was unofficially referred to as the Pussy-bus.  The P2 bus on those small 
ones was used for something that I've long since forgotten; there was a 
project in the Lionel Singer Group (Aussie agent for WICAT) to use 
standard Multibus cards in them until we discovered upon reading the 
circuits (we had circuit diagrams in those days!) that WICAT had hijacked 
the P2 bus, possibly for extended memory, possibly for its weird ICI board 
(8-port serial board + disk, as I vaguely recall), possibly something 
else.

I was glad to see the end of the WICATs, because their attempt at System 
III was woeful; I had to do pre-sales demos, *knowing* that the damned 
thing would crash on me, and got very good at excuses.  "Sorry guys, we've 
been having a bit of trouble with this new controller, but we're told 
it'll be fixed Real Soon Now(tm)" when I knew that it was the poxy OS at 
fault.  How do you explain to the customer that the OS itself is 
fundamentally rat-shit?

I am desperately trying to forget the exact details, but it involved 
someone telling Lionel Singer himself that his half-arsed idea was just 
that...

> [...]
> >> 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.
> 
> The terminal emulator (screen and minicom behave identically) receives 
> the output from the console perfectly - otherwise, I would have also 
> suspected an incorrect baudrate. And different baudrates for RX and TX 
> would be highly unusual (I have only seen these in German BTX dialup 
> systems in the 1980s, which used 1200/75 baud modems).

1200/75?  That was popular in Australia, on a scheme called Viatel, which 
thankfully died off when ISPs began to rise up (until then it was either 
FidoNet or the Phone Company's Viatel) and implement 1200/1200.

> Luckily, the driver chip for the UART RX line is an AM26LS32. While this 
> chip is no longer available, I can get an AM26LS32A here at Farnell 
> (which is just around the corner from my house :-)). Does anyone know 
> the difference between the 26LS32 and the 26LS32A? I only found a page 
> at TI that didn't list specific differences...

Offhand no, but Farknell (as they're known in Australia - say it out loud) 
ought to know, as they're pretty clued up.

-- Dave

[TUHS] Codata restoration - day 1

[Erik Fair]

On Oct 10, 2014, at 12:55, Dave Horsfall <dave at horsfall.org> wrote:

> I was glad to see the end of the WICATs, because their attempt at System 
> III was woeful; I had to do pre-sales demos, *knowing* that the damned 
> thing would crash on me, and got very good at excuses.  "Sorry guys, we've 
> been having a bit of trouble with this new controller, but we're told 
> it'll be fixed Real Soon Now(tm)" when I knew that it was the poxy OS at 
> fault.  How do you explain to the customer that the OS itself is 
> fundamentally rat-shit?

At Dual Systems, we never shipped AT&T USG System III to our customers, other than a few alphas/betas - it was such a disaster, we spent a year fixing show-stopper bugs in it. By the time we got System III into what we considered "shippable/supportable" shape, System V was out, so we started work on that. Our customers had to jump from v7 to System V, but they were spared System III.

System V was pretty awful too, but it was "industry standard" and we had to put up with that idiocy from AT&T USG. I daily retreated back to the much more pleasant use of BSD UNIX systems at UCB that I still had access to.

	Erik <fair at netbsd.org>

[TUHS] Codata restoration - day 1

[Clem Cole]

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

below

On Fri, Oct 10, 2014 at 3:21 PM, Engel, Michael <M.Engel at leedsbeckett.ac.uk>
wrote:

>
>
> That's what I also thought. Do you know if there were systems which used
> P2 to connect to memory boards?
>
​Pretty much everyone that was successfull - Masscomp, Apollo, etc...   And
they are all different.​




>
>
> Luckily, the driver chip for the UART RX line is an AM26LS32. While
> this chip is no longer available, I can get an AM26LS32A here at Farnell
> (which is just around the corner from my house :-)). Does anyone know
> the difference between the 26LS32 and the 26LS32A? I only found a
> page at TI that didn't list specific differences...


​Hmm...
I looked in my old AMD books, and I unfortunately do not have an AM26xxx
anything in there.
the difference between the MC1489/SN75189 and MC1489A/
SN75189
 is input hysteresis on the receiver side.  I wonder if AMD did the same
when they created the 26L32​

​ to compete with Moto and TI (in those days the 1488/1489 system was king
until MAX shows up on the scene with a single 5v device).

So, I'll give you the text from Page 5-42 of the Moto Interface book on the
1489/1489A:

*The MC1489 input has typical turn-on voltage of 1.25 volts and turn off of
1.0 volt for an input hysteresis of 250mv. ​ The MC1489A has a typical turn
on a 1.95 volts and turn off of .8 volts for typically 1.15 volts of
hysteresis.*


I suspect the A version will work fine, usually the differences was things
like this where they made the part better in real world applications (250mv
of hysteresis for a device that was supposed to be able to handle swing
between +30/-30 volts is tiny).

Best of luck.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141011/f3a7c237/attachment.html>

[TUHS] Codata restoration - day 1

[Hans Rosenfeld]

Hi Michael,

On Fri, Oct 10, 2014 at 05:26:58PM +0000, Engel, Michael wrote:
> 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).
> 
> The UART itself seems to work (exchanged it with the one from the non
> working board - same result), so now I suspect the AM26LS32 RS423
> driver to be the culprit.

I've had that a few times with PDP11s and VAXen from the 80s. The line
receivers suddenly died, showing exactly the symptoms you describe.
Those were different chips (ua96XX), but the concept is the same.
Replacing them with newer chips from the same family worked without
problems.


Hans


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

[TUHS] Codata restoration - day 1

[Warner Losh]

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

These days, you can buy 5.0V or 3.3V to USB adapters in the hobbyist or robotics section of many computer stores. I’ve used them to trouble shoot blown driver chips to verify they really were toast. Be careful of the voltage levels, though, since many 3.3V products can’t tolerate 5.0V…

Warner


On Oct 10, 2014, at 2:13 PM, Hans Rosenfeld <rosenfeld at grumpf.hope-2000.org> wrote:

> Hi Michael,
> 
> On Fri, Oct 10, 2014 at 05:26:58PM +0000, Engel, Michael wrote:
>> 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).
>> 
>> The UART itself seems to work (exchanged it with the one from the non
>> working board - same result), so now I suspect the AM26LS32 RS423
>> driver to be the culprit.
> 
> I've had that a few times with PDP11s and VAXen from the 80s. The line
> receivers suddenly died, showing exactly the symptoms you describe.
> Those were different chips (ua96XX), but the concept is the same.
> Replacing them with newer chips from the same family worked without
> problems.
> 
> 
> Hans
> 
> 
> -- 
> %SYSTEM-F-ANARCHISM, The operating system has been overthrown
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141010/d3ecb218/attachment.sig>