DUP STORECI

[br...@quarterbyte.com]

The DUP STORECI problem is due to two things:

• Primary: the simulator's default settings make the disk way too fast. In (just) the circumstances that occur during a DUP STORECI operation, there is overlapped printing and heavy disk activity, so frequent disk driver interrupts prevent the printer interrupt handler from finishing its job of constructing the next line bitmap, and a printer scan check occurs.
   
• Secondary: There are major errors in the way the printer emulation implements the scan check bit, so the DMS printer driver's automatic scan check recovery is failing in various spectacular ways.
  
  

This explains why the problem didn't occur when using an 1442 printer -- the 1442 requires almost no CPU effort.

I will go ahead and work on the scan check issue, since it should work, but the more important fix is slowing the disk down so that it doesn't starve the printer. (Perhaps at some point it might be possible to make the disk timing adapt automatically to printer activity; but, that's not "real")

IF you are using an 1132 printer in your simh setup, add the following two lines to your SIMH startup script:

dep dsk stime 200

dep dsk rtime 200

(that is, let the CPU execute 200 instructions between a read or cylinder advance command and its completion interrupt).

This gives the printer enough CPU time to get its job done. DUP STORECI works.

You can also make these settings the default by changing ibm1130_dsk.c from

int32 dsk_swait = 50;

int32 dsk_rwait = 50;

to

int32 dsk_swait = 200;

int32 dsk_rwait = 200;

and recompiling.

I have been working on the scan check bit issue. It's getting closer, but DMS still fails to recover, I have a nice CPU trace so it should be fixable.

Brian

[John McKee]

Really nice explanation of the STORECI issue.  Nice to know that this wasn't an issue with the real 1130.

BTW, printer is 1403 <g>.  I am pretty sure you knew that.

--
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.

[Bob Flanders]

Very cool. Thanks Brian!

Bob

[Eddy Quicksall]

When do you give the interrupt and clear BUSY on the emulated 1132?

 

It’s been 48 years since I worked on PRNT1 but that was in the print scan code not in the ISR. But I can say something with certainty … when tested it I did not wait some fixed time before I issued the next LIBF to print the next line. I can only make an educated guess at this time but I suspect the interrupt and clear of BUSY did not occur until after the cycle steal was finished.

 

I found this in some old code. Does DUP or something else have it (but DUP would not use a LIBF)?

 

                          LIBF    PRNT1     *

                          DC      /0000     TEST PRINTER BUSY

                          MDX     *-3       *

 

 

My emulation does not actually emulate the 1132 … I just use PRNT1 as a 2^nd printer and both go to a separate 1403’s. I’ll see if an old colleague remembers but we are all getting kind-a old. J

 

Eddy

[Carl Claunch]

On my fpga based emulation, I model each physical process of the device and make it as close to real life timing as possible.

Thus, for the 1132, a process advances the print wheel whenever the device is on. That process is what triggers the interrupts when a new character has rotated into position on the emulated print wheels. 

Cycle stealing fetches the print scan field, the least timing accurate part of the emulation.

The main print cycle waits the appropriate time then sets conditions that result in the interrupts.

Busy as a condition in the DSW is on once the XIO executes and is reset at the time the real device would.

I have found that some diagnostics are quite picky about the ordering and timing of conditions - for example the 1403 can interrupt when it has fetched the print buffer, but remain busy until a later point where it interrupts for print completion. If an XIO Control or XIO Write was issued after the XIO IW began but before it ended, the space or skip is 'stacked up' by the control unit and will begin after print ends, leaving the printer busy after print complete interrupt, up until the carriage movement complete interrupt. 

In the real world, these conditions can all stack up if the interrupt handler hasn't responded yet to the earlier ones, but the diagnostic and some hand code is written to pick these out individually. 

Carl 

[John Doty]

On Aug 4, 2016, at 9:43 AM, Carl Claunch <carlcl...@gmail.com> wrote:

 If an XIO Control or XIO Write was issued after the XIO IW began but before it ended, the space or skip is 'stacked up' by the control unit and will begin after print ends, leaving the printer busy after print complete interrupt, up until the carriage movement complete interrupt. 

Yes. In FORGO we managed to squeeze a little more speed out of the 1403 by figuring out exactly what we could stack up without confusing the machinery.

John Doty              Noqsi Aerospace, Ltd.

http://www.noqsi.com/

j...@noqsi.com

[Eddy Quicksall]

Please send us the functional characters of the 1132, especially the bit map of the DSW.

 

Eddy

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of Carl Claunch
Sent: Thursday, August 04, 2016 9:44 AM
To: IBM1130
Subject: Re: [IBM1130] DUP STORECI

 

On my fpga based emulation, I model each physical process of the device and make it as close to real life timing as possible.

--

[Carl Claunch]

http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/1130/fe/227-3670-0_1130_Computing_System_Features_FETOM.pdf 

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

http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/1130/fe/1131-B/1131-B_004_ALD_XP-ZW.pdf (XP pages describe 1132 adapter logic)

Carl