Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.vms > #2596 > unrolled thread

RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750?

Back to article view | Back to comp.os.vms

Contents

  RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? vaxorcist <vaxorcist@googlemail.com> - 2011-05-02 02:52 -0700
    Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-02 08:49 -0700
    Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-02 14:57 -0700
    Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? SeanOBanion <sean@obanion.us> - 2011-05-02 17:05 -0700
      Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-02 21:59 -0700
        Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 08:13 -0500
          Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Roger Ivie <rivie@ridgenet.net> - 2011-05-03 08:28 -0500
            Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 12:34 -0500
              Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-03 22:50 -0700
                Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-04 08:32 -0500
                  Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-04 10:13 -0700
                    Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-04 12:22 -0500
                      Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-04 20:25 -0700
                        Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-05 09:02 -0500
                          Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-05 09:57 -0700
                            Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? SeanOBanion <sean@obanion.us> - 2011-05-06 07:54 -0700
                              Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@update.uu.se> - 2011-05-06 10:00 -0700
                          Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-05 10:01 -0700
                        Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-06 11:54 -0500
                          Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@update.uu.se> - 2011-05-06 10:05 -0700
          Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-03 08:44 -0700
            Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 12:36 -0500
            Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 12:42 -0500
        Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? SeanOBanion <sean@obanion.us> - 2011-05-03 09:38 -0700
          Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? SeanOBanion <sean@obanion.us> - 2011-05-03 09:48 -0700
            Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-03 10:35 -0700
              Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? BillPedersen <pedersen@ccsscorp.com> - 2011-05-03 10:47 -0700
            Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? Johnny Billquist <bqt@softjar.se> - 2011-05-03 23:09 -0700
    Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? ChrisQ <meru@devnull.com> - 2011-05-03 14:16 +0100
      Re: RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750? koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 12:27 -0500

Page 1 of 2  [1] 2  Next page →

#2596 — RB730 Integrated Disk Controller (R80/RL02) usable with VAX-11/750?

Can the RB730 Integrated Disk Controller (primarily developed for R80/
RL02 drives with the VAX-11/730 and /725) be used with the VAX-11/750?
This might have been a "low cost" solution to connect disk drives to
the /750.

Any hints welcome!

Regards,

Ulli

[toc] | [next] | [standalone]

#2606

On 2011-05-02 02:52, vaxorcist wrote:
> Can the RB730 Integrated Disk Controller (primarily developed for R80/
> RL02 drives with the VAX-11/730 and /725) be used with the VAX-11/750?
> This might have been a "low cost" solution to connect disk drives to
> the /750.
>
> Any hints welcome!

Have not tested, but if it sits on the Unibus then I can't see a reason 
why not. However, if it sits directly on a dedicated slot on the CPU 
backplane, then most likely not.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[toc] | [prev] | [next] | [standalone]

#2625

On May 2, 10:52 am, vaxorcist <vaxorc...@googlemail.com> wrote:
> Can the RB730 Integrated Disk Controller (primarily developed for R80/
> RL02 drives with the VAX-11/730 and /725) be used with the VAX-11/750?
> This might have been a "low cost" solution to connect disk drives to
> the /750.
>
> Any hints welcome!
>
> Regards,
>
> Ulli

I don't think it sits on the Unibus in the traditional way.

EK-RB730-TD is the VAX 11/730 IDC Technical Description and there's
one at
http://www.bitsavers.org/pdf/dec/vax/730/EK-RB730-TD-001_VAX-11_730_IDC_Technical_Description_Sep82.pdf

Figure 2-1 shows the interfaces. Yes there are many UNIBUS signals.
But there are also signals which I would not expect on the UNIBUS, but
which are associated with the RB730's tight integration with the
VAX730 CPU e.g. CPU Writable Control Store stuff. Why is that there?
Not 100% sure, but I think the AMD2900 bitslice micro which is the
heart of the VAX 730 CPU also plays an essential part in the operation
of the RB730. Given that, I wouldn't expect it to work (let alone be
supported) on a 750. But I could be wrong.

I'm afraid I don't have any suggestions for "low cost" storage
adapters for a 750, maybe others do?

