The DMS2 IPL card

[Paul Anagnostopoulos]

I presume at least a few of you have read the code for the DMS2 IPL card. It's a masterpiece of diabolical programming in order to cram the necessary code on the 80-column card in whacky IPL format.

Does anyone from the IBM development group know why you felt it necessary to cram the entire thing on one card? It could certainly have been coded on three or four cards, with only the first one in IPL format. It would have been easier to write and more user-friendly.

Why only one card?

~~ Paul

[Paul Duggan]

To the best of my recollection from 48 years ago (gasp!), it was felt that CEs (customer engineers) would appreciate having a deck of single-card diagnostics for the CPU and all of the peripherals. Some wag insisted that they couldn’t be trusted with more than one card at a time.

 

Once our outstanding programmers, e.g., Gary Wheeler, mastered the bootstrap (IPL), the diagnostics were easy.

 

Also, with a multiple, say two card IPL, the first card would largely be consumed with reading the second, and on and on.

 

Regards,

 

Paul

 

______________________________________

Paul N. Duggan

17446 Plaza Otonal

San Diego, CA  92128

858.524.7876

Cell: 858.705.7876

pdugg...@gmail.com

www.ShoreFood.info

 

Sent from my old broken-down H-P laptop

 

---

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5246 - Release Date: 09/03/12

[Gary]

I agree with what Paul had to say about the desire to have the IPL reside on one card.  The guy in the development group that came up with this card (John Wood) was a programming genius.

 

Gary Wheeler

[Paul Anagnostopoulos]

Well, I suppose a multi-card deck might be shuffled by mistake, which would make for some fun. There isn't really an infinite regress on the number of cards. One can write a 2-card bootstrap loader that can load an arbitrary number of cards in 1800 format, so a 4- or 5-card deck to IPL the system would have been easy.

I suppose that in this grand tradition, the IPL deck for my fictitious OS/1130 should be one card. Will Gary Wheeler mind if I crib him?

~~ Paul

[Gary]

Hi Paul,

 

As I mentioned in a previous note today, I can’t take any credit for the one-card IPL loader.  I believe that as I mentioned in the other note, I believe the author was John Wood.  A true work of programming genius.

 

Gary Wheeler

[Bob Flanders]

Gary, 

Do you have any contact info for Mr Wood? Do you think he would be interested in joining the group?

Cheers, 

Bob

[John Doty]

On Sep 3, 2012, at 12:25 PM, Paul Duggan wrote:

Also, with a multiple, say two card IPL, the first card would largely be consumed with reading the second, and on and on.

Yes. The IPL hardware was rather clever. It wasn't just straight 12 bits in: it did some mapping. The the subset of instructions it supported encompassed most of what you needed in a boot loader. On the other hand, if your IPL program just read 12 bit card columns, you'd need to do substantial shift/mask stuff to get the next stage out of it. And then, the 1442 was a bit complicated to operate. Much easier to read a boot sector from the cartridge. That got you 320 words, and from there you could go places.

One of my friends once sent me an IPL card in the mail. It printed his mailing address on the console. Tricky bit of code, that.

John Doty              Noqsi Aerospace, Ltd.

http://www.noqsi.com/

j...@noqsi.com

[Paul Anagnostopoulos]

In honor of John Wood, I attach a listing of the DMS2 1-card disk bootstrap program.

~~ Paul

[Gary]

I believe John is in Rochester, MN, but I don’t have his e-mail address.

 

Gary

[F Towle]

Unless Mr Wood preceeded the 1130 system you should NOT assign credit to him.� As in many many instances of software being reinvented (many times out of ignorance of preceeding work) the idea of a one-card IPL goes back to BEFORE the IBM 709 (circa 1959).

In my 50+ years of software development there have be many instances of credit being taken (and profit made) for other peoples work including my own 'S.T.EM' product and of course the famous Lotus 1-2-3 vs Visicalc copyright case.� And, how about Al Gore inventing the internet...

Sorry for the rant - just had to.

Frank

On 9/3/2012 6:44 PM, Bob Flanders wrote:

Gary,�

Do you have any contact info for Mr Wood? Do you think he would be interested in joining the group?

Cheers,�

Bob

On Monday, September 3, 2012, Gary wrote:

Hi Paul,

�

As I mentioned in a previous note today, I can�t take any credit for the one-card IPL loader.� I believe that as I mentioned in the other note, I believe the author was John Wood.� A true work of programming genius.

