Using B6700 memory modules on the B5700 as fast disk?

[Nigel Williams]

I found the reference below to using B6700 memory modules as extended memory for the B5700. Can anyone provide further information about this mechanism? presumably it required a MCP extension to access this extended memory.

https://groups.google.com/forum/?hl=en#!original/comp.sys.unisys/zAherVBinlY/Qxh9Mh1qt2oJ

Path: gmdzi!ieee.org!dorm.rutgers.edu!rutgers!cs.utexas.edu!wupost!spool.mu.edu!agate!darkstar!cats.ucsc.edu!haynes
From: hay...@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.sys.unisys
Subject: Re: History of Burroughs/Unisys Machines
Message-ID: <25...@darkstar.ucsc.edu>
Date: 23 Dec 91 05:03:38 GMT
References: <0101009...@titipu.meta.com>
Sender: use...@darkstar.ucsc.edu
Organization: University of California, Santa Cruz
Lines: 20


I'm not very authoritative, but I believe all B-5000s were converted
to B-5500s early on.  I forget now what the difference was.

The B-5700 was basically the same machine - model number inflation
occurred as the B-6500 became the B-6700 and the 5500 became the 5700.
The 5500 was a superb batch machine and a lousy timesharing machine.
One reason it was lousy at timeshare was that swapping between disk and
memory was quite slow.  Hence there was a scheme developed to connect
B-6700 memory modules to a B-5500 as a virtual disk.  That and one other
change I can't remember was what was called the B-5700. 

I'll have to dig in my archives and find some literature references to
post.
-- 
hay...@cats.ucsc.edu
hay...@cats.bitnet

[Sid McHarg]

This was called AuxMem and required the MCP to be compiled with an option to support that feature. AuxMem was accessed through the ports used from drum devices, DRA and DRB.  As such it was limited to 32K words per device, and initially used as a high speed overlay device. 

I believe the MCP reference manual in printer backup format discusses a number of the changes made to better support AuxMem. 

In releases subsequent to the Mark XIII release a number of further enhancements were made to support placement of code and other resources in AuxMem. 

In a recent conversation with a colleague he mentioned some custom engineering work was done by Burroughs to enable direct execution of MCP code from AuxMem, thus freeing some of the 32K address space for other use. 

In the B5500 emulator I've built, an MCP compiled with AuxMem enabled doesn't have issues with an implementation supporting such a volatile store. 

The other change for the B5700 mentioned below was the DCP for data comm. 

-Sid (from iPad)

--
You received this message because you are subscribed to the Google Groups "retro-B5500" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-b5500...@googlegroups.com.
Visit this group at http://groups.google.com/group/retro-b5500.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-b5500/CACCFpdz5fj%2BTAV1XytNcpgdFmth4HUSYkbS7T5YK%2BR9bfa2gHw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Sid McHarg]

Here are some excerpts from SPO traffic on my emulator showing a DCMCP compiled with the AUXMEM option running with two 32K AUXMEM modules present.  The run-time options options are shown first, followed by some snapshots of responses to the CU and AU commands taken while compiling the COBOL Master Test program.  AU reports AUXMEM usage in addition to main memory usage.

You can see the AUXMEM usage is initially reported as zero, and the grows during the compile, and the returns to zero when the compile completes.

Options:

-H/L WITH MCP002A/DISK MARK XIII-002A MODS RRRRRRRR-

 TIME IS 1936

 DATE IS MONDAY, 1/ 6/14

#TR PLEASE

dt 1/11/14

 DATE IS SATURDAY, 1/11/14

tr 1022

 TIME IS 1022

#MTJ RET ONLINE TESTAPE

#LP BACK-UP ON MTD

au

 TOTAL AUX MEM USED: 0.

to

47 DRA SET

46 DRB SET

45 BOJ SET

44 EOJ SET

43 OPEN SET

42 TERMNATE SET

41 DATE NOT SET

40 TIME SET

39 ONEBREAK NOT SET

38 AUTOPRNT SET

37 CLEARWRS NOT SET

36 DISCONDC NOT SET

35 CMPLFILE NOT SET

34 CLOSE SET

33 ERRORMSG SET

32 RET SET

31 LIBMSG SET

30 SCHEDMSG SET

29 SECMSG SET

28 DSKTOG NOT SET

27 RELTOG NOT SET

26 PBDREL SET

25 CHECK NOT SET

24 DISKMSG SET

23 NOT USED SET

22 NOT USED NOT SET

21 PBDONLY SET

20 SAVEPBT NOT SET

19 RSMSG NOT SET

18 AUTOUNLD NOT SET

17 RNALL NOT SET

16 CODEOLAY SET

15 COREST NOT SET

14 DATAOLAY SET

13 NOT USED NOT SET

12 NOT USED SET

11 NOT USED NOT SET

10 NOT USED NOT SET

09 NOT USED NOT SET

08 YEARMM SET

07 OPTN NOT SET

wm

 MCP002A/DISK XIII-002A INCLUDES DATACOM,DCSPO,DFX,CHECKLINK,DEBUGGING

,AUXMEM

Compile:

 5:COBOL/MASTER= 3 BOJ 1024

 LDCNTRL/DISK= 1 EOJ 1024

 PBD0736 OUT LINE:COBOL/MASTER= 3

cu

0:MCP002A/DISK= 0:SAVE=5364 OLAY=4040

 0:PRNPBT/DISK= 2:SAVE=509 OLAY=4

 5:COBOL/MASTER= 3:SAVE=3516 OLAY=18937

TOTAL MEM IN USE= 32370

au

 0:PRNPBT/DISK= 2:DATA=0,CODE=0

 5:COBOL/MASTER= 3:DATA=10592,CODE=16720

 TOTAL AUX MEM USED: 27312.

au

 0:PRNPBT/DISK= 2:DATA=0,CODE=0

 5:COBOL/MASTER= 3:DATA=12800,CODE=21392

 TOTAL AUX MEM USED: 34192.

 0:PRNPBT/DISK= 1 BOJ 1024

# PBD 0736001 IN USE:PRNPBT/DISK= 1

 DECK#0388 REMOVED

 COBOL/MASTER= 3 EOJ 1024

au

 0:PRNPBT/DISK= 1:DATA=0,CODE=0

 0:PRNPBT/DISK= 2:DATA=0,CODE=0

 TOTAL AUX MEM USED: 0.

 PBD/0735001 REMOVED

 PRNPBT/DISK= 2 EOJ 1025

The YEARMM option is a local patch to cause dates with years prior to 60 to be treated as being in this century.  This at least permits the MCP to display the correct weekday.  The option parsing does not support option names containing numeric characters, so the more obvious Y2K name was not usable.

-SId McHarg

[Bob McKenzie]

The response by smcharg is correct.  It was simply a way to reduce the footprint of the MCP in the limited B5500 memory.  The odd thing is that it was advertised by Detroit as having a 200 nanosec cycle on a 52 bit word, while the B5500 had a 4 microsec cycle on a 48 bit word.   True the facts were correct, since the memory module was a B6500 memory module, the additional seep was lost as were the few extra bits. While the issue was missed by Detroit, the technical review caught it, causing some embarrassment for Burroughs.  The other part of the B5700 was the DCP which I discussed in my last post.