• Please review our updated Terms and Rules here

VAX Haul...

When I get my cable and smoke test the monitor :)-)) I will check.

Thanks.

I will look in the manual and see if I can decode how you got that. I may need a bit of help if I can't...

Dave
 
The BNC to VGA adapter arrived earlier and I tried it on my Vaxstation 4000 90 with the only monitor I have to hand at the moment, a modern LCD. The LCD monitor comes out of sleep when I power the Vaxstation on and after POST completes on the Vaxstation I see no errors on the VT520 connected to the serial port and a show error displays no errors. The LCD only displays a grey screen. I guess this monitor doesn't sync on green, I'll have to dig out my old CRT monitor that I know does sync on green.
 
Last edited:
Tried it with a different LCD monitor, success I get the POST screen on the LCD but I now have an error displayed,

?? 003 DZ 0112

>>> show error

?? 003 DZ 0070
003 000A 00000071 00008120 00000000 etc

>>> TEST /UTIL LCSPX appears to work, all subtest in menu pass and display correctly on the LCD screen.

I'll investigate further tomorrow.
 
Last edited:
So, it is smart enough to spot that there is no monitor connected. That is the first time I have come across that in a machine!

I managed to erase the last two SCSI disks tonight (both 0.5 GB - RZ25). One erased OK, but the second failed. I suppose one bad disk in the collection isn’t too bad is it?

I will be in touch with people presently (probably the weekend) to arrange delivery.

I can then try and install my CDROM and see (a) if it works and (b) whether I can install VMS...

Dave
 
I suspect it also reads back and verify that all blocks are good. And I think formatting takes more time than just simple reads or writes.

A SCSI drive does a full low level format of the media, and that obviously takes time proportional to the capacity. It will map out bad blocks so that you will see the full advertised capacity, unless of course there were too many errors.
 
The ?? 003 DZ 0112 is the serial port. DZ left over from PDP-11 days? So my assumption is that with a keyboard and monitor connected this error is OK because if I move switch 5 back and re-connect a terminal to the port I do not receive the error. Next task will be to get DECwindows Motif running. I have OpenVMS 7.3 installed. I'll open a new thread for that in the near future.
 
If I am reading/understanding the error section of the manual correctly, your DZ 003 error is a missing mouse. DZ 002 is a missing keyboard.

Yes, HEX code 0070 (hex) is a mouse error.

Dave
 
Brilliant. thanks Dave. Never even thought of that. There is obviously a lot of intelligence in these machines detecting hardware is connected like, mouse, keyboard and monitor. I think I've got a good working machine anyway with no issues. I'm back on a serial connected terminal for now and I've run all of the test available without error, including NVR. I have a mouse that I can use but I'd like a DEC one:wink:
 
>>> but I'd like a DEC one.

Same here (or the digitising tablet - probably even rarer)...

I'll keep an eye out. Whilst chatting to another colleague about something totally unrelated yesterday - I got wind of another secret hoard of VAX machines. I will enquire...

I don't think any of our applications used a mouse interface - but I just wonder if they were connected to prevent the errors and tucked away...

Dave
 
Tried it with a different LCD monitor, success I get the POST screen on the LCD but I now have an error displayed,

?? 003 DZ 0112

>>> show error

?? 003 DZ 0070
003 000A 00000071 00008120 00000000 etc

>>> TEST /UTIL LCSPX appears to work, all subtest in menu pass and display correctly on the LCD screen.

I'll investigate further tomorrow.

As others said - mouse test failure. More specifically transfer timeout.
So I would guess that just means there was no mouse that responded to some data sent out.

And yes, DZ is (I would assume) a spillover from the Unibus days, when you had a serial port controller named DZ11, and on the Qbus the DZV11. Rather stupid controllers, with four or eight lines. Probably very matching in their capabilities to the serial ports on the VAX here.
 
