• Please review our updated Terms and Rules here

v7 unix and architecture/model questions

I

iainmaoileoin

Experienced Member
Joined
Dec 24, 2014
Messages
216
Location
inverness
I should know the answer to this, but I cant find the neuron with the info.
An hour on the web left me just as neuronless.

I wanted to boot up my rl02 Version 7 unix on one of my "currently with power" systems.

I cant get it to boot on a 34/73/83/84 then I stopped.
On my 94 I get
@boot
New Boot, known devices are hp ht rk rl rp tm vt
: rl(0,0)rl2unix
not a directory

I dont hear a head moving before the error, but the boot program must have got to the rl02 controller - it looks like the secondary boot is not getting data from the disk.


----
*same disk* in an 11/73
Starting system from DL0

@boot
New Boot, known devices are hp ht rk rl rp tm vt
: rl(0,0)rl2unix
mem = 448192
ka6 = 2225
aps = 141704
pc = 1332 ps = 340
trap type 0

That program counter looks terribly small - I have not examined the memory about that location.

----
There are random notes on the web about it being
a processor
b memory
c Q bus 22 (that is why I tried the 84/94 set up)
d something else
So that did not move me forward.
-----
Subsequently I have tried out simh and get the same errors (as expected), do I need to delve in the assembler to to try to identify the problem. or can some kind soul tell me not to waste my time since it is e.g. a Q bus issue?

I dont have an 11/45 to run the system on, what else might I build from the "more modern" bits I have?

Any clues.
 
Maybe neurons are on a holiday break this week because I'd say you lost me. I'm not sure I can help but let me try to repeat what I think you said. You have V7 UNIX on a physical RL02 (?) which you successfully booted in the past on different physical hardware (?) but now it fails to boot as expected for various reasons (?). You also have a similar problem attempting to boot on SIMH emulating each of your processors (?) with an image file of that RL02 (?). Is this even close or did I totally misunderstand?
 
You understand; Does that mean we can be pals?

Where did i get the V7 image from? I have no idea! Perhaps then this is the wrong place to start and I should get (or build) an image from a trackable souce? There is nothing that I know of on the disk image that is special to me in any way.

The disk image does boot on simh (set cpu 11/45) but wont boot on simh with a cpu as 23+/73/74/84/94 (the type of kit that I now have). That shows the image itself is not mince.
I had hoped that the /84 - being sort of unibus might boot it.

Ah ... Status register? Did you have to do something on the '45 front panel to get V7 to boot? Most of my time was spent with SI controllers and we just toggled a bootstrap loader by hand. I really cant remember what we did to boot off the other disks.
 
Not real answers, but a few comments about hardware:

The 11/45 is a straight Unibus machine with I/D space and dual register sets. 128K words max. No Unibus map like on 11/70, 11/44, (11/24?), 11/84. 11/94. The Unibus map systems use 18-bit controllers and "map" Unibus DMA requests to memory within the 4MB address space. The 11/24 does not have I/D space or dual register sets. The 11/44 does not have dual register sets. I think the J11 CPUs do not have some of the error registers implemented on the 11/45 and 11/70 (I have no idea if Unix cares about that).

11/23+, 11/73, 11/83, 11/93 all have a 22-bit QBUS. All controllers in the system must know how to DMA to all 4MB directly. As noted above 11/23+ has no I/D, and there may be some missing stuff on J11 CPUs.

This link might be useful: What Unixes run on What PDPs?
 
Last edited:
Plenty of answers there sir. The neurons are remembering what they have forgotten.
The Unibus map is probably the critical part I had forgotten about. That is why I can read in the boot block, but then not find "/" on the disk.

I HAD read the processor manuals looking for instruction set/memory map differences but had totally skipped the (important) bit about the Unibus mapper.

OK, so I guess I need to find a '45!
Your input is much appreciated.
 
