Talk:IBM 1130

Indirect addressing

Earlier drafts referred to the 16thbit being used for indirect addressing. That is incorrect. The indirect bit is in the instruction format, not the address. Addressing was 15bits (32K 16bit WORDS), addresses were signed so address arithmetic makes sense. KymFarnik 03:08, 2 April 2007 (UTC)

I remember it well . . .

When I was at Waikato University in the late 70s/early 80s, there was an 1130 out the back. It was already obsolete then and had been replaced by a PDP 11/70 and an 11/34. It was fascinating, with this great big back panel covered in blinking lights, and the golf-ball typewriter, and great big disk cartridges that seemed to hold about 3 bits of information! For the fun of it I wrote a 4x4x4 noughts and crosses game on it in Fortran (I think) - it worked pretty well, although it relied on reprinting the position after each move. I don't think I've got a listing of it any more, though. I have since written a new game in Delphi (nDm) loosely based on it to run under Windows. Pedrocelli 01:11, 18 September 2007 (UTC)

When I started at Kingsport Press in August 1969 in the Tape Data Processing department, TDP was running type composition on an IBM 1130. Manuscripts were keyed to paper tape on Friden Flexowriters, font setwidths were stored as card decks, and the justified and hyphenated output paper tapes from the composition program on the 1130 were used to drive Mergenthaler Linotype linecasters. Paper tapes from the Cafeteria cash registers were also processed on our 1130 for payroll deductions of cafeteria charges. Compared to the IBM 360 in MIS, our 1130 was cute. Naaman Brown (talk) 15:22, 4 May 2009 (UTC)

I also remember it well ... I was one of the authors of the EMU-IBM 1130 Fortran Compiler. I still have a copy of the user manual we wrote as documentation for our users. It started as an attempt to produce better diagnostics; I took on the front end, working on the parser, while my colleague C. David Morse, looked into the object code generation. I was in my senior year, and Dave was a grad student. We obtained a copy of the source code from the computer center at the University of Michigan, who had bought the tape from IBM. What we got was a file cabinet full of punched cards - I think it was one deck of assembler code for each of 27 phases of the compiler. By the time we finished we had added two phases, and upgraded the compiler from Fortran II to Fortran IV. The work was carried out by Peter Diehr and C. David Morse, staff programmers for Instructional Computer Services of Eastern Michigan University. Pdiehr (talk) 12:53, 22 March 2011 (UTC)

Number Sold?

The article states that the 1130 "became quite popular." I don't dispute that, but does anyone have information on how many 1130's were manufactured and/or shipped? Peter Flass (talk) 17:17, 1 January 2012 (UTC)

I understand that there are tribes in the Amazon who count: one, two, three(?), many. I'd say the answer is "many". - Denimadept (talk) 19:22, 1 January 2012 (UTC)

Fortuitously I happened to run into the Brian Utley interview from IBM1130.org which gave me a ballpark number of 10,000 systems. Too bad this hasn't yet been transcribed. Peter Flass (talk) 13:55, 2 January 2012 (UTC)

Program Examples

I suggest that the program examples are very long, don't add anything to the article, and should be removed. Peter Flass (talk) 01:35, 3 January 2012 (UTC)

IMNSHO, they do add to the article. Especially for those of us that once programmed an 1130. Eeekster (talk) 04:55, 20 February 2012 (UTC)

The examples should illustrate something and not just assist in reminiscing. In my opinion, the example in assembly language illustrates the interplay of job control cards and user program to make a complete job; and illustrates calling routines with both CALL and LIBF, whose mechanics were explained in preceding sections. Spike-from-NH (talk) 14:15, 1 March 2012 (UTC)

And copyright notice

I just looked at the programming examples. Are we allowed to have stuff which requires such attribution? - Denimadept (talk) 22:45, 29 March 2012 (UTC)

As far as I can tell this is the only article on Wikipedia that has an in-article MIT copyright notice. Wikipedia's guidelines don't seem to explicitly prohibit the use of an MIT licence but I would be astonished if portions of an article could have a separate licence from the overriding article licence - besides which all submissions require that the submitter irrevocably agrees to release his contribution under the CC BY-SA 3.0 etc. I've taken that out but left the copyright notice in the source code as a non-legally-binding comment. -146.200.202.185 (talk) 12:45, 29 August 2015 (UTC)

