mystories

I used to work for a computer company, and one of our customers in Jacksonville called to say our computer couldn't communicate with any of the other computers on base. The company dutifully flew me down there to troubleshoot in person. I did some tests on our computer, and everything checked out, but sure enough, it couldn't talk to any of the other computers. I asked the folks there if the other computers could talk to each other. Nope, nobody was talking to anybody. Was it possible the other computers were all broken? I asked if I could get access to the other computers. They said it was okay, and I logged in to one of them to investigate. It was misconfigured, so I reconfigured it. Sure enough, it could then talk to our computer.

I proceeded to go through the rest of the other vendors' computers, fixing them one at a time. When I was done, all of the computers could talk to all of the other computers, which caused the customer to believe that I had been right all along and the other computers had indeed been the broken ones - the ones whose own vendors had been unable to fix. Our company came off looking really good, fixing all the other vendors' computers after the other vendors had been there and simply blamed everybody else (as I too had, originally - but I had been right!).

The customer said to let them know any time I felt like a trip to Jacksonville, they'd be glad to invent a problem and request to have me come down to "fix" it.

I was working on a contract where we were going to sell SCSI connected floppy disk drives. We got a drive in, but it didn't work, so they assigned it to me. I added in some debugging code, and it looked like the drive was wonky. The computer would send a "read" command, and the device would respond "OK". This confused the computer deeply, as it expected the drive to either return a block of data and "OK", or an error. Just responding "OK" didn't make sense. All the other devices on the bus worked just fine.

The hardware engineer on the project rented a SCSI analyzer, which also insisted the drive was misbehaving. It clearly showed the read command going out, and the "OK" status coming back. So we ordered another drive, and when it arrived, it did exactly the same thing. Monitoring other devices showed the expected behaviour: send a read command, get data, then get the OK status.

I, however, did not trust the SCSI analyzer. It operated on the assumption that everything was operating according to specifications, and was designed to show what data was going back and forth, not investigate weird protocol violations.

Accordingly, I went and rounded up a logic analyzer, which just shows the raw signals, and does not interpret them at all. It is more effort to figure out what's going on from the raw logic levels, but the logic analyzer doesn't hide anything either. And sure enough, when I puzzled out what the logic analyzer was telling me, it became clear what was happening. The computer would put the read command on the bus, one byte at a time, assert the strobe signal to indicate that the command byte was ready to read, take away the byte, and wait for the "ack" (acknowledge) signal back from the target device. And this is wrong. What it should do is leave the byte on the bus until it gets the ack back. The SCSI control chip in the computer was very simple, and did not do the signal sequencing itself, depending on its device driver to do so. And, looking at the device driver source code (fortunately, we had access to it), it showed the same sequence of events: put data on bus, assert strobe, take data away, wait for ack. So I swapped two lines in the driver, so it would put the data on the bus, assert strobe, wait for ack, and then take the data away.

And lo, the SCSI floppy disk drive started to work perfectly! The remaining question was, why did the other devices work? My theory is that the other, fancier, devices had hardware SCSI interfaces that latched the incoming command bytes immediately upon strobe, so they didn't care that the data went away immediately afterward. Whereas the floppy drive implemented its SCSI interface with a microcontroller. The strobe signal would send an interrupt to the microcontroller, which would then go read the data byte off the SCSI bus. Unfortunately, by the time it got around to it, the data was gone, and the bus terminators had pulled the data lines back to their idle state of zero. And, sure enough, a SCSI command block of all zeroes is a valid command: "test unit ready", for which the correct response is simply "OK".

When I had my first computer capable of video games, an Atari 800, I wrote a very simple game, which I dubbed "Kill the Cities". It laid out a three by three arrangement of red and green rectangles, which were the cities. To destroy a city, you had to shoot it. The cities were in plain view, did not move, did not have shields, and did not shoot back. You had unlimited shots. The only tricky part was the aiming cursor code was rudimentary, and erased anything under it. So if you took your time and scrubbed over a city, you could eventually render it invisible. Given this immense degree of difficulty, if you somehow managed to destroy all nine cities, the game would produce a hissing sound, and the text:

You win! You hear that? They're cheering for you!

This was actually one of my more popular games.

When I was studying computers in school, the early courses were packed, and used as weed-out courses to reduce the student load in the higher courses to a smaller set of theoretically more appropriate students. However, I took issue with the courses that weeded people out by being taught poorly. Since there was no mechanism to test out of these, I had to go and take them too, even though I pretty much knew all the material.

I noticed that the lecture hall for my ForTran class was vacant after the class ended, so I'd stick around, and re-teach each day's lesson in my style to whoever felt like hanging around. I got a huge benefit from this, as teaching something is a great way to find out what I really understood and where I was on thin ice. The stuff I realized I didn't quite get either, we'd work through together. A win all around.

Like many programmers, when I'm developing code, I'll put in amusing error messages for when the code does something I don't expect. However, sometimes this code will get shipped before it's ready. Which leads to querulous calls from the customers. We've had the United States Navy ask us about some of these, which must have caused some consternation out at sea when they popped up. Seriously, folks, ASK me before you ship my software!

One time, I was writing a driver while the hardware engineer (his nickname was "Hoppy") was simultaneously debugging the hardware. I kept getting a particular error condition, only to find out it was because Hoppy had been screwing with something. After a few iterations of this, I simply put a printout at that point in the code that said "Hoppy's playing with the wires!" Sure enough, I forgot to remove it, and that message popped up in the field.

"Shut 'er down, Slim, she's sucking mud!" (a favourite of my friend, Ron Eirtle)

And my personal favourite: "I can't get a buffer to save my ass!"

We were getting ready for a fancy demo to a customer, including showing off our fancy new parallel data link. But, at the last minute, one of the wires came loose, so when we sent "Hello, world!" across it, it arrived at the other end as "Jello, world!"