Glad you were happy with that previous stuff. Did you notice the part in the linked page about patching the image so V7 Unix will boot on a /44 by making Unix assume it is a /45? That will put the system in 18 bit I/D mode, but it should work. I suspect the same thing would work on a J11 machine like an 11/73.

I think you will find the source code for the patch you need to make in the file /usr/sys/conf/mch.s shortly after the label "start:". My first thought is to change the mask where SSR3 is tested for the 20 octal bit (bit 4 controls 22-bit mapping) and if non-zero the global _cputype is changed to 70 (it defaults to 45). If you patch the word containing 20 octal to 0 in the boot image then the code will always think it is running on an 11/45, and presumably stay in 18-bit mode. I don't know where in the image that would be (I have sources, but no image at the moment), but a link map should tell you where the "start:" label is and it should be pretty easy to find it from there. I would think you could try that patch easily in SIMH to see how it goes.
 
Ta

Ta

Uniballer said:
Glad you were happy with that previous stuff. Did you notice the part in the linked page about patching the image so V7 Unix will boot on a /44 by making Unix assume it is a /45? That will put the system in 18 bit I/D mode, but it should work. I suspect the same thing would work on a J11 machine like an 11/73.

I think you will find the source code for the patch you need to make in the file /usr/sys/conf/mch.s shortly after the label "start:". My first thought is to change the mask where SSR3 is tested for the 20 octal bit (bit 4 controls 22-bit mapping) and if non-zero the global _cputype is changed to 70 (it defaults to 45). If you patch the word containing 20 octal to 0 in the boot image then the code will always think it is running on an 11/45, and presumably stay in 18-bit mode. I don't know where in the image that would be (I have sources, but no image at the moment), but a link map should tell you where the "start:" label is and it should be pretty easy to find it from there. I would think you could try that patch easily in SIMH to see how it goes.
Click to expand...

Yep, I saw that I have a job for tonight - or tomorrow night - but I have an RJS03 in bits and it wants some attention tooooo.

adb -w /dev/kmem may be the place for me to start.
Those were the days.
Our printers used to hang.
A quick adb -w on kmem would often allow us to reset the controller without a reboot. Getting a hook in the device driver was toooo messy, so I remember that we eventually ended up gubbing the "nice" system call to have a "bad" parameter that caused the printer to reset!

It was fun.

I will report back and - if it works - publish the image for anyone else who wants it.
 
http://www.tuhs.org/Archive/PDP-11/Distributions/dec/Jean_Huens_v7m/

I am 1/2 way through building the above system from the files on the web-site.

With a minimal rl02 system installed (none of the tars installed) it certainly boots in simh on cpus of 23+,73 and 84. It boots to the same degree from an RL02 on my '73.
My plan is that I can use that v7m system to mount the older "v7" RL02s that I have and see what is actually on the disks.

I will go back and do the patching on the original "v7" when I am spared.

BTW if anybody needs to know, I had to put these lines in mkdisttap.pl to write out a "simulated tape".

I could run mkfs and restor ok (note the 512 byte blocks). I could NOT boot into the programs using a BSD2.11 type 10240 byte blocks, nor could I restore the root image on a 10240 byte block size.

I have NOT yet read in the 2 x tar files - files 7 and 8. I wonder if they may have to be 512 blocks as well?
critical part of mkdisttap.pl:
add_file("tapefile1", 512);
end_file();
add_file("tapefile2", 512);
end_file();
add_file("tapefile3", 512);
end_file();
add_file("tapefile4", 512);
end_file();
add_file("tapefile5", 512);
end_file();
add_file("tapefile6", 10240);
end_file();
add_file("tapefile7.tar", 10240);
end_file();
add_file("tapefile8.tar", 10240);
end_file();
 
Last edited:
v7m (the dec "improved" release of version 7 unix)

Check out the link http://www.scotnet.co.uk/iain/DEC/v7m/index.html for a set of commands to build a generic v7m using simh under a unix operating system.