�

Gary Wheeler

�

From: Paul Anagnostopoulos

Sent: Monday, September 03, 2012 3:25 PM

To: ibm...@googlegroups.com

Subject: Re: [IBM1130] The DMS2 IPL card

�

[Gary]

Well, I worked directly with John Wood for a few years, so I’m sticking with my earlier judgment of his abilities.

 

Gary

 

From: F Towle

Sent: Tuesday, September 04, 2012 8:58 AM

To: ibm...@googlegroups.com

Subject: Re: [IBM1130] The DMS2 IPL card

 

Unless Mr Wood preceeded the 1130 system you should NOT assign credit to him.  As in many many instances of software being reinvented (many times out of ignorance of preceeding work) the idea of a one-card IPL goes back to BEFORE the IBM 709 (circa 1959).

In my 50+ years of software development there have be many instances of credit being taken (and profit made) for other peoples work including my own 'S.T.EM' product and of course the famous Lotus 1-2-3 vs Visicalc copyright case.  And, how about Al Gore inventing the internet...

Sorry for the rant - just had to.

Frank

On 9/3/2012 6:44 PM, Bob Flanders wrote:

Gary, 

 

Do you have any contact info for Mr Wood? Do you think he would be interested in joining the group?

 

Cheers, 

Bob

 

On Monday, September 3, 2012, Gary wrote:

Hi Paul,

 

As I mentioned in a previous note today, I can’t take any credit for the one-card IPL loader.  I believe that as I mentioned in the other note, I believe the author was John Wood.  A true work of programming genius.

 

Gary Wheeler

 

From: Paul Anagnostopoulos

Sent: Monday, September 03, 2012 3:25 PM

To: javascript:_e({}, 'cvml', 'ibm...@googlegroups.com');

Subject: Re: [IBM1130] The DMS2 IPL card

[Paul Anagnostopoulos]

I don't think we were crediting Wood with the idea, just the implementation.

Here to whomever came up with the idea!

~~ Paul

[Eddy Quicksall]

I remember this card very well. This one would seek one track at a time and caused a buzzing noise until it got to track 0. I re-wrote it so there would only be one seek and that was what all of our customers at DNA used. I wish I had had the source at the time, I had to decode it all by hand to figure out how it worked. It was cool how the 12 bits from a card column was mapped to a 16 bit word. If John Wood was the one that thought that mapping technique then my hat is off to him.

BTW, I always wondered who it was that figured out the algorithm to convert 12 bit Hollerith to EBCDIC without using a table.

[Paul Anagnostopoulos]

Does anyone know why the IPL program did 1-cylinder seeks? According to the disk spec, it's perfectly fine to pull out the arm 203 cylinders in one seek.

~~ Paul

[John R Pierce]

isn't the only seek in IPL a 'home' ? IPL doesn't have anyway of
knowing what cylinder the disk is on, so it has to single step it until
the 'home' sense bit pops up. The 'seek' IOCTL is relative, and you
don't want to tell the disk to move 203 cylinders out when its only at
cylinder 10 or whatever.

[Paul Anagnostopoulos]

As far as I can tell from the documentation, you can pull the arm out 203 cylinders and it will stop when home. Doesn't matter what cylinder the arm is on when you do it. From Field Engineering Theory of Operation:

The adapter circuits prevent the access mechanism from moving backwards from the home position as the result of an operation. Remember that the 'access home latch' is off when the mechanism is in home position or is turned off when the mechanism reaches home during access movement. When 'access home latch' is off, activating 'access ready' turns off 'access control,' and no motion can occur.

Is it possible that the 2310 or 2311 drives didn't behave that way? I'd be surprised if anyone would design a disk access mechanism that would grind when overshot.

~~ Paul

[John Doty]

The APL IPL card did the 203 cylinder seek, with a loud "BRAAAAAT" as opposed to the clickety, clickety, clickety of the DM2 method.

The programming manuals often omitted details that the field engineering manuals contained, and the software often reflected this. None of the 1403 drivers in DM2 could drive the 1403 at the full 600 LPM. To do that, you needed to issue the next command before the completion interrupt for the current command. You could only do this if you alternated print and paper feed commands: otherwise you'd confuse the interface. The software manuals simplified this to "don't issue a new command before the completion of the current command", but you could get the real story from the field engineering manual.

Getting the 1403 to do 600 LPM was one of the speed tweaks we put into FORGO at Brockport.

