Biggest and best 1130 ever?
68 views
Skip to first unread message
rbsteup
Mar 26, 2015, 4:39:43 PM3/26/15
to ibm...@googlegroups.com
I am a retired IBM engineer and worked at several of IBM plants and labs. IBM was a heavy user of 1130's. It was said that there was no place in the Fishkill, NY plant where there was not an 1130 in sight unless you were in a rest room. I was a heavy user of the 1130 in both the development labs and manufacturing.
While working at the Manassas, VA plant, I and three other engineers worked for several years on a integrated circuit design program using what I suspect might be the most loaded up 1130 of all time.
The system had the full 32K word memory. Attachments included a 2501 card reader, 1442 card punch, two 2315 disk drives, 2250 display, dual 7 / 9 track tape drive and a Computervision digitizer / plotter attached to a digital I/O board, and a modem connected phone line.
The system was used to develop a program for graphical design of large scale integrated circuits which were manufactured at the Manassas plant. The program was in continuous development and upgrades for a period of several years. There were over 100,000 source cards for the system, a mixture of Fortran and Assembler.
We had engineers using the program at many IBM sites. We received daily bug reports and improvement requests from our users. Bug fixes were usually made the same day and the users could download them to their 1130 the same evening over the modem. Requested improvements were usually done in a day or two! The modem was also used to RJE (Remote Job Entry) completed designs to an S/360 which did the artwork generation for the photolithography masks for the manufacturing line.
Attached are several screen shots of the 2250 display. The program was named IPF ( Interactive Pre-FADS )
While working at the Manassas, VA plant, I and three other engineers worked for several years on a integrated circuit design program using what I suspect might be the most loaded up 1130 of all time.
The system had the full 32K word memory. Attachments included a 2501 card reader, 1442 card punch, two 2315 disk drives, 2250 display, dual 7 / 9 track tape drive and a Computervision digitizer / plotter attached to a digital I/O board, and a modem connected phone line.
The system was used to develop a program for graphical design of large scale integrated circuits which were manufactured at the Manassas plant. The program was in continuous development and upgrades for a period of several years. There were over 100,000 source cards for the system, a mixture of Fortran and Assembler.
We had engineers using the program at many IBM sites. We received daily bug reports and improvement requests from our users. Bug fixes were usually made the same day and the users could download them to their 1130 the same evening over the modem. Requested improvements were usually done in a day or two! The modem was also used to RJE (Remote Job Entry) completed designs to an S/360 which did the artwork generation for the photolithography masks for the manufacturing line.
Attached are several screen shots of the 2250 display. The program was named IPF ( Interactive Pre-FADS )
Howard Shubs
Mar 27, 2015, 6:25:46 AM3/27/15
to ibm...@googlegroups.com
On Thursday, March 26, 2015 at 1:39:43 PM UTC-7, rbsteup wrote:
We had engineers using the program at many IBM sites. We received daily bug reports and improvement requests from our users. Bug fixes were usually made the same day and the users could download them to their 1130 the same evening over the modem. Requested improvements were usually done in a day or two! The modem was also used to RJE (Remote Job Entry) completed designs to an S/360 which did the artwork generation for the photolithography masks for the manufacturing line.
Attached are several screen shots of the 2250 display. The program was named IPF ( Interactive Pre-FADS )
Impressive stuff! Thanks for posting that.
mwright
Mar 27, 2015, 1:48:49 PM3/27/15
to ibm...@googlegroups.com
+1 on the IBM use of 1130s (and 1800s) at East Fishkill (and Kingston and Poughkeepsie). I was a (young) CE ca 1977-1982 and worked on both 1130 and 1800 systems with all sorts of (sometimes unsupported) attached devices. In addition to IBM using these systems, local IBM vendors across the Mid-Hudson Valley also had 1130s and 1800s installed for their manufacturing and testing of subassemblies. Broken Selectric parts and burnt-out light bulbs caused a lot of outages. Bad capacitors in power supplies were a problem too. These systems ran around the clock, so I would often be fixing one in the middle of the night.
Mike
On Thursday, March 26, 2015 at 1:39:43 PM UTC-7, rbsteup wrote:
Johannes Thelen
Mar 29, 2015, 1:52:55 PM3/29/15
to ibm...@googlegroups.com
Can I borrow these photos on my blog? I'm writing (slowly) historical review of computer displays before home computer to my blog (ennenmikrotietokoneita.blogspot.fi) and these would nicely fit that story!
Ps. Just curios, what is first computer display if we forget Williams tubes and SAGE system, display what was ment to general purpose use (not memory with visual benefits nor radar display)? Maybe IBM 740..? http://www-03.ibm.com/ibm/history/exhibits/701/701_1415bx40.html
rbsteup
Mar 29, 2015, 3:38:47 PM3/29/15
to ibm...@googlegroups.com
Johannes Thelen
I have a total of 25 screen photos of the IPF system / 2250 display. You are welcome to use any or all of them.
The photos were taken for slides to be used in a presentation I gave at the Yorktown, NY Research conference on design automation.
I forget the date. I'll attach all of them here.
Johannes Thelen
Mar 30, 2015, 4:59:09 PM3/30/15
to ibm...@googlegroups.com
Perfect! Thank you! :D
It is amazing if we download flash light app to our phone, it takes 10 megabytes. And you guys had IC CAD in 64 kilobyte ;)
There is not much photos of 2250 on the Net, either any early CAD systems (I have ever seen anything like this amazing before!)
rbsteup
Mar 30, 2015, 6:36:01 PM3/30/15
to ibm...@googlegroups.com
The 2250 display for the 1130 was an expensive beast, about $200,000 as I remember. Not many around!
The graphics buffer for the 2250 was allocated in the 1130 memory. IPF used an 8K (word) buffer which took a big bite out of the 32k word memory leaving only 24K for programs and data. We had to use locals / socals ( load on call subroutines ) to make it all fit. Being that we worked for IBM we had access to the source code for the Fortran compiler and the 1130 Disk Monitor System (DMS). So we made many "improvements" to both!
One improvement to the DMS was in the boot code to figure out what I/O devices were attached ( 1132 vs 1403 printer, 2501 vs 1442 card reader ) and reconfigure the system to accomodate the hardware configuration. This was necessary because there was no standard hardware configuration among our users and doing it the standard IBM way by changing cards in the config card deck and running it which was a pain in the neck. Our users usually used whatever 1130 system was available to them at the moment and repeatedly reconfiguring their system disk was a pain in the a**!
One of the changes to the Fortran compiler was to add the Fortran internal buffer as an additional read / write device. That way we could use fortran read write and format statements to convert between character strings and integer and real numbers. We could only write characters to the 2250 display, so this allowed us to write to the 2250 screen with Fortran.
The IBM software support for the 2250 was very poor so we used a internally written Graphic Input Outport Support Program ( GIOSP ) which we also heavily modified for our purposes. One of our improvements was an odometer capability to continuously display the coordinates of the light pen as it moved in chip coordinates. GIOSP was written entirely in 1130 assembler.
The graphics buffer for the 2250 was allocated in the 1130 memory. IPF used an 8K (word) buffer which took a big bite out of the 32k word memory leaving only 24K for programs and data. We had to use locals / socals ( load on call subroutines ) to make it all fit. Being that we worked for IBM we had access to the source code for the Fortran compiler and the 1130 Disk Monitor System (DMS). So we made many "improvements" to both!
One improvement to the DMS was in the boot code to figure out what I/O devices were attached ( 1132 vs 1403 printer, 2501 vs 1442 card reader ) and reconfigure the system to accomodate the hardware configuration. This was necessary because there was no standard hardware configuration among our users and doing it the standard IBM way by changing cards in the config card deck and running it which was a pain in the neck. Our users usually used whatever 1130 system was available to them at the moment and repeatedly reconfiguring their system disk was a pain in the a**!
One of the changes to the Fortran compiler was to add the Fortran internal buffer as an additional read / write device. That way we could use fortran read write and format statements to convert between character strings and integer and real numbers. We could only write characters to the 2250 display, so this allowed us to write to the 2250 screen with Fortran.
The IBM software support for the 2250 was very poor so we used a internally written Graphic Input Outport Support Program ( GIOSP ) which we also heavily modified for our purposes. One of our improvements was an odometer capability to continuously display the coordinates of the light pen as it moved in chip coordinates. GIOSP was written entirely in 1130 assembler.
rbsteup
Mar 31, 2015, 9:35:28 AM3/31/15
to ibm...@googlegroups.com
More interesting things about the 1130 IPF Program.
The IPF program was written in the mid 70's. The 1130 Disk Monitor Program was very primitive compared to today's operating systems. One of the biggest problems was the way the DMS handled disk I/O to give programs access to files.
The IPF program consisted of quite a few mainline programs which used a Fortran CALL LINK statement to switch between various tasks. The programs were large and only one at a time could occupy the available memory. The programs were stored as core images to speed things up. BUT the DMS required that the absolute disk addresses of the files to be accessed be stored in the core image program. We had to write our own disk data management system since there might be several part numbers on the data disk at one time and each part had a number of data files associated with it which could grow or shrink in size as the design progressed. This ruled out the DMS requirement of having files in the fixed area of disk which had to be specified at the time the core image program was built.
In Fortran the files to be used in the program were defined by DEFINE FILE statements, which if not specified in the core image build were assigned to working storage on the disk. The solution was to write an assembler language program called DEFFL which was called at execution time to dynamically modify the internal Fortran file definition table to assign absolute disk addresses, record lengths etc. at execution time. The IPF data disk was set up as all fixed area with just one file which took up the entire disk which was controlled entirely by the IPF Program. One of the options in the IPF program was to initialize a new IPF data disk.
The IPF program was written in the mid 70's. The 1130 Disk Monitor Program was very primitive compared to today's operating systems. One of the biggest problems was the way the DMS handled disk I/O to give programs access to files.
The IPF program consisted of quite a few mainline programs which used a Fortran CALL LINK statement to switch between various tasks. The programs were large and only one at a time could occupy the available memory. The programs were stored as core images to speed things up. BUT the DMS required that the absolute disk addresses of the files to be accessed be stored in the core image program. We had to write our own disk data management system since there might be several part numbers on the data disk at one time and each part had a number of data files associated with it which could grow or shrink in size as the design progressed. This ruled out the DMS requirement of having files in the fixed area of disk which had to be specified at the time the core image program was built.
In Fortran the files to be used in the program were defined by DEFINE FILE statements, which if not specified in the core image build were assigned to working storage on the disk. The solution was to write an assembler language program called DEFFL which was called at execution time to dynamically modify the internal Fortran file definition table to assign absolute disk addresses, record lengths etc. at execution time. The IPF data disk was set up as all fixed area with just one file which took up the entire disk which was controlled entirely by the IPF Program. One of the options in the IPF program was to initialize a new IPF data disk.
Reply all
Reply to author
Forward
0 new messages