Work on DMS distribution project and mag tape interface

MAG TAPE INTERFACE TO 1130

I decided to pick up an NCR5380 chip and interface it to an fpga, allowing me to drive the 9 track tape drives I own. This will be part of the SAC Interface Box, implementing the tape drives as IBM 2415 drives attached through an IBM 1133 multiplexer box with the Selector Channel RPQ,  the multiplexer box hooked to the 1130.

I have to create a PCB for the NCR chip and other circuitry to connect it to a Spartan 3E fpga. The fpga I am considered is connected by my fast link to the central ztex fpga board in my interface box.

CREATION OF DISTRIBUTION VERSION OF DMS2 V12

I researched the checksum process used by the loader and DUP and created a subroutine to allow me to calculate a checksum to punch in the card decks I will create from the SLET phases on my disk cartridge. Having ensured the checksum is working properly, I went on to write the larger routine to take a SLET entry and read the phase it points to into a buffer.

Those subroutines in turn are called by code that reads the SLET, phase by phase and for each calls my reading routine. The final bit of code will be the subroutine to convert a buffer read from disk to card images appropriate for use n the System Initialization/Reload process.

I found some files online that are described as DMS V2 R11 card trays - but the format of the files aren't known. There is a decent chance this may be the full card decks I am recreating - a third view of them to help me triangulate on the canonical version,. At the least, I may be able to recreate the sector break card text that is missing from the IBM1130.org recreated files - and missing for the decks that I don't have in my trays.

Some sections appear to encode the card columns with rows 12 down to 9 left justified in a word, which would leave the low nibble of each word as 0x00, but there are other sections where it is 1130 object code pure and simple, with nonzero values in all nibbles of each word.

Work on 1053, DMS2 system files and the mag tape support for 1130

1053 CONSOLE PRINTER RESTORATION

I removed the mainspring and began the task of rewinding the string to pull the carrier left and right, either under spring tension for spacing or under power to do a carrier return that winds the spring back up.

The ribbon color tape, a nylon tape that is hooked to the carrier and passes around fixed and levered pulleys on the frame, is used to either shift the ribbon to the black ink section or the red ink section of the ribbon. One end of the ribbon color tape tore off its hook, which I need to repair to restore bicolor operation.

I found a glue, Bondic, that is UV cured, based on the glues that are used by dentists on teeth. This promises to allow me to form a new loop at the end of the tape to attach the hook end. I did a test with a tape of the same type, but one that is too short to work on my machine. I found it does hold onto the tape end when the surface is roughed up and the glue is bonded as a clamp totally around the tape.

I tested the loop and did cause it to fail, but on the section that was not fully surrounded by glue. This looks promising, however, once I try a few times on the short tape and perfect my technique.

MAG TAPE SUPPORT FOR 1130

I am still researching means of driving my 9 track tape drives, the simplest being a card that plugs into a PC but that adds more complexity to the interfacing. I am hoping for something I can readily hook to the fpga inside the SAC Interface box.

I have to lock down the location of the tape connection before I make design decisions about how the adapter logic will work. I can't go too far on this, but I did stick in vestigial logic to respond to the tape area code and to provide ILSW and sense information back.

RECREATING SYSTEM DISTRIBUTION CARTRIDGE

IBM distributes DMS2 on a disk cartridge set up so you boot the disk to have it punch the 5000+ cards that will form the system initial load deck needed to put DMS2 on your own cart. The card decks I brought back from Kansas are system reload decks, containing only some of the 'phases' not everything. For example, about half of the Disk Utility Program phases are missing.

I have been doing some design work to reverse engineer the card decks by reading all those phases from my active cartridge using the SLET on sectors 3, 4 and 5. It points me to the core image of each phase on the disk and gives me the remaining information I need to recreate the card decks. What I can't completely recreate are the comments on the type 1 card that is first in each phase. These don't appear in the source code I see on the IBM1130.org web site nor are they stored on disk.

I worked through documentation and dumped some disk sectors to check out my hypotheses. I should be able to build equivalent card decks which will produce the same system disk cartridge when loaded as are currently on my disks. I can cross check against the many decks I do have - more than half but not all the phases - to ensure I am doing this right.