[David N. Lombard]

On 12/09/2012 05:01 PM, Paul Anagnostopoulos wrote:
>
> Is it possible that the 2310 or 2311 drives didn't behave that way? I'd
> be surprised if anyone would design a disk access mechanism that would
> grind when overshot.

ISTR that crashes would occasionally result in a sickening grinding
sound. I had assumed the noise was the head assembly plowing into the
home position. But, I could well have assumed too much...

--
dnl

[John R Pierce]

IIRC, if the disk got a bad sector error and had to retry, it did the
single step all the way home, then seeked back and resumed. 2-3 of these
in a row, and you likely had a bad disk pack (or a disk that was written
on a drive that was in a different alignment than this one).

[Paul Anagnostopoulos]

Yes, I have a vague recollection of grinding noises, too. It would seem strange to design a drive to do that, when clearly it had a "access mechanism home" latch anyway.

My emulator halts the seek when the mechanism is home, so I'm relying on that for OS/1130. That's my story and I'm stickin' to it!

~~ Paul

[Peter Sawyer]

Delving into ancient memory here. The cold start card that was current when I first used the 1130 did the full 203 cylinder seek. I think that was DMS V2M5. It was changed to the incremental seek, I think at V2M7 (we only saw odd-numbered levels where I was). I think this was at the same time that some new disk hardware support was added. The built-in drive certainly had no problem with a seek that

[Peter Sawyer]

Delving into ancient memory here. The cold start card that was current when I first used the 1130 did the full 203 cylinder seek. I think that was DMS V2M5. It was changed to the incremental seek, I think at V2M7 (we only saw odd-numbered levels where I was). I think this was at the same time that some new disk hardware support was added. The built-in drive certainly had no problem with a seek that could not be fully executed. We used the older version of the card with newer software, up to and including V2M11.

 

(Apologies for the previous message. It was accidentally sent before being finished.)

----- Original Message -----

From: Paul Anagnostopoulos

To: ibm...@googlegroups.com

Sent: Sunday, December 09, 2012 21:32

[Carl Claunch]

A crash is when the disk head strikes the surface of the disk platter rather than 'flying' on the air streaming past (the air dragged by the rotating disk platter is a layered flow that acts on the head to force it to hover or fly a small distance above the disk surface). The head is forced onto the disk once it is at full rotational speed to ensure it flys rather than physically touching the platter. When a crash occurs, the head strikes the surface making a  scratch or divot. Imagine that an edge of the head touches the rotating platter, which digs in, tries to slow the massive platter, twists the arm and head and causes a rebound. The head swings and crashes in again and again. The sickening grinding sound is a head dragging across the platter digging a groove. Doing a seek will take the radial groove and turn it into a spiral gouge on the platter. 

Moving back to the home position will not cause a crash nor should it make any different sound from any other one or two cylinder movement. 

The physical mechanism has two rails of notched stops, one side used to stop a two-cylinder seek and the other to stop a one-cylinder seek step. When the drive detects the switch at the home position, it causes the adapter logic to abandon efforts to seek any further. The drive moves the arm an amount it things is roughly one or two cylinders, then a solenoid rams into a v shaped notch on the rail to force the arm to stop at the center of the v notch. A timer waits for the head and arm to finish shaking from its deceleration to a stop, then the adapter signals completion of the seek. 

As others have said, you can give it any number of cylinders to seek in an XIO Control command, with the adapter converting those into the only movements the drive can make, a 1 or 2 cylinder seek. The adapter logic will move 1 cylinder at the start for an odd number seek, then continue to issue 2 cylinder seeks until the count you provided in the IOCCC is exhausted or the home cylinder is reached. 

Interestingly, no switch exists for cylinder 203, which makes one wonder what happens if you try to overseek in that direction? 

Not sure what happens if you do a 2 cylinder seek and the home position is only 1 cylinder away, it may mechanically try but end up finding only the tooth for the home position on the stopping rail. 

The very slow sound of the 1 cylinder seek sounds like the programmer of the card issues a 1 cylinder seek XIO Control then uses the completion interrupt to issue the next one, after checking the home bit in the DSW. The faster sounding movement described for other IPL cards sounds as if the programmer issued a single XIO Control for a large number of cylinders and the drive issued one interrupt when it reached home position.

Not sure if there are drive problem scenarios that make the iterative single seek a preferred approach, or if it was just a personal choice by the programmer.

Carl

[John R Pierce]

