Monday, March 21, 2016

Virtual 1403 printer function completed, moving on to a Calcomp 565 plotter restoration to create a real 1627


Implementing virtual 1403 printer

For my first test of the day, I set up latches to record bit 1 (channel 2) as it is being written into the buffer for lines 1 to 4. This should match the pattern I am sending from the Python program, 0-1-0-1 unlike the detected pattern when I looked at the output of the buffer, 0-1-1-1

One teeny flaw in the latching logic, so none of the latches worked. Thirty minutes to correct before I can retry the test. At least these tests can occur without powering up the 1130 - they are focused on actions that occur between the Python code in the PC and the logic in the fpga.

Interesting. The input to the memory for lines 1 to 4 during the write cycle when the buffer write enable is set up was 0-1-0-1, exactly what I should see. This leaves a few possibilities to explain the problems I am facing. I need to work through the cases, unfortunately in half hour or longer intervals. I say longer, because as a retired person, I have the distractability of an ADHD afflicted child. This means that while waiting for the toolchain to complete, I wander off and may not return for a while.

I saw that the buffer had the right input (bit off) at the time I was setting up to write to the memory for line 3, but when it was fetched during the carriage movement process, the bit was now on. I altered the latches to show me the bit for the cycles after it has written, also to latch if the output of the buffer is set after the writing cycle.

Line 3 is not disturbed by writing and not disturbed if I use XIO Control (space one line) commands to move past line 3. I am forced to conclude that my problem is caused only when performing carriage skip processing, although the mechanism by which this can happen is obscure. I have to think of further diagnostic tests to determine what is actually occurring.

Assumed I had a race hazard on changing of the address to the buffer memory, which I blocked by idling one cycle before changing, but the flaw is still present. This bug is so frustrating. Perhaps I am overwriting words in the buffer as part of the seven 'write special data' transactions that are needed to load the 66 word buffer, ten words at a time.

If you can't spot the race hazard, register the signal. I set the carriage tape buffer process to lock in the line number as the buffer address while the carriage movement process is in its timing loop, simulating the time delay of 1403 printer movement, well away from the cycles where it is checked against a skip command. That did the trick. I now have the virtual 1403 printer function working exactly as I wish.


My friend Bob offered a Calcomp 565 that I can try to restore. It is in pieces and the drum is dented, but there is a good chance that I could this back in operating state. IBM sold the Calcomp as the IBM 1627, for use with the 1620 and 1130 systems. If I restore this, it would replace the Strobe 100 I am currently using as a 1627 substitute.

Calcomp 565 - comes in various skin colors such as teal or black
I should consider changing the paint and labeling to be as close as possible to the IBM appearance. I will need to repaint the outer cover, paint the panels that hold the switches/knobs, and create the right decals for the labeling of panels and the front bar.

IBM 1627 - different skin and panel colors, plus changed logo


  1. I'd sure like to give that Calcomp a good home as a true Calcomp 565 hooked up to a PDP-8/E or 8/I. If you have second thoughts about altering it, please let me know!