return to main page

Tape Channel Analyser and 729 Tape System Emulator

Bob Feretich, Grant Saviers and Jeff Stutzman worked on this major project

from Marc Verdiell
    The Tape Emulator is a hardware test and emulation instrument that was developed to bring up the tape system on the 1401. It hooks up to the 1401 CPU tape channel, and emulates the behavior of up to six 729 Magnetic Tape Units, responding to all controller operations as if they it had real tapes attached. In addition, it allows monitoring and diagnosis of the tape channel interface.

Table of Contents:


An e-mail from Bob Feretich - 10 Sep 2005
Date: Sat, 10 Sep 2005 19:52:52 -0700
From: Bob Feretich

To: 1401 Restoration Team
Subject: Tape Drive Emulator

Our bring-up of the 1401 TAU is making good progress. We now have the three main TAU timers working, Read Timer, Write Timer, and Delay Timer. My proposed plan for step by step TAU bring-up is presented below. Note that the TAU CE panel seems to be able to isolate the TAU from the CPU and permit the TAU bring-up to proceed quite far before the CPU/TAU interface variable needs to be introduced. This is a very good thing because the Overlap Feature participates in this interface.
  1. Check out the "decodes" of the timers. (It should take about a day to accomplish that.)
  2. Check out the handshake logic between the TAU and drives out on the interface. (State machines inside the TAU require valid handshakes to operate correctly.)
  3. Check out the simple TAU operations. (Rewind, Rewind and Unload, Turn On Tape Indicator, Turn Off Tape Indicator)
  4. Check out the intermediate difficulty TAU operations. (Backspace, Erase)
  5. Check out tape Write and Write Tape Mark. (Requires the interface to loop-back Write Data onto the Read Bus)
  6. Check out tape Read. (Requires a working tape drive.)
  7. Check out the CPU/TAU interface. (Initiate operations from program instructions.)
  8. Check out variations in read and write instructions. (Load variations, different densities, diagnostic variations, etc.)
Problem:
Staring at step 2, we need to observe and stimulate the 1401's tape drive interface. The complexity of observation and stimulation increases in each step thereafter. Currently, no tape drives are ready to attach to the interface. Even if there was a tape drive that was ready, the ability to observe and stimulate the interface using a standard tape drive is poor.

Reasons a real tape drive is a poor choice for early TAU bring-up.

  • You can't directly observe the interface. You can only observe how the tape drive reacts to the interface. This causes a problem if the tape drive does not react in the expected manner or if the TAU operations do nor cause uniquely identifiable reactions.
  • The ability to stimulate the interface is limited to the personality of the tape drive. Example: It would be difficult to make a 729V respond like a 729II or to respond with specific operation failures. If I am debugging a block of TAU logic, I would prefer to test the block with responses from each model tape drive, rather than bring-up the whole TAU with a 729V and then verify the entire TAU again with the other model drives.
  • You can't separately debug the read operation and the write operation. If you write data to a tape and then receive garbage when you read the data. You have no way of knowing whether the write operation or the read operation failed. Having to debug both read and write operations simultaneously would significantly complicate bring-up.

Solution 1 - Build a Lights and Switches Box.
Ok, the lights would give us static observability, but several problems need to be solved.

  1. The box must be reasonably easy to attach and detach from the system. The best way would be to connect it to the tape drive channel through standard 200 pin biscuit connector. We don't have any of these connectors to spare. (We might be able to get a Terminator from Paul Pierce and use the Terminators connector.)
  2. A logic board would be needed in the box to translate voltage levels and generate consistent responses. For example: The TAU Select signal is used to tell the box to simultaneously present the box's state. The state (e.g. Ready/NotReady, Read/Write, Hi/Lo Density, Tape Drive Model, etc.) could be held in switches, but presentation of the state requires logic and voltage level translation.
  3. The logic board also needs to wrap Write Data onto the Read Bus. Not only must voltage level translation occur, but the box must convert the Write Data to NRZI.
  4. Unless we add substantial complexity to the logic board, the box would only be able to generate a fixed bit pattern of Read Data. It would not be able to generate or check LRC characters.
  5. Note that it would be beyond the capability of A "Lights and Switches" box capture and display block of Write Data, or to present a block of Read Data.