Author Farnik asserts a copyright to the examples, as one must not when contributing to Wikipedia. It would be better if Farnik either renounced the copyright to the material from 9 years ago and deleted the copyright notice, or withdrew the contribution. It is not a solution to leave the copyright notice in the "source code" and declare on the talk page that it doesn't mean what it says. Spike-from-NH (talk) 14:14, 29 August 2015 (UTC)

Just to clarify, the copyright and license assertions clearly only apply to the assembler example. The Fortran and APL examples predate it and do not contain such assertions. RossPatterson (talk) 15:23, 29 August 2015 (UTC)

The assembler example was added by user KymFarnik on 29 April 2006. Given the coincidence in names, there is a high probability that they are the same person. Given that the code was added to the article before the CC-BY-SA dual-licensing change in 2009, user KymFarnik would have added the code to the article under the GNU Free Documentation License, and it would still be licensed that way, regardless of what it says in the code comments (or in the article proper, where the copyright assertion that Spike-from-NH just deleted was also added in the same revision). To make matters more interesting, this article was started in March 2004 by user Farnik, whose last contribution was the same day as user KymFarnik's first, so they may also both be the same person. RossPatterson (talk) 15:24, 29 August 2015 (UTC)

Quibble: It was 146.200.202.185, not I, who deleted the assertion in the text, though I agree with it. Spike-from-NH (talk) 15:48, 29 August 2015 (UTC)

Yes, both id's are me. I renounce copyright of the code KymFarnik (talk) 06:38, 30 August 2015 (UTC)

Remaining Machines

Looking at the 360 article I see they list remaining systems, whether working or not. This should be included also for the 1130. Peter Flass (talk) 01:35, 3 January 2012 (UTC)

Last I looked, there was one in the Seattle area, and one in Nice, France. I'm not sure if the one in Nice is still there. - Denimadept (talk) 05:44, 20 February 2012 (UTC)

Based on our pictures, there is also one at the Computer History Museum in California, one at Bletchley Park's National Museum of Computing, and one in private hands at http://www.dvq.com/1130/1130.htm --agr (talk) 19:41, 20 February 2012 (UTC)

Might anyone know if there exists, anywhere in the world, a working IBM 1130 system? (where “working”, in the same sense as used above, just means that it can run some minimal programs on occasion) 76.100.23.153 (talk) 02:31, 3 November 2012 (UTC)

Operating System vs. Monitor

Overall I like the recent edits by Spike-from-NH, but what's the distinction between "operating system" and "monitor?" The terms are often used interchangeably, e.g. "TOPS-10 monitor" is certainly an OS. On the other hand MS-DOS is considered an "operating system", and I would rate it about the complexity of DM2 or worse (DOS users usually did direct hardware video IO, bypassing the cruddy video support). I think the distinction is subjective. "Not complainin, just askin." Peter Flass (talk) 13:16, 1 March 2012 (UTC)

Your comment suggests that wording toward the start of Section 1.2--which now reads, "The 1130 did not have an operating system but a 'monitor.'"--is too categorical, and that's a valid comment. MS-DOS is an operating system, despite its simplicity, because it provides a "full" range of run-time services (whether or not you elect to use them). Did the Skeleton Supervisor provide run-time services (beyond the ability to end the current job)? Even if the user had to link IBM run-time services into his program, they might be regarded as part of an "operating system." Spike-from-NH (talk) 13:35, 1 March 2012 (UTC)

PS--Upon further review, the article doesn't lose anything if I just delete the above sentence. DMS is defined shortly thereafter, and the reader can decide for himself whether it is an "operating system." Spike-from-NH (talk) 14:04, 1 March 2012 (UTC)

Resident monitor vs Operating system#Summary - Denimadept (talk) 22:48, 29 March 2012 (UTC)

Though I noted above the deletion of the one problematic sentence, I've now added the term resident monitor to that section (Operating procedure). Spike-from-NH (talk) 23:22, 29 March 2012 (UTC)

LIBF vs. CALL

What were the advantages of using LIBF rather than CALL? Peter Flass (talk) 06:16, 3 March 2012 (UTC)

Looking for the answer to my own question, I guess LIBF calls were short calls and saved a word for each call. Peter Flass (talk) 06:25, 3 March 2012 (UTC)

I think so. NickyMcLean has made useful technical corrections, but one change was to move the rationale for LIBF from the start of that section to near the end. I questioned this on his talk page and will now revert that small piece of his edits. Spike-from-NH (talk) 10:33, 3 March 2012 (UTC)