[toc] | [prev] | [next] | [standalone]

#2633

On May 2, 2:52 am, vaxorcist <vaxorc...@googlemail.com> wrote:
> Can the RB730 Integrated Disk Controller (primarily developed for R80/
> RL02 drives with the VAX-11/730 and /725) be used with the VAX-11/750?
> This might have been a "low cost" solution to connect disk drives to
> the /750.
>
> Any hints welcome!
>
> Regards,
>
> Ulli

No.

The IDC is part of the 730 CPU, stealling CPU cycles in a hidden way
to get it's work done.

The later version of the 730 did away with the IDC for a single UDA50
Unibus adapter that also reduced the amount of memory the system could
support:
system memeory of a 730 sat on the Unibus.

For a discustion of supported disk adapters and systems, see:
http://h30266.www3.hp.com/odl/vax/opsys/vmsos73/vmsos73/6136/6136pro_005.html


Sean

[toc] | [prev] | [next] | [standalone]

#2634

On 2011-05-02 17:05, SeanOBanion wrote:
> On May 2, 2:52 am, vaxorcist<vaxorc...@googlemail.com>  wrote:
>> Can the RB730 Integrated Disk Controller (primarily developed for R80/
>> RL02 drives with the VAX-11/730 and /725) be used with the VAX-11/750?
>> This might have been a "low cost" solution to connect disk drives to
>> the /750.
>>
>> Any hints welcome!
>>
>> Regards,
>>
>> Ulli
>
> No.
>
> The IDC is part of the 730 CPU, stealling CPU cycles in a hidden way
> to get it's work done.

Cute. I have never examined the IDC in detail... :-)

> The later version of the 730 did away with the IDC for a single UDA50
> Unibus adapter that also reduced the amount of memory the system could
> support:
> system memeory of a 730 sat on the Unibus.

What??? Are you sure? The Unibus only have 18 address lines, which means 
256K addressable. And some of that is needed for I/O. I would be very 
surprised if memory really sat on the Unibus.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[toc] | [prev] | [next] | [standalone]

#2642

In article <ipo238$id3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> What??? Are you sure? The Unibus only have 18 address lines, which means 
> 256K addressable. And some of that is needed for I/O. I would be very 
> surprised if memory really sat on the Unibus.

   IIRC, the 730 and 725 were true UNIBUS systems, using the UNIBUS
   as the system bus, with all its limitations, just like my PDP-11/34 
   and 11/44.

   With virtual memory, who needs more than 265KB?  (These systems
   were not meant to be fast, real word processing doesn't need
   much.)

[toc] | [prev] | [next] | [standalone]

#2644

On 2011-05-03, Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
> In article <ipo238$id3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>> 
>> What??? Are you sure? The Unibus only have 18 address lines, which means 
>> 256K addressable. And some of that is needed for I/O. I would be very 
>> surprised if memory really sat on the Unibus.
>
>    IIRC, the 730 and 725 were true UNIBUS systems, using the UNIBUS
>    as the system bus, with all its limitations, just like my PDP-11/34 
>    and 11/44.

It's been a *long* time since I've used a /730, but I'm certain it had a
UNIBUS map. I think the one I used to use had a couple megs of RAM.

AFAIK, the only VAX without a UNIBUS map (or its equivalent) was
MicroVAX I, which used QBUS memory and was therefore limited to 4MB.

My original design idea for the Firefox QBUS adapter involved having 4MB
of RAM on the adapter so that it didn't need to get on the MBUS for DMA;
the cache structure on Firefox was such that it was difficult to
guarantee that a DMA transaction could be completed within the DMA
timeout. I made the mistake of trying to sell it to VMS as "conceptually
pretty much just like MicroVAX I"; I pulled back a bloody stump because
the VMS guys hated MicroVAX I due to the lack of a scatter/gather map
and had just barely managed to clean all the MicroVAX I support out of
the code base.