Solution 2 - Build a 1401 Tape Channel to PC interface.
Solutions to problems beyond #2 above would be easier done using a programmable microcontroller (PIC if you like). The initial implementation could be done to implement "Lights and Switches" functionality up to and including #2 above. Then it could be extended incrementally through #5 as needed.

Since we still have not solved the problem of bridging the 1401 Software Development Environment to the 1401 hardware, a "Step 6" could be added to move tape data between the TAU and the PC in a way that fully emulates a tape drive accessing a tape.

Decision needed:
To proceed with TAU bring-up we must either start building a "Lights and Switches Box" or a "Basic 1401 Tape Channel to PC Interface" within the next week. I think that it makes a lot more sense to go with Solution 2, the 1401 Tape Channel to PC interface.

Does anyone object with proceeding with initial implementation of the 1401 Tape Channel to PC interface?

Regards,
Bob Feretich

And a (positive) response from Grant Saviers - 9/10/2005
From Grant Saviers, 9/10/2005 To: 1401 Restoration Team

Now that I have assisted Bob with the TAU debug and assisted Allen with the 729 clutch problems, I think building a uP/PC based emulator is a very good idea. With Allen gone for another three weeks, not much is going to happen on the clutch problems (unless somebody else wants to advise me on the internals of the clutch) or can get a 729 operating.

Bob's previously sketched out emulator design seems to have enough speed to at least emulate a lower speed 200 bpi drive. I've also studied the TAU analog circuits, and thought about simulating the drive read signals. The capability will also help us debug/test the TAU analog signal paths.

I'm signed up to help build Solution 2.

I also think a scavenger hunt for a 1401 cable/shoe needs to be done in both 1401 Shoreline and Moffet storage.

Grant

Emulator's SVN Repository
from Bob Feretich, Oct 21, 2008 

 I have opened the Emulator's SVN repository for anonymous read access.
 Updating the repository still requires a valid user ID and password.
 
The Emulator SVN repositories are located at:
      https://svn.rafresearch.com/repos/IBM1401/
      (updated May 2014)
You can use your browser to look at the data in the repositories.
You may have to accept my non-standard SSL certificate to access the site.
 
I access the the Java parts of the project using the Subversive Eclipse 
plug-in. For info on the Subversive plug-in see the bottom of this e-mail.
 
I use TortoiseSVN for checkout/checkin of the non JAVA/Eclipse pieces of 
the project. The Drivers are developed under Microsoft Visual C++ 
Express 2005 (free, there is a 2008 version of it out now, but I have 
not upgraded.) The firmware used Microchip's Interactive Development 
Environment (IDE). (Also free)
 
The initial version is tagged "version_1_0".
For the latest version of the data check out the "trunk" copy of the 
project that you will be developing. I use the tagged versions for 
production releases (frozen versions). 1_2 is the latest production 
version. There have been a few minor updates to the trunk since its release.
< 
Naming convention for releases:
A release designator consists of __.
First digit (Version)- Major new functionality or compatibility 
difference. Should incremented when a change to a project makes it 
incompatible with other projects. Any TAPEUSB 1_x_x project should be 
usable with tapeusbdll 1_x_x project. Change this digit when there is a 
change in the interfaces between projects.
Second digit (Revision)- release revision number. Incremented when a new 
stable release is to be distributed. Zeroed when the first digit is 
incremented.
Third digit (Edition)- used only for bug fix patches on old releases. 
(Always performed as a branch.)
 
You can view them using your browser.
 
So far projects under SVN are:
** Emulator **
The Eclipse dynamic web project for the Emulator. Your web pages, java 
scripts, and servlets should be placed in this project. The Eclipse 
Subversive plug-in was used to create this project.

** TAPEUSB **
The Eclipse Java project for the Java wrapper classes for the dll 
routines. The output jar file from this project must be manually copied 
into the WebContent/WEB-INF/lib/ of the Emulator project when it is changed.

** sys **
The kernel driver. I imported the Visual C++ 2005 Express project into 
SVN using Tortoise.

** tapeusbdll **
The user mode driver. I imported the Visual C++ 2005 Express project 
into SVN using Tortoise.

