Thursday, July 28, 2016

Virtual 1403 printer working now, prepping for show, accidentally damaged replica display pedestal (!)


I began collecting and amassing in one area all the items I will be bringing to the event - ALDs, manuals, example SLT cards, books and so forth. I also began formalizing the demo decks I will use and printing out each for reference by visitors as they run.

My current list of demonstrations include:

  • Fortran program to calculate and print square roots on the 1132 printer
  • Fortran program to solve equations, using 1403 printer and disk
  • Assembly of some code
  • Boot of internal disk drive using 1132 and 1442 reader for boot card, then virt 1442
  • Boot of virtual disk, virtual 1403 and virtual 1442 to run decks above
  • Hand code to show the 1130 add instruction in action
  • DCIP utility to dump disk sector to virtual 1403
  • Load core with CPU diagnostics and run to completion

I got out my saws, clamps and wood glue to begin building the upper metal piece for the 1130 replica. I had an alternative in mind to the original plan, which was to build wood pieces that sat atop the existing metalwork under the display pedestal. The new idea is to remove that piece of metal entirely and build up the top entirely of painted MDF. I went out to measure for the alternative and see how reasonable it is.

While moving parts around, the display pedestal part tipped over and the front plexiglas panel broke off. Too, the rotary dial came loose. Disaster! I need to go back out later when I am not so emotional about it and look for a way to repair this. If not, I have to scratch the replica entirely from the exhibition.

The mounting of the plexiglas on the pedestal was always a weak point. However, if I can repair this somehow, I can swap in a real rotary mode switch plate from an 1130, given to me by Jeff Jonas, which will improve the fidelity of the replica, although its paint is yellowed (tanned?) and a bit chipped up.

I am still too heartbroken to attempt the pedestal repair, but I do have it all inside where I can work on it once I am ready. Meanwhile, I am focusing on non-replica tasks. It doesn't make too much sense to finish the top, attach covers and test out the electronics if it is too damaged to display.


-- virtual 1403 line printer --

Carefully reviewing the log file from the GUI, it became clear that my FPGA logic for the skip is where the flaw lies. The stopping points after a skip were always correct, in the GUI, for the current line number sent up from the FPGA. The problem was the current line number being returned.

I will have to test using the LED lamps and some hand code, checking where the logic reaches compared to the known correct answer, then interpolating the flaw from it. I did look over the VHDL code for a bit

I discovered that it was a timing thing - depending on when I polled, I would get various line numbers that didn't reflect where the virtual carriage would stop. I stopped looking at the 'last line number' field sent up from the FPGA, instead keeping track purely in the GUI, and the results were perfect.

I then began testing with different channels in the skip list to see if the function worked properly. I tried skipping to channel 4, which had a punch at each line modulo 4, and to channel 7 which was punched modulo 7 - good results.

I then did a test with skip to channel 1, which gave me a reasonable printout but I could see that the FPGA carriage tape mechanism was running away, cycling continuously. I need to figure out and fix this problem.

It may be a timing issue, in that I reset the line number back to 1 and then do the checks of the ctape buffer output just a couple of cycles later, but my FSM for changing the address of the buffer needs a bit of time before it emits the new address and then the output is available one cycle after that. I added to dummy cycles to let the address change and the carriage control tape buffer output to become correct before I start testing the match of channel bits and the skip list.

As well, I want to reset the 1403 printer to line 1 whenever paper is loaded, thus it has to happen during the process that makes the printer ready. I actually implemented this as a reset of the line number to 1 when the print is made not-ready, so that it will work on any reload of virtual paper.

Back out to test with the new code and the skip to channel 1 program. It still loops perpetually, but all the other skip channels work great. I need to look carefully at my logic to see how I am messing this up, because when fixed, the entire virtual 1403 printer will be fully debugged.

I decided I should change the LEDs to show me the bit for channel 1 on the buffer output, just to verify it was correctly written into the carriage control tape buffer and present for use. I also began thinking about how to break the loop of the 1403 printer. I think it should look at Not Ready and reset immediately, at the same place where I reset the line number to 1.

I tested and confirmed that I am NOT loading the first word of the carriage control tape, or at least not the first bit which governs skip to channel 1.  I looked over the write special data transaction and compared it to the successful version for the 1442 card reader. I spotted a couple of differences, one of which might have caused a timing problem with buffer address changes.

I cleaned up the transaction and reran my testing to see if I now have channel 1 stored in the buffer for line 1. It is still not set. At least my logic to reset a runaway printer when it goes not-ready is working. While I don't understand what is going wrong, I can make a hardcoded decision that anytime we are at line 1, we will have a match on channel 1 during a skip. Lets see how this works out.

All seems good now - the channel 1 skips work properly, mixed skip commands stop on the first matching hole, as they should, and the XIO Sense DSW shows channel 9 or 12 when we are on the relevant line of the page.  I consider this tentatively ready for use.

-- test of three virtual devices working in tandem --

I set up a test where I mounted a version of my DMS2 pack that support 1403 printers on my virtual 2310 drive, mounted paper on the virtual 1403 printer, and booted up the machine. I then inserted a card deck in the virtual 1442 reader and watched it begin processing. I had some issue where it looped up in high storage during the Fortran compile stage.

When I looked at the virtual printout, I saw some random junk overlaying some print lines, which should not happen. Since it was also getting a bit hot in the workshop, I ceased work for the day and will retry this when everything is nice and cool tomorrow. I will also check high memory to be sure we don't have any memory issues recurring.  I did make a small change to the GUI where it fetches the print line, which should make it more reliable. 


  1. Carl, somehow my comment got lost. It sounds like you're going to set the printer to line one whenever the printer is stopped and restarted. This is not the action on a real 1403, which can be stopped and restarted. Also, when loading paper the operator would push the button( restore?) to skip to channel one before starting the printer. Channel one would never be line one, and on a special form might be anywhere down the page.

  2. Hi Pete

    I didn't implement a "Stop" button on my GUI, thus the only way to have it stop is when I close the current "paper" file on the PC and load a new one.

    As far as channel 1, the convention with the 1130 was that skip to channel one meant go to the top of the next page. Thus it would have usually been line 1.

    That said, I agree that this was an expediency in the rush to get ready for the exhibition this weekend. A carriage control tape could have channel 1 in multiple places - one example I remember is when printing checks, which came with multiple checks per physical page, where skip to ch 1 took you to the next check.

    As far as the definition of line 1 - I didn't mean the exact top of the page at the crease, but the spot where an operator would crank the paper and hit Restore to set it as line 1. I guess I am using line 1 as defined on a carriage control tape.

    I suppose I could add in a Restore button in the GUI, which reset to line 1, independent of resetting the rest of the printer drive as paper is removed or attached.

    It is always an interesting decision on how much to model about a device. Should I put in the Start, Stop, Space, and Restore buttons? Should I move 6 and 8 LPI? Should I model the clutch and physically moving the paper while declutched?

    Ultimate realism would model all of that, but the current virtual 1403 is not so complete.