🚀 go-pugleaf

A few years back I was working on some software for a brand-new
hardware prototype (a board level implementation of the Intel 432,
if you must know, that will produce gasps and sighs from the oldtimers).

There were remarkably few debugging aids, and the software seemed to
be behaving in a very strange way: execution seemed to be getting "stuck"
on one particular address.   It looked like the program was running OK
until it hit this one address, then it seemed as though the program counter
wasn't being incremented, and it would repeatedly execute the instruction
at that address to the exclusion of all others.

This was really strange!  "Perhaps there is a big piece of data, sticking out
blocking the bus at the next address" I suggested helpfully.  We hauled out the
oscilloscope (after exhausting the traditional software engineer methods
of dealing with recalcitrant hardware - i.e. we knocked it silly).  We
probed that board left and right, up and down, side to side, and do you know
what we found?

(that was a rhetorical question,
press "sp" if you want the rhetorical answer)


It looked like execution was getting stuck at that one address because
execution *was* getting stuck at that one address!  There was an interrupt
line which had not been strapped down, and zillions of spurious interrupts
were coming in on it.  In fact it was continuously interrupting, causing
a continuous diversion of the flow of control to the first location in
the interrupt service routine.  Perfectly obvious once it's pointed out
to you, but we certainly puzzled over our slightly out-of-whack observation.
Merry Christmas, and to all a good hack.

----------------
Satisfaction not included.  Batteries vary.  Your mileage may guarantee.
Peter van der Linden     lin...@SuN.cOm    (415) 336-6206