Once I have virtual card decks for all the phases, I can build a complete system initial load on the IBM 1130 simulator to prove out the process. If that works well, the last step is to pass these through the UCART utility which will turn a blank disk cartridge into a distribution cart that can be booted to punch out all the decks. Having a distribution cartridge means I can take it to any restored 1130 with a card punch and help them create their own system load decks.

I found that the format of the phases on disk is not any of the usual disk formats used by DMS2 - such as DSF or DCI or DDF - instead being just the core contents written on disk in the system area, with the SLET indicating the sector, word count and the execution address for the phase when fetched into core. The card images are a variant of the card formats - a type 1 card is the header, then card data format records, ending with a program end record. These look a lot like the output of the assembler or compilers.

Thus, after the header card, I have to read the disk image and convert each group of 45 words into a card image, with its own pseudo load address word, checksum and identifier at the front, the data words starting in col 10, and a module identifer plus sequencing in 73-80. I can fit seven full cards plus a residual card of five words into each disk sector.

I could continue this way until I have converted the total number of words from the system area on disk into punched cards. However, knowing that the loader will deal with spanning sectors, I will just punch the data I find on disk with 45 words per card until done. I then punch the end program card using the execution address from the SLET entry, to wrap up the card version of the phase.

Again, this won't exactly match the deck that would be produced by the assembly. The assembler pays no attention to sector breaks. Further, if it ends a card with some BSS or an area skipped by an ORG, it doesn't load those words. Instead, the next card begins with the first defined content address and continues. One oddity is that the first data card will begin with two words, zero and the phase number, in the two addresses preceding the initial core location but these are not stored on the disk. That adds two words to the card file compared to the disk file length.

Thus, the actual deck for DUP phase 02 is 35 data cards plus the type 1 header and end program cards. My method would punch 33 data cards (32 full plus two words on the last card). Mine is slightly more efficient because I am not hopping around with each ORG and attempting to skip over BSS blocks.

An alternate method is to assemble the program, save the punched deck and see how I might convert it to the system load format. My test worked out beautifully - if I assemble and then do a *DUMP from WS to cards, I get almost exactly the same deck. The first two cards punched by the *DUMP are tossed and my type 1 header is stuck in its place, but the remainder of the cards are exactly correct.

However, this is only as good as the source code I have purporting to be DMS V2. It is very close but I can't guarantee it exactly matches the version I have on my system. Therefore, I still need to produce my decks based on reading the system areas of my disk cartridge. 

Mag Tape routines and interface planning for SAC Interface Box

So little free time this weekend I could only do some quick reading and thinking in short breaks.

TAPE DRIVE SUPPORT FOR 1130

I have successfully assembled the mag tape subroutine and interrupt handler code necessary to use tape drives attached to the 1130 system, resolving any open questions about implementation specs for the SAC Interface Box. I now can implement the support, which is a subset of the Selector Channel RPQ plus adapter logic to make my 9 track drives behave as if they were 2400 series units.

Quite a few functions of a selector channel are not used by the subroutine - thus won't need to be implemented. Command Chaining, Transfer in Channel, Test IO, Halt IO, Data Chaining and Program Controlled Interrupts won't be supported, therefore. The only CCW flag that is used is Suppress Length Indication.

The subroutines I am using, an FDP distributed as program 0.03.003 for the 1130, were written for use with DMS Version 1, not V2. As such I have to make modifications for their use on V2. The original code made use of ISS number 5, which was not used in DMS V1 but is in conflict with the interrupt service subroutine for disk in V2.  I modified it to use ISS 15 for mag tape. I also had to rebuild the ILS04 they provided, since it did not include support for devices such as 2501 which were not supported in DMS V1.

The subroutine MAGTZ intended to allow use in FORTRAN requires a change to at least one run-time routine, SIOF, but also modifications to the Fortran compiler itself to recognize the IOCS device MAGNETIC TAPE and to support that on logical unit 11 in the program. The modifications to the compiler are not shown in the documentation I have and in any case would be unusable as they refer to the very old version of the compiler found in DMS V1.

I can support the new device type on the IOCS card by a source modification to kforph01 but I would either need to reload the system or turn it into a patch that can be applied to the existing load module on disk. I have not yet figured out the place to update where it will allow 11 as a logical unit number when tape was specified.