** Firmware **
The PIC firmware. I imported the Microchip IDE project into SVN using 
Tortoise.

There are Visual Studio and Microchip IDE plug-ins for SVN, but I have 
not played with them. Using TortoiseSVN is convenient.

The Java code is all compiled under Java SE 5.
The version of Tomcat used is Tomcat 6.0.
I use Eclipse 3.3. It's much faster than earlier versions. I haven't 
tried newer versions.

I'll assign write access passwords later.

Write me if you have questions. See you Thursday.

Regards,
Bob Feretich



********************************************

To install the Subversive plug-in for Eclipse: In Eclipse,...

   1. Select Help->Software Updates...->Find and Install
   2. Select Search for new features to install, press Next
   3. Select New Remote Site...
      In the pop-up enter:
      Name: Subversive Plugin
      URL:
      http://download.eclipse.org/technology/subversive/0.7/update-site/
   4. Select New Remote Site...
      In the pop-up enter:
      Name: Subversive Connector
      URL:
         http://www.eclipse.org/subversive/
         Click on the "Downloads" link.
         Follow the instruction to install.
             (updated May 2014)
   5. Continue Next/Finish. You will need to also check "Mylan
      prerequisites" when given the opportunity.
   6. After installation, you need to restart Eclipse.

To install the TAPEUSB project from SVN: In Eclipse...

   1. Select File->New->Other
   2. Select Svn->Projects from SVN, Next.
   3. Fill in the dialog box.
      URL: http://svn.rafresearch.com/repos/IBM1401
      Use custom label: TAPEUSB
      Press Next.
   4. Choose the revision to download.
      For now, trunk->TAPEUSB  (ignore the numbers after the names)
      Select Checkout as a project with the name specified.
      Next & Finish.

Regards,
Bob

Current Status - Mar 2009 - done, working

TAU Analyzer/729 Emulator

The 729 Tape Drive Emulator is operational and stable. We are currently using it to emulate a bank of five 729 drives for our bring-up of the Autocoder (on Tape) software.

The Emulator consists of:

  • A custom hardware unit that attaches to the 1401 Tape Channel Interface just like a standard tape drive. The unit contains 1401 interface electronics, a USB slave port, and a microcontroller. The microcontroller emulates microsecond level tape drive operations and passes tape record data to a PC via the USB port.
  • A PC that is configured to run the Apache Tomcat 6 webserver application and communicate to the hardware unit. The Tomcat provides the runtime environment for the Emulator web application.
  • The Emulator Web Application provides a Graphic User Interface GUI to users via the internet browser on their own PCs. The GUI very closely resembles the operator panel on a real IBM 729 Tape Drive.
  • User mode and kernel drivers interface the webserver application software to the hardware unit. The user mode driver provides the interface into the webserver’s Java Virtual Machine. The kernel driver communicates with the hardware unit and performs millisecond level emulation of tape drive actions.

Features of the 729 Emulator:

  • It’s capable of simultaneously emulating up to six 729 tape drives.
  • The virtual magnetic tapes are stored as files on the webserver or uploaded/downloaded to network attached user PCs. Tape images are stored in ASCII format (transparent conversions occur between ASCII and 1401 BCD) to permit easy user viewing and editing.
  • The Emulator supports a library of tape images that is maintained on the webserver. Currently the library contains a few utilities (Card-to-Printer, Tape-Copy, etc.) and a standard application (Autocder assembler).
  • User tape images are uploaded from the user’s PC at the beginning of a session and written tape images are downloaded at the end of the session. No user tape data is stored on the webserver.
  • The Emulator is also a powerful debug tool for the 1401 tape interface subsystem. It monitors and validates control signals on the tape channel interface. It has a diagnostic record generator capable of generating various size records containing various data patterns. It can emulate the behavior of 729 model II, IV, and V drives. It can emulate tape data transfers at 200, 556, and 800 CPI. It can also force many interface error conditions. These features were important in our bring-up of the Tape Adapter Units of both the German and Connecticut 1401s.
  • The analog section of the emulator provides simulated read signals from the 729 drives as the TAU performs all of the tape analog signal processing in the 1401 system. The analog section enables simulation of virtually all possible tape read signals and can be used to verify correct operation of the TAU clock recovery and signal checking features. Thus, the Analyzer can also be used in situ as a sophisticated card tester for the analog cards which would be difficult to test by other means. However, this capability is not included in the current TAU Analyzer code.