"END START"

Re: "odd-looking "END START": I don't think that's odd -- don't all assemblers accept a start address on the END statement? Certainly all I'm aware of. [I know that's not your change, but you made me look...]Peter Flass (talk) 17:27, 22 March 2012 (UTC)

Yes, the adjective is a value judgment, and a lot of assemblers do put the start address there. I debated style on User talk:NickyMcLean, as Nicky likes to highlight the counter-intuitiveness of things in a way I find non-encyclopedic. I'll take another look at the article. Spike-from-NH (talk) 17:39, 22 March 2012 (UTC)

Hmm. I would not have included that sentence at all, but in view of the discussion on style, I won't remove it now. A much better way than prose to discuss coding nuances (including CALL HLEBC) is by including more comments in the code example itself; I would do so, but am unsure what it means that the example deck is copyrighted. Spike-from-NH (talk) 17:45, 22 March 2012 (UTC)

It was after the assembler-based encounters of END START and the like that I came to view with disfavour the absence of such a protocol in higher-level languages, and thus the appearance of desperately lame commentary in the source file such as " end; {of procedure SIMPLE}" as might appear in Pascal for example. In pl/i, by contrast the name (if supplied) was checked by the compiler, with obvious benefits for nests of "ends", and while I dislike this and that about pl/i, I strongly approve of the name linking and always used it. Adding commentary on statements to explain the statement rather than the usage or effect of the statement is out of place except in a context explaining the statement's form (as in a manual on how to write assembler source) - an example prog. should contain commentary on what the example does (as would be normal for a documented prog.) while the associated text is the place for explanations of how the various protocols employed work, especially those that lead to surprising results such as END START. Or so it seems to me... I mean, the author chose "START" precisely so as to create this contrast. Well, I certainly did this but perhaps I should not extend my guilt to presume others guilty also.NickyMcLean (talk) 20:47, 22 March 2012 (UTC)

I too code end; {case} and end; {record} in Pascal although it does nothing. All of us ASM coders enjoyed the self-contradiction of END START but it was hardly the only reason to name your program's starting point START. Again, my personal opinion is that the supposed irony doesn't add anything to the article, and I am on the fence as to whether the explanation of END START appreciably helps anyone understand the example. Spike-from-NH (talk) 21:25, 23 March 2012 (UTC)

1132

I'm in a nitpickey mood today. The description of the sample assembler program saye "The printer, however, recognises text in 8-bit EBCDIC". This is true of the 1403; I had to look up the 1132 to check my memory, but technically the printer doesn't recognize anything. The print wheels are continuously running, and the 1132 continuously makes available to the CPU the code for the print wheel character in position to print next. An instruction of the print routine causes this code to be sent to the CPU. The routine compares this code with each character in the output record. Each time an equal is encountered, a bit is stored in the printer scan field

http://media.ibm1130.org/IBM%20227-3622-1%20FETO-MOI%201132%20printer.pdf

Peter Flass (talk) 22:57, 22 March 2012 (UTC)

Well, not quite. The printer when primed for action generates an interrupt whereby it reports that it will shortly be ready to start printing the next character in sequence on a print wheel; the 1130 then scans the text in the supplied buffer for printing to find occurrences of that character and sets ones correspondingly in a special fixed memory area that the printer will later scan (ready or not!) to decide which print wheels to trigger. The character coding could be any coding suitable for the device but in fact it uses EBCDIC codings, provided by a disc rotating in synchrony with the print wheels that has apertures for on-bits; the pattern of apertures is the EBCDIC code rather than some private code that may provide some hardware advantage - the console printer uses a rotate&tilt code for its golfball for example. It could use card hole patterns, or something else, but EBCDIC is the one. The 1403 printer used its own encodings also, not EBCDIC, but something related to the chain mechanism. As I recall, the character to be printed was reported sixteen position steps before the print impact, thus given successive symbols being in place somewhere on the line, sixteen sets of wheels would be at various stages of motion towards the platen, provided the 1130 kept up with the rotation trigger points. NickyMcLean (talk) 04:05, 23 March 2012 (UTC)

Interesting details, I didn't know this. I thought the 1403 was buffered and the 1130 sent it a line at a time. Of course it's been a couple of years now, and I didn't really know that much at the time anyhow. Peter Flass (talk) 12:53, 23 March 2012 (UTC)