I smoke tested the terminals I had acquired - a bit disappointing :-(...

I have one VT220 (white) and one VT420 (green) that are OK.

The other VT220 appears to have a power-supply related issue (the on/off lamp flashes as though there is either a short circuit somewhere or the PSU can't supply the normal current required).

One other VT420 has a very dim screen (yes, I did turn the brightness up) and the other VT420 screen appears to be completely dead. I do hear a 'beep' - so the PSU and logic should be OK.

Got my VAX station 4000/96 finally set up (after erasing all of the SCSI disks for everyone). 80MB RAM, A 1GB RZ26 disk and a CDROM drive. The next task is to install OpenVMS (assuming the CDROM works of course)...

I also need to smoke test the VRT19 monitor before connecting it to the VAX (thanks G4UGM for the cable - it arrived OK).

I also need to find a mouse or a digitiser tablet. I have sent an email to a guy that has a digitiser tablet for sale - but not received any response yet. I didn't realise that the mouse connector was not PS/2 compatible. Why would I think otherwise :)?!

Dave
 
Last edited:
This period of mice and keyboard interfaces during the VAXstation years were all about the proprietary interfaces! Keyboard is unique, as is the mouse! :p

One of the nicer "advances" we made over the years of computing, standardized interfaces!
 
I was hoping to use an old PS/2 mouse on my Vaxstation but as you say looking at the mouse port it is not PS/2 but uses 7 pins. There are a couple of VSXXX-AA on ebay but they are very expensive. The pinout of the port is attached.

processed.jpeg
 
I was hoping to use an old PS/2 mouse on my Vaxstation but as you say looking at the mouse port it is not PS/2 but uses 7 pins. There are a couple of VSXXX-AA on ebay but they are very expensive. The pinout of the port is attached.

View attachment 64098

If we had the protocol we could use a PIC chip or Arduino. Isn't the Keyboard a "standard" DEC keyboard.
 
Yup, they're all "standard" DEC keyboards.

I have one of the VSXXX mice, would you all like a picture of the internals if it would help?
 
I have a spare VSXXX mouse I'd be happy to loan to anybody interested in reverse-engineering the protocol with an eye toward making an adapter.
 
I have one myself, and I believe its a serial mouse. I wonder if the SIMH VAX emulators already do some translation

This looks like the info we need...

https://lists.debian.org/debian-mips/2001/07/msg00029.html

/* Mouse protocol is as follows:
* 4800 bits per second, 8 data bits, 1 stop bit, odd parity
+ * 3 data bytes per data packet:
* 7 6 5 4 3 2 1 0
* First Byte: 1 0 0 SignX SignY LMB MMB RMB
* Second Byte 0 DX DX DX DX DX DX DX
@@ -1304,8 +1306,29 @@ static int M_vsxxx_aa(Gpm_Event *state,
* DX and DY: 7-bit-absolute values for delta-X and delta-Y, sign extensions
* are in SignX resp. SignY.
*
- * Initialization is done by sending an "R" to the mouse; before receiving
- * this character, the mouse does not produce a bytestream
+ * There are a few commands the mouse accepts:
+ * "D" selects the prompt mode,
+ * "P" requests the mouse's position (also selects the prompt mode),
+ * "R" selects the incremental stream mode,
+ * "T" performs a self test and identification (power-up-like),
+ * "Z" performs undocumented test functions (a byte follows).
+ * Parity as well as bit #7 of commands are ignored by the mouse.
+ *
+ * 4 data bytes per self test packet (useful for hot-plug):
+ * 7 6 5 4 3 2 1 0
+ * First Byte: 1 0 1 0 R3 R2 R1 R0
+ * Second Byte 0 M2 M1 M0 0 0 1 0
+ * Third Byte 0 E6 E5 E4 E3 E2 E1 E0
+ * Fourth Byte 0 0 0 0 0 LMB MMB RMB
+ *
+ * R3-R0: revision,
+ * M2-M0: manufacturer location code,
+ * E6-E0: error code:
+ * 0x00-0x1f: no error (fourth byte is button state),
+ * 0x3d: button error (fourth byte specifies which),
+ * else: other error.
+ *
+ * The mouse powers up in the prompt mode but we use the stream mode.
 
Back
Top