We expect that the Emulator will be an important tool for future educational classes that may be taught using the 1401. Programs that are developed using the PC based 1401 cross-development environment (ROPE) may be loaded and executed directly from the students’ notebook computers.

The Emulator project is now in maintenance mode. No new features are planned. As use of the Emulator increases, bug reports are expected. Reported bugs are being fixed.

Efforts to upgrade the host PC - as of Dec 29, 2016 

1
    On 12/27/2016 8:07 AM, Guy Fedorkow wrote:

        hi Bob, You probably know that I've been working on a 
        "Theory of Operation" to help new folks at CHM understand     
        how the 1401 system works. With considerable help from 
        Iggy, Carl and others, I've taken a first pass through the 
        tape subsystem. My draft doc on the tape drive is attached... 
        It's intended to become a chapter in the overall doc, which is   
        posted on Ed's web page under the name 
          "modern theory of operation". 
        But I wonder if you might have time and interest to    
        take a look through the draft and see if I've misunderstood 
        any of the details of the machine? There are quite a few    
        spots marked in orange text where I have questions or uncertainty... 
        many of those I know how to resolve with a bit more research, 
        but I'd be glad to have comments on any part of the doc. 

        It also struck me that I should add a paragraph or two   
        on the TAU emulator, as it's an important part of CHM's 
       restoration effort, even if it wasn't part of the original machine. 
       But I think I've seen docs on this on Ed's eclectic web site; 
       I'll look that up. Let me know if you see anything in the doc 
       you'd want to correct?

       Thanks for your help!
       /guy fedorkow 

      apparently attached to the original e-mail
           < IBM-1401-Theory-of-Operation-Tape-tmp1.docx >

--------------------------------------
2


    From: Bob Feretich  
    Date: December 29, 2016 at 12:53:18 AM PST
    To: Guy Fedorkow  
    Cc: ...
    Subject: Re: IBM 1401 tape drive description - with attachment


    My comments on your draft are in the document using a green font. 
    Overall it looks very good.

    You should probably write a little about the "Rewind", "Rewind & Unload", 
    and "Tape Indicator" logic. All of these are implemented in the TAU/729 
    by combinational (unclocked) logic. The failure of one of the handshake
    signals results in everything being hung. 

    There is no indication if it was the CPU, TAU, or 729 that failed. 
    The Emulator manual (cited below) has a pretty good description of each 
    of the 729/TAU interface signals as well as a discussion of the "Rewind" 
    and "Rewind & Unload" operations.

    Tape Indicator seems to be a giant set/reset flip-flop that has its 
    feedback paths span the TAU and the 729; and has some subtle side effects 
    on TAU operation. I troubleshot a problem in this logic before. 

    The failure of one of the signals in the feedback loop caused the 
    TAU/drive to hang and requires the troubleshooter (me) to dig through pages 
    and pages of TAU and 729 ALDS to identify the entire feedback circuit. 
    Unfortunately, I don't recall the implementation. This is an area 
    where I am not sure that I got the Emulator implementation correct.

    The 729 Emulator specification are on the web at...
    IBM 1401 Tape Channel Analyzer, Spec Ver 1.3

    It was named the Tape Channel Analyzer because it goes beyond just 
    emulating the 729 tape drives and for some political reasons that existed 
       in the early days. 
    It contains some support to emulate various 729 failures that can       
    exercise recovery logic in the TAU.

    It is able to emulate one drive up to an entire bank of  tape drives. 
    (Possible because the TAU only enters a session with one drive at a time 
    and that it has an entire IRG delay to switch from one drive to the next.) 
    It can also mimic the timings of any type of 729 drive.

    Regards,

    Bob


