Pete Turnbull wrote:
>
> OK. From what you've written there, and a few other places, I assume you
> have some manuals and/or printsets?
Most of them, but from the MK11 memory box, only the MOS board and both
controller boards.
> > > That's an unusual address, and it's only 32K bytes (16KW). You said
> you
> > > had two 64KW boards. What type are they? They probably have switches
> Are they M8728-AA or M8728-CA? The latter is only 16KW. The easy way to
> tell the difference, if there's no -A or -C beside the number, is that
One is a '-AA' version, the other is a '-AC' one, and both are fully
populated.
> I was, no surprise to anyone, wrong about their having switches --
> showing
> my ignorance about the specifics of 11/70's. Most of the things I've
> written are gleaned from the meagre information in one or two of the
> processor handbooks, or from my (incomplete) collection of microfiche.
Well, nobody is perfect :=)
>
> Anyway, the memory box has switches on the front (and I assume you've
> checked those?) but as far as I can see from the 'fiche, the memory card
> base addresses depend only on their position in the box. So the two cards
> have to be adjacent, and nearest the other cards, I think. Do you agree?
There are no switches at the front of the box, unless you mean the
control panel
which contains the thumbwheel switches and a few other switches?
Do you have documentation on the data buffer board? This one does have 2
switchbanks,
and all are currently 'open'. Those 2 boards are the only one for which
I do not
have any docs.
>
> It looks as though the box might be set to the wrong address -- 400000
> is
> 131072 decimal, or 128K -- and is only showing 16KW (32KB) of memory. I
> don't know how you set the address of the box, though.
I changed the size register on the 8143 to 32K, and it 'disappeared'
completely
from the system, i.e. no memory address was usable. I then changed 2
switches
(W12 & W15 seem to be wrong marked in one of the FE sheets) and is was
visible
again, and it still was set at 400000...
> > It is the 23-233F1 diag rom.
>
> OK, I've found some data (actually the listing) for that ROM. It's
> assembled at 165000 (but it looks like position-independant code, so
> that's
> possibly not its real address). It ends at 165776, ie 1000 bytes (octal)
> later. It is indeed an 11/70 diagnostic ROM for the M9312, probably just
> a
> later version than the 23-616F1 my other docs refer to.
>
> The docs say there's no way to enter the diagnostics directly, only by
> entering a bootstrap at the "run with diagnostics" address. They suggest
> that would be 173006/173206/173406/173606 depending on whether you're
> booting from a bootstrap ROM in socket 1, 2, 3 or 4.
>
> The docs also say that when the 11/70 powers up (or you press a boot switch
> attached to TP1 and TP2 on the M9312), it loads the PC from address 773024,
> and PSW from 773026. And indeed every boot ROM has a reserved word at that
> address for the PC, followed by 000340, which is the usual interrupt mask
> to set in the PSW for booting. Every ROM has code (opcode SEC) starting at
> 173x04 leading to a BCC BDIAG at 173020. In every boot ROM, that branch
> goes to an absolute jump, JMP _at_#DIAG, which in turn leads to a
> PC-relative
> jump at absolute address 165564, which goes to 165000 (the actual code is
> 165564 000167 177210 DIAG: JMP START).
>
> Why do you think address 777644 is the diagnostics ROM start address?
That was a mistake, I did mean 765744, which is spoken about in the
documentation.
> All the 11/70 tests halt on error (unlike the CPU diagnostics for the
> 11/34
> and other processors, which loop on error). The first section tests
> assorted instructions that needn't to use memory, the secondary CPU
> tests
> use the stack (R6 set to 000776). However, the very first instructions
> in
> the diagnostics code store registers at 000700...000704, and use 000706
> to
> hold a flag which tells the code whether it's running on an 11/60 or an
> 11/70. If the memory isn't working, this will cause problems later in
> the
> diagnostics.
>
> Address 165344 is one of the error halts partway through the secondary
> CPU
> tests (assuming the diag ROM starts at 165000). What it does is set
> SP=776, then does a PC-relative JSR to the address 2 ahead of where it
> is.
> The code there checks to see if the top of the stack contains the
> correct
> return address, and should halt at 165326 if it doesn't (it should halt
> at
> 165320 if the JSR didn't execute). If it does see the correect return
> address, it adjusts the stack contents, does an RTS, ending up at
> 165342.
> At 165342, it pushes a zero and an address on the stack and then tests
> RTI. 165344 is the address of the push instruction, and 165350 is the
> RTI.
> That's folowed by a jump to the next test, which is the memory-sizing
> routine.
>
> So having it loop until you stop it, and then halt at some address
> ending
> in 344 doesn't make much sense to me. Either you're not starting at a
> sensible address, or there's something wrong that is sending it into a
> loop. That could be a CPU fault, or maybe (I've not read all the cache
> test code) something to do with not having memory between 000700 and
> 001000.
That sounds more logical to me, but I can only substantiate that when I
have
the memory being available at address 000000.
As a tryout, I'll swap all the other boards in the cpu (I have a
complete spare CPU)
to see if this has some effect as well. I didn't do this before, as the
machine was
in operation until about a year ago, so it is likely to assume that this
could have
worked. I do not know if the MK11 is the original one, or is from
another 11/70.
I'll let you know tomorrow.
Ed
--
The Wanderer | Politici zijn gore oplichters.
quapla_at_xs4all.nl | Europarlementariers: zakkenvullers
http://www.xs4all.nl/~quapla | en neuspeuteraars.
Unix Lives! M$ Windows is rommel! | Kilometerheffing : De overheid
'97 TL1000S | weet waar je bent geweest!
Received on Tue Jan 08 2002 - 03:44:06 GMT