On 12/10/2012 10:59 AM, Carl Claunch wrote:
> Not sure what happens if you do a 2 cylinder seek and the home
> position is only 1 cylinder away, it may mechanically try but end up
> finding only the tooth for the home position on the stopping rail.

IIRC, it makes a nasty sound. which is why 'home' used single seeks,
as did position error retries.

[John McKee]

The explanation was really nice. Now, I am wondering what the drive
would do if an attempt was made to seek past cylinder 203.......

Story I heard years ago was of a man who wanted to solve a system of
equations with 100 equations and 100 unknowns. No way would it fit in
memory. I have no idea how he coded it, but what I heard was he
estimated the program would require 24 hours of near constant disk
operation. The voice coil overheated after 12 hours. I don't
remember if the CE had to come out once or twice to replace the burned
out voice coil. But, a field revision was performed - a thermisistor
was installed to slow the seeking down as the coil heated.

John McKee

[Derrick]

As I remember(I was the one that did the recoding)- the origonal program
was supposed to run on a 370/145, but the PHD did not have the $$ to run
it there. So the 1130 that I was using as an RJE station during the day
was used for local computing nights and weekends. I took the fortran
code and redesigned it to use a 3x100 matrix for the work through the
100x100 matrixworth of data. talk about disk I/O. there was a log, but
I only had the 3MB system platter. The program ran, slowly but it ran
and produced the results he wanted.

For me, that was all that matered at the time. But that was a long time
ago (1971-72).

Later I used what I learned there to dilerbately sequentally crash 300
MB disk drives on a Prime 450 system at the Prime Computer
Headquarter's, after their head engineer told me it could not be done
since they were using CDC drives. What he did not know cost him 4
drives and a lobister dinner.

derrick

[John McKee]

Do you remember how it worked?

As I recall, I/O was not overlapped with FORTRAN.

So. either you wrote it all in Assembler, or had an Assembler
subroutine. Just wild guessing.

Maybe either double buffering of disk I/O or something else?

I had a wild idea to keep card reader, printer, console printer and
keyboard hot. Worked, sort of. I didn't have, at that time, anything
that needed that capability. I was looking at writing a program that
solicited responses for financial table creation and then stacked the
data for a COBOL program. I had my program hook into the interrupt
chain so I would always know when something was complete and could
start something else.

Maybe I am seeing more to the equation solver tan was needed. Just
wondering if you did that or not, and, if so, how.

John McKee

[miles_gmail]

Christmas Greetings all,

My initial introduction to the 1130 was as Manager of the C.E. Shull
Computing Center at Bridgewater College in Bridgewater VA in 1967. I was
recruited away from military research work at The Johns Hopkins Ballistic
Analysis Laboratory in Baltimore. John White was the Director of the Center
and had been recruited away from his work at Cape Kennedy. The 1130 was
bought on a NSF grant and was used for teaching and administrative working
replacing old IBM Unit Record Equipent.

In 1970 we left the college and formed Innovative Management Systems (IMS)
in Staunton VA along with Hiram Knopp who was president of Knopp Bros., Inc
(A Building Material Dealer company). IMS existed as a service bureau until
the 1980s.

Anyhow, we wrote everything in FORTRAN and learned early on that the native
FORTRAN I/O was SLOW! Through routines obtained from the COMMON library we
solved that problem. It required that we read and write as a "string" of
characters, 80 for the card readers, 132 for the printers, etc. The IBM
Commercial Subroutine Library provided routines to convert from character to
"Real" and "Integer" formats, etc.

The I/O routines were fully buffered and interrupt driven and we could
achieve unbelievable performance compared to the native FORTRAN mode. We
went from the 1132 to a 1403 printer. The "low" speed/price 1403 worked
great. We found that IBM had placed a jumper that kept performance low,
timed to the start point on the print chain. I remember well the
trepidation I had when I decided to remove that jumper to see if performance
increased. Would I mess something up and break the printer, etc. Anyhow, I
tried it and we then had the fast 1403 instead of the slower one. I admit
that this cheated IBM out of rental income, but that's water over the dam
now.

We eventually acquired LOGICON peripherals as more cost and performance
effective devices. We had a 600 lpm printer, 2314 type disk which gave us
the equivalent of 4 2310 platters plus a bulk area. We had a 9 track mag
tape, paper tape reader and 1200 baud async adapter.

It was a fun time.

Miles Sandin
Bridgewater VA