The controller for the 1403 had an internal buffer, so programs just output a line of characters to be printed (in BCD on the 1400 series, EBCDIC on the 360s and up) to the controller. The controller then generated the appropriate pulses for the print hammer. The 1130 avoided the need for all that circuitry by figuring out the pulse patterns in the printer driver as described above. I'm not sure why the disc rotating in synchrony with the 1132 print wheels would need anything more than hole for each printwheel position to generate the interrupt and an extra hole to serve as an index mark. The driver can easily keep track of which code in up next to print.--agr (talk) 20:26, 23 March 2012 (UTC)

Agreed that the 1130 design minimised expensive electronics, so that peripherals had very little and encoding tasks were done by the cpu which has lots of electronics anyway; a saving. If the 1132 printer signalled merely an index mark (say for the letter A) plus a tick for each impending character, the 1130cpu could contain a schedule of characters in the correct order but the driver would have to be always in synchrony (via interrupts) with the rotation of the print set even when not printing, or, when printing is to begin, would have to await the special index tick and then stay in synchrony. I didn't actually dare disassemble the printer mechanism (or the covers) - though I did attach voltmeters to the console lights - so I can't say for certain, but I thinly recall being told this by the IBM engineer and seeing the disc (but I may be retrospectively creating that recollection), and do not recall seeing any such table in the printer driver. (I twiddled them all, saving space to introduce a WAIT op code) Anyway, a patterned disc with a few light sensors whose state was transferrable to the cpu is not so much circuitry. This would mean that print scanning could commence on the very next character tick. NickyMcLean (talk) 03:16, 24 March 2012 (UTC)

Did you meant 1132 in the above?? The 1403 had a controller with a buffer, you just sent it all the characters for a line in 1403 character code. See http://www.ibm1130.net/functional/Printers.html. As for the the 1132 timing disk, it's tricky to read multiple channels off of a disk like that due to timing issues. Most modern coded wheels use Gray code to minimize such problems. --agr (talk) 23:32, 29 March 2012 (UTC)

Yes, my mistake and corrected, thanks. For the code signalling, a grey code would not be needed as this is not a matter of the position of the disc being measured (as in the direction of the wind) and the position annoyingly hovering close to a boundary with some sensors flickering on/off. It is more like reading paper tape or card punch holes, where the sensor state can be taken at a time in the middle of the state, well after boundaries have passed over the sensors and they have settled into the current state. NickyMcLean (talk) 20:22, 3 April 2012 (UTC)

I looked up the 1132 in the IBM 1130 Functional Characteristics manual [1]. On page 46 it describes the 1132 Read Emitter instruction: "This instruction cause the eight-bit code of the next character to be printed, emitted by the printer, to be read..." So you are indeed correct.--agr (talk) 20:54, 3 April 2012 (UTC)

"Software oddities"

This section of the article should be reorganized. The final three items, on the derivation of "IBM 1130", are more like Apocrypha and deserve to be the final section. (They also deserve citation, or maybe omission.)

The first item, incompatibilities in object file formats, I'd delete as way outside the scope of the article.

The other items are not "oddities" but useful information directly related to information elsewhere in the article and ought to be moved. The second item (which belongs at the end of "Instruction set overview") is:

The index registers were replicated in core memory at locations 1, 2 and 3. Index register 0 (IAR) was a genuine hardware register, and memory word zero usually was set to contain a BR *-1, which is to say, a jump to itself. This would trap any jump to location zero, which would surely be an error.

Relative addressing is akin to indexation, but is there any real evidence that IAR is best thought of as an "index register"? To what extent are 1, 2, and 3 not also "genuine hardware registers"? Spike-from-NH (talk) 18:12, 1 April 2012 (UTC)

The opcode format assigned two bits to indicate which register to involve, and 00 = XR0 = IAR so it is accessible as an index register but one implemented in circuitry rather than core memory. The 1800 used circuitry for all the index registers as a point of difference and presumably, core memory locations 1 ,2 and 3 became available as well. But because XR0 was of course used as the instruction address register and was incremented as an opcode was decoded, it is special and deserves the speedy access of a in-circuitry register. I don't recall whether the assembler accepted the use of the XR0 form, as in LDX 0 as well as LDX 1 etc. but a number of apparently distinct mnemonics were in fact special forms of a more general instruction. Whereas on the PDP-11, the IAR was register 7 and called PC, while register 6 was called SP for stack pointer and with PC had extra action from the hardware, not just as per opcode-commanded manipulation, thus hardware interrupts messed with SP, so you couldn't quite decide to use say R5 as a stack pointer instead. Anyway, as for "best thought of as", for IAR presumably not, because it is messed with by the hardware no matter what you may choose to think better of. It is quite possible to have all registers (including ACC, and EXT) actually in core memory (circuitry being expensive) and various tricks suddenly become possible just as the MDM instruction is a deformation of modify index register. But, there is a large performance boost from registers in cpu circuitry, at a cost. So, the difference should be described if possibly not with "genuine".

