Re: Dumping Images of my VAX-11/730's Drives?

[Mark J. Blair]

> On Mar 8, 2016, at 15:21, Peter Coghlan  wrote:
> 
> If you get TCP/IP networking like Multinet (ie not like CMUIP) running, you
> should be able to use FTP, rcp or maybe even TFTP to move a VMS BACKUP saveset
> to another system.  The snag is you need enough scratch space to create the
> saveset on the 11/730 before you transfer it.

Well, there's the problem: I don't have scratch space, since all of the hard 
drives are precisely what I want to image.

> C-Kermit for VMS might be able to do this - I can't recall.

Getting it onto the machine in the first place might be a challenge!

> 
> If you mount /foreign your non-system disk, it should be accessible at a 
> logical
> block level instead of at a file level.  VMS BACKUP won't like this but COPY
> should just copy logical blocks from the foreign mounted device.  This 
> probably
> isn't very useful to you but rcp or FTP PUT might also similarly cope with a
> foreign mounted devices and this may be another way of generating a raw dump
> of the device, provided there are no errors on it.  (There may be issues
> detecting the size of the device and the operation may end with an error when
> no more blocks can be read.  If whatever software you use doesn't try to
> discard it's output on encountering an error, all should be well.)  However,
> you can't mount your system disk /foreign.

I can boot either 7.3 from the R80 fixed drive, or 5.2 from an RL02 pack. So in 
theory, I should be able to boot from each of them to image the other. There 
might be TCP/IP support on the 7.3 installation, but I doubt there's any TCP/IP 
support on the 5.2. I hope that the DECNET support is there on both 
installations for the ethernet card.

I set up a VM on my Mac running Ubuntu with DECNET support installed. Despite 
being orphaned several years ago, it still seems to run. So I think that trying 
to bring up DECNET on the VAX might give me options. I was thinking that if 
nothing else, if I can log into the VAX remotely via DECNET and log the 
terminal output, then maybe I could just DUMP a foreign-mounted volume and then 
write some throw-away program to transmogrify the hex dump into a block-level 
image. It would be slow, but I hope it would at least be quite a bit faster 
than dumping over an async serial port.

If I can write a file from the VAX to that Ubuntu VM via DECNET, then maybe I 
can just COPY a foreign-mounted volume to a file on the VM. I don't know what 
capabilities the Linux DECNET support gives me yet, but if I can do this then 
that should be a good option. I wonder if I can image tapes that way, too?

> 
> Another way would be to write some code (VAX MACRO assembly / C / FORTRAN /
> BASIC or whatever compiler you have to use VMS system services like SYS$ASSIGN
> and SYS$QIO to read logical blocks from the disks and do something sensible
> when errors are encountered.  This might involve a steep learning curve and 
> the
> results will probably not be as well optimised to the task as VMS BACKUP.  It
> should be possible to find some sample code to do something like this.

I hope I don't have to go to that much effort, particularly since I don't know 
if there are any language compilers/assemblers on the system, and I want to 
image the drives before I monkey around with the system much.

> Clustering is pretty simple when you know how but if you don't want to get 
> into
> configuring a cluster, a DECnet connected system or emulated system would
> probably be the way to go.  Configuring DECnet on VMS can be done very easily
> with surprisingly little understanding of what is going on and is less 
> invasive
> than configuring a cluster.

You had me at "surprisingly little understanding of what is going on"! This 
sounds like the thing for me to try next.


> On VMS, any file, including a BACKUP saveset can be specified as being located
> on a remote DECnet node, so it is possible to run BACKUP on your 11/730 and 
> have
> the output saveset situated on a different VAX / Alpha / Itanium / emulated
> system running VMS or on a unix or other system capable of running DECnet 
> well,
> (ultrix?), even a PC/Macintosh running DOS/Windows/Macos and DEC Pathworks.

That sounds very promising!


> If your 11/730 is already configured to be a cluster member (if it says
> something like "Waiting to form or join a VAXcluster" on the console at boot
> time and then pauses for while before continuing) then you probably don't have
> to do anything further to it to make it function as part of a cluster.  The
> only experimentation required would be on the additional cluster member, which
> could be an emulated system using simh for example if you don't have any other
> suitable hardware available.  Once you are clustered, you can access disks on
> a remote cluster node as if they were local.  Clustering with an emulated
> system would be especially suitable for producing raw block copies of the
> disks on the 11/730 on the filesystem of 

Re: VMS 4.4 source code microfiche

[Rob Doyle]

On 3/8/2016 1:35 PM, devin davison wrote:


I purchased a DEC VMS 4.4 source code microfiche set a while back. A
buddy of mine works at a local library where there is a fancy
microfiche scanner, I'm planning to scan it all. Some of the film is
scratched pretty bad, does anyone else around here have this set, so
that i can recover the full page set?

--Devin


I have the DEC VMS 4.1 source code microfiche set with no way to scan
it. It looks to be in very good condition. How good of a friend is he?

Rob.

Re: Dumping Images of my VAX-11/730's Drives?

[Peter Coghlan]

>
> I want to get raw images of the system's drives off the machine and onto my
> modern systems. I can think of several approaches, and still more approaches
> have already been suggested in that VCF thread. I have a number of questions,
> and I'm also keeping my eyes open for hardware that might help me out. I'm not
> presently talking to eBay, so that limits my options.
>
> First of all, if I manage to get TCP/IP networking up and running today, is
> there some way under VMS for me to dump raw disk blocks over the network to
> one of my UNIX-like systems? Alternately, if I manage to cobble together a
> Linux box running an older DECNET-aware distribution and bring up DECNET on
> the VAX, would that give me a way to dump raw disk blocks to a file on it
> across the network? I'm still quite clumsy under VMS. One of these
> network-based approaches seem like the only options that I would have any
> chance of achieving today, assuming that the networking hardware on my 11/730
> is even in working order.
>

Savesets produced using VMS BACKUP are the ideal way to archive your VMS system.
They will save everything you need in a format which can be restored onto any
disk big enough to hold the data, selectively if necessary, while dealing with
any errors on the input or output media.  BACKUP can be run standalone or under
VMS.

If you get TCP/IP networking like Multinet (ie not like CMUIP) running, you
should be able to use FTP, rcp or maybe even TFTP to move a VMS BACKUP saveset
to another system.  The snag is you need enough scratch space to create the
saveset on the 11/730 before you transfer it.

>
> I don't think I have the patience to dump an R80 drive across an async serial
> port, but if I did have the patience, is there some way to accomplish this
> under a stock VMS 5.2/7.3 installation? Ditto for the RL02 and 9-track tapes.
>

C-Kermit for VMS might be able to do this - I can't recall.

If you mount /foreign your non-system disk, it should be accessible at a logical
block level instead of at a file level.  VMS BACKUP won't like this but COPY
should just copy logical blocks from the foreign mounted device.  This probably
isn't very useful to you but rcp or FTP PUT might also similarly cope with a
foreign mounted devices and this may be another way of generating a raw dump
of the device, provided there are no errors on it.  (There may be issues
detecting the size of the device and the operation may end with an error when
no more blocks can be read.  If whatever software you use doesn't try to
discard it's output on encountering an error, all should be well.)  However,
you can't mount your system disk /foreign.

Another way would be to write some code (VAX MACRO assembly / C / FORTRAN /
BASIC or whatever compiler you have to use VMS system services like SYS$ASSIGN
and SYS$QIO to read logical blocks from the disks and do something sensible
when errors are encountered.  This might involve a steep learning curve and the
results will probably not be as well optimised to the task as VMS BACKUP.  It
should be possible to find some sample code to do something like this.

>
> * It was suggested that I might be able to cluster the 11/730 with a MicroVAX,
> and then transfer data onto some SCSI device on the MicroVAX such as a
> SCSI2SD.  I think I'd need to find a fairly turnkey MicroVAX, though, to
> avoid a bring-up problem that's even bigger than the data transfer problem
> I'm trying to solve.
>

Clustering is pretty simple when you know how but if you don't want to get into
configuring a cluster, a DECnet connected system or emulated system would
probably be the way to go.  Configuring DECnet on VMS can be done very easily
with surprisingly little understanding of what is going on and is less invasive
than configuring a cluster.

On VMS, any file, including a BACKUP saveset can be specified as being located
on a remote DECnet node, so it is possible to run BACKUP on your 11/730 and have
the output saveset situated on a different VAX / Alpha / Itanium / emulated
system running VMS or on a unix or other system capable of running DECnet well,
(ultrix?), even a PC/Macintosh running DOS/Windows/Macos and DEC Pathworks.

If your 11/730 is already configured to be a cluster member (if it says
something like "Waiting to form or join a VAXcluster" on the console at boot
time and then pauses for while before continuing) then you probably don't have
to do anything further to it to make it function as part of a cluster.  The
only experimentation required would be on the additional cluster member, which
could be an emulated system using simh for example if you don't have any other
suitable hardware available.  Once you are clustered, you can access disks on
a remote cluster node as if they were local.  Clustering with an emulated
system would be especially suitable for producing raw block copies of the
disks on the 11/730 on the filesystem of the system hosting the emulation.

Regards,
Peter Coghlan.

Re: tops20 assembly tutorials

[David Bridgham]

On 03/08/2016 05:47 PM, Phil Budne wrote:
> CIRC is an MIT/ITS instruction; ISTR a flavor of "rotate"

It's a double-word rotate like ROTC except the two registers rotate in
opposite directions.  The instruction

CIRC  AC, 36.

will swap AC and AC+1 and reverse both of their bit orders.

Re: tops20 assembly tutorials

[Phil Budne]

CIRC is an MIT/ITS instruction; ISTR a flavor of "rotate"

p

Re: MEM11A questions

[Guy Sotomayor]

> On Mar 8, 2016, at 12:44 PM, Mike Ross  wrote:
> 
>> 
>> No, it will only have 128KW.  Since it’s a single FRAM part, I’m not going to
>> try and “stock” different flavors (especially since I’ll be having the boards
>> assembled at the board house).
> 
> But you will do something to allow memory to be switched in and out? I
> presume this thing wouldn't work in an 11/20 unless it was strapped
> back to 32KW? Or will the 11/20 be happy and simply ignore the
> unaddressable memory beyond 32KW?
> 
It will have 2 sets of configuration switches.  One is the starting address
(on a 4KB boundary).  The other is the number of 4KB blocks that the
board will respond to.

I may have a couple of other options like the speed at which it can
respond (the FRAMs have a 35 ns access time) and the size of the
IO hole.

I wrote the Verilog for the CPLD last night and as I finished it, I thought of
a few other options that might be useful.  I’ll look it at some more once I’ve
done the simulation.

TTFN - Guy

Re: MEM11A questions

[Paul Koning]

> On Mar 8, 2016, at 3:44 PM, Mike Ross  wrote:
> 
>>> ...
>> 
>> No, it will only have 128KW.  Since it’s a single FRAM part, I’m not going to
>> try and “stock” different flavors (especially since I’ll be having the boards
>> assembled at the board house).
> 
> But you will do something to allow memory to be switched in and out? I
> presume this thing wouldn't work in an 11/20 unless it was strapped
> back to 32KW? Or will the 11/20 be happy and simply ignore the
> unaddressable memory beyond 32KW?

The Unibus has 18 address lines.  This should work so long as the memory 
doens't respond to I/O page addresses (the top 4kW of the address space).  
That's a requirement for any Unibus memory on any PDP11.  The difference 
between 11/20 and 11/05 vs. the others is that the lack of MMU means that the 
CPU can't generate addresses in the range 28 to 124 kW.  (I/O devices can, 
though, which would be rather interesting.)

paul

Re: MEM11A questions

[Mike Ross]

On Wed, Mar 9, 2016 at 8:15 AM, Guy Sotomayor  wrote:
>
>> On Mar 8, 2016, at 11:12 AM, Henk Gooijen  wrote:
>>
>> -Oorspronkelijk bericht- From: Guy Sotomayor
>> Sent: Tuesday, March 08, 2016 7:17 PM
>> To: General Discussion: On-Topic and Off-Topic Posts
>> Subject: Re: MEM11A questions
>>
>>
>>> On Mar 8, 2016, at 10:11 AM, Henk Gooijen  wrote:
>>> Guy,
>>> I have one 11/20. CPU state unknown ... but the card cage only has the CPU.
>>> So I would be glad to get some memory.   Plenty of space left for other
>>> interfaces, so the MEM11 would be sufficient for me. 128 KW is probably
>>> overkill. The 11/20 can only address up to 64 KW, correct?
>>> Depending cost, I am seriously interested in one MEM11.
>>
>> The 11/20 can address only 32KW (64KB).  You need an MMU to access
>> more.
>>
>> TTFN - Guy
>> -
>> Ah yes, of course Guy!  The 32 kW vs. 64 kB error. I'll never learn ;-)
>> The 11/20 did never have an MMU (AFAIK).
>> Will the MEM11 come in "flavors" regarding the installed amount of FRAM?
>> (32/64/128KW)
>>
>
> No, it will only have 128KW.  Since it’s a single FRAM part, I’m not going to
> try and “stock” different flavors (especially since I’ll be having the boards
> assembled at the board house).

But you will do something to allow memory to be switched in and out? I
presume this thing wouldn't work in an 11/20 unless it was strapped
back to 32KW? Or will the 11/20 be happy and simply ignore the
unaddressable memory beyond 32KW?

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

VMS 4.4 source code microfiche

[devin davison]

I purchased a DEC VMS 4.4 source code microfiche set a while back. A buddy
of mine works at a local library where there is a fancy microfiche scanner,
I'm planning to scan it all. Some of the film is scratched pretty bad, does
anyone else around here have this set, so that i can recover the full page
set?

--Devin

Re: MEM11A questions

[Henk Gooijen]

-Oorspronkelijk bericht- 
From: Guy Sotomayor

Sent: Tuesday, March 08, 2016 7:17 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: MEM11A questions


On Mar 8, 2016, at 10:11 AM, Henk Gooijen  
wrote:

Guy,
I have one 11/20. CPU state unknown ... but the card cage only has the 
CPU.

So I would be glad to get some memory.   Plenty of space left for other
interfaces, so the MEM11 would be sufficient for me. 128 KW is probably
overkill. The 11/20 can only address up to 64 KW, correct?
Depending cost, I am seriously interested in one MEM11.


The 11/20 can address only 32KW (64KB).  You need an MMU to access
more.

TTFN - Guy
-
Ah yes, of course Guy!  The 32 kW vs. 64 kB error. I'll never learn ;-)
The 11/20 did never have an MMU (AFAIK).
Will the MEM11 come in "flavors" regarding the installed amount of FRAM?
(32/64/128KW)

- Henk

RE: tops20 assembly tutorials

[Rich Alderson]

From: David Griffith
Sent: Monday, March 07, 2016 11:53 PM

> Specifically I'm trying to build and run this:

>  TITLE HACK
>  SEARCH MONSYM
> 
> HACK:   SKIPA 4,[^D4]
> HACK0:   SOJL 4,TRAILL
>  SETZB 1,3
> HACK1:  TLNE 1,77
>   JRST HACK0
>  MOVE 2,1
>  CIRC 2,-^D18
   
...

>  END HACK

> When I do COMPILE, LOAD, and SAVE on it and run the executable, I get this:

> $hack
> ?Illegal instruction 247100,,56 at HACK1+3
> ?Undefined operation code

As well you should.  There is no CIRC in the standard PDP-10 instruction set.
Opcode 247 is unassigned, so if someone defined CIRC locally (say, in an OPDEF,
although I don't see one here), the result you report would be precisely what
I would expect.

Where did this code come from?  From the presence of the LITES% JSYS I infer
that it has something to do with Bob Armstrong's panel.  Perhaps you should
direct a query in his direction?  SpareTimeGizmos.com, and all that.

Rich


Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: MEM11A questions

[Guy Sotomayor]

> On Mar 8, 2016, at 10:39 AM, Jay West  wrote:
> 
> 
> Guy wrote...
> --
> The 11/20 can address only 32KW (64KB).  You need an MMU to access more.
> --
> So MEM11 doesn't have a MMU "on board" then, got it.

The MMU is a CPU function.

> 
> Just curious... I seem to recall you were having trouble fitting all the 
> desired functionality on the UMF11, probably taking it out of the SPC form 
> factor (or something similar).
> Would moving forward with your MEM11 as "the" memory option and then removing 
> memory from the UMF deliverables - free up the silicon to solve the earlier 
> size issue?
> 
It doesn’t help.  On the UMF11, I use a 256K x 16 FRAM for “memory”.  Since the 
Unibus only can
only access 128K x 16, I’m using the other “half” of the memory for other stuff 
(J1 uCode images,
configuration settings, Boot ROM images, Console emulator ROM image, etc, etc). 
 So it really doesn’t
save anything if I removed that functionality (the footprint of the 256K x 16 
FRAM is the same as
the 128K x 16 FRAM).

There’s a lot of random crap that I have to deal with (5v to 3.3v translators) 
power supplies (3.3v,
2.5v, 1.8v), connectors for the SLUs, etc.

However, what I’m most worried about is power.  According to DEC specs, an SPC 
board can only
draw 4 amps off the 5v supply.  I’m not sure what the current draw will be.  
I’ll know more once I
build the prototype and can actually measure it.

TTFN - Guy

RE: MEM11A questions

[Jay West]

Guy wrote...
--
The 11/20 can address only 32KW (64KB).  You need an MMU to access more.
--
So MEM11 doesn't have a MMU "on board" then, got it.

Just curious... I seem to recall you were having trouble fitting all the 
desired functionality on the UMF11, probably taking it out of the SPC form 
factor (or something similar).
Would moving forward with your MEM11 as "the" memory option and then removing 
memory from the UMF deliverables - free up the silicon to solve the earlier 
size issue?

J

Re: MEM11A questions

[Guy Sotomayor]

> On Mar 8, 2016, at 10:11 AM, Henk Gooijen  wrote:
> 
> -Oorspronkelijk bericht- From: Guy Sotomayor
> Sent: Monday, March 07, 2016 8:16 PM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: MEM11A questions
> 
> Hi,
> 
> Over the weekend I was looking through some old CAD files and came across my
> original design for the MEM11A.  It was an SPC board that contained only 128KW
> of FRAM.
> 
> I’m wondering if there’s any interest in that board.  I do have to iterate on 
> the design
> a bit but I should be able to get something ready sooner than with my current 
> board
> design (plus I know it will fit in an SPC form factor because I’ve already 
> done it).
> 
> What I’d like to know from folks is if there’s interest in that design? Would 
> there still
> be interest in what I’m now calling UMF11 (Unibus Multi-Function)?
> 
> I won’t have pricing (on either) until I build (and debug) a couple of 
> prototypes because
> I need to know what the assembly costs would be (no I won’t be offering kits).
> 
> To also answer the other question, no I haven’t run into any issues with the 
> UMF11,
> I just came across this long forgotten design and wanted to know if there’s 
> any
> interest in it as I can probably get it into “production” sooner than the 
> UMF11.
> 
> Thanks.
> 
> TTFN - Guy
> 
> -
> Guy,
> I have one 11/20. CPU state unknown ... but the card cage only has the CPU.
> So I would be glad to get some memory.   Plenty of space left for other
> interfaces, so the MEM11 would be sufficient for me. 128 KW is probably
> overkill. The 11/20 can only address up to 64 KW, correct?
> Depending cost, I am seriously interested in one MEM11.

The 11/20 can address only 32KW (64KB).  You need an MMU to access
more.

TTFN - Guy

Re: Release of the HP 3000 Series III simulator

[COURYHOUSE]

I will have to  try this...
a  great undertaking Dave!
Ed#   _www.smecc.org_ (http://www.smecc.org)  
 
 
In a message dated 3/8/2016 6:29:11 A.M. US Mountain Standard Time,  
jw...@classiccmp.org writes:

Awesome  Dave! Can't wait to test drive it. A very sincere Thank You for all
the  time & effort you've spent on  that.

Best,

J

Re: MEM11A questions

[Henk Gooijen]

-Oorspronkelijk bericht- 
From: Guy Sotomayor

Sent: Monday, March 07, 2016 8:16 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: MEM11A questions

Hi,

Over the weekend I was looking through some old CAD files and came across my
original design for the MEM11A.  It was an SPC board that contained only 
128KW

of FRAM.

I’m wondering if there’s any interest in that board.  I do have to iterate 
on the design
a bit but I should be able to get something ready sooner than with my 
current board
design (plus I know it will fit in an SPC form factor because I’ve already 
done it).


What I’d like to know from folks is if there’s interest in that design? 
Would there still

be interest in what I’m now calling UMF11 (Unibus Multi-Function)?

I won’t have pricing (on either) until I build (and debug) a couple of 
prototypes because
I need to know what the assembly costs would be (no I won’t be offering 
kits).


To also answer the other question, no I haven’t run into any issues with the 
UMF11,
I just came across this long forgotten design and wanted to know if there’s 
any
interest in it as I can probably get it into “production” sooner than the 
UMF11.


Thanks.

TTFN - Guy

-
Guy,
I have one 11/20. CPU state unknown ... but the card cage only has the CPU.
So I would be glad to get some memory.   Plenty of space left for other
interfaces, so the MEM11 would be sufficient for me. 128 KW is probably
overkill. The 11/20 can only address up to 64 KW, correct?
Depending cost, I am seriously interested in one MEM11.

Thanks,
- Henk 

RE: Release of the HP 3000 Series III simulator

[Jay West]

Awesome Dave! Can't wait to test drive it. A very sincere Thank You for all
the time & effort you've spent on that.

Best,

J

BA23 Box with RLV11 (Was: 11/23+ box with Microvax Memory)

[Jerome H. Fine]

>jwsmobile wrote:

I see on the usual site, an 11/23 box with a couple of random boards, 
one of which is an M7608 board.  This is a Microvax memory board.


I wonder if one can build up a Microvax in that backplane, or if that 
is not recommended.  It would obviously be an 18 bit backplane.  The 
backplane is H9276A.


The auction also has a M9047 Bus grant card in it, so is essentially 
just the box.  But I'd never seen Microvax parts plugged into those 
backplanes, and it made me think.


thanks
Jim


Probably not as unexpected, but just as unusual in my mind:

I once saw a BA23 box with an M8190-AB (PDP-11/73) CPU
in slot 1 followed by an RLV11 (M8013 / M8014) in slots 2 / 3
connected to an RL02 drive.  Usually, by the time a system
had a PDP-11/73 board, a couple of MB of memory and an
RL02 drive, the RL02 controller was upgraded to an RLV12
(M8061) board.  NOTE that slots 2 / 3 had to be used for
the RLV11 since they were the only 2 slots left with ABCD.
Placing the RLV11 in any other position in a BA23 box lets
out the magic smoke.

As a bit of additional information, the other 5 slots were used
to hold the memory and other modules that were required.  There
did not seem to be any problem with the memory being placed
in slot 4.

Jerome Fine