An e-mail from Bob Feretich
And a (positive) response from Grant Saviers
Emulator's SVN Repository
Current Status - Mar 2009 - done, working
Date: Sat, 10 Sep 2005 19:52:52 -0700
From: Bob FeretichTo: 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. Problem:
- Check out the "decodes" of the timers. (It should take about a day to accomplish that.)
- 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.)
- Check out the simple TAU operations. (Rewind, Rewind and Unload, Turn On Tape Indicator, Turn Off Tape Indicator)
- Check out the intermediate difficulty TAU operations. (Backspace, Erase)
- Check out tape Write and Write Tape Mark. (Requires the interface to loop-back Write Data onto the Read Bus)
- Check out tape Read. (Requires a working tape drive.)
- Check out the CPU/TAU interface. (Initiate operations from program instructions.)
- Check out variations in read and write instructions. (Load variations, different densities, diagnostic variations, etc.)
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.
- 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.)
- 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.
- 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.
- 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.
- 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
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
from Bob Feretich, Oct 21, 2008
http://svn.rafresearch.com/repos/IBM1401 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.polarion.org/projects/subversive/download/eclipse/2.0/update-site/ 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