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.