The fortran support via MAGTZ (using READ/WRITE commands) is not a priority and involves the work I described above. Fortunately, a slightly more cumbersome means is available for FORTRAN programs to use tape, via the subroutine MAGTA., Instead of READ/WRITE, the user issues CALL MAGTA statements and must do all data formatting operations that are otherwise performed by Fortran IO and FORMAT statements.

Not much work time, but some research leading to potential to hook tape drives to 1130

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Driver chip 3 seemed a likely suspect as it controls the six bits that are hot when I am loading a PC file in the 1130 core memory. However, I powered up the SAC Interface box and the 1130, where I didn't see any problem. I will have to keep watching this, because of the perfect alignment to the driver chip.

It is definitely not the SLT card in the 1131, since bits 6 and 7 are on one card and the remaining bits are on another, plus other bits on those cards work fine. No common point in the 1131 that would produce the symptoms seen.

I continued my careful study of the VHDL and all Xilinx warnings, tightening up code where it makes sense. Nothing stood out as a problem. Until I can get time to go into the workshop and test with more diagnostic information, I won't lick this issue.

2400 TAPE DRIVE ATTACHMENT TO 1130

I resumed my investigation into interfacing tape drives to the 1130, through my SAC box, as I now have enough to meet my two requirements - software which uses the tape drives and an adequately detailed description of the programming interface (XIO commands, interrupts, status words and so forth).

Peter Vaughan of the National Museum of Computing in the UK gave me the successful lead - a document on Bitsavers of a field developed program for accessing the mag tape drives from both assembler and Fortran - 00.3.003 - which includes listings of the programs including the interrupt handler.

It is clear that the attachment of the 2400 tape drives (usually 2415 models which had an integrated control unit that attach to a S/360 selector channel) was through the Selector Channel RPQ that put such a channel inside the 1133 Multiplexor box. This is adequately described in the Attachment Channel RPQ document on Bitsavers and matches what I see in the software.

The Selector Channel is accessed as area code 27 and interrupts on level 4 with ILSW bit position 12 indicating it is the source of the interrupt. This however adds a bit of convolution to the interface since the XIO Write function in the 1130 are used to pass a string of Channel Command Words to the selector channel, each three words long. Further, the XIO Sense Device uses its modifier bits to select which of four Channel Status Words rather than returning a single word of status.

The tape drives are programmed by CCWs just as they are on a S/360 system, which does allow me to reference the 360 library manuals for the 2400 drives to properly model the drive's behavior. The software supports a string of up to eight tape drives on a control unit.

Implementing a full selector channel involves a lot of capabilities - Transfer in Channel which is a branch to a new CCW location in core memory, Data chaining and command chaining, program controlled interrupts and other nuances. I am tempted to dig through the software and implement only those parts of the selector channel function that are used by the code.

I will set up the code from the manual as machine readable card images and test with the 1130 simulator to be sure I have a clean assembly and the code looks good. That can occur as I work out the Selector Channel RPQ function in the SAC Interface Box.

I will still have to figure out how I attach the actual tape drives - I have two that are SCSI based which would either require me building SCSI hardware into my SAC box or they could be attached to a PC with a SCSI card and have the data pass over the USB link. My current PC for the USB link and the Python program is a laptop running Linux so even the PC attachment alternative would be a bit more disruptive than it seems. 

Looking for cause of hot bits on inbound data from SAC interface box

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Still hunting down the phantom source of the 0x03F0 injected into the inbound data register. It is possible that this could be a hardware issue, since we are talking about six contiguous bits that are hot, but I can test that by using a voltmeter on my driver boards.

I did take the time to walk through the thousands of lines of output from the synthesis report, looking for warnings that I could clean up - not only for the phantom hot bits but just to cut down on errors to make any actual issues easier to spot in the future.

So little time until I get through the crunch time at work.

Debugging activity on the SAC box and a bit of remote aid

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Making good progress on the debugging of the 1053 mirror device, now that I included plenty of diagnostic information that I could watch on the PC as the fpga box did its thing. I started the ZDCIP standalone disk utility, which first types some instructions and choices on the 1053 console printer.

I could see that I was correctly setting up data characters, pushing them into the FIFO and popping them back out, because the values were visible while the activity was underway. What seemed to go awry was in the delivery of that retrieved word back to the PC.

