Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

which OS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Interesting. I usually find the CMD controllers to be the most common ones...

    If you would have SCSI on another machine, that would be a very easy way to get a disk setup for running on the real machine.
    Otherwise, I guess tools to send the system over the console port will work, but will take time.
    Once you have the first system up, and over, life will be much easier.

    Comment


      #17
      One advantage of the /TM version of the CMD controllers is that they can do both MSCP and TMSCP at the same time with a single controller, while the Emulex UC07 can be configured for one or the other, but not both at the same time. The Emulex UC08 can do both at the same time, as from the hardware point of view it is essentially two completely separate controllers on the same board.

      With a SCSI hard drive and SCSI hard drive attached to the same CMD /TM controller I have installed RSTS/E 10.1 and 2.11BSD from tape to the hard drive several times in the past. It is somewhat of an interesting experience to do it on real hardware a few times. After that gets old, it is much quicker to do the installation on SIMH, and then 'dd' the hard drive image created with SIMH to the physical SCSI hard drive to use with the physical system. Just take some care that the geometry of the hard drive image created with SIMH matches the geometry of the physical SCSI hard drive as configured by physical SCSI controller.

      Comment


        #18
        I could definitely see the benefit of the CMD controllers, and as a result I guess the CQD-220A/TM is probably the most desirable. But as a practical matter, I don’t think I’d ever use a tape drive…

        Comment


          #19
          Originally posted by MattCarp View Post
          I could definitely see the benefit of the CMD controllers, and as a result I guess the CQD-220A/TM is probably the most desirable. But as a practical matter, I don’t think I’d ever use a tape drive…
          I have a DDS3 hooked up to my machine, and are running weekly backups... Well, actually I have a TK70, an Exabyte and the DDS3.
          Always good to be able to read things, if needed. Also means I can do an installation from a tape distribution, if I were to mess things really up. I do have distributions written to DDS3 tapes.

          Comment


            #20
            Originally posted by bqt View Post
            Ah! Now I see it. The -JB and -JC are PMI *only*, while the -JD and -JE are PMI and/or Qbus.
            Basically, more J11-era buggy DEC silicon. Although I recall the bug being described as the earlier boards would only work in the 11/84. That may have been because the Q-side of the 11/84 didn't support Q-bus peripheral controllers, only the CPU and memory.

            Comment


              #21
              Originally posted by gslick View Post
              Just take some care that the geometry of the hard drive image created with SIMH matches the geometry of the physical SCSI hard drive as configured by physical SCSI controller.
              I suppose the safest / most certain way to do this would be to hook the drive up to the UC07, let it autoconfigure to get the drive geometry, then display the drive geometry and use that to set up a disk file for simh.

              I am going to plug in a Seagate ST15230N. It uses zone bit recording, so the number of sectors per track varies. The average is 110. It has 19 read/write heads, and, 3992 "tracks/surface" (which I take as cylinders). 110 sectors / track * 19 heads * 3992 cylinders = 8,343,280 sectors 8,343,280 sectors *. 512 bytes/sector = 4,271,759,360 bytes.

              Reading this thread, the simh disk setup is:

              # dd bs=512 count=8343280 < /dev/zero > st15230.dsk

              Then I run simh, attach the disk, install RSX (or whatever). When done, I just dd the file to the physical drive:

              # dd bs=512 if=st15230.dsk of=/dev/sdb

              (of course, triple checking that the physical disk I'm going to write is /dev/sdb or whatever)



              Comment


                #22
                Originally posted by MattCarp View Post

                I suppose the safest / most certain way to do this would be to hook the drive up to the UC07, let it autoconfigure to get the drive geometry, then display the drive geometry and use that to set up a disk file for simh.

                I am going to plug in a Seagate ST15230N. It uses zone bit recording, so the number of sectors per track varies. The average is 110. It has 19 read/write heads, and, 3992 "tracks/surface" (which I take as cylinders). 110 sectors / track * 19 heads * 3992 cylinders = 8,343,280 sectors 8,343,280 sectors *. 512 bytes/sector = 4,271,759,360 bytes.

                Reading this thread, the simh disk setup is:

                # dd bs=512 count=8343280 < /dev/zero > st15230.dsk

                Then I run simh, attach the disk, install RSX (or whatever). When done, I just dd the file to the physical drive:

                # dd bs=512 if=st15230.dsk of=/dev/sdb

                (of course, triple checking that the physical disk I'm going to write is /dev/sdb or whatever)


                I use the UC07 and ST15230N as my standard kit for Q-Bus systems. I swap between physical and SIMH disk images without geometry concerns. Booting the F.R.D. use this drive as a type 4 drive. The UC07 reliably reads this drives geometry. I've never had to manually set it. You then can set a few options like bad block replacement and spin up control.

                Jerry

                Comment


                  #23
                  Thanks Jerry! Exactly what I’m going to do! So, how big is your simh disk file, or, do you create it first from the physical disk (dd)?

                  also, since it’s not a dec standard disk, how do you declare the disk (attach it) in simh, since the simh first has you declare a type, then attach:


                  SET RP ENABLE
                  SET RP0 RP06
                  ATTACH RP0 RP06.000
                  SET RP1 RP06
                  ATTACH RP1 RP06.001

                  Comment


                    #24
                    Originally posted by MattCarp View Post
                    Thanks Jerry! Exactly what I’m going to do! So, how big is your simh disk file, or, do you create it first from the physical disk (dd)?

                    also, since it’s not a dec standard disk, how do you declare the disk (attach it) in simh, since the simh first has you declare a type, then attach:


                    SET RP ENABLE
                    SET RP0 RP06
                    ATTACH RP0 RP06.000
                    SET RP1 RP06
                    ATTACH RP1 RP06.001
                    The beauty of MSCP and using SCSI disks is that at the OS level (in general) they present the media as a set of logically addressable blocks 0-> N. You just want to match the physical size with that used in SIMH when swapping images between them. Use the RQ device with autosize enabled. Look over the SIMH documentation for "attach", as it explains options for things like read-only or creating a new file. You have a grasp on the data transfer process already.

                    Under RT-11 and VMS you can create non-standard sizse by using a SCSI2SD and a microSD card.

                    I don't do much RSX or RSTS, so you need to explore that yourself or with the help of others.


                    Comment


                      #25
                      First of all, as suggested, use MSCP. The disk under the UC07 is an MSCP disk, and you should do the same for the simh.
                      With simh, you can use RAUSER=n to tell an arbitrary size of the disk, so just give the same size as the UC07 (or your Linux system) reports.
                      Or even better, just hook the SCSI drive to you Linux box, and directly use it under simh, without going through an intermediate disk image (I believe simh can do this, E11 definitely can).

                      And MSCP, like SCSI, do not have the more traditional view of geometry, so avoid involving that unless some tool really insist. Finally, bad blocks as such are outside the scope of visible blocks, both in MSCP and SCSI, so don't try to do something related to that.

                      In RSX, MSCP disks are always using the size they report from the controller. Nothing special at all. VMS is the same. You don't create anything. The disk is the size it is. When you create a file system on it, the file system will hold all the blocks the disk reports it has. Also, RSX can't real with disks larger than 8G. If you have a larger disk, RSX will truncate it to 8G. So anything above is just ignored.

                      Comment

                      Working...
                      X