Consequently, FQAM wound up using an ugly hack that was put in place to
try to make FTAM work (Firefox Tape Adapter Module, the first attempt at a
QBUS adapter for Firefox, which consisted of a CQBIC) to tame the
MBUS: while ownership of the QBUS was granted, the FQAM used the
absolute priority given to node 0 to keep the MBUS 100% busy doing short
transactions to guarantee that another node couldn't start a transaction
that would take so long to complete that it would prevent an FQAM
transaction from completing within the QBUS deadline.

Which is why Firefox can't get anything done while QBUS DMA is going on.
Ugly, but it works, for certain definitions of "work".
-- 
roger ivie
rivie@ridgenet.net

[toc] | [prev] | [next] | [standalone]

#2652

In article <slrnis00n9.m6.rivie@stench.no.domain>, Roger Ivie <rivie@ridgenet.net> writes:
> On 2011-05-03, Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
>>
>>    IIRC, the 730 and 725 were true UNIBUS systems, using the UNIBUS
>>    as the system bus, with all its limitations, just like my PDP-11/34 
>>    and 11/44.
> 
> It's been a *long* time since I've used a /730, but I'm certain it had a
> UNIBUS map. I think the one I used to use had a couple megs of RAM.

   Yes, you can find a discussion of LARGO on the 'net, an 11/730 with 
   3 1MB memory modules.  Just because it's an 18 bit system bus doesn't
   mean the system is limited to 18 bits, you just have to get
   inventive.

> AFAIK, the only VAX without a UNIBUS map (or its equivalent) was
> MicroVAX I, which used QBUS memory and was therefore limited to 4MB.

   The 11/725 wasn't just a stripped down 730.  It's map would not
   automatically update at page boundaries, so drivers had to break
   down large transfers and update the map between pages.  (There's
   no way to be sure that successive pages in virtual memory are
   in the same part of the map in physical space.)

[toc] | [prev] | [next] | [standalone]

#2666

On 2011-05-03 10:34, Bob Koehler wrote:
> In article<slrnis00n9.m6.rivie@stench.no.domain>, Roger Ivie<rivie@ridgenet.net>  writes:
>> On 2011-05-03, Bob Koehler<koehler@eisner.nospam.encompasserve.org>  wrote:
>>>
>>>     IIRC, the 730 and 725 were true UNIBUS systems, using the UNIBUS
>>>     as the system bus, with all its limitations, just like my PDP-11/34
>>>     and 11/44.
>>
>> It's been a *long* time since I've used a /730, but I'm certain it had a
>> UNIBUS map. I think the one I used to use had a couple megs of RAM.
>
>     Yes, you can find a discussion of LARGO on the 'net, an 11/730 with
>     3 1MB memory modules.  Just because it's an 18 bit system bus doesn't
>     mean the system is limited to 18 bits, you just have to get
>     inventive.

Except then of course it isn't the system bus, but just an I/O bus... :-)

>> AFAIK, the only VAX without a UNIBUS map (or its equivalent) was
>> MicroVAX I, which used QBUS memory and was therefore limited to 4MB.
>
>     The 11/725 wasn't just a stripped down 730.  It's map would not
>     automatically update at page boundaries, so drivers had to break
>     down large transfers and update the map between pages.  (There's
>     no way to be sure that successive pages in virtual memory are
>     in the same part of the map in physical space.)

I'm not even sure I understand that comment.
The Unibus map is a way to map the Unibus 18-bit address into a 22-bit 
address (for large PDP-11s) or 32-bit address (for VAXen). You normally 
never updated in during DMA transfers. You set up the whole mapping for 
your DMA before starting a transfer, and the scatter/gather behavior of 
the Unibus map was passively there all the time.
Exactly how you split up the 18-bit Unibus address decides how large 
your Unibus map is. I don't remember for the on the VAX, but I suspect 
each "page" is 512 bytes (since the VAX loves that size in all weather), 
which means 512 registers in the map. A DMA runs through a range of 
addresses, and might touch one or several map registers.

The map itself is static, and is not updated at page boundaries, or on 
any other conditions either, except for programmatical writes to the 
map, which are done prior to starting a transfer. So, what do the quoted 
paragraph above actually mean?

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[toc] | [prev] | [next] | [standalone]

