Blinking Lights are useful

Artykuł
07/31/2015

A while ago, computers had blinking lights on a front panel. I recognized various patterns of blinking lights as indicating various operating modes: idle, waiting for teletype input, typing on the teletype machine, reading a paper tape, busy with high CPU usage.

This is similar to the technology of the computer that‘s still running on Voyager 1 launched 38 years ago in 1977. It keeps the antenna pointed toward Earth and controls the cameras.

There aren’t many electronic things that old that are still running. Imagine using the technology of the 70’s and striving to make the code for that machine work for several decades without human touch. In fact, imagine designing code today that will run for the next 40 years, to the year 2055!

Here’s a picture of a clock that I made in 1970/1971 that’s been working continuously since, and is on my desk showing the correct time today as I write this. (I used a soldering iron to melt out the cutout of a black plastic box to create the container. I bought all the parts at Radio Shack: the 7 segment digital LED digits each cost $7, and I could only get one digit per month with my meager allowance.)

Below is an image of my first computer, a Digital Equipment Corp PDP-8/L. It was in the local high school, and I was in middle school. There was only one computer shared by about 3 towns.

I had to sign up for a twenty minute time slots once per week to use it.

In this image, there are three main rows of blinking lights: the Memory Address indicates the address in memory the processor was reading. The Memory Buffer typically indicates the contents of the fetched memory. This computer had only one general purpose register, called the Accumulator.

There’re some switches at the right labelled LoadAddr, Start, Stop, SingleStep.

When the computer is first turned on (via the key on the left) the core memory had no contents, all was 0, because it required power to maintain memory. Thus I then had to toggle in a bootstrap program via the switches for the computer to execute some instructions. The bootstrap was a set of about 15 twelve bit instructions to read in a Loader from the paper tape reader.

These instructions were 12 bits wide, and were represented as octal (base 8) numbers.

I would first set a pattern in the switch register (labelled 0-11) for the address into which I wanted the program to be entered. Then I would hit the LoadAddr switch, and the Memory Address would then be set to be the same as the switches. Once the address was set, for each of the 15 instruction patterns I would set the switches, then hit the Dep (deposit) switch.

After the instructions were toggled in, put in the start address again and hit the Start switch to start the execution of the bootstrap. (Or I could have single stepped the bootstrap with the Sing Step key)

All instructions were 12 bits wide. The “Instruction” lights shows the high order 3 bits of the instruction being executed. The machine only had 8 possible main instructions, represented by 3 lights (2^3 = 8).

0: AND And a value with the accumulator, leaving the result in the accumulator

1: TAD Two’s Complement Add: add a value to the accumulator.

2: ISZ Increment and Skip (the next instruction) if zero

3: DCA Deposit the Contents of the Accumulator

4: JMS Jump to Subroutine

5: JMP Jump to location

6: I/O Input/Output instruction (3 bits indicate which device)

7: MicroInstructions, like CLA (7100 Clear Accumulator), CLL (7200) Clear Link (the accumulator’s overflow bit), etc.

Thus a single instruction could do multiple things: CLA CLL (7300) cleared the Link and the Accumulator

This machine didn’t even have a stack. The first address of a subroutine would hold the return address. Thus recursion was impossible using JMS. I had to mimic a stack to do recursion.

The memory addresses jump all over the place while executing as program, flashing the lights. The intensity of each light indicates how often it’s on. In fact, if you put an AM radio next to the computer there’s a huge amount of AM signal (noise) generated, and if you program the computer to flash the lights in patterns, you could actually make multiple tone chords and music. Computer music on the radio

After a while, computers didn’t have blinking lights like that anymore: typically there were just a couple LEDs indicating Power On or, if lucky, a hard disk busy light. Even that light could tell me that I was waiting for the disk.

When the first IBM PC came out in August of 1980, I bought one (dual floppy drives, 256K RAM, no hard disk). There was only a power light and a LED for each floppy. I wanted flashing lights so I could see what was happening while programs were executing, so I bought a BreadBoard and hooked up 2 Digital to Analog converters (DAC). The IBM PC had a 8088 processor, and a 20 bit address bus. I attached the high 8 bits of the address bus to one DAC (the Y axis) and the next 8 bits to the other (the X axis), so I had 2 analog outputs. I built a HeathKit oscilloscope, and attached the 2 inputs as X and Y, plotting X vs Y. I could then see what addresses were being read in memory: if the display went high, then I knew that high addresses were being accessed, like the ROM B IOS. Lower addresses were applications memory, and in between was the heap.

Because the IBMPC clock was only 4.77 MegHz my 35 Mhz Dual Trace Oscilloscope had no problem.

Nowadays, without blinking lights, I find that programs for which you can enable good logging can show what’s happening during execution, and can be much easier to maintain and understand.

Distributed application systems, where several programs run on multiple machines to achieve a common goal can use logging to a central location (like a file share or a database). I used Windows Communication Foundation (WCF) and its Message Inspectors to watch WCF traffic and log events to a central database several years ago.

You can do logging in your test projectsusing the TestContext.WriteLine method.

However, using this method, you can’t see the output until the test is done.

If you output to a text file, however, and open the text file in Visual Studio, and have VS update the file display at the content changes, then we have our own blinking lights back (see Create a logger for watching your test progress as it runs. )

If you do File->New->Project->Visual C#->Test, Unit Test Project UnitTestProject1

Then paste in this code:

<code>

 using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace UnitTestProject1
{
    [TestClass]
    public class UnitTest1
    {
        public TestContext TestContext { get; set; }
        [TestMethod]
        public void TestMethod1()
        {
            for (int i = 0; i < 100000; i++)
            {
                TestContext.WriteLine("here i am {0}", i);
            }
        }
    }
}

</code>

the Test Explorer window is open: (Alt-S W T)

Now with the cursor in the TestMethod1, hit Ctrl-R + T to run the test (Ctrl_R +L to repeat the last test run: one of my favorite shortcuts)

The test runs fairly quickly. Now click on TestMethod1 in the Test Explorer Window. The bottom pane will show a link called “Output”

Click on that “Output” to see the fancy test Output that we created.

In Visual Studio 2015, this opens the test output very quickly. In Prior VS versions, the large output took a very long time (dozens of seconds). The view opened is not very useful: you can’t search it, you can’t highlight any text, you can’t copy it to clipboard.

I was quite pleased that VS 2015 opened the file so quickly.

Now I know the reason:

Comments

Anonymous
August 10, 2015
They were different 30 years ago, old friend. So were we :-)
Anonymous
December 08, 2015
Even my roller skates had blinky lights on them back then. I miss seeing your clock on your desk.
Anonymous
July 15, 2016
The comment has been removed

Udostępnij za pośrednictwem

Blinking Lights are useful

Comments

Dodatkowe zasoby