Also I have put up a pair of RL02 images build by the process. These boot on my real kit and (under simh) can be used on everything I have tried from a 23+ via a 45 to an 83.

The setup.txt from the v7m release shows how to build for RP RM type disks. I only built for 2 x RL02 because I have RL02 drives on my systems.

comments/bug fixes welcome.

Uniballer I hope to be back on the patch idea later this week.



Enjoy
 
The v7m source gives up all the secrets
# ed mch_i.s
25431
1
/ machine language assist
/ for non-separate I & D space CPU's
/ 11/23, 11/24, 11/34, 11/40, & 11/60 CPUs
/ Fred Canter 8/2/81
/
/ Added a "bic" instruction after the symbol "start:".
/ This is required in order to allow the I space only
/ versions of unix v7 to be booted via the standalone
/ boot code, which enters unix with memory management
/ enabled after loading unix into memory.
/ This change allows the I space only unix monitors
/ to be booted via the standalone boot or
/ directly via the block zero boot.

Also ... in the "id" boot

/ machine language assist
/ for separate I & D space CPU's
/ 11/44, 11/45, & 11/70 CPUs
/
/ The following modifications have been made:
/
/ 1. In order to allow a unibus disk (rm02/3, rl02, & rk06/7)
/ to be the root device on an 11/44 or 11/70, the
/ unibus map is no longer enabled in mch.s. Instead the map
/ is enabled in machdep.c, after it has been initialized.

So, I am off to try that mod and recompile the kernel. It has been a looooong time. Just as much fun this time around - apart from the backspace key doing what it does ;-)
 
I just looked at module conf/mch_i.s & conf/mch_id.s, and it looks like 22-bit mapping is not explicitly enabled unless a unibus map is found. Probably because the 11/23+ and 11/73 did not yet exist when this code was released. Of course, if 22-bit mapping is already enabled at "start:" then it might still work. Can you confirm how much memory is found on an 11/23+ or 11/73?
 
I presume you mean you cant find the 22 bit mapping on the v7 sources - or do you mean v7m?

On my 73, v7 blows way before it gets to printing the mem size.
[My 23+ is in another room over christmas and i wong get to it for a day or two.]

The 73 panics before the kernel prints anything useful.
The panic starts with ka6=
as the first line of output.
----------
I have read a comment somewhere -in the last few days- about the boot program enabling 22-bit - but I dont know if that was in v7 or v7m sources.

I cant find such a comment in either sources, I must have be dreaming.

to confirm: the v7m unix does boot OK on the hardware
 
iainmaoileoin said:
I presume you mean you cant find the 22 bit mapping on the v7 sources - or do you mean v7m?
Click to expand...
I meant v7m. Since you pointed it out I thought I would look at it. The code only explicitly enables 22-bit mapping when a unibus map is found. This could result in a 22-bit qbus system running as if it only has 256KB of memory. As I said, if 22-bit mapping is already enabled before any of the v7m code is run then it might find and use all the memory, but I wonder if the RLV12 controller for your RL02 will also be handled correctly. I'm just too lazy to check for myself.
 
I used your tape image (thanks) to build an RL02/TU10 system. When I tell SIMH that I have an 11/23+ with 1M of RAM the rl02tmunix bootup says:
Code: 
unix/v7m 2.1

mem = 206592
#

So it clearly is not finding all the RAM on an 11/23+.

When I tell SIMH that I have an 11/83 with 1M of memory I get:

Code: 
unix/v7m 2.1

mem = 1001216
#

In either case, it goes into multi-user mode just fine. I don't know how to fill up memory without writing a stupid little program, but that should be easy (except *ugh* ed).
 
I have also found that the Unix V7m I/D space kernel that I built crashes on an 11/83 or 11/84, but works fine if I tell SIMH to make the system an 11/45 or 11/70.

EDIT: also boots on an 11/44
 
Last edited:
You must log in or register to reply here.
Back
Top