• Please review our updated Terms and Rules here

UC17 question

tradde said:
Thanks for the info. I have an M7856 that I used long ago to boot an image to an 11/34 that I no longer have using
TU58. I may have to try that if I don't figure something out soon.
Click to expand...

You can also use PDP11GUI to download the .BIC (basically a .BIN file but 'chainable' in XXDP parlance) directly thru its download a binary image function.
I haven't tried this personally but it should work.

Don
 
tradde said:
I believe the terminal is set to 38400. It reports the 11/84 start up info properly. I have never
changed anything on this terminal nor the 11/84 port. Not sure why it would not work for the
FRD. I'll try the tape version just as an additional check. I am not too worried about the NOVRAM
being reset. I know how to set it back up once I get into FRD. I'll try the Ctrl-Q just to see what
happens. It's just weird this used to work as this system is now configured. Nothing was changed
since I used it several years ago. The only thing I would do is from time to time I'd power it on
to make sure it would pass the bootup tests and end up at "4" on the front display.
Click to expand...

We like to think that the electronics we have will work fine in xx years from now, but that's not going to be the reality. I have some old video cameras that won't turn on. One of my M8192's won't boot reliably, while the other spews garbage out the console port after about 10 secs.

Why? Electrolytic capacitors do not last forever as you see in these pages. EPROMS, Flash Memory and SSD's will eventually leak their electrical charges. Anything mechanical will wear, rot or decompose. Even crystals on clocks drift as they age or are stressed. There are many things we could speculate on. The voltages on the computer may be at the right level, but there might be more noise due to capacitor aging. Some of the semiconductors weren't sealed properly and moisture works it way in. Perhaps there is a ground loop that is interfering with the serial communication.

The UC17/UC07 has a pretty thorough set of self tests, including checks for firmware and many components. It is hard to understand why you cannot get it to run FRD based on the work you've done so far. You can only test, either in isolation or collectively. Check things, even if you think it will work, until you find some lead or unexpected result that lets you home in on the cause. The earlier DEC machines have test software and prints that allow you to diagnose to a pretty low functional or component level. By the time the 11/84 arrived, it was all board swaps and return to depot for repair. Don's programs are trying to move the needle back the other way. I can't tell you the number of times I trusted some component, power or board because I "assumed" or "it appeared" to worked okay, only to find the "trusted" part was the bad-guy.

Note: The reason I suggested shifting to a lower speed on the serial ports is because the FRD code it downloads does not use interrupts. Its all programmed I/O and in my experience the console ports on DEC CPU's are not reliable at their max speeds.

Jerry
 
I don't have an easy way to run PDP11GUI at this time. My main Windows machine is in one room, and the computers are
all in another. If it comes to using it I will work something out. Tried removing the network card in slot 5 which is
where the UC17 used to live. Put in a NPG card since the slot is now blank. No change. Set SW4-5 to zero for TMSCP.
Got the first line of the banner displaying "**** **** Emulex" and that was all. Very weird. Set SW4-5 back to 1 and
back to the same status as before. I guess it's possible that some instruction is flaking out. Hard to tell. But I don't
believe that as everything else works. I can boot BSD and run no problems. So I continue to research what else to
check.
 
I was wrong when I stated it was set to 38400. It is actually at 9600. Yeah, I know it could be many things.
I am usually good at tracing down problems. Must be why I went into computers and programming. I'll
figure this out and it will be something simple or something stupid I did not do or did not notice. :)
 
tradde said:
I was wrong when I stated it was set to 38400. It is actually at 9600. Yeah, I know it could be many things.
I am usually good at tracing down problems. Must be why I went into computers and programming. I'll
figure this out and it will be something simple or something stupid I did not do or did not notice. :)
Click to expand...

The fact that you got some of the "**** **** Emulex" message from the TMSCP FRD is promising. Slowly you are closing in.

If the context of changing something "Trusted" from my earlier note...

1) Change the baud rate anyway. Yes.. 9600 is not that fast for a console port, but you have anomalous behavior in this interface.

2) Try another terminal (or terminal emulator).

3) Make sure the power for the terminal and computer are from the same power phase.


Even if BSD boots normally, the conditions here are not the same. Interrupt IO may be a tad bit slower than PIO for example.
 
Progress made. I wasn't sure how to change the baud rate of the current VT320. So I grabbed
my newly acquired VT102 and saw it was already at 9600. Emulex screen comes up fine on it.
I am not sure what this means except I can get back into the FRD. Now if I can just solve
RSTS not booting I will be more happy. It could be how I have the settings. I'll have to look.
Dumped the NOVRAM settings and it is configured for an RA92. I no longer have that drive
but I set up my SD in the SCSI2SD to look like an RA92.
 
Glad to see that you have access to FRD again.


I'll defer to others on RSTS. i don't have much configuration experience on this OS.

Jerry
 