Next, the PC was receiving empty buffer status but not handling it correctly. I need to tweak the Python program on the PC side to deal with this.

I then experienced the same problem again, with something locking up and forcing 0x03F0 on the inbound B bus, which is read anytime an XIO instruction or cycle steal looks to that shared bus. I think I triggered this by shutting off the 1130 before I had stopped the mirror 1053 adapter function.

However, even when I power cycled the SAC adapter, started up the Python program again and cycled the USB interface cord, the system still had the erroneous status on the bus. I am not sure how this could persist over the cold restart that I did. It might be a flaw in the USB driver in Linux on the PC or it might be something in the 1130 itself - this is puzzling.

I need to figure out ways this might happen, instrument some checks and figure out what happens, since when it reaches this wedged state with 0x03F0 forced on, I can't do any other testing. It is a priority problem.

HELP TO FELLOW RESTORERS

Today I was able to offer advice and suggestions to one friend, who is assisting a US based museum in restoring some 4381 and 360 systems, and to check out the 'normal' behavior of a part on a keypunch for another friend working on a keypunch at a UK based institution.

The 4381 startup is terminated when the -1.5V power supply detects over-current as it ramps up, protectively dropping all power to the system. It seems to be reaching a bit over 80 amperes when this happens. They were pondering ways of measuring the actual current draw to sections of the machine, but didn't have a good tool. We are looking at something under 18 thousandths of an ohm resistance. It takes a very accurate and precise ohmmeter to sort out the real resistance of the load.

Since the power is delivered over a laminated sandwich of power bars, one of which carries the -1.5V current, those bus bars having very low resistance but not zero, once can treat them as a resistor in series between the power supply and the load. Stick a sensitive voltmeter across the two 'ends' of the bus bar, nearest the supply and nearest the load, and you can determine the current. This is because the resistance of the bar can be measured, out of circuit, and once known the voltage drop measured is simply IxR. Thus, the current carried on the bus bar will be calculated as V/R.

The keypunch is not feeding well. It has a pair of'knives' that select just the front card and pull it down into the rollers, but one of the knives pivots left and right while the other is fixed in position. I verified from my 029 keypunch that both knives should pivot. If the knife is frozen and its front is not exactly parallel with the cards in the hopper, the 'high' end will push the cards backwards, such that they won't slide down the 'throat' that is carefully adjusted to be a bit over one card thick. 

Starting in on string retrheading in 1053 and further debugging of the SAC Interface Box

Work reaching a peak level lately, which starves me of time to spend on the systems.

1053 CONSOLE PRINTER RESTORATION

The string is fouled up that winds the mainspring when a carrier return is done and releases that energy powering space, tab and similar forward operations. It has wound around the hub of the mainspring takeup pulley, which I have to clear up before I can put the string back on its small pulleys and tensioner. I may need to rewind the spring as well to get it back to the right initial tension.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I found an interrupt status word feed that wasn't sourced, cleaned it up and had a successful load and verification of core memory. I could then get back to testing.

I did get the 2310 diagnostic to get through reading the first sectors of the virtual disk drive I had mounted on the PC. I made a few changes in the code but also saw the transactional engine hang up, which meant that a 'done' signal was not sensed leaving one or more FSMs stranded in the wrong state.

NIXIE TUBE CLOCK WITH DEKATRON TUBE PENDULUM

I assembled a clock with six Nixie tubes displaying the hour, minute and second digits, and a Dekatron tube spinning back and forth as an electronic pendulum. Nixie tube clock working I wanted the retro feel of the orange glow of these cold cathode gas discharge tubes. The Nixies have ten cathodes, shaped like the ten digits, while the Dekatron has ten positions around the circular face of the tube.

Dekatron's were built to display decimal data, often counters of some kind, with the discharge moving around the clock face each time a pulse arrives to make the glow jump to the successor position.

This was a quick little project to leverage the tubes which I have had in my collection of retro esoterica for quite a while. The final project will be a melange of different eras and looks - it will be housed in a cathedral radio cabinet, very 20s-30s, has digital display not analog so modern, but uses tube technology so kind of 1950s feel. I guess the pendulum is quasi-analog, with the moving dot reflecting the virtual pendulum swing.