#2669

In article <ipqpfi$qvl$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> Except then of course it isn't the system bus, but just an I/O bus... :-)

   If everything except the CPU-memory connection is on the same
   bus, and CPU and memory are also on that bus, then which is the
   system bus?

> 
> I'm not even sure I understand that comment.
> The Unibus map is a way to map the Unibus 18-bit address into a 22-bit 
> address (for large PDP-11s) or 32-bit address (for VAXen).

   It's a matter of how big the "map" is.  Drivers had to break up
   large transfers, so I assume the "map" was only one entry (more
   like an APR than a map).  Or maybe it was just a few, I forget
   the upper limit, but I recall it was only for the 11/725.

[toc] | [prev] | [next] | [standalone]

#2675

On 2011-05-04 06:32, Bob Koehler wrote:
> In article<ipqpfi$qvl$1@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>  writes:
>>
>> Except then of course it isn't the system bus, but just an I/O bus... :-)
>
>     If everything except the CPU-memory connection is on the same
>     bus, and CPU and memory are also on that bus, then which is the
>     system bus?

Uh? The memory is not on that bus, or even near it. I thought we had 
just established that.
Also, the CPU is not exactly just sitting on the Unibus either. The CPU 
generates a 28-bit physical address through the MMU (as do all VAXen, 
except some NVAX CPUs which can generate a 34-bit physical address). The 
18-bit Unibus address space is then mapped into some part of this 28-bit 
physical address space. And the actual memory is mapped into some other 
part of this physical address space.

It's really simple. The Unibus is just an I/O bus for the CPU. The CPU 
don't sit straight on the Unibus.

>> I'm not even sure I understand that comment.
>> The Unibus map is a way to map the Unibus 18-bit address into a 22-bit
>> address (for large PDP-11s) or 32-bit address (for VAXen).
>
>     It's a matter of how big the "map" is.  Drivers had to break up
>     large transfers, so I assume the "map" was only one entry (more
>     like an APR than a map).  Or maybe it was just a few, I forget
>     the upper limit, but I recall it was only for the 11/725.

Unfortunately the 11/725 documents don't seem to be on bitsavers, so I 
can't read up on this. But it do sound weird. The 11/730 atleast have a 
full Unibus map, which covers the full 256K.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[toc] | [prev] | [next] | [standalone]

#2677

In article <ips1gq$7i2$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> On 2011-05-04 06:32, Bob Koehler wrote:
>> In article<ipqpfi$qvl$1@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>  writes:
>>>
>>> Except then of course it isn't the system bus, but just an I/O bus... :-)
>>
>>     If everything except the CPU-memory connection is on the same
>>     bus, and CPU and memory are also on that bus, then which is the
>>     system bus?
> 
> Uh? The memory is not on that bus, or even near it. I thought we had 
> just established that.

   If the memory was not on the UNIBUS, then I/O peripherals could not
   do DMA.  There might have been some PDP somewhere that I haven't
   looked at that couldn't do DMA, but all VAXen certainly can.

[toc] | [prev] | [next] | [standalone]

#2685

On 2011-05-04 10:22, Bob Koehler wrote:
> In article<ips1gq$7i2$1@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>  writes:
>> On 2011-05-04 06:32, Bob Koehler wrote:
>>> In article<ipqpfi$qvl$1@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>   writes:
>>>>
>>>> Except then of course it isn't the system bus, but just an I/O bus... :-)
>>>
>>>      If everything except the CPU-memory connection is on the same
>>>      bus, and CPU and memory are also on that bus, then which is the
>>>      system bus?
>>
>> Uh? The memory is not on that bus, or even near it. I thought we had
>> just established that.
>
>     If the memory was not on the UNIBUS, then I/O peripherals could not
>     do DMA.  There might have been some PDP somewhere that I haven't
>     looked at that couldn't do DMA, but all VAXen certainly can.