My question is why did it work on the VT102? I know it used to work on the VT320.
As to RSTS I have very little knowledge of it too. Never really used it. I am more
of a Unix/Linux person. That's why I first set up to boot BSD. But always wanted to
try RSTS so I sysgen'd one via Simh and then moved it to the SCSI2SD. And it worked.
I always will be a pdp-8 person first though, then pdp-11, and of course pdp-10.
 
wa2flq said:
I'll defer to others on RSTS. i don't have much configuration experience on this OS.
Click to expand...
Where did the RSTS image on the SCSI2SD come from? Does that image boot under simh? Also, what RSTS version are we talking about?

Edit: I see you answered the first 2 of my questions a minute before I posted. What RSTS version is it?

Almost all of my simh experiences is on the PiDP11, but at least there the boot process is quite different from "real" -11 hardware. On a real -11, the M9312 (or equivalent) boot ROM(s) load a bootblock from the device and branch to it. Under simh it seems like that is replaced with "... and then some magic happens". This may be a red herring, though.

My guess is that there is something "funny" about how the controller is seeing the SCSI2SD and mapping it onto some corresponding DEC drive model.

I have a vague recollection (this is 35+ years ago) that the one of the first things the RSTS/E bootloader does is send a linefeed to the console terminal (which is harder to notice on CRTs than on hardcopy terminals). If you didn't get the linefeed, either the bootloader was not read correctly or there is something very wrong with the system. We can probably discount the latter as you can boot other operating systems.

Speaking of booting other operating systems - it might be informative to look at the first few blocks of your RSTS disk with "od" under BSD (or similar) to make sure that the "disk" is readable and it looks like there might be an operating system on there.
 
Last edited:
AK6DN said:
My 11/34 on the other hand is very finnicky. Sometimes it starts up, other times it hangs. I have cleaned fingers and backplane connections using Deoxit Gold numerous times. Changed CPU backplane and CPU boards. Always the same behavior. I'm beginning to think the BA11K box itself is haunted. With enough fiddling it will come alive again and run for the rest of the day.

NPR/BR connectivity is sometimes an issue, where the system will run fine until the first DMA device kicks in.
Click to expand...
The wire tension on the Gardner-Denver automated machinery that wired the backplanes was not always controlled to an acceptable level, creating backplanes that "rotted" over time as the (supposedly) gas-tight seal between the wire and the socket pins degraded and oxidized. Back in the day, you used to be able to DECmailer any revision backplane and get a new-revision one back, but they caught on after a while and started restricting acceptable revisions to only ones that were wrapped after DEC improved their processes*.

* Looking back, we tend to forget how primitive some of that stuff was. DEC didn't start using anti-static packaging until rather late in the PDP-11's history - I received an RK611 (RK07 controller) purchased directly from DEC for an 11/44 and the individual cards still came in raw cardboard boxes with no ESD protection.
 
tradde said:
My question is why did it work on the VT102? I know it used to work on the VT320.
As to RSTS I have very little knowledge of it too. Never really used it. I am more
of a Unix/Linux person. That's why I first set up to boot BSD. But always wanted to
try RSTS so I sysgen'd one via Simh and then moved it to the SCSI2SD. And it worked.
I always will be a pdp-8 person first though, then pdp-11, and of course pdp-10.
Click to expand...


There is a marginal condition on the serial interface. It could be the VT320, the 11/84 serial port or the cable. Bad or incorrect grounding, weak charge-pump on the +-15v supplies for the transmitter or other component failure. Some equipment is more tolerant of out specification conditions than others.

A VOM or LED serial board breakout tester should help investigate the first two. If you don't have strong background in analog and/or digital electronics here is some background material.

https://www.lammertbies.nl/comm/info/RS-232_specs.html
https://www.lammertbies.nl/comm/cable/dec-mmj.html
https://arcelect.com/rs232.htm

Jerry
 
Terry Kennedy said:
Where did the RSTS image on the SCSI2SD come from? Does that image boot under simh? Also, what RSTS version are we talking about?

Edit: I see you answered the first 2 of my questions a minute before I posted. What RSTS version is it?

Almost all of my simh experiences is on the PiDP11, but at least there the boot process is quite different from "real" -11 hardware. On a real -11, the M9312 (or equivalent) boot ROM(s) load a bootblock from the device and branch to it. Under simh it seems like that is replaced with "... and then some magic happens". This may be a red herring, though.

My guess is that there is something "funny" about how the controller is seeing the SCSI2SD and mapping it onto some corresponding DEC drive model.

I have a vague recollection (this is 35+ years ago) that the one of the first things the RSTS/E bootloader does is send a linefeed to the console terminal (which is harder to notice on CRTs than on hardcopy terminals). If you didn't get the linefeed, either the bootloader was not read correctly or there is something very wrong with the system. We can probably discount the latter as you can boot other operating systems.

