On Feb 10, 17:23, Jay Jaeger wrote:
> Rats. So it would seem. Forgot about that angle. Useful program --
just
> not for floppies.
>
> Oh well.
>
> (Hmm. I wonder how "bzzzzt"s taste when you have to eat them with your
> hat?) I suspect that they kind of tingle, eh?
As far as I remember, yes. I've tried it a few times myself :-)
--
Pete Peter Turnbull
Network Manager
University of York
On Feb 8, 8:31, Bill Gunshannon wrote:
> RX50's came pre-formatted from DEC. There was never a way to
> format them on PDP's or VAX as far as I knew. I do think it is
> possible to create them using PUTR and an old PC with a proper
> floppy controller and a 1.2M floppy drive configured the right
> way.
You can format them on a Rainbow, but not an -11 or VAX.
> My understanding is they are 80 track, 96 tpi format but spin
> at the slow spead of normal 5.25 disks and not the higher speed
> used by IBM HD disks.
Very similar low-level format to IBM floppies, except that, as Bill says,
they're 80-track. The spec is 80-track, 96 tpi, single-side, double
density (not HD), 10 sectors per track, 512 bytes/sector. DEC squeeze the
extra sector in by shortening some of the gaps; even so the timing is a
little tight and the drive speed has to be better-than-averagely accurate.
It doesn't matter whether you write them at 300 rpm or 360, so long as the
controller adjusts its data rate accordingly (250kbps or 300kbps). Which
is what a PC does (uses 250kbps for 300rpm and 300kbps for 360 rpm).
However, many HD-capable drives use pin 2 on the interface not only to
change the speed but change the write current. Some such drives have
jumpers to set the correct values.
> As a curious note, I actually had (and may still have in the
> attic somewhere) a real shugart 80 track 5.25 drive that would
> have been the equivalent of an RX50, so it was not only DEC who
> used that format. I had them on a TRS-80 and NewDOS-80 and
> DOSPlus had no problems formatting and using the drive. This
> was long before my first PDP, but I now wonder if they would
> have been able to read and write (and maybe even format!) RX50's.
If the controller it was attached to can write MFM (double-density), then
it would work. Drives of that type were very common before PCs took over.
In fact you can fudge one to look like half of an RX50 (a real RX50 plays
funny tricks with the SideSelect and Track00 signals, and some DEC
controllers use that to recognise an RX50).
--
Pete Peter Turnbull
Network Manager
University of York
On Feb 9, 8:37, Jay Jaeger wrote:
> Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11
> FORMTR RX50 . This is a formatter program for a Micro PDP-11.
>
> It is a *diagnostic* program (not a user program) for formatting these
> beasties. Mine is for the -11, I would imagine that there is one for the
> MicroVAX as well.
Jay, I just checked on that. It's not an RX50 formatter, it's the XXDP V2
formatting and diagnostics routines for an RXDX3. IIRC it will format RD5x
hard drives, and RX33, but not an RX50. Can you get a directory listing of
the disk?
--
Pete Peter Turnbull
Network Manager
University of York
On Feb 9, 12:14, Bill Gunshannon wrote:
> On Sat, 9 Feb 2002, Jay Jaeger wrote:
>
> > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11
> > FORMTR RX50 . This is a formatter program for a Micro PDP-11.
> I guess this constitutes the last straw for this myth. Or was it merely
> a business decision intended to promote the sale of pre-formatted RX-50
> diskettes. (A practice not uncommon in those days. For example, at one
> place where I worked we were responsible for maintaining Terak Micros, a
> LSI-11 based system. Any time we reported a floppy problem the first
> question was, "Are you using Terak brand diskettes??" Of course,
everyone
> at that time knew there were only 3 manufacturers of platens and
everybody
> else just supplied labels!!)
>
> Other arguments: I have an Andromeda Disk Controller. I know one of the
> supported floppy formats is RX50. I'll bet the their formatting program
> won't care what drive is there and will happily format diskettes for use
> in this and other RX-50's.
I expect it would. It's not hard to write a formatter program. I wrote
one for my Acorn Archimedes, and an RX50 copier program as well.
> I wonder if there is anyone who could be contacted about releasing it??
> Maybe even the VMS version, too. Or even, the source?? Somehow, I doubt
> that Compaq still sells many pre-formatted RX50's.
I seem to recall that DEC let people copy XXDP between machines without too
much excitement.
> And while we're on the subject, what about this supposed problem using
> anything put certain kinds of diskettes?? I used my 80 track 96tpi drive
> all the time with the same diskettes I used in my other SS/SD, DS/SD
drives
> all the time and never had a problem. Is this perhaps another myth
intended
> to foster the sale of pre-formatted diskettes??
So long as they're labelled SD or DD and not HD, they have the right
coercivity. Some people argue that the fineness of the emulsion may be a
factor, but actually you'd have to be incredibly unlucky to have a flaw on
a disk that would allow it to be perfect for SD but not DD. Some people
have likewise argued that the disk head gap is only about half as wide for
80-track as it is for 40-track, but that's irrelevant: even if the gap is a
third of the track pitch, thats around 1/300", the resulting bit density
(300 bpi) on the radius of the disk is still much coarser than the bit
density around the circumference (about 3300 bpi for single density).
I do have a few very old S/S floppies with flaws on the second side, and
which therefore aren't good to use as D/S (I value my data!) but I have
hundreds more sold as S/S that are work fine as D/S. They just weren't
certified that way; they probably just weren't tested, in the days when
lots of disks didn't need to be.
--
Pete Peter Turnbull
Network Manager
University of York
On Feb 9, 8:37, Jay Jaeger wrote:
> Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11
> FORMTR RX50 . This is a formatter program for a Micro PDP-11.
>
> It is a *diagnostic* program (not a user program) for formatting these
> beasties. Mine is for the -11, I would imagine that there is one for the
> MicroVAX as well.
> At 11:42 PM 2/8/2002 +0000, Pete Turnbull wrote:
> >You can format them on a Rainbow, but not an -11 or VAX.
Jay, I'd be very interested to know more about that. I never heard of it
before, and I thought I had a pretty comprehensive collection of the PDP-11
(including microPDP-11) diagnostics. Was it standard issue with a
particular model? Is there a date on it?
--
Pete Peter Turnbull
Network Manager
University of York
I can't believe I haven't figured this out yet. I bought an
RX50, and installed it in my PDP-11/53 running 2.11BSD. It's
nice having that empty hole in the front of the BA23 plugged,
but I hope for even more. The drive seems alive: if I say "cp
/dev/ra1a /dev/null", it starts groaning and ticking as if it
were reading the floppy.
But how do you format the floppies?
I tried XXDP/ZRQCH0 (downloaded via VTserver), but it says the
floppies are UNFORMATTABLE. That does that mean?
--
Jonathan Engdahl Rockwell Automation
Principal Research Engineer 1 Allen-Bradley Drive
Advanced Technology Mayfield Heights, OH 44124
http://users.safeaccess.com/engdahl engdahl(a)safeaccess.com
"The things which are seen are temporary,
but the things which are not seen are eternal." II Cor. 4:18
I built an 11/23 with 256K RAM, a UDC11 disk controller, one 80 meg MFM hard
drive. The hard drive formatter runs under RT-11. The assumption is that you
have a working floppy from which you can boot RT-11. I want to devise a
method to run the formatter via VTserver.
I figured out how to do this for the RQDX3 and XXDP. You can run XXDP under
E11, load the utility you want to run, then stop E11 and dump the entire 28K
word memory image to a disk file. By hacking a header onto this memory
image, you can turn it into a standalone that can be bootstrapped via
VTserver, just like the disklabel, mkfs, and restor standlones. This is
easy, because XXDP tells you what the restart address is when you load a
program.
The question: is is possible to restart RT11SJ in the same manner as XXDP? I
read some of the manuals, and tried using ODT to restart RT-11 at various
points pointed to by the vector table and fixed area. By starting at the
trap 4 address I can get it to restart and live. However, this seems to make
RT-11 forget that I had done a "GET" of the utility that I wanted to run. I
tried restarting at the RMON address, but that crashes.
One other experiment I've tried is to GET the utility then "START 1000", but
that crashes too. If I GET then just type "START" it lives. What am I doing
wrong?
One assumption is that the utility only uses memory and TT: system calls --
no disk accesses or swapping. Is it possible to abuse RT-11 in this manner?
The utilities I'm trying to run are the UDC11 OCT and UDCT utilities. I want
to make it possible to reformat the hard drive on this single drive system
without tearing it apart and moving pieces to another system. It is also
possible to mess up the NVRAM on the UDC11 so that you cannot boot. If this
happens, and you are lucky enough to have another running system (and I am),
you can rejumper the CSR of the stuck board and fix it on the other system.
Otherwise, you are in big trouble.
I wonder if it would be possible to bootstrap a VM0: image into high RAM and
boot from it?
I realize there are other solutions. The standard answer to questions like
this is "get more hardware". The reason for doing this is I want to invent a
method that will work for a very minimal pile of hardware. And the whole
point of that is to make it possible for people to get a PDP-11 running with
minimal investment.
--
Jonathan Engdahl Rockwell Automation
Principal Research Engineer 1 Allen-Bradley Drive
Advanced Technology Mayfield Heights, OH 44124, USA
Mayfield Heights Labs engdahl(a)safeaccess.com 440-646-7326
http://users.safeaccess.com/engdahl/PDP-11.htm
All,
With the freeing up of the Unix source, not only can I open up
the Unix Archive to anonymous downloads, but I can now make my Unix Tree
web site available anonymously: http://minnie.tuhs.org/UnixTree/
Here is where you will find unpacked versions of Unix source code, and
a means of comparing files between different versions.
Cheers,
Warren
P.S Thanks to the many people who have set up mirrors of the Unix Archive.
Greg Lehey:
To repeat what I said earlier: the hardware-dependent code isn't very
interesting, it's the kernel interfaces. Minix is not UNIX; BSD is.
You'll find it easier to adapt a BSD driver to the Sixth or Seventh
Edition than you will a Minix or Linux driver.
It depends on approach, which depends in turn on intent.
If the intent is to get a system up and running as quickly as possible,
it would probably be best to shoehorn existing code into the existing
old UNIX framework, and code from a current BSD system is probably easier
to do that with than code from Minix (says someone who has looked at
neither within living memory).
If the intent is to learn about the innards of operating systems and
how they interact with hardware, or about the specifics of old UNIXes
or the OS aspects of Intel hardware, it is better to compare different
descriptions of the hardware (whether abstract descriptions in books
or pragmatic ones in code), write your own small test programs to be
run on bare hardware or as special cases within some system that
already runs there, and eventually write your own code or adopt code
that you now understand thoroughly.
Which of these you consider fun depends both on your goals and on your
personal taste. Both are worthy of respect.
In days long past, when I did a lot of work to make a research version
of UNIX as robust as possible against hardware flaws (recover if possible,
at least explain clearly what broke if not) and to port it to a few new
VAXes of the time, I found the best hardware information to lie in the
VAX/VMS source fiche. The UNIXes of the day tended either to crash on
the slightest hardware error or to ignore the error and just misbehave
until rebooted. Stealing code from them would have been easier, but it
wouldn't have done what I wanted. Reading the VMS sources and treating
them as a hardware reference manual did. Modern UNIXes doubtless do
better, but the point is that different systems do different things
with the hardware, and if your goal is understanding and not just
function, you will gain more by looking in many places.
An irrelevant but fun anecdote: it could be argued that the resulting
code recovered too smoothly from errors. One day I discovered that
one of our systems was running more slowly than usual, though it was
otherwise OK; checking back on the paper console log, I discovered
that several weeks earlier it had had a hard cache error, reported it
and cheerfully turned off the bad half of the cache, and continued on
its way. So I called Field Service and we scheduled a convenient time
to run diagnostics--yes, the hardware really had failed--and replace
the bad CPU board; but it would have been better to have noticed
earlier. I watched the console logs more carefully after that.
Norman Wilson
Toronto ON
