The curious case of the STORECI in the nighttime

[br...@quarterbyte.com]

The STORECI issue just got more interesting.

A few days ago I noted that slowing the disk speed down made the STORECI issue go away. But it appears that I was wrong about the reason: too-frequent disk interrupt activity was not starving the printer driver of CPU cycles. (I should have remembered that the disk has a lower interrupt priority interrupt. Only the card reader or very heavy memory cycle stealing could starve the printer driver of enough CPU cycles to do its job)

Recall that the 1132 printer driver sets up a bitmap in memory words 32-39, using one bit per print position, and the printer hardware uses cycle-stealing to read the bitmap when it's time to fire the hammers. A particular bit in that range has to be set to 1 to prove that the bitmap is correctly set up. If it's 0, the scan check occurs. (This is address 39, bit 15, the least significant bit).

I just found that are two instances where DUP uses this 8 word buffer as a scratchpad, on the assumption that no printing is going on. Normally, by the time DUP gets to this code, printing of the previous DUP control record would have completed. Running on SIMH, with disk activity occurring at lightning speed, the simulated 1132 is still printing, the "scan buffer complete" bit gets overwritten, and if it happens to be a 0, the printer hardware issues the printer check.

That's why the printed output line had unexpected repeated letters in it -- the bitmap contained unexpected bits. And why DMS could crash: the printer driver could zero the buffer while it contained code that was executing.

And that's why the 1403 doesn't have the problem, as it doesn't use this buffer.

I've made fixes to the 1132 printer emulation, and the scan check condition is correctly simulated now.

The crash with the fast disk speed is now considerably worse, because the correct emulation leads to worse problems. But, I''m no longer worried about recovery from the scan check -- that was not the problem.

The problem is the buffer re-use triggered by too-fast disk activity, so the notes the other day about setting

    deposit dsk stime 200

    deposit dsk rtime 200

still apply. I'm making those the defaults in future builds of ibm1130.exe.

The DMS code, by the way, if you're interested, is in jidexit. DUP uses the printer bitmap memory range to hold 8 words of code that it then executes, to get the flow of execution out of the way reading in the core load builder. LDX 2 32 puts the address of the bitmap memory into index 2, then pairs of words are copied in, followed by a jump to them. The code consists a call to the disk read routine, followed by a jump to the loaded core load builder.

                           569 | *                                                   J0905690

                           570 | *   MOVE READING PROGRAM TO LOW CORE                J0905700

                           571 | *                                                   J0905710

0235 6220                  572 |       LDX   2 32                                    J0905720

0236 C80D                  573 |       LDD     EX090                                 J0905730

0237 DA00                  574 |       STD   2 0         MOVE BSI INSTRUCTION        J0905740

0238 C80D                  575 |       LDD     EX090+2                               J0905750

0239 DA02                  576 |       STD   2 2         MOVE MDX INSTRUCTION        J0905760

023A C80D                  577 |       LDD     EX090+4                               J0905770

023B DA04                  578 |       STD   2 4         MOVE MDX INSTRUCTION        J0905780

023C C80D                  579 |       LDD     EX090+6                               J0905790

023D DA06                  580 |       STD   2 6         MOVE BSC INSTRUCTION        J0905800

                           581 | *                                                   J0905810

                           582 | *   GO TO LOW CORE TO READ IN CORE LOAD BUILDER     J0905820

                           583 | *                                                   J0905830

023E C803                  584 |       LDD     EX080     LOAD ACC AND EXTENSION      J0905840

023F 4C00 0020             585 |       BSC  L  32        BRANCH TO READ IN CLB       J0905850

                           586 | *                                                   J0905860

                           587 | *   PROGRAM TO READ IN CLB                          J0905870

                           588 | *                                                   J0905880

0242                       589 |       BSS  E  0                                     J0905890

0242 7000                  590 | EX080 DC      /7000     DISK READ FUNCTION          J0905900

0243 0000                  591 |       DC      *-*       ADDRESS OF WORD COUNT       J0905910

0244 4400 00F2             592 | EX090 BSI  L  DZ000     LINK TO READ IN CLB         J0905920

0246 7400 00EE             593 |       MDX  L  $DBSY,0   TEST BUSY SWITCH            J0905930

0248 70FD                  594 |       MDX     *-3       BRANCH IF STILL BUSY        J0905940

0249 4C00 0000             595 |       BSC  L  *-*       BRANCH TO ENTER CLB         J0905950

This pattern occurs twice in this module, but this is the one that we were running into.

Perhaps it would have been better to use some other memory range for this purpose, but 8 words are hard to come by, and the author would never have run into the overlap of activity and printing that we do, and the author could well have had a 1403 printer installed and would have missed it either way.

We can work around this by keeping the disk activity slow, but if any PTFs are to be written in 2016, this is a good candidate. I'm sure there are 8 words somewhere that could be used.

Brian

[John McKee]

Very nice explanation.  I never worked on an actual 1130 witha 1132 attached.  The 1132 was replaced by a 1403 just before I saw the machine.

You may have said it and I missed it or misunderstood. but how did a genuine 1130, configured with an 1132, avoid the issue?  Did early users just shrug their shoulders?  Obvious same DUP condition still existed.

John McKee

--
You received this message because you are subscribed to the Google Groups "IBM1130" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibm1130+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[br...@quarterbyte.com]

On a real 1130, disk activity was much slower. The card sequence is

// DUP

*STORECI    WS  UA  HELLW

DUP starts echoing echoing the STORECI card to the system printer, then does a bunch of disk activity before getting to the point where it tries to load the core image builder via that call sequence that's put in the printer buffer. 