Speaking of booting other operating systems - it might be informative to look at the first few blocks of your RSTS disk with "od" under BSD (or similar) to make sure that the "disk" is readable and it looks like there might be an operating system on there.
Click to expand...
I used an image available online booting it with Simh and then genning my own perssonalized copy for my machine.
I started with version 7, then found later versions available. I believe I have v10. Or possibly v9.
 
wa2flq said:
There is a marginal condition on the serial interface. It could be the VT320, the 11/84 serial port or the cable. Bad or incorrect grounding, weak charge-pump on the +-15v supplies for the transmitter or other component failure. Some equipment is more tolerant of out specification conditions than others.

A VOM or LED serial board breakout tester should help investigate the first two. If you don't have strong background in analog and/or digital electronics here is some background material.

https://www.lammertbies.nl/comm/info/RS-232_specs.html
https://www.lammertbies.nl/comm/cable/dec-mmj.html
https://arcelect.com/rs232.htm

Jerry
Click to expand...
Yet it works for booting, and only not for displaying the FRD screen? This
seems odd. I'd expect flakiness all throughout the boot process. Whatever. I may get
back to checking this some day, but for now I want to be able to boot my RSTS copy.
 
tradde said:
Yet it works for booting, and only not for displaying the FRD screen? This
seems odd. I'd expect flakiness all throughout the boot process. Whatever. I may get
back to checking this some day, but for now I want to be able to boot my RSTS copy.
Click to expand...

On the programming side of a "digital" computer, its all ones and zeros.

One the electronic side, it is all analog. Sometimes shifting a signal by just a fraction in voltage and/or time will change the results.
 
Ok, so I was able to build Simh pdp11 on my Mac laptop after downloading the developers packages.
It works as I have always seen it work. Trying to boot RSTS fails. But I may have missed something
in the configuration. I no longer have the machine I used to run Simh on so the startup scripts I
used are gone. Here is the attempt at booting and the error:
PDP-11 simulator V3.9-0
sim> set cpu 11/84
Disabling XQ
sim> att rq0 rsts.dsk
sim> b rq0


Disk error during boot phase
PC=063370 PS=034341 OV=000001 M5=004000 M6=001400 SP=041162
R0=172152 R1=000026 R2=000077 R3=000026 R4=041500 R5=157570

SP-> 004200 021364 041214 000000 067602 000026

Fatal RSTS/E system initialization error!
The fatal error occurred during the bootstrap phase
of system initialization; there is no recovery.

HALT instruction, PC: 017024 (JMP @#2340)
 
You are correct. That's what I was using so never looked for newer. The newer 4.0 Simh boots RSTS at least to a prompt.
I will see if it fully starts. Thank you. If so this tells me the image on the SD card is fine.
 
tradde said:
You are correct. That's what I was using so never looked for newer. The newer 4.0 Simh boots RSTS at least to a prompt.
I will see if it fully starts. Thank you. If so this tells me the image on the SD card is fine.
Click to expand...

One thing I have found with RSTS is it is sensitive to the total physical size of the disk it resides on, in terms of file system.
If you setup a, for example, 1G SIMH disk image and init that with RSTS, and then copy that 1G image file to a 2G physical disk, RSTS will puke during startup and die.

Not so with other operating systems. For example, I made 32MB (maximum 65536 block * 512byte/block filesystem) RT11, XXDP images, and copy those to 2G physical disks and they boot and run fine. The extra unused physical blocks are ignored, no problem.

Same for 2.11BSD. Init a 1G physical image and copy to a 2G physical disk and it still boots and runs fine as a 1G filesystem. No problem.

Don't know about RSX11M, don't use it (never liked it 40 years ago, still don't).

So with RSTS make sure your SCSI2SD card physical drive sizes matches what you did in SIMH.

Don
 
It should work, as I used this long ago and it booted fine. I may hae to sysgen a new copy though
as I am not sure of the exact set up from back then. It boots to this now:
sim> boot rq0



RSTS V10.1-L RSTS (DU0) INIT V10.1-0L


Today's date? ^C

Enter today's date as DAY-MONTH-YEAR (e.g., 7-SEP-85)
Today's date?
Simulation stopped, PC: 127056 (RTS PC)
sim> b rq0



RSTS V10.1-L RSTS (DU0) INIT V10.1-0L


Today's date? 07-09-80

Enter today's date as DAY-MONTH-YEAR (e.g., 7-SEP-85)
Today's date? 9-JUL-19

Current time? 11:25


Start timesharing? <Yes>

Size of monitor has changed from 78K to 74K.
Adjusting memory table.

Memory allocation table:

0K: 00000000 - 00447777 ( 74K) : EXEC
74K: 00450000 - 15523777 (1675K) : USER
1749K: 15524000 - 17757777 ( 295K) : XBUF

Memory available to RSTS/E is 2044K words.

19.07.09 11:25
??Disk pack mount error
000000 000000 000000 000000 000000 000000 000400 000000 174000
Simulation stopped, PC: 101140 (BR 101130)
 
You must log in or register to reply here.
Back
Top