Doug Jackson - pesonal email <doug at stillhq.com> wrote:
> Hi Everybody
>
> I was reading some doco last night (specifically the DEC RL11/01 Disk
> Subsystem Training Handout), and I am confused.
>
> (That is nothing new...)
>
> In the "Subsystem commands section", the addresses specified for DAR and
> CSR are 774404, and 774400 respectively, but in the back of the
> document, under the 'toggle in programs' section, the DAR and CSR are
> shown as being at 174404 and 174400 respectively.
>
> Hmmm. I see three possibilities:
>
> 1. I have (re) discovered a documentation error - I wonder if DEC, no,
> HP, no Compaq, would be happy for me to submit an amendment :-)
>
> 2. The hardware throws away the upper bits so both references are
> correct. Hmmm Possibly not :-)
>
> 3. There is some other stuff happening that I missed...
>
> If anybody could shed some light on this I would appreciate it. The
> background to the problem is that I can not convince my shiny,
> wonderful, (and noisy) DL01 to perform the seek test - Me thinks there
> is a problem....
People have already convered most of this, and essentially got all the
details down.
I'll just make a few comments, which relates to several answers. And
maybe clarify things in a bit more technical detail.
The PDP-11 CPU is a 16-bit machine, so all code will always just deal
with 16-bit values.
The PDP-11 can have different buses, with different behaviours, but
basically we can divide them into three groups.
16-bit bus
18-bit bus
22-bit bus
Machines with a simple 16-bit bus is almost nonexistant, but there was
some early Q-bus CPUs with a pure 16-bit address range, I seem to remember.
18-bit means all Unibus machines, as well as some Q-bus machines.
22-bit means most Q-bus machines.
When the PDP-11 sits on anything but a 16-bit bus, it must use tricks to
somehow actually utilize the extra address bits. This is done at several
places, and in several ways.
The most important component here is the MMU. When you enable the MMU,
you can select wether you want 18-bit or 22-bit addressing (assuming you
have a 22-bit capable machine).
With MMU turned off, addresses are directly physical. The MMU will
simply just extend the physical address 160000-177777 to 760000-777777
if we have an 18-bit bus, and 17760000-17777777 of we have a 22-bit bus.
If you enable the MMU in 18-bit mode, the MMU will start using the APR
registers to relocate your addressing. All your addresses in the PDP-11
will be virtual addresses, which combined with the APR values will form
physical addresses. If this is on a 22-bit capable machine, the MMU will
now detect if you are addressing physical 760000-777777, and extend
those addresses to physical 17760000-17777777, same as when you play in
16-bit mode, except for which physical addresses it remaps.
In 22-bit mode, the MMU will use your virtual address in combination
with the APR value to create a physical 22-bit address, and be happy.
So, to answer another persons comment. A 11/70 can be run in either
18-bit addressing or 22-bit addressing. Also, since a Unibus is always
18-bit, any Unibus device will work fine in an 11/70, even though it has
22-bit addressing (the same is true of the 11/44, 11/24, 11/84 and
11/94, by the way).
If the 11/70 is run in 18-bit mode, DMA from Unibus will directly
address memory and everything will be just fine.
Now, the really tricky part is how to deal with DMA on a Unibus machine,
where devices doing DMA only can put out 18-bit addresses, while the MMU
is using 22-bit addressing. When 22-bit addressing is enabled, there are
two PDP-11 designs. From a normal users point of view, the difference is
irrelevant. For OS programmers, it do make a difference, however.
11/70: all DMA addressing will actually be directed to a 124KW area
addressed at 17000000-17760000. Notice how this is physically directly
before the I/O page. These addresses cannot hold any memory. Instead,
this area of memory is virtual, and subjected to a new remapping by the
Unibus Map, if enabled. This remapped address in turn, is always on the
memory bus. So the Unibus Map is only a mapping between
17000000-17760000 and the memory bus.
This also means that on an 11/70, you can access addresses in the I/O
page, on the memory bus, but you have to go through the Unibus Map. And
this is needed, if you want to access the CSRs of the memory boxes,
which don't sit on the Unibus at all.
Note that the Unibus Map don't have anything to do with the I/O page
addressing. That is done by the MMU as a part of forming the physical
address. The MMU will then forward the address to either the memory,
Unibus Map, or Unibus, depending on which physical address it is.
The Unibus will, however, always forward DMA transfers to the Unibus
map, which will convert it into a physical address, and always pass it
on to the memory bus. (As a parethesis the RH70 massbus controllers in
the 11/70 generate 22-bit addresses straight away, and sends them
directly to the memory bus.)
11/84 and 11/94: With the 11/84 and 11/94, DEC removed the concept that
the physical addresses 17000000-17760000 are remapped by the Unibus map.
Instead they placed the Unibus map between the Unibus and the CPU bus.
And all physical addresses on the CPU bus stay physical, and either
address memory, or the I/O page. When the access is to the I/O page, the
Unibus Map also relays the access back out on the Unibus, so both things
on the CPU bus and the Unibus can respond.
I haven't checked, but I believe that the 11/24 and 11/44 are a mix of
the two above. They reserve the memory area like the 11/70, but the
Unibus map works somewhat like the 11/84 and 11/94. But I/O page access
don't do through it, and I think that the memory CSRs are visible on the
Unibus instead. (Maybe this would be a third variation, but I'm a bit
uncertain at this point on exactly how they work.)
The only thing remaining are the pure 22-bit machines, which are most
Q-bus machines. They don't have a Unibus map. Instead all devices can
address the whole memory directly with DMA, and can run as is.
This is where the RLV11 and similar devices runs into a small problem.
These controllers are actually designed for 18-bit Q-bus machines. But
the only thing that happens is that the high address bits are left
cleared always when they do DMA, so they can do DMA just fine in 22-bit
machines, with the limitation that they can only do DMA to the low 128KW
of memory. That's why the bounce buffers are needed for these.
Johnny
Does anyone know the specs for the wall wart for one of these? I have seen 2 different ones, and would like some clarification.
I've seen 9V DC center positive and 12V DC center positive.
Thanks for any help,
Kelly
The other day, I noted that both the DTC 3280 and the UltraStor 14N
SCSI controllers have an option to add a 3rd floppy drive to the
common floppy cable. Essentially, they place the motor control on
pin 4 and drive select on pin 6 for the extra drive. It's not hard
to make up a cable (Ultrastor supplied one with their kits) and a
simple DOS driver provides access to the third diskette. I have a
couple of drivers, if anyone's interested.
But I wanted to use a Future Domain 1670 controller in this case. It
uses the same FDC (National DP8473), but doesn't bring the motor and
drive select out to the floppy connector. So, for 5 minutes of time,
and a couple of lengths of wire wrap wire and a hot soldering iron,
all one need do is strap pin 4 of the floppy connect to pin 1 of the
8473 and pin 6 of the floppy connector to pin 42 of the 8473.
Works great. Wish I would have thought of this trick when the
controller was new 15 years ago.
Cheers,
Chuck
Anyone have one of these ISA SCSI controllers out there with a
version 3.4 or 3.5 BIOS? I'm looking to upgrade the old BIOS on my
card and would appreciate a data snapshot of the ROM.
Thanks,
Chuck
This machine is not mine, which has been mine for a while. Somebody bought
it but left it in my basement for the last two years. I can't store it for
him any more, but his email stopped working and I can not find him. I sell
it with the price he bought it from me, in case that he comes to me for it
in the future.
You are expected to pick it up. Otherwise you must arrange shipment.
vax, 9000
Hi
I saw a message on the classic computer list in 2003 from Ethan saying
that he had a RB5X robot controller with a 8073 SC/MP controller on it.
The thread degenerated into a general car discussion from what I have
been able to determine.
Today, I received my INS8060 and INS8073 CPU chips from Unicorn - The
8060's are easy, I have been able to find tons of doco, and will be
producing a couple of SC/MP blinken lights and swiches systems (but not
with 2012 ram chips ;-) ) shortly - That's the easy bit.
I am very interested in the INS8073 (with Tiny Basic onboard), and have
so far come across a PDF of the 807x (8070/8072), as another spare time
consuming system - My questions are;
1) Has anybody got a reference implementation for the 8073 - I suspect
that it involves a 4Mhz xtal, and a RS232 line driver/receiver connected
to SA (as RXD) and F1 (as TXD) - that can be breadboarded easily, but
the real secret is what address will it be expecting the external 6164
ram to provide the 8k of massive storage...
2) Did anybody end up reverse engineering the RB5X board - in the words
of a somebody wiser than me -- "That'l do in a pinch"
3) Does anybody have the basic reference guide that indicates the
allowed word lists for this part?
Thanks,
Doug Jackson
