Tuesday, December 22, 2015

Done with System Load deck work

SYSTEM LOAD DECK WORK

I am still having problems with the phase 1 loader program (DSYSLDR1) reading in the phsae 2 loader (FSYSLDR2). The error I receive is E03 Seq Error or Missing Record which the code shows can come from three faults:
  1. SCON card not read after the loading of the phase 2 loader is complete
  2. the phase 2 loader did not have a type F card recognized (end of its deck)
I have already processed the MODE card and the code is reading the phase 2 loader when the error occurs. Something is wrong with the phase 2 loader deck or something is wrong with the phase 1 code that is reading it. It shouldn't be looking for the SCON card until it finished reading the phase 2 loader and in any case, there is a valid SCON card immediately after the end of phase 2.

I suspect the problem is with the check for the type F card. However, the phase 1 code that is throwing off the error is unique in that it is stored in the binary card loader format, not the usual card data CDD format of all the other phases. This is processed by a utility provided by Brian Knittel, Makeboot, which might be causing some problem with my DSYSLDR1 deck. I will need to carefully examine both programs and perhaps do some hand-debugging on the 1130 simulator.

I used the listing to figure out where to place a WAIT instruction and how to investigate which of the two causes has triggered the error message. When I ran it, the reason was that it hadn't recognized the type F record. I can see a type F at the end of the deck, so there must be something malformed about that card image.

The problem comes in how I split the deck assembled from the single source PMONITOR which yields decks used in two different places in the load process. The first portion is the resident monitor, EMN, which is loaded by DSYSLDR1 just prior to loading FSYSLDR2 and continuing. The second portion are the device driver phases 8C to 98 which come in sequence after the core image loader phases.

Brian split the source deck, assembled each separately, but I decided to assemble it as one and divide up the binary object deck. The type F card is produced by the assembler when it sees the END directive at the end of the source program. Thus, the type F card was misplaced at the end of the device phases rather than right after the resident monitor. I moved the card around to the proper location and the ERR 03 went away.

My next stop was when loading phase 7 of the DUP program, where I had ERR 04 ORG BACKWARD on program JGDELETE. It was simply because I had omitted the SBRK card at the front of the source code, easily fixed. I now was able to process the entire system reload deck. From the initial testing I have done, it is all working properly.

My next step was to package the update into the files in the same groupings as for the V12 update. Similarly, I am finalizing a grouping that would represent a full initial load cartridge as it might have existed if IBM had shipped a V13 of the monitor system.

This project is essentially complete now - I have canonical versions of V11 and V12 plus a correct update from V11 to V12. In addition, I have a presumptive full version of "V13" and an update from V12 to "V13". I can build cartridge images for any of these versions.

WILLIAMS TUBE MEMORY PROJECT

Bob Erickson began a project to produce a working Williams-Kilburn tube memory system. This was a technique used in a few of the earliest computers, such as Manchester Mark I, Von Neumann's IAS system and the IBM 701, using the surface of a CRT tube to store bits as a memory. Mercury delay lines were a contemporaneous alternative, as used in the Univac 1, but these all gave way to magnetic core memories once they were developed by Jay Forrestor.

Bob had serviced these systems while at IBM and had a memory tray in his possession which he intended to use, with driving circuitry he would design in line with the circuits he knew from the 701, to recreate a working memory for visitors. Bob and a few other volunteers worked on building this up, but Bob succumbed to cancer before the system could be completed.

The CHM doesn't want it taking up space in the workroom, so I have taken temporary custody of the unit. I would like to participate in completing this but have far too many other projects in line first to accomplish anything in the near term. Still, better to preserve this and hope to build a team later than to see it scrapped.

No comments:

Post a Comment