Well. Despite all recent VAX-11/750 bashing it actually booted both VMS 6.1
and Ultrix-32 4.0 today. Yes, the gate arrays can be a problem. But until
now I haven't found one that is faulty. The problem is usually bad contact
in the sockets which can be solved easily by removing them and clean the
chip and socket with isopropanol. A DPM (L0002) board that failed the
microverify at %C, passed straight away after that treatment.
The gate arrays themselves are ceramic chips which I think will keep up
many years if not abused. And since they are TTL and not MOS the likelihood
of damage due to static electricity is small.
BTW. The CPU of the 11/750 is contained on five extended HEX boards,
(L0002, L0003, L0004, L0008, L0011/L0016/L0022). Then there is the optional
RMD (L0006) module and possible MBA and extra unibus adapters.
I used a SCSI2SD card connected to a Emulex UC17 board.
A booting 750:
>>>B
%%
@@
Patch Control Store is Present
Done loading Patch bits and PCS
Ultrixboot - V4.0 Sat Mar 31 04:11:56 EST 1990
Loading (a)vmunix ...
Sizes:
text = 593304
data = 100864
bss = 320516
Starting at 0x2d4d
ULTRIX V4.0 (Rev. 161) System #1: Thu May 20 23:26:51 GMT+0100 1976
real mem = 8388608
avail mem = 5921792
using 204 buffers containing 838656 bytes of memory
VAX 11/750, hardware level = 0x8c, microcode level = 99
mcr0 (MS750) at address 0xf20000
uba0 at address 0xf30000
uda0 at uba0
uq0 at uda0 csr 172150 vec 774, ipl 15
ra1 at uq0 slave 1 (RA81)
ra0 at uq0 slave 0 (RA81)
WARNING: todr too small -- CHECK AND RESET THE DATE!
Sun Jun 20 23:35:50 GMT+0100 1976
Automatic reboot in progress...
/dev/ra0a: 596 files, 5592 used, 9959 free (143 frags, 1227 blocks, 0.9%
fragmentation)
/dev/rra0d: umounted cleanly
check quotas: done.
savecore: checking for dump...dump does not exist
local daemons: syslog sendmail.
Removing remnant Opser files
preserving editor files
clearing /tmp
standard daemons: update cron accounting network snmpd.
start errlog daemon - elcsd
Sun Jun 20 23:36:51 GMT+0100 1976
ULTRIX V4.0 (Rev. 161) (vax)
login: root
Password:
Last login: Sun Jun 20 23:35:25 on console
ULTRIX V4.0 (Rev. 161) System #1: Thu May 20 23:26:51 GMT+0100 1976
Digital Equipment Corporation
Nashua, New Hampshire
*** SOFTWARE INSTALLATION PROCEDURE COMPLETE ***
The following files were created during the installation procedure:
/vmunix - customized kernel
/genvmunix - generic kernel
/usr/adm/install.log - installation log file
/usr/adm/install.FS.log - file systems log file
/usr/adm/install.DEV.log - special device log file
2015-06-16 9:59 GMT+02:00 Mattis Lind <mattisl...@gmail.com>:
> In my efforts to understand the problem with the Cache/TB Diagnostics I
> tried to run it under 11/750 simulator in SimH. It fails too!
>
> ECKAL -- VAX 11/750 Cache/TB Diagnostic
> HALT instruction, PC: 00002608 (MTPR #F,#26)
>
> Although not the same location.
>
> On the real machine:
>
> @?ECKAL -- VAX 11/750 Cache/TB Diagnostic
>
> 00003488 06
>
>
> Trying to disassemble at 3488 in SimH gives me:
>
> EXTZV @-1D(R7),#0,#0,(R8)+
>
>
> The EXTZV is supposed be "Extract Zero-Extended Field"
>
>
> I have never done any VAX-11 assembly coding so this is very new ground
> for me... As far as I understand the diagnostic starts at address 200. But
> then understanding what it does without the listing... Well. A long journey
> for me.
>
>
> /Mattis
>
> 2015-06-15 22:07 GMT+02:00 Mark J. Blair <n...@nf6x.net>:
>
>>
>> > On Jun 15, 2015, at 11:59 , tony duell <a...@p850ug1.demon.co.uk> wrote:
>> >
>> >
>> >> I also may dump the console firmware PROMs at some point. I've already
>> done some preliminary
>> >> disassembly of the TU58 firmware.
>> >
>> > I am pretty sure I dumped all the PROMs and PALs in the CPU of my
>> 11/730 (but not the ones in the
>> > R80) long before there was a bitsavers. I can see if I can find the
>> dumps. What I don't have is the
>> > Remote Diagnostic ROMs (this was another pair of 2K*4 ROMs that plug
>> into sockets on the WCS
>> > board and which run on the 8085). So no dumps of that.
>>
>> I have three WCS cards, including the one in my machine, but none of them
>> have the remote diagnostic option.
>>
>> --
>> Mark J. Blair, NF6X <n...@nf6x.net>
>> http://www.nf6x.net/
>>
>>
>