-----------------------------------
3
         

        On 12/21/2016 9:48 PM, Marc Verdiell wrote:

            Bob,

            Got the servlet working on the new machine - once I understood that 
            the only thing I needed was to deploy the .war file 
            it got a lot easier ;-)

            Now I am struggling with the USB driver install. 
            I found the generic.sys, tapeusb.sys and tapeusb.inf in one folder. 
            I thought I just needed to point the new hardware found wizard 
            to the .inf file in that folder, but it hangs the wizard 
            (stays forever trying to install it). 
            Anything I missed? Any other way to install it 
            (I tried right clicking the .inf and choosing install, 
            but that did not work either)? I have not tried force installing yet.

            Also, what do I do with tapesubdll.dll file 
               which I found in a different folder?

            Thanks,

            Marc


---------------------------------------
4



        From: Bob Feretich  
        Date: Wednesday, December 21, 2016 at 11:02 PM
        To: "marc.verdiell@gmail.com"  
        Cc: ...
        Subject: Re: Tape emulator help
       

        Good progress.
        
        What are the characteristics of the new machine?
         
        Is it running Windows XP? Anything newer would be a problem. The driver
        model changed after XP.
         
        Are the drivers in the same folders where they were originally installed?
         
        The .inf file guides windows through the driver installation. Based upon
        the OS level, it conditionally copied driver software from the source
        location to the final install location.
         
        There is help info on the web regarding how to interpret the .inf
        contents. Most of the source / destination path name segments are pulled
        from environment variables.
         
        Assuming you are running XP, the environment variable values would be
        the first thing I check.
         
        Regards,
         
        Bob

------------------------
5