-----Original Message-----
From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf

Of John McKee
Sent: Thursday, December 13, 2012 12:02 PM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] The DMS2 IPL card

[Pete]

On Thursday, December 13, 2012 1:06:48 PM UTC-5, miles wrote:

Christmas Greetings all,

In 1970 we left the college and formed Innovative Management Systems (IMS)
in Staunton VA along with Hiram Knopp who was president of Knopp Bros., Inc
(A Building Material Dealer company).  IMS existed as a service bureau until
the 1980s.

Funny you should say this.  Perhaps because the 1130 was the "first" (FSVO "first") small affordable computer it may have inspired a lot of people to at least think of using it to start a business.  I know I toyed with the idea for a while back in 1968.

[John Doty]

On Dec 13, 2012, at 10:02 AM, John McKee wrote:

> As I recall, I/O was not overlapped with FORTRAN.

It was interrupt-driven, so you could compute and print at the same time, for example. It was not spooled, or even double buffered, so there were serious limits to the amount of concurrency you could achieve.

[John McKee]

I was just wondering how much, if any, performance would have been impacted if, instead of using FORTR

On Fri, Dec 14, 2012 at 2:26 PM, John Doty <j...@noqsi.com> wrote:

On Dec 13, 2012, at 10:02 AM, John McKee wrote:

> As I recall, I/O was not overlapped with FORTRAN.I/O, an Assembler routine was used to initiate data transfer for three rows while three rows were being worked.  Kind of like the double buffer card reading subroutine example I have seen - might have been in the IBM manual.  Based on the original estimate of 24 hours and apparently near constant Disk I/O, I was thinking that was the reason for the voice coil overheating.  With FORTRAN I/O, I didn't think the CPU was fast enough to need more rows that quickly.

My brother had a TRS-80 years ago.  There was a BASIC program to solve a system of equations.  No disk was used.  It was slow.  I rewrote the code that did the solution processing in Z-80 Assembler, calling ROM routines for all the math functions.  It was an amazing improvement.

So, from distant memory, was disk drive pretty much constantly busy without double buffering?

John McKee

[David DiVincenzo]

I wrote an overlapped I/O card deck listing program in Assembler. I don’t think it was possible in Fortran or other high-level languages because you had to work at the interrupt levels to initiate events and then test for completion later.

 

David A. DiVincenzo

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of John McKee
Sent: Friday, December 14, 2012 3:55 PM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] The DMS2 IPL card

 

I was just wondering how much, if any, performance would have been impacted if, instead of using FORTR

[miles_gmail]

Using the routines from the COMMON Library, we achieved full rated speed of the card reader and printer.  We printed invoices and statements (reading the data from the disk, doing calculations etc) while printing at full rated speed.  No exaggeration, folks.  We were a service bureau doing the work for laundries, building material dealers in Staunton, Petersburg and Lynchburg; dozens of payrolls and general ledgers, etc.  We had two full time data entry folks (using IBM 129 keypunches).  We used TI 742 programmable terminals to accumulate the data at our client’s offices and then “Polled” them during the night to retrieve the data and sending the reports back via courier/Trailways etc the next day.  We were busy and the 1130 was up to the task.  All written in FORTRAN and using “CALLable” routines from the IBM and COMMON libraries.

 

Miles

[John Doty]

On Dec 14, 2012, at 1:55 PM, John McKee wrote:

So, from distant memory, was disk drive pretty much constantly busy without double buffering?

In most cases, enough disk buffer to have had a significant effect would have taken too much precious memory. Also, in a standard DM2 Fortran flow, disk seeks were the largest bottleneck. The "Ramkit" disk had an extremely slow head carriage. Buffering doesn't help that problem much.

For FORGO, we carefully arranged compiler overlays ("phases") on the disk to minimize seeking, and we created pre-linked library files to avoid the large number of seeks the linker normally needed.

There was an exception: there was one regular class assignment that involved simple processing of a large data set, so while code was small, data was too big to fit into memory, requiring the student to keep working data on disk. For this, we set up a special library with a simple disk cache hiding underneath Fortran's binary I/O. I don't remember exactly what the problem was, but I recall that it had the characteristic that accesses were correlated. The code tended to repeatedly access a small subset of the data. Because of this special characteristic, the cache produced a substantial speedup. But the 1130's primary memory was too small for effective cacheing in most circumstances.

[David N. Lombard]

