First Power

After a little sanity checking to make sure the gigantic power supply caps were still OK, I powered on one of the SWTPCs yesterday afternoon.  With a linear power supply, I could check it with no load and make sure it was putting out the proper voltages.

The SS-50 bus in these computers has been called “hacker friendly,” and this it undoubtedly is.  Unfortunately, it also has some hazards associated with it.  Most of these hazards have to do with the fact that the bus amounts to a forest of exposed conductors.  This fact, coupled with the enormous electrolytic caps in the power supply means that even if you unplug the computer, you can easily pop fuses while working inside the computer.

The first fuse I blew yesterday was while checking the 8V supply, but the second one blew while I was plugging in a dual serial board, with the computer powered off and unplugged.  The back panel bracket managed to bridge a couple of the protruding half-inch long pins as I was getting it lined up and I saw a little flash off in the direction of the power supply.  I had already bought a package of completely different fuses that afternoon and didn’t feel like going out again, so I borrowed a replacement from the other machine.

After that I was careful not only to unplug the computer, but also remove the fuse from the +16V line when inserting or removing interface boards, since that’s the last one of those I have at the moment.

The chassis I selected was the one with the MP-MB backplane and the MP-ID Interface Driver board.  I borrowed a 6821 PIA from the EPROM programmer and plugged it into the MP-T timer board.  I used a little hot glue to fasten Slim’s ROM selector switch to the side of the CPU board to keep it from blowing more fuses.

A little digression is in order here about the SWTPC bus.  It is in two parts, the SS-50, which is a proper bus, and the SS-30, which is “geographically” addressed.  In other words, each slot has its own select line, so it doesn’t have a full complement of address lines.  These board select signals are generated by circuitry on the motherboard in older systems, such as the MP-B3, or by the MP-ID board in the later system.  You can set the specific addressing with jumpers.  This makes the I/O boards simpler and cheaper, since they don’t need to decode their own addresses.  But they do need to be plugged into the slot that the monitor and OS expect them to be in.

The SS-50 bus has all the address lines (including the extended address lines on the newer system).  It is mainly used for the CPU board and memory boards, but of course one could make an I/O board that would go on the SS-50 bus and have its own address decoder.

So some time went into figuring out where the interface cards needed to be located in order to make S-BUG and OS-9 happy, and checking jumper settings for addressing and baud rates.

I plugged it all in and turned it on, hooked up the Wyse terminal, but got nothing on the screen.  I was looking for a ‘>’ character as a prompt from the monitor, but no such thing was forthcoming.  The 6809 felt slightly warmer than most of the other chips, so I thought it was probably trying to do something.  But whatever it was trying to do wasn’t making it as far as the terminal.   I was falling asleep, so I shut it off for the night.

This morning I came at it with a little more systematic approach.  I dug out my logic probe and took advantage of the “hacker friendly” bus to power it up.  The first things I checked were the Bus Status (BS) and Bus Available (BA) pins on the 6809.  They were both low, which indicated that it was in normal operating mode.  I could see the BS line go high when I hit the reset switch, which indicated it was servicing a reset or interrupt request.  I could also see that the high-order address lines were active, which added to my confidence that it was actually executing a program.

I figured out which toggle switch setting activated the S-BUG ROM and which one put it in UNIBUG.  The UNIBUG monitor apparently uses interrupts, which you could see periodically on the logic probe.  UNIBUG apparently doesn’t do much except boot UNIFLEX, unless you play dirty tricks on it, so I switched back to S-BUG.

I also determined that I had put the MP-S2 dual serial board in the wrong slot.  Actually I had moved it there from the right slot after reading the S-BUG documentation.  So much for TFM.  S-BUG was periodically asserting the board select signal for slot 0, so I moved the serial board back there.

I still wasn’t getting anything to come up on the terminal though, so I decided to see if I could get something else to talk to the Wyse.  I plugged in an old Pentium 133 laptop with Windows 98 and fired up Hyperterminal.  I hate that terminal program, but it was handy and came in a small package.  I set it to 9600, 8, none, 1, and hooked it up to the Wyse with a null-modem cable.

I could see characters from the Wyse in Hyperterminal, but nothing from the laptop showed up on the terminal.  Now I had set the terminal to half duplex while testing it.  The way I had understood half duplex was simply that it would echo on the local screen whatever you type.  But I thought that would mean that if the remote host echoed back your characters you would get two copies of everything you typed.  In this case it apparently means that it simply ignores anything that comes in from the outside world.  Whatever.

Switching it to full duplex resulted in the expected behavior.  So I plugged the Wyse back into the SWTPC and still got nothing.  Then I plugged it into serial port B, and you can see the results below.

First Power-on

S-BUG says 'hello'