On Dec 29, 2016, at 1:54 AM, Bob Feretich   wrote:

    My holiday guests have just departed, so I am starting go work down 
    the backlog of work that came up.
    Sorry that there was a delay.

    My comments are inline...  [ colored red on this web page ]

    On 12/22/2016 10:07 PM, Marc Verdiell wrote:

        Bob,

        It’s a HP small form factor WinXP SP3 machine, much more recent 
        than the current one, multi Gb/s processor, 2G of RAM, relatively 
        large disk, clean install, everything works, 
        should run the emulator easily.

    The machine seems to be compatible.

        I believe the problem is exactly what you say, as I am trying to 
        fish the relevant files from the old installation. Do you happen 
        to have a clean distribution of the driver with the folders already 
        at the right place? 
    
    From my examination of the tapeusb.inf file...
    
           
  • The .inf file installs tapeusb.sys and generic.sys.
           
  • It expects the .sys files are in the same folder as the .inf file.
           
  • The Emulator must be powered on and attached to a usb port. 
                 (the PnP ID of  VID_0403&PID_6001 is expected).
           
  • The destination folder for the .sys files should be
        10,System32\Drivers
       where 10 indicated the Windows environment variable which is normally set to
          "C:\Windows". 
       Resulting in a full path of
          "C:\Windows\System32\Drivers\"
        
  • Registry entries are created notifying the USB driver of their existence 
       and establishing linkage to this location; 
       and identifying tapeusb.sys as a service..


    Most likely the .inf wouldn't work because the Emulator was not connected 
    and powered on. Copying the .sys files to the Drivers folder didn't work, 
    because the registry entries were not created.
        
        It might also be easier if you could stop by for a few hours. 
        In hindsight it was a simple install once I figured out how this 
        is supposed to work and where the important files are, 
        but I am just inefficiently discovering things scattered in the old computer 
        (which by now has a ton of irrelevant things on it) 
        and piecing them together bit by bit. 
    
    If installing the the .inf file via "Add Device" does not work 
    (with the Emulator plugged in and powered on), then I should be able 
    to come in and look at it next week. However, the week after I will 
    be traveling again for a couple weeks.          (Dates are not certain yet.)

        Step one is to get it all working on another machine quickly: 
        some people were ready to dump the tape emulator because of a 
        perception that it was tied to only one PC that could die at anytime, 
        that no one knew how to install a new one, 
        and that we had lost the install files. 

        We can’t let that happen! I love your emulator, it is a very powerful and
        incredibly useful tool for working with tapes, 
        and an important 1401 engineering project to boot. 

        All I need is to gather all the pieces in a clean place 
        and make a little install blurb for people to follow. 
        I’m almost there. 

        In a second step want to clone the repo and make sure I can 
        setup to recompile with Eclipse, and document that process. 
    
    Great.

        Finally, there was a question if anything could be done about the 
        2000 char record limitation. We are trying to run tape Fortran, 
        and it has records larger than this. 

        Is this part of the memory limitation in the hardware emulator?      
        Anything we could do to run around it? 

        BTW, do we have the design files for the hardware also? 
        Schematics? I am trying to gather all the design pieces in one place.
    
    
        
  • The microcontroller that I used only has 3700 bytes of RAM. 
        3072 bytes are available as a tape record buffer. 
        (Less than 700 bytes of RAM were used for stack and all         
        working variables in the Emulator's implementation.)
        
  • Van stated that the Fortran Compiler tape only contained 
        one record that was larger than 3K. He created a version of the tape 
        that cut the record into smaller pieces. 
        I tried to run that tape on the German 1401 (before the Connecticut
          1401 arrived), but it didn't work. 
        I did not try to trouble shoot that problem, 
        because we were making progress running the Autocoder on Tape compiler. 
        We were able to load that compiler, but the 1401 would crash randomly 
        during the compilation. Sometimes during the early phases. 
        Sometimes during the later phases. The failures were traced to memory 
        errors and simple instruction failures. The 1401 would sometimes run 
        the compiler for more than 30 minutes before a failure. 

        In the end, we judged that that the 1401 was to prone to 
        intermittent errors to expect it to run such a long complex program. 
        The correct path was to "margin" the 1401 to reduce intermittent errors; 
        but since the ability to margin the German machine was removed, 
        and no one wanted to begin a "margining project", the whole idea was abandoned. 

        My opinion is that the German machine will never be stable enough 
        to run such a program.
        
  • Perhaps the Connecticut 1401 is more stable. 
        Can the CT 1401 run a program for an hour without failing? I mean a 
        program that uses a wide variety of instructions, 
        not just a simple loop that gets executed many times. 

        If so, I suggest starting with the Autocoder Compiler or maybe Sort7. 
        (I think these tapes have smaller records. They were designed to run 
        on 1401s with less memory. 

        Scan the object tapes for long records first, though. 
        To see the actual record lengths, 
        you need to read the object tapes using Read Tape (without tape marks)) 

        Also, making another attempt to get Van's "split record" 
        Fortran compiler tape to work may be worthwhile. 
        The problem with it may have been a simple bug. 
        Yes, I have all the design files and can pass them to you.
 

    Regards,

    Bob

     Marc



----------------------------
6


From: Robert Garner  
Date: Thursday, December 29, 2016 at 2:48 PM
To: Bob Feretich  
Cc: ...
 
Bob,

Thanks for helping Marc out on your inimitable 
TAU/729 Emulator/Tape Channel Analyzer!!

Per your comments, it would be stellar to get (all of or one of) 
the native Autocoder, Sort7, & Fortran images running on the 
CT and DE machines. 

What's a restoration project without a few challenges! ;-))

- Robert

Ps. There are but ~500,000 discrete components in each of our systems.  ;-)


----------------------------
7

Subject:  Re: Tape emulator help
From: Marc Verdiell  	 
Date:	Thu, Dec 29, 2016 5:24 pm
To:	Robert Garner ...

Getting there.

There was nothing wrong with the .inf and location of the driver files. 
I just force installed the driver and that worked. Finally I got the 
platform going after I manually put the tapeusbdll in the 
Windows\System32\ folder and added the Library of tape objects 
into C:\IBM1401\Libraries that the web.xml file was pointing to. 
It’s all documented now, I think we can make build clones of the 
PC part. We were not quite able to operate the Emulator successfully 
with either the old or new computer, but I suspect that’s something else 
as it was working before.

If we could get the documentation for the hardware that would be awesome.

Marc

Emulator Documents from Bob Feretich - Jan 2, 2017
On Jan 2, 2017, Bob Feretich sent the following documents, by directory
Info - .sch files are generated, and can be opened, by a free, really neat PCB schematic program.

Pictures

Stutzman & Feretich
Top View Interface Electronics
Front View Electronics Box
Sam Sjogren at console

User Interface (PC)
User Interface (PC)