On 12/14/2012 12:26 PM, John Doty wrote:
>
> On Dec 13, 2012, at 10:02 AM, John McKee wrote:
>
>> As I recall, I/O was not overlapped with FORTRAN.
>
> It was interrupt-driven, so you could compute and print at the same time, for example. It was not spooled, or even double buffered, so there were serious limits to the amount of concurrency you could achieve.
>

There was a software package (from COMMON?) that provided full spooling
among the 1442 card reader and 1132 printer. IIRC, an equivalence was
used to enable it?

Wow, thinking about this, I recall a UEOP function that would set a value
whenever the EOP was hit since you couldn't actually read the carriage
control tape. Code using this would look something like

...
CALL UEOP(MAGIC)

10 CONTINUE
...compute...
IF(MAGIC.EQ.1) WRITE(3,100)
WRITE...
WRITE...
IF(.NOT.DONE) GO TO 10
...

100 FORMAT(1H1)

--
dnl

[John McKee]

Maybe an Assembler program that was called immediately after an I/O operation was completed that only did the seek might have made a difference.  Still use FORTRAN I/O as normal.  In this case, the FORTRAN I/O would determine (maybe) that the heads were where they needed to be, thus a *little* faster.

Anyway, this makes disk I/O on the IBM 1401 make sense.  On those disk drives, reading and writing were dedicated functions.  But, seeking was asychronous.  You could start a seek, do something, then test seek status and stay in a loop waiting for completion. 

Kid of related, but on a completely different system:  I attended a system management class for a VAX system in 1990.  The teacher had prepared a very good demonstration on how VMS handled memory paging and swapping.  Simple FORTRAN program.  It had a two dimension array.  FORTRAN on VAX/VMS handled arrays just like the 1130 - in column major order.  His little program was in two versions.  One did array processing in row major order, and the other in column major order.  The column major order screamed right through.  The row major order brought the multi-user system to its knees.  There was an incredible amount of page faulting going on.   Few of use (out of 8) could even log in to see that faulting.  Just incredibly slow.  Difference between VAX/VMS and the 1130 is that the 1130 could only swap out entire programs and the VAX system (VMS was the operating system) swapped out memory pages.  As a student programming assignment on the 1130, we had to create a rather involve RPG program.  It was so big that all the subroutines were *LOCALed.  Incredibly slow.  Convert program to DCI and it ran considerably faster.  Seek time, I assume, was the improvement.

John McKee

[Jeff Jonas]

John McKee:

> Difference between VAX/VMS and the 1130 is that the 1130 could only swap
> out entire programs and the VAX system (VMS was the operating system)
> swapped out memory pages. As a student programming assignment on the 1130,
> we had to create a rather involve RPG program. It was so big that all the
> subroutines were *LOCALed. Incredibly slow. Convert program to DCI and it
> ran considerably faster. Seek time, I assume, was the improvement.

A minor correction: the IBM 1130 and most systems of the 50s and 60s
used overlays, not virtual memory.
It was all software without any hardware assist.
I believe the linker implemented
LOCAL (load on call) and SOCAL (system call load on call)
since it set up the subroutine call linkage.

The major differences:
- paging Virtual Memory writes back all "dirty" pages,
loading pages only as required.
Hardware assist is required to interrupt the instruction
when it accesses non-allocated memory and to track modified pages.
- swapping VM writes back entire segments (text, data) for context switch
and must load the entire segment for the process/task to run.
I guess it can run without hardware assist,
but cannot detect when RAM is modified.
- overlays only READ a single subroutine into core
There is NO write-back.
It can be implemented by intercepting the function call
to assure it's already in RAM.


A simple single overlay was something like this:
- compile each subroutine into a separate file (or library member)
- specify what subroutines are load-on-call/overlays
- the linker allocates RAM for the largest subroutine
- before every call to a subroutine in the overlay list
Is the desired subroutine already in RAM?
no: read it in from disk

then goto/gosub the function in the overlay area

More advanced overlay systems allowed for multiple areas
and for overlays to call other overlays.
The nested calls were specified in advance
with a tree-like structure.

The stock IBM 1130 running DM2 was a single task batch system.
Some folks modified the system with things like the old PC-DOS "sidekick"
where a small program was memory-resident and resumed with a hotkey.
As to swapping out entire tasks,
I'm sure it was done at least as a checkpoint/restart
(a feature that Windows 8 embedded just rediscovered!)

