>Pete Turnbull wrote:
> On Jan 5, 16:34, Tom Leffingwell wrote:
> > On Sat, 5 Jan 2002, Pete Turnbull wrote:
>
> > I did find on the MSV11-L
> > that X was connected to U. I'm not sure what U is for, but seemed to be
> > grounded, so I removed it, which I assume set the address back to 0. At
> > that point it started working.
>
> Yes, U is the ground for V...Z (K is the ground for L...P). X-U (with all
> other bank pins disconnected) gives a start address of 00100000 (32K,
> decimal).
>
> > How do I know whether or not I need to enable or disable I/O page
> > setting? I haven't tried to enable it on the MSV11-L, although it was
> > enabled on the MSV11-D before I removed it. What symptoms occur if its
> > set wrong?
>
> If you have any devices in the lower 2KW of the I/O page, you should
> disable memory access to that area. If you don't, you'll get a conflict
> when both the I/O device and the memory try to respond to the same address.
> However, not many small QBus systems have I/O devices in that address
> range (160000-167777). It's normal to leave the whole I/O page for I/O
> devices, and disable memory in that area, though.
>
> > > And that's the second thing. The MSV11-L doesn't use BBS7 for
> everything
> > > it decodes, so you have to set it according to whether it's in a 22-bit
> > > system or an 18-bit system. If there's a jumper from R-T, it's set for
> a
> > > 2MW system. Remove it for 128KW systems.
> >
> > I did find out that I have the 22-bit KDF11-A, although I haven't checked
> > the backplane yet. If the backplane is 22-bit, should put the R-T jumper
> > in the M8059? Does it matter if I only have 128KW of memory?
>
> I don't know; try it and see :-) I suspect if you set it to 18-bit mode
> and use it in a 22-bit system, it will respond to multiple addresses. If
> you set it to 22-bit mode and use it in an 18-bit system with no
> termination on the upper 4 lines, it may respond to noise on those lines
> and not turn on when it should. The bus signals are active low, so if
> there's no signal they should float high and read as zeros -- but life and
> bus systems are not always so predictable.
>
> OTOH, if you have a 22-bit processor, it's easy to upgrade the backplane by
> soldering four pieces of wire-wrap wire to bus the extra 4 address bits
> (and upgrade the BDV11 if necessaary).
Jerome Fine adds the following:
(a) My experience with upgrading the backplane is VERY satisfactory. It
was done by someone with sufficient skills with a soldering iron. And yes,
wire-wrap wire was used. The specific model was the VT103 which was
a 4 * quad backplane, i.e. 4 quad boards or 8 dual boards. And terminating
resistors did not seem to be needed - perhaps because of so few boards.
(b) With regard to the use of the M8044 and M8045 memory boards, at
one time I did that mod as well - using only 4096 bytes for the IOPAGE
addresses (from 170000 to 177776). However, if I remember correctly
(perhaps Megan can help with this aspect), it ONLY worked with either
the RT11SJ or RT11FB monitors - i.e. UNMAPPED. As soon as I
use the 11/23 board WITH the MMU activated, the MMU hardware under
RT11XM forced the full 8192 bytes of the IOPAGE to be used - there
was no other option. In addition, with the 11/73, it was NOT possible to
use a 4096 Byte IOPAGE AT ALL
Comments on the use of the 4096 Byte IOPAGE vs an 8192 Byte IOPAGE:
If you have ONLY an 11/03 which can't run RT11XM or is running a
stand-alone application without any operating system, then using a 4096 Byte
IOPAGE does provide the user with an extra 4096 Bytes of program
address space. HOWEVER, these days if anyone has at least an 11/23
and is running at least RT-11, then using RT11XM with at least 128 KBytes
of memory does not seem to be a factor as far as cost is concerned. As
such, I have yet to see an application which runs under RT11SJ and conforms
to normal RT-11 rules which can't run under RT11XM, although I am
certain that someone could immediately find one for me. But in most cases,
the problems with an ISR (Interrupt Service Routine) is simply to place the
code into the address range 00000 to 17776 (PAR0 which allows up to
almost 8192 Bytes). So even if the program itself must have access to the
IOPAGE, it is still possible to use extended memory for the address range
020000 to 157776 (PAR1,2,3,4,5,6) which means that the program has
much more memory available than even under RT11SJ since now the locations
used by the Resident Monitor in RT11SJ are also available and more than
compensate for losing the address range from 160000 to 167776 for the
RT11SJ Resident Monitor when the 4096 Byte IOPAGE is used.
If memory mapping is OK, all 7 of the upper PAR ranges can be used
under different windows, as required. I have one program which makes
use of 152 KBytes of upper memory - 2 buffers of 48 KBytes each and
initial set-up and data retention of 56 KBytes - the IOPAGE is not used.
What is interesting is that I/O requests can be initiated in either of the
48 KByte buffers (.ReadC EMT Request) immediately after which the
window for the other 48 KByte buffer can be activated and the I/O
will automatically continue into the now unmapped 48 KByte buffer
while the program processes the 96 blocks in the other 48 KByte
buffer - using the code in PAR0 and PAR1 (00000 - 37776).
The very nice part is that this program initially requests ONLY 8192
Bytes of memory and then checks to see if it is running under RT11XM
or not. If the latter, a .SetTop is done and the rest of the program is
read into memory if there is sufficient available and it uses as much as
is available for the now very small buffers. Otherwise, if the former,
152 KBytes of memory are requested and 2 buffers of 48 Kbytes each
are then available plus 56 Kbytes of code and data to manage everything.
Now that is impossible with an 11/03 and even an 11/23 running the
RT11SJ monitor.
Received on Sun Jan 06 2002 - 10:26:15 GMT
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:34:52 BST