As for cpu speeds, I haven't looked closely... I do recall that it was a matter of the length of a delay line, and when your cpu was upgraded to a higher cost version, the cpu was just the same but the delay line was shorter, a deed requiring only a short visit from the IBM fellow, who possibly was expected to delay matters to make the change appear more significant - a remove and replace, rather than twiddle a knob. I had idle thoughts of applying a wire cutter... The printer-interrupt-on trick was tested, and established that Victoria university did not have the slower version by test not just accepting assertion, so motivation was lacking. If instead the slower versions had IAR as memory word zero, there would be substantial circuitry changed (thus increasing costs for the model range), plus BR *-1 could no longer be in address zero. Instead, a jump to address zero would encounter zero, which is the opcode for STOP (or would be an invalid opcode, and cause a stop) except that should an interrupt follow then after the interrupt is processed the return would be to address 1, while with the BR *-1, at the end of each opcode execution (when an interrupt is accepted), IAR = 0 so that the return would be to address zero.NickyMcLean (talk) 20:15, 3 April 2012 (UTC)

PS--And more questions. The table says the Model 4 runs at "3.6 μsec (70% performance)". The prose says "with a 5.6 µs cycle time". I can't reconcile these figures; which is correct? In what order are the columns of the table? Shouldn't they be in chronological order, which is also basically Model 1, 2, 3, 4, 5? Spike-from-NH (talk) 00:38, 3 April 2012 (UTC)

Index registers

Didn't the 1800 have real index registers? I think this was a difference between the 1130 and 1800. Peter Flass (talk) 02:06, 4 April 2012 (UTC)

I've post-edited Nicky in the table, as the key point there is not whether or not they are hardware registers but that they have memory addresses. Spike-from-NH (talk) 02:28, 4 April 2012 (UTC)

The 1800 did indeed have hardware registers for all four (or IAR + XR1-3) so that low memory was normal, but I've no idea what use might be made of memory locations 1-3 thereby released.NickyMcLean (talk) 21:06, 4 April 2012 (UTC)

1620

I think the 1620 was a precursor in that it was aimed at the same market - small scientific/engineering organizations. They were physically both desk-sized systems. Other than that, you're right. The 1620 and the 1130 were both about as similar as the 7090 and the 360, or the 1401 and the 360, but I think you could say the 7090 and 1401 were "precursors" of the 360, or maybe better, the 360 was a "successor" of them both. Peter Flass (talk) 23:58, 4 April 2012 (UTC)

FORTRAN IV

GeneOsten's edit to the article is correct; anyone following the article's External Links can download a PDF of the FORTRAN manual preceding Eastern Michigan's improvements, which billed itself not as FORTRAN II but "1130/1800 Basic FORTRAN IV". Spike-from-NH (talk) 00:03, 18 September 2014 (UTC)

Disk formats

I can't seem to find information on how the LET/FLET entry identifies the disk location of the file. Also DUP documentation touches on "disk blocks" which seem to be separate from sectors but I can't find a definition. Peter Flass (talk) 01:41, 7 February 2015 (UTC)

You've checked Disk Monitor System, Version 2? - Denimadept (talk) 01:48, 7 February 2015 (UTC)

I guess you've been looking here. Did it just calculate the location by adding up the lengths of all the previous files? It says in the article the disk was always kept defragged. I remember whenever you deleted a file the files further along the disk would be inevitably copied down to remove any embedded free space. If the file was an old one and so early on the disk this would take ages. Thincat (talk) 22:38, 7 February 2015 (UTC)

The defrag statement was there before I worked on the article; I have to verify it, I think in passing I noted a reference to using DUP to compact the disk. The way the disk was structured it would not need to be defragged as often as other systems. Peter Flass (talk) 22:59, 7 February 2015 (UTC)

