jnc at mercury.lcs.mit.edu
Sat Dec 9 21:31:06 CST 2017
> From: Henk Gooijen
> the M7859 is sort of a UNIBUS device. The (front panel) console only
> communicates with the M7859.
Not quite; it does _mostly_ 'do its thing' over the UNIBUS, but there are
also two special lines carried across the DD11-P backplane to the CPU, 'Halt
Request' and 'Halt Grant' (which is why it has to be in the same backplane as
the CPU); more here:
> I cannot remember whether a demux for the displays is on the console
> PCB, or on the M7859.
I'm not sure exactly what you mean by 'demux', but... the interface between
the board and console is i) 3 bits of digit, and ii) 6 individual select
lines. Code in the micro on the M7859 sends one digit at a time down the 3
'digit' lines, along with the appropriate 'select' line.
> If you get 000000 on the dsipaly and when halted it shows 173066 I
> presume it is looping.
Well, I haven't looked at the M9312 ROM code, but if it's anything like the
M9301 code (which I have dumped and disassembled), looping in the ROM at
173066 is not necessarily bad.
There is a listing of some of the ROM code on BitSavers:
but it doesn't seem to cover the stuff at 173000 (which is where the CPU
starts running on power-on) - or maybe I just didn't study the listings
> If it loops, it will repeatedly read from a device address which is
> most likely the CSR of the boot device.
Depends on the switch settings on the M9312. If it's set to boot, if the
device is there, yes; otherwise it would get a NXM fault. If it's set to go
into the console mode, it's probably trying to read characters (commands)
from the console.
More information about the cctalk