That's what the Unibus Map is there for. The Unibus map sits between the 
Unibus and the memory, and remaps DMA from the Unibus into the larger 
address space of the memory bus. Same both on the 22-bit capable PDP-11s 
and all VAXen. The exact details of the Unibus map differs between a 
PDP-11 and a VAX, though, but the principles are exactly the same.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[toc] | [prev] | [next] | [standalone]

#2689

In article <ipt5am$d6v$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> That's what the Unibus Map is there for. The Unibus map sits between the 
> Unibus and the memory, and remaps DMA from the Unibus into the larger 
> address space of the memory bus. Same both on the 22-bit capable PDP-11s 
> and all VAXen. The exact details of the Unibus map differs between a 
> PDP-11 and a VAX, though, but the principles are exactly the same.

   Too me, that map is part of the memory subsystem.

[toc] | [prev] | [next] | [standalone]

#2690

On 2011-05-05 07:02, Bob Koehler wrote:
> In article<ipt5am$d6v$3@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>  writes:
>>
>> That's what the Unibus Map is there for. The Unibus map sits between the
>> Unibus and the memory, and remaps DMA from the Unibus into the larger
>> address space of the memory bus. Same both on the 22-bit capable PDP-11s
>> and all VAXen. The exact details of the Unibus map differs between a
>> PDP-11 and a VAX, though, but the principles are exactly the same.
>
>     Too me, that map is part of the memory subsystem.

The Unibus map is the very important piece that maps Unibus addresses to 
memory bus addresses for DMA. As such, is it a part of the memory 
system, or the Unibus? It sits on both...

Either way, it is absolutely necessary in order to have DMA from the 
Unibus work on a machine where the memory does *not* sit on the Unibus.

On lowly PDP-11 models, where the CPU only address 18 bits (or less), 
the memory really sits on the Unibus, and DMA can be performed directly 
there, and memory is responding to Unibus signals. This is (obviously) 
very different from when you have machines with a Unibus map.

Thus, on any VAX, the memory does not sit on the Unibus, and the Unibus 
is only used as an I/O bus. As someone else mentioned, the MicroVAX I is 
the only design where you really only have one bus, the Q-bus in that 
case. The uVAX I therefor is limited to the physical address space of 
the Q-bus (which is 22 bits), and DMA can be performed directly between 
peripherials and memory, which both sits on the same bus.

A short additional note. On PDP-11s the Unibus map is located in 
different places depending on model. For the 11/44 it's in the MMU. The 
11/70 have it along the cache. The 11/84 and 11/94 have the Unibus map 
on the Unibus adapter which is a separate card on those machines.
For all of them, DMA from the Unibus "speaks" (that is, do all the 
Unibus handshaking and signalling) with whatever have the Unibus map. 
And the Unibus map in turn then "speaks" with the actual memory.
When the CPU speaks to memory, the Unibus is totally unaware, and 
remains quiescent.
(For a machine like the 11/70, and VAXen, when devices not on that 
Unibus speaks to memory, the Unibus is also quiescent.)

So no, the memory is *not* on the Unibus. Memory can exist on the 
Unibus, and do so for 18-bit PDP-11 models, and that is obviously very 
different.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[toc] | [prev] | [next] | [standalone]

#2693