I recall no DUP command to compact the disk. Rather, whenever a file was deleted, DUP went right ahead and did the compaction. The immediate compaction is mentioned here (search for *DELETE). However, it doesn't explicitly say that file locations are not stored (and, as I said, I think they are calculated). Thincat (talk) 00:03, 8 February 2015 (UTC)

Note "1DUMY" entries. - Denimadept (talk) 00:55, 8 February 2015 (UTC)

Fortran code example

Regarding the revert war over the Fortran code example, I don't know and don't care about fortran versus fortranfixed, as ensuring that keywords and numerals appear in pretty colors does not help understanding. However, the last edit of Cedar101 (reverted by Denimadept) solved one problem: Interpreting as Fortran the numeric data at the end of the card deck imposed coloration that actively impeded understanding.

There is a fundamental problem here: The example is a deck of punched cards that includes Job Control Language (//), Fortran, and data and cannot be treated correctly in a single <source>...</source> block.

Separately, youse should talk to each other (for example: below) and agree on the goal of your edits. Spike-from-NH (talk) 13:10, 15 April 2016 (UTC)

We have talked. It's not a war. It's trying to get the formatting to come out straight. Look at the details of the edits. - Denimadept (talk) 23:41, 15 April 2016 (UTC)

Very good. "War" not in the sense of armaments and casualties. Thanks. Spike-from-NH (talk) 00:39, 16 April 2016 (UTC)

Thanks, I know what an edit war is. :-> - Denimadept (talk) 16:50, 16 April 2016 (UTC)

PRE

I don't know what has changed, but parts of this article using <PRE>...</PRE>, such as the instruction-set overview and some short code examples, are now being displayed in a variable-width font. This impedes understanding, as it prevents the columns from lining up. Spike-from-NH (talk) 14:44, 24 May 2016 (UTC)

The <pre>, <source lang="fortranfixed"> and lines with leading spaces all look fixed-width to me (and I know how important it is for the columns to line up right) Firefox 46, Windows 10 but also Chrome and Edge. Thincat (talk) 15:33, 24 May 2016 (UTC)

I glanced at the instruction set overview and it looks fine to me -Safari, iOS on iPAD. Peter Flass (talk) 16:02, 24 May 2016 (UTC)

OK, thanks for the check. My problem must be some local setting. Spike-from-NH (talk) 16:33, 24 May 2016 (UTC)

1130s today

I added a section listing existing 1130 systems. It would be nice for someone who knows to update the status: display/storage, working/non-working,, etc. or add any other existing systems. Peter Flass (talk) 13:34, 13 July 2016 (UTC)

LIBF vs CALL and FORTRAN vs Assembler

The section called Programming opens as if talking about FORTRAN and gets to LIBF. LIBF was more or less an IBM thing (per the PLM: "The cost, of course, is that XR3 is taken away from the user and the transfer vector is limited to 255 words"), and while one could code an ASM LIBF, it was atypical. It certainly wouldn't have been directly FORTRAN-callable. Reminds me... I wanted to add something to XR3, but ended up adding /0038.

LIBF invocations were from ASM code, or were generated by the FORTRAN compiler and hence were mostly invisible to the end-user (excluding rhose running disassemblers and reading core dumps) Pi314m (talk) 09:28, 12 February 2017 (UTC)

I think I added the first paragraph of Programming by way of justifying why I was converting "subroutine" to "subprogram," but as most of the section does indeed deal with assembler, it seems unnecessary and I'll remove it. Regarding your edit, documenting the supervisor's use of individual memory words might be beyond the scope of the article. Spike-from-NH (talk) 12:42, 12 February 2017 (UTC)

Within "Operating procedure" and before "Recovery procedures" I'd recommend a heading "Initial Program Load (IPL)" so that "Recovery procedures" can have a followup regarding restoring the operating system or the use of 1-card programs (while changing disks, e.g. for APL).

Following "Initial Program Load (IPL)" would be

it was usual to begin by booting. The bootstrap procedure read one card from the card reader. The boot card contained binary code to read the contents of sector zero of the disk drive, which in turn would handle the "operation complete" interrupt from the disk drive and perform additional disk reads to prepare the 1130 for the first punched-card job. The whole process took about a second to complete.

(unchanged). "Recovery procedures" could then begin with "When the IBM 1130 was started ..." Pi314m (talk) 22:12, 13 February 2017 (UTC)

A new unnumbered head sounds fine, as this is technically not a "recovery procedure." Spike-from-NH (talk) 01:45, 14 February 2017 (UTC)

INT REQ already mentioned

2 matters, plus-

#1, it was not the next "//" card to which the system skipped, it was the next "// JOB" card

#2, the text at the start of Operating Procedures already mentions INT REQ

#3a, the JOB card had a "T" option, for temporary files. Users who stored a subroutine or function, for a separately oompiled/assembled module, knew that it would "go away" at the end of the job.

#3b, the cancelling of a job in effect meant that the "temp" subprograms were effectively gone at that point.

As to what edits to make... that's for the next edit. Pi314m (talk) 05:43, 17 February 2017 (UTC)

Operationally, most 1130s were operated either as Glass-house (closed shop) or Open-shop.

The first INT REQ can be for Glass-house, and the second for Open-shop, with unnumbered sections named accordingly. Pi314m (talk) 06:31, 21 February 2017 (UTC)

End of production

Does anyone know when the production run ended? - Denimadept (talk) 18:42, 7 November 2017 (UTC)

Fortran compiler

My university bought a 4K machine to go with its 16K machine. Student jobs desiring only to syntax-check a program were designated for the 4K machine. This is the basis of the text I added years ago that "The 1130 Fortran compiler could run on a machine with only 4,096 words of core—though the compiled program might not fit on such a machine."

So the article notes that the first phase of compilation "read the source statements into memory." On one hand, it is unremarkable that lines would be read into memory; you can't manipulate strings on disk. On the other hand, surely the entire program was not read into memory, from which it would be handed off to subsequent phases, as this passage implies. If there was a temporary file passed from phase to phase, wouldn't this fact be more crucial than listing what the first phase does? Spike-from-NH (talk) 14:55, 27 January 2019 (UTC)

The 1130 Fortran compiler didn't use the disk for temporary space, only for the DSF output, made famous by the "Output has been surpressed" message. The "into memory" part makes a good point. Other small-for-their-day compilers spooled (another fun word, Simultaneous Peripheral Operation On-Line, the latter being another potential for putting this sentence on the push-down stack) the source to magtape! This allowed for more memory to hold compiler code. IBM chose to have a larger number of compiler phases, and keep the source code in-memory.

Without a Compiler PLM handy, this may seem like WP:OR, but I liked IBM's use of phases, including for DM2, since it allowed patching and adding phases to track system "date" (there was none, unless added locally), user accounting, and other tricks borrowed from the 360 arena. Pi314m (talk) 22:45, 28 January 2019 (UTC)

Well, I am baffled. Sure, phases (being overlays) free up more RAM for the program being compiled, but again, I remember that we compiled programs even though they would not load on the same machine. It may be that the sentence I cited at the start of this needs to go. Spike-from-NH (talk) 22:56, 28 January 2019 (UTC)

The sentence is fine and is correct as is. A program that included a DIMENSION statement for 20 items, each needing 250 IBM-1130 16 bit words, could readily compile on a 4K machine, yet it couldn't run on that machine.

Just as an aside, the space-squeezing techniques made it impossible for the compiler to see the problem with:

.... DO 120 J=1.256 ... 120 CONTINUE

(which is why programs like Lint (software) were written.

"Lint"-type programs could see the spaces, but the compiler saw it as

.... DO120J=1.256 (a simple assignment statement) Pi314m (talk) 04:28, 29 January 2019 (UTC)

Thanks for the clarification. Yes, the sentence can stand (though there were FORTRAN programs that couldn't be compiled in 4K based on the size of the program code). On your aside, the RFO-BASIC! interpreter, which can be sideloaded into an Android device, suffers from the same problem due to the same compression (and, to boot, requires one to not pick variable names whose start is a reserved word). Spike-from-NH (talk) 05:28, 29 January 2019 (UTC)

Note the next sentence "The compiler was available in a disk-resident version as well as on 8-channel punched paper tape or punched cards." - systems without a disc drive facility could not use temporary storage (since card readers/punchers and paper tape don't do "rewind and re-read" very well), thus the card-only systems for assembler really did require a second pass of the card deck through the reader/punch. I'm happy not to have suffered this arrangement on an 1130, but on an IBM1620 at Auckland University, which did not have a disc system, there was indeed temporary output to a deck of cards which had to be read in for the compiler's second pass and then discarded. Lots of cards. Cringe. Also, the cards of its symbol table output (the last part of the intermediate output card deck) had to be found and placed at the start of the deck to be read, since otherwise, forwards references (that were finalised only when the last source statement had been read in the first pass) still could not be resolved in the second pass if it were at the end of the deck. It was the last phase of the 1130's Fortran compiler that could write the finalised relocatable machine code it had developed in memory - to cards, paper tape, or to the disc drive.

I vaguely remember occasional problems when the compiler ran out of memory during its processing, not just in its input phase - some phases caused an increase in the size of the representation of the code as compilation proceeded and the phases "massaged" the internal representation, and this resulted in pained scrutiny of the size, number, complexity and prolixity of FORMAT statements or possibly the splitting of the source (subprogram or main prog.) into parts which would then require some sort of arrangement to share data. Simply changing the size of arrays would not help with the problem of source code complexity and bulk. It was thanks to arrays that most often a prog. would not fit at run time. This problem promoted the re-use of variables for different purposes in different parts of a prog. rather than each part having its own properly-named variables, with obvious opportunities for mistakes. The corresponding encouragement of divide-and-conquer for the source code was countered by the increasing annoyance of arranging communication between the parts, and pragmatically, splitting a subprogram A into A1, A2, A3 meant that each had its own working storage that could not be shared (except via increasing dismay with COMMON storage arrangements and their risks) and since memory usage was static, the working storage required for A2 and A3 was consumed even though A1 was the only one active. Code storage could be shared with LOCAL (load-on-call) arrangements, but everyone preferred the faster-running offered by progs. that did not employ this.

At Victoria University Clive Nicholson and I modified the Fortran compiler's input phase so that instead of rejecting outright any source that had a statement with more than six (?) continuation lines, it would do so only if the squeezed representation of the continued statement exceeded the internal representation's statement length limit, which was the actual problem. Thereby, a complex statement could be presented in some sort of semi-readable layout, perhaps. Persons engaged in Quantum Mechanical Computation liked high-order expressions, some similar in form to the expansion of (A + B)**i x (A - B)**j. for i and j up to nine in one case, where A**i actually meant A(i), etc.. I should have written a prog. to produce the expansions. Instead, the student and his professor worked through them by hand, as did I when checking. Ah well. NickyMcLean (talk) 10:21, 30 January 2019 (UTC)

Two-pass card-based assemblers weren’t uncommon. I think the S/360 BPS assembler punched the assembled instruction back into reserved columns of the source card. — Preceding unsigned comment added by Peter Flass (talk • contribs)

Indeed, it was the 1130's relatively affordable disk drive, which made compilation so much easier, that made it a quantum leap over earlier low end IBM computers.--agr (talk) 16:50, 30 January 2019 (UTC)

1130 vs.PDP-8

A recent edit mentioned that the PDP-8 was “smaller, cheaper, and better-selling” than the 1130. Smaller and better-selling are obvious, but how did similarly-configured systems compare in price? The 1130 came with a 1MB disk, 65KB on RAM, and 1050 console printer and usually (IME) a card-reader/punch and 80lpm printer. I think the PDP-8 usually came with nothing. Also, it looks like the -8 was faster, but how did the two systems compare on benchmarks? Peter Flass (talk) 00:36, 27 April 2020 (UTC)

Since many different models of the PDP-8 were produced, at different speeds, and available I/O devices, over many years, this comparison isn't so easy. It only makes sense to compare ones with similar I/O devices. For example, don't compare a disk based Fortran compiler on the 1130 with a paper tape or maybe DECtape compiler on the PDP-8. As well as I know, many PDP-8 systems might run with only paper tape I/O, and an ASR-33 terminal for user I/O. Gah4 (talk) 03:32, 27 April 2020 (UTC)

Xerox 530

1973: Xerox had a 530 at a trade show. People stopped by. 530s were bought by 1130 shops. The success stories of the 530, however, were not enough to offset that the 560s apparently didn't do as well. Pi314m (talk) 01:49, 17 September 2020 (UTC)

SAC

The section "reserved memory" has the SAC interrupting on IL1,2,3,4,5. Attachment Channel RPQ description lists only IL4. It makes sense that it would use only one interrupt level. I believe the SCA used IL3. I guess the info in the article as written comes from "Functional Characteristics." Can anyone clarify? I don't want to make changes unless someone else agrees. Peter Flass (talk) 14:56, 28 May 2023 (UTC)