>> For FORGO, we carefully arranged compiler overlays ("phases") on the disk
>> to minimize seeking, and we created pre-linked library files to avoid the
>> large number of seeks the linker normally needed.

Wowzers, memories of SOAP (Self Optimizing Assembler Program)
where computers running directly from drum (before core!)
similarly optimized the placement of operands
to execute with minimal rotational latency!
Shades of Mel a Real Programmer :-)


-- jeffj

[miles_gmail]

There were routines written and submitted to the Common Library that enabled
buffering, etc. These were invoked by the FORTRAN "CALL" statement.

Miles

-----Original Message-----
From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf
Of John Doty
Sent: Friday, December 14, 2012 3:27 PM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] The DMS2 IPL card

[Derrick]

Maybe I am not remembering correctly - but I seem to remember that 1130
Fortran allowed for inline assembler code. That was one of the tricks
that I used because memory was so tight. Until we got the memory
upgrade there were a lot of programs that we could not load the compiler
and the source code into memory ar the same time.

That is just something that I learned about taking all of the advantages
offered by a language, even when they weren't that well documented - at
least not in the IBM documentation that I had available.
derrick

[John R Pierce]

On 12/16/2012 5:49 PM, Derrick wrote:
> Maybe I am not remembering correctly - but I seem to remember that
> 1130 Fortran allowed for inline assembler code. That was one of the
> tricks that I used because memory was so tight. Until we got the
> memory upgrade there were a lot of programs that we could not load the
> compiler and the source code into memory ar the same time.

no, the assembler and 1130 fortran were completely different. you had
to compile assembler with // ASM and could link it with Fortran ....

[James Field]

Rubbish! You can linkedit ANY correctly structured results of a compile
or assembly into a core-loadable module. This is as true then as it is
today.

I do not recall any feechur in 1130 Fortran, described in the Fortran
manual that described a formal method of linking subroutines written
different higher level languages but I DO know that I did it (as many
others did).

Jim

[John R Pierce]

On 12/19/2012 11:05 AM, James Field wrote:
>>
> Rubbish! You can linkedit ANY correctly structured results of a
> compile or assembly into a core-loadable module. This is as true then
> as it is today.

thats what I was trying to say.

the OP was asking about inline assembler in a FORTRAN program, that
wasn't supported at all, I was saying, perhaps not clearly enough, that
you had to assemble the assembler code with // ASM, then link it
together with your fortran.

[John Doty]

Yes. Note that the Fortran compiler did not pass its code through the assembler: it translated directly to relocatable binary. Thus, inline assembly language would have been difficult to support.

[John R Pierce]

On 12/19/2012 12:34 PM, John Doty wrote:
> Yes. Note that the Fortran compiler did not pass its code through the assembler: it translated directly to relocatable binary. Thus, inline assembly language would have been difficult to support.

eggzaktly.

that Fortran compiler was quite a piece of work, it was like 27 passes
or something. pass one read the source deck, parsed and tokenized the
keywords and constants, tossed the comments, and stored the entire
program in whatever free memory was left (about 5K in an 8K machine).
Each successive pass loaded its code overlay, and took one swipe through
that in-memory stream, massaging it down farther and farther, until the
final pass wrote out the object code to the temporary area on the hard
drive.

[Paul Anagnostopoulos]

All hail the Fortran compiler designers and programmers!

~~ Paul

[Eddy Quicksall]

I don't know. As I said my IPL only did one XIO to move to the home position. All I did was to seek 203 cylinders in one shot. It could be that the earliest drives would get damaged if you try to seek past cylinder 0. I remember I was a little scared that I would screw up the drive and a little experimenting showed it didn't seem to hurt it a bit.

On the GA 18/30 (an 1130/1800 mixture clone), they used multiple cards. Also the 18/30 used the IBM 1800 IPL format I think. That IPL format used just 8 bits per card column. It took 2 columns to make a word. So for the 1800 it was much easier to write the IPL code.

I suspect that when they designed the 1130 they figured out a way to IPL with just one card using the "split" technique.

Eddy

On Sun, Dec 9, 2012 at 4:40 PM, Paul Anagnostopoulos <pcanagno...@gmail.com> wrote:

Does anyone know why the IPL program did 1-cylinder seeks? According to the disk spec, it's perfectly fine to pull out the arm 203 cylinders in one seek.

~~ Paul

[Eddy Quicksall]