On May 5, 9:57 am, Johnny Billquist <b...@softjar.se> wrote:
> On 2011-05-05 07:02, Bob Koehler wrote:
>
> > In article<ipt5am$d6...@Iltempo.Update.UU.SE>, Johnny Billquist<b...@softjar.se>  writes:
>
> >> That's what the Unibus Map is there for. The Unibus map sits between the
> >> Unibus and the memory, and remaps DMA from the Unibus into the larger
> >> address space of the memory bus. Same both on the 22-bit capable PDP-11s
> >> and all VAXen. The exact details of the Unibus map differs between a
> >> PDP-11 and a VAX, though, but the principles are exactly the same.
>
> >     Too me, that map is part of the memory subsystem.
>
> The Unibus map is the very important piece that maps Unibus addresses to
> memory bus addresses for DMA. As such, is it a part of the memory
> system, or the Unibus? It sits on both...
>
> Either way, it is absolutely necessary in order to have DMA from the
> Unibus work on a machine where the memory does *not* sit on the Unibus.
>
> On lowly PDP-11 models, where the CPU only address 18 bits (or less),
> the memory really sits on the Unibus, and DMA can be performed directly
> there, and memory is responding to Unibus signals. This is (obviously)
> very different from when you have machines with a Unibus map.
>
> Thus, on any VAX, the memory does not sit on the Unibus, and the Unibus
> is only used as an I/O bus. As someone else mentioned, the MicroVAX I is
> the only design where you really only have one bus, the Q-bus in that
> case. The uVAX I therefor is limited to the physical address space of
> the Q-bus (which is 22 bits), and DMA can be performed directly between
> peripherials and memory, which both sits on the same bus.
>
> A short additional note. On PDP-11s the Unibus map is located in
> different places depending on model. For the 11/44 it's in the MMU. The
> 11/70 have it along the cache. The 11/84 and 11/94 have the Unibus map
> on the Unibus adapter which is a separate card on those machines.
> For all of them, DMA from the Unibus "speaks" (that is, do all the
> Unibus handshaking and signalling) with whatever have the Unibus map.
> And the Unibus map in turn then "speaks" with the actual memory.
> When the CPU speaks to memory, the Unibus is totally unaware, and
> remains quiescent.
> (For a machine like the 11/70, and VAXen, when devices not on that
> Unibus speaks to memory, the Unibus is also quiescent.)
>
> So no, the memory is *not* on the Unibus. Memory can exist on the
> Unibus, and do so for 18-bit PDP-11 models, and that is obviously very
> different.
>
>         Johnny
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip
> email: b...@softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Yes, that does make sense, and fits what the doc's seem to say.
So my recollection / understanding of what was done to the 730 in
college must be wrong.

For the UDA50 version of the 730, I have to wonder if the UDA50
displaced some of the memory cards in the system box, because the
memory limit went from 5MB for the IDC version down to 3 MB.
Or at least did so in the factory version, but I can't tell if the
UDA50 could go in the expansion box (H9642-DH)


Thanks!
Sean

[toc] | [prev] | [next] | [standalone]

#2695

On 2011-05-06 07.54, SeanOBanion wrote:
> On May 5, 9:57 am, Johnny Billquist<b...@softjar.se>  wrote:
>> On 2011-05-05 07:02, Bob Koehler wrote:
>>
>>> In article<ipt5am$d6...@Iltempo.Update.UU.SE>, Johnny Billquist<b...@softjar.se>    writes:
>>
>>>> That's what the Unibus Map is there for. The Unibus map sits between the
>>>> Unibus and the memory, and remaps DMA from the Unibus into the larger
>>>> address space of the memory bus. Same both on the 22-bit capable PDP-11s
>>>> and all VAXen. The exact details of the Unibus map differs between a
>>>> PDP-11 and a VAX, though, but the principles are exactly the same.
>>
>>>      Too me, that map is part of the memory subsystem.
>>
>> The Unibus map is the very important piece that maps Unibus addresses to
>> memory bus addresses for DMA. As such, is it a part of the memory
>> system, or the Unibus? It sits on both...
>>
>> Either way, it is absolutely necessary in order to have DMA from the
>> Unibus work on a machine where the memory does *not* sit on the Unibus.
>>
>> On lowly PDP-11 models, where the CPU only address 18 bits (or less),
>> the memory really sits on the Unibus, and DMA can be performed directly
>> there, and memory is responding to Unibus signals. This is (obviously)
>> very different from when you have machines with a Unibus map.
>>
>> Thus, on any VAX, the memory does not sit on the Unibus, and the Unibus
>> is only used as an I/O bus. As someone else mentioned, the MicroVAX I is
>> the only design where you really only have one bus, the Q-bus in that
>> case. The uVAX I therefor is limited to the physical address space of
>> the Q-bus (which is 22 bits), and DMA can be performed directly between
>> peripherials and memory, which both sits on the same bus.
>>
>> A short additional note. On PDP-11s the Unibus map is located in
>> different places depending on model. For the 11/44 it's in the MMU. The
>> 11/70 have it along the cache. The 11/84 and 11/94 have the Unibus map
>> on the Unibus adapter which is a separate card on those machines.
>> For all of them, DMA from the Unibus "speaks" (that is, do all the
>> Unibus handshaking and signalling) with whatever have the Unibus map.
>> And the Unibus map in turn then "speaks" with the actual memory.
>> When the CPU speaks to memory, the Unibus is totally unaware, and
>> remains quiescent.
>> (For a machine like the 11/70, and VAXen, when devices not on that
>> Unibus speaks to memory, the Unibus is also quiescent.)
>>
>> So no, the memory is *not* on the Unibus. Memory can exist on the
>> Unibus, and do so for 18-bit PDP-11 models, and that is obviously very
>> different.
>>
>>          Johnny
>>
>> --
>> Johnny Billquist                  || "I'm on a bus
>>                                     ||  on a psychedelic trip
>> email: b...@softjar.se             ||  Reading murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>
> Yes, that does make sense, and fits what the doc's seem to say.
> So my recollection / understanding of what was done to the 730 in
> college must be wrong.
>
> For the UDA50 version of the 730, I have to wonder if the UDA50
> displaced some of the memory cards in the system box, because the
> memory limit went from 5MB for the IDC version down to 3 MB.
> Or at least did so in the factory version, but I can't tell if the
> UDA50 could go in the expansion box (H9642-DH)