On a real 1130, the disk activity was slow enough that the printer finishes before the disk activity, so, the printer buffer is no longer in use when it gets reused.

Slowing the disk activity down circumvents the problem.

On a modern hardware implementation (eg. FPGA), I don't know what happens...

[Carl Claunch]

Hi John

It does not fail on a real 1130 nor do spurious characters show up in the print line. 

I did a run with a STORECI this morning with my 1130 system and had no problem or scan checks. 

Carl

[eddy]

We used an 1132 for a long time. We probably didn't see this problem due to it's slow speed. With version 1 IBM did have a race condition with the card reader interrupt. If I remember correctly it was because some drivers used a WAIT thinking that the card was finished if it bounced off of the WAIT. Also there is a race that happens if you press STOP on any device between the time the driver tests for READY and the time of the XIO. The proper method is to do the XIO then check to see if it went busy. That was fixed on the 1800.

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone

[John Doty]

On Aug 1, 2016, at 2:51 AM, br...@quarterbyte.com wrote:

Perhaps it would have been better to use some other memory range for this purpose, but 8 words are hard to come by, and the author would never have run into the overlap of activity and printing that we do, and the author could well have had a 1403 printer installed and would have missed it either way.

We can work around this by keeping the disk activity slow, but if any PTFs are to be written in 2016, this is a good candidate. I'm sure there are 8 wordssomewhere that could be used.

Just doing a busy wait on $PBSY before using the buffer should fix the problem.

John Doty              Noqsi Aerospace, Ltd.

http://www.noqsi.com/

j...@noqsi.com

[Brian Knittel]

That was my conclusion too. Instead of trying to relocate the buffer (hide the problem), add a wait loop (fix the problem).

[Eddy Quicksall]

I think the problem you are having is not a race condition as it does not happen with my emulator. I think the problem is that you are giving the op/cop too soon. I have not looked at the spec yet and that may tell when the op/cop should be given.

 

Eddy

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of br...@quarterbyte.com
Sent: Monday, August 01, 2016 2:52 AM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] The curious case of the STORECI in the nighttime

 

On a real 1130, disk activity was much slower. The card sequence is

Virus-free. www.avast.com

[Eddy Quicksall]

Does anyone know where I can find the 1132 functional characteristics manual?

 

Eddy

[John McKee]

Does this help?

http://www.bitsavers.org/pdf/ibm/1130/functional_characteristics/GA26-5881-6_1130_Functional_Characteristics_Apr72.pdf

John McKee

[Eddy Quicksall]

Yes, thanks.

 

Eddy

[Eddy Quicksall]

Do you know where I can find the source to IBM’s 1132 driver?

[Eddy Quicksall]

Never mind. I found an 1132 driver here: https://www.cosecans.ch/cosecans/IBM1130OSPrograms/T5PRNTZ.txt

[Eddy Quicksall]

No, it’s been over 50 years since I wrote the fast 1132 driver and now I don’t see an op/cop associated with the 1132. Sorry for the mix up.

 

Eddy

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of Eddy Quicksall

Sent: Wednesday, November 21, 2018 2:14 PM
To: ibm...@googlegroups.com

[John Pierce]

the 1132 driver is a pretty nasty little piece of work.

it gets a high priority interrupt for each character on the drum, and has a limited number of milliseconds to fill a buffer at a fixed location in low core with a 1 bit for each hammer, then set a print-ready bit...    if it doesn't get that bit set in time, the printer stops with a fault light, otherwise, the hammers that have a 1 bit all fire, and you get another interrupt to setup for the next EBCDIC character on the print wheel (IIRC, it only had 48 characters).   once you've printed all the characters of the line, the driver fires the carriage advance and starts over.

PRNTZ was the default driver, and kind of slow, IIRC, there was a faster driver PRNT1 or something that did better overlapping of hammering and advancing to get more Line/sec throughput, but this faster driver wasn't resident.

-john r pierce

  recycling used bits in santa cruz

[Eddy Quicksall]

I wrote a PRNT1 around ’67 or ’68. I can’t remember very well but as I remember I read the character wheel to see which character would be printed next. Then I started with that character. I think IBM always started with a fixed character which made it slow and a fixed speed. Mine would print at a variable speed. The best case was fairly “fast” and the worst case was the IBM speed.

 

When we wrote TSO in the 70’s we didn’t support the 1132 because our drivers were in what we called AUX CORE which was an additional 32K where our kernel ran. The drivers being in AUX CORE allowed us to switch users while the cycle steeling was taking place.

 

Eddy

[John Pierce]

yeah, I don't think any of the 1130 'clones' that TSO ran on supported the 1132, I know CHI didn't support it on their 2130...

[Eddy Quicksall]

Come to think of it we supported two 1403’s and the 1132 drivers went to the 2^nd 1403.

[Eddy Quicksall]

Hi John. I assume you worked for CHI. Did you know John Currie? I think he worked for CHI before he worked for DNA.

[John Pierce]

that name certainly rings a bell, but I was only there like 6 months in 1975, long long ago and far far away

[Eddy Quicksall]

Did you use TSO?

[John Pierce]

yeah, thats what we ran at CHI on the development system, and also what most of CHI's customers ran in the mid 70s.

[Eddy Quicksall]

I have an emulator that has TSO on it. You can run two remote terminals plus the console. If you want to play with it you can get it here: https://www.dropbox.com/sh/44x0fxfhuwnn3pv/AADVRXVr3HchbYlBOLtfZIBVa?dl=0

 

But it requires some form of MSDOS. I run it under Windows by running vmware and installing XP. It will support 4 users but I have never been able to get vmware to support the other two serial lines.