While at DNA Systems, I wrote the card reader spooling for 1130 TSO (Time Sharing Option). I read the cards in the background and after the last column was read I jumped to interrupt level 4 where I would write the image to disk. We had a 1000cpm reader and it would go full speed even with terminals, tape, printer and probably more running full speed (but this was on an 1130 clone called the Digital Scientific Meta-4).

[mad...@vijit.com]

I remember disassembling IBM's version of the IPL card. The following
information is from memory, so I may be wrong...

ISTR that it did a (descending) seek for 1 cylinder, then read a sector
off the disk, compared the expected address with what it read, and then
halted if there was a mismatch. Keep it up until you hit cylinder 0.

I think that the sector address was written in the first part of each sector
on the disk, thus you could read a sector and "know" the arm position.

I remember when we got the much faster boot card that did the single seek to
home. We were eternally grateful to whomever wrote it -- no one seemed to
know who it was, though.

In my experiments with the hardware, I do recall that seeking to
home with an overly large cylinder count was OK -- the arm would just
stop -- but God forbid you should seek inwards too far: it would just
continue to grind and make a bad noise until it exhausted the cylinder count
you specified. I was told it could hurt the mechanism in some way as
well (but I was never told what the problem would be).

Assuming I'm correct in my recollection of the IPL code, it makes sense,
as it was checking the disk seek mechanism against the disk, making sure both
were OK. If you're a paranoid IBM programmer writing production code, this
is something you might do. And who knows, maybe they had reliability
problems with early seek mechanisms or reading disk sectors or something
and wanted to make sure they had a "known" working disk before starting
the OS. Or maybe they did disk engineering changes and needed a reliable IPL
card that would make sure it was working.

If anyone knows the history behind why it was written that way, it would
be really interesting to know!

And, on another note, a fun property of the 1442 punch was that it
would stop punching a card only when you told it. If you told the punch
it was the end of the card after 10 columns, it would eject the card. And
if you just happened (like I did) to tell the punch that the card had 81
columns, well, you'd get an extra column on your card. Not that you could
read it, but an 81-column laced card was a fun thing to show people.
The CE warned me that making laced cards was really hard on the punch so I
didn't do it too often. The loud grinding noice it made when lacing a card
was interesting...

And finally, a piece from an IBM diagnostic to determine whether the machine
the code was running on was the 2.2 usec or 3.6 usec cycle time model:
LDX L1 2000
[other stuff not of interest]
XIO [shift console ribbon to red from black]
ZIPD [get interrupt switch]
BZ ZIPE
MDX 1 -1 Bump timer
MDX ZIPD
[if here, 2.2 us machine]
[...]
ZIPE [if here, 3.6 us machine]

Note: This was copied from an old note and I may not have written it
correctly. The main cool thing here was that it used the shift console
ribbon to red as a timing device, which I think was really creative.
I assume that either some earlier code piece made sure it was already
shift-to-black or that the timing was unaffected if the ribbon happened
to be already red -- I don't know.

OK, one more anecdote...
When I was at the University of Chicago, the IBM 1130 was located in the
Graduate School of Education. There was a music program that ran on the
1130; you would punch the notes on cards and the program would then play
the song through a radio placed underneath the console. I was told
that it worked by creating long strings of NOPs with a branch at the
end of them, and that that code at the end created the RFI that, when
repeated many times per second, created the correct sound frequency coming
from the radio. I.e., the NOPs were "silent" and essentially used for
timing the RFI pulses. I was told this program was written by Tom Emerson
at the UoC, but I was never able to verify that one way or another.
Anyway, I was looking at the code for it at the time, as I was curious
as to how it worked. One comment read "INPUT IS FUBAR". I was maybe 13-15
years old and didn't know what this term meant, so I went to the
lab's director (Wylie Crawford) and asked him. There was quite
a long pause and at the time I wondered why.
He told me an answer that was reasonable but wasn't quite literal :-)
I only found out years later what it meant. It still makes me smile.

---dcm

[Eddy Quicksall]

>>I remember when we got the much faster boot card that did the single seek to
>>home.  We were eternally grateful to whomever wrote it -- no one seemed to
>>know who it was, though.

I think that was me. I used to use that card as my "calling card". I called it "quickboot" (a play from my last name: Quicksall). In this thread I said how I did it.

Eddy

[Eddy Quicksall]

The IBM Fortran would not overlap disk I/O but in the early 70's I replaced SDFIO with an overlapped version. I sold a few until Dave Morse wrote XBASE which had many extensions including overlapped disk I/O.