The UDA50 should definitely be possible to place in the expansion box. 
Looking at the slot assignments in the CPU box, it would appear that 
only the last memory slot could be used by some Unibus cards instead, so 
I'm not sure why the memory limit would go down from 5MB to 3MB, since 
5MB seems to imply 5 1MB cards, and thus two cards would be removed.

However, I do know that the UDA50 draws a lot of power, and there might 
be power limitations that caused the restrictions on memory in this case.

Obviously, having the UDA50 in an expansion box would remove the power 
limitation reason as well.

	Johnny

[toc] | [prev] | [next] | [standalone]

#2691

On 2011-05-05 07:02, Bob Koehler wrote:
> In article<ipt5am$d6v$3@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>  writes:
>>
>> That's what the Unibus Map is there for. The Unibus map sits between the
>> Unibus and the memory, and remaps DMA from the Unibus into the larger
>> address space of the memory bus. Same both on the 22-bit capable PDP-11s
>> and all VAXen. The exact details of the Unibus map differs between a
>> PDP-11 and a VAX, though, but the principles are exactly the same.
>
>     Too me, that map is part of the memory subsystem.

By the way, an important point contradicting this view. When the CPU 
access memory, the Unibus map is not involved. If the Unibus map was 
part of the memory subsystem, the CPU would have no way of avoiding it, 
so it don't really make sense to look at the UBA as a part of the memory 
subsystem. (On a PDP-11/70, when massbus do DMA, the Unibus map is also 
not involved, it is only involved in DMA from the Unibus. The same is 
true for all VAXen.)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[toc] | [prev] | [next] | [standalone]

#2694

In article <ipul5a$p7$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> On 2011-05-05 07:02, Bob Koehler wrote:

>>     Too me, that map is part of the memory subsystem.
> 
> By the way, an important point contradicting this view.

   So we disagree.  Time to stop splitting hairs.

[toc] | [prev] | [next] | [standalone]

#2696

On 2011-05-06 09.54, Bob Koehler wrote:
> In article<ipul5a$p7$2@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>  writes:
>> On 2011-05-05 07:02, Bob Koehler wrote:
>
>>>      Too me, that map is part of the memory subsystem.
>>
>> By the way, an important point contradicting this view.
>
>     So we disagree.  Time to stop splitting hairs.

You mean that you think that the Unibus map is a part of the memory 
subsystem, even though none would exist if you don't have a Unibus?

Or do you disagree that the Unibus map is not involved in memory access 
from other sources than the Unibus?

This is not splitting hairs. The Unibus map, it's location and function, 
are rather big and important details.

	Johnny

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.vms

csiph-web