>Was this TM03 originally installed on the KS or has it come from
>somewhere else. I'm wondering if it's got all the correct varients
>for the TU77 and 18 bit bit fidler.
>
>Anyone have a TM03 print set that I can look at...
When we got the -10s, we got print sets... and I know that there
are some TM03/TU77 printsets in there... I'll have to look. I
also have a bunch of manuals at work (that I rescued recently)
relating to TU77.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
<> 48tpi single sided (sa400)
<> 48tpi double sided (sa450)
<> 96tpi single sided (teac Fd55E or DEC RX50)
<> 96tpi double sided (teac FD55F)
<> 100tpi single and double sided models (micropolis I think)
<>
<
<Ok, I wasn't aware of any 96tpi drives except the HD ones... Were
<they ever used in the PC marketplace, or was it mostly a DEC thing?
<After re-reading my uVAX manual about the RX50, I agree it is a
In the PC market place... what that? ;) Ok, No. PCs used 48tpi and the
later 96tpi/all mode (fd55gfv or similar).
Most of the 96tpi drives known as QD were in the CPM/CCdos/Zdos market
and were DD rate but double storage due to twice the tracks of the 48 tpi
drives (hence quad density). The same format that gave 360k on a 48tpi
two sided drive allowed 720k on a QD drive by virtue of more tracks.
<96tpi single sided drive, though the manual says: "Use only formatted
<RX50 diskettes, available from DIGITAL or its licensed distributors"
RX50 is not a media problem it's a formatting problem as it's 10 512byte
sectors per track and the 1793 (and kin) really are the correct parts to
exactly duplicate that format. Most PCs can with the right drive format
RX50 media (teac FD55E or 55F with correct jumpers in place).
RX50 media is standard two sided DD
media. I use it for RX180 and also RX180 for RX50 properly erased and
formatted and both work in PCs as 360k media (erased and formatted).
<RX50 360K,96tpi,80tracks/side
<???? 720K,96tpi,80tracks/side - What was (is) this called? DSQD?
Yep! It was used in many machines but most were CPM based or PCdos
not on standard PC hardware( or CCdos on S100).
<DSHD 1.2M,96tpi,80tracks/side - can read older media, but writing
< is unreliable (head isn't wide
< enough to erase the whole old track)
Correct.
<If Bill indeed has DSDD media, bulk erasing the media before applying
<it to the 96tpi (non-HD) drive should work fine. This erases the old
<data from between the new (half as wide) tracks, so it doesn't
<interfere with reading.
Correct.
In the 5.25" drive market from 1977 to current the number and variation of
drives and controllers and formats used would make one batty. there were
for the most part only a few differnt media though. Most of the media with
the exception of 1.2mb (or it's derivitives) was all the same oxide and
any variation was hard sector, odd envelopes or only one side certified
good (though both were usually good.).
FYI: I have NON-PC 5.25 media for:
old 35track sa400s (verbatum and shugart) hard and soft sector
(inclued the originals for my NS* system that have short window
and the ICOM FDOS soft sector media with short window)
Visual 1050 96tpi 1 and two sided variations. <FD55F and 55G>
RX180 <sa400l and tandon TM100-1>
RX50 (vms, POS, RT11, Rainbow, RSX, Netbsd, XXDP, OS8, WPS
filesystems) <rx50>
RX33 (dec 1.2m for Vaxmate and Later vaxen) <FD55GFV>
Ti99/4 (40tr SSSD) <sa440L>
H89 softsector <tm100-1>
Kaypro (SSDD, DSDD, DSQD advent turborom format) <mix of drives>
Ampro 48tpi and 96tpi CPM <I used FD55B 48tpi early on>
And a box of misc mongrul formats.
Those are the ones in active use here. I've endevored to reduce the
number of formats to those. PCs I unilaterally have discontinued active
5.25 media use as it's inconsistant at best and 3.5" is supported in most
I use (I have one system that can do 360, 1.2 or ?? if need be).
Allison
What hardware is needed in order to connect a RX02 to a PDP8/e? Is
it just the M8357 RX8E interface card, or is something else (data break?)
needed?
Can I boot an operating system from a PDP8/e with only a serial terminal
and a RX02?
While i'm at it, does anyone have a spare M8357?
-Lawrence LeMay
lemay(a)cs.umn.edu
<
<F_..E...D...C...B...A...9...8...7...6...5...4_..3_..2_..1?..
<
< ? E 0040 0000.0005
< ? C 0080 0000.4001
< ? 6 00A0 0000.4001
<?? 1 00C0 0011.700E
<
<>>>
No disk? or not bootable.
Also, the 3100 is a superset of the Vs2000 so any info on that also applies
generally.
Check here:
http://www.netbsd.org/Library/Hardware/Machines/DEC/vax/index.html
<Trying to run a test from the >>> prompt doesn't work either.
T 50 doesnt work?
Allison
PS: copy of an old message from tim on tests.
From: Tim Shoppa <shoppa(a)alph01.triumf.ca>
Message-Id: <9805241840.AA08441(a)alph01.triumf.ca>
Subject: Re: VS2000 tests and other oddities?
> I was poking around for various test numbers and letters on a VS2000 when
> I came across the most interesting test 90. It obviously has to do with
> stats on the ethernet device, but is there anything else it does?
>
> I knew about test 70 being an MFM disk formatter, but what's test 71?
>
> test 70 gives "KA410-A RDRXfmt"
> test 71 gives "KA410-A RDver"
>
> Then tests 51, 52, and 53 seem to do more than your average bogus test
> which results in "?17 ILL CMD" but at the same time it's not obvious to me
> what it actually is that they do (if anything).
What I reproduce below is from an old DEC SPD on the built-in
diagnostics; I hope it helps. Somewhere here I have the DEC
part number for the "Hardware key" used to enable the less-well-known
packages.
PRODUCT NAME: MicroVAX 2000/VAXstation 2000 Diagnostic Package
TEST 0 - Invokes the customer runnable system excerciser. This test
executes a serial string test of all devices in the system.
After serial device testing has completed, a concurrent device test
is executed. The test automatically configures the test based
on the system's hardware configuration and will test all devices
present. This test runs for two test passes and concludes with a
summary table of test results.
TEST 50 - A utility that displays the hardware configuration of
the system. It displays a listing of all functionality present
along with status of each device on the last diagnostic executed.
Additionally, this display identifies the current revision of
firmware in the system as well as the system I.D. number (used as
the system's hardware address when networked).
TEST 51 - Allows the user to define a default boot device for
automatic bootstrapping of the system.
TEST 52 - Allows the user to set default boot flags to be used by the
operating system during boot operations.
TEST 53 - Allows the user to set default recovery action flags used
by the system during power up and also used by the system if an
error is detected with the operating environment.
TEST 54 - Displays a language inquiry menu on the console device
(VAXstation 2000 only) to allow the customer to select the
appropriate keyboard type based on the country keyboard in use.
On MicroVAX 2000, this function is accomplished through the
language set-up utility that is part of the console terminal.
TEST 61 - Sends a full screen of E's to the console monitor display
(VAXstation 2000 only) allowing a quick check of the monitor's
linearity adjustments.
TEST 62 - Sends a full white screen to the console monitor display
(VAXstation 2000 only) allowing a quick check of the monitor's
raster as well as a check of the video controller's display memory.
TEST 70 - Allows the customer to format hard disk drives and RX33
floppy diskettes. RX50 diskettes need not use this utility as they
come pre-formatted. If formatting a non-Digital Equipment
Corporation hard disk drive, this utility goes into a query mode
thus allowing the customer to enter drive parameter data prior to
actually performing the format operation.
Note: Formatting destroys all user data on the disk or diskette
being formatted.
TEST 71 - A disk verifier utility. This utility does a
non-destructive test of hard disk formats to search for new bad
blocks on the media since operating system installation and
identifies any new bad blocks to the customer. This utility is for
use with hard disks only.
TEST 90 - A utility that is used with systems that are connected
in a network configuration. This utility, when invoked, puts the
system in a test mode to provide loopback and system I.D. support
to network level diagnostics run from a host or boot node. Working
in combination with network level excercisers, this utility assists
in verifying the system's network hardware/firmware interface is
correctly functioning.
TEST 80000050 - A utility that displays all system firmware
revision levels by function (i.e. self test, bootstrap code,
console code, etc.).
Part III - Extended Diagnostics/Maintenance Utilities for Digital Equipment
Corporation Field Service Personnel and Licensed Customers
This section describes diagnostic functionality that is proprietary to
the Digital Equipment Corporation Field Service and Support organizations.
This
series of routines require the use of a special hardware key to invoke and
execute.
TEST 60 - A utility that displays a circle/crosshatch pattern on
the console monitor (VAXstation 2000 only). It is used by service
personnel to check/adjust monitor linearity and aspect ratio.
TEST 72 - A utility that writes a special key on scratch floppy
diskettes. After running a floppy diskette through this utility,
the diskette can then be used with the Field Service system
excerciser to do write testing of the floppy diskette subsystem.
Floppy diskettes used with the system excerciser that do not have
this special key written on the media will do a read test only.
TEST 73 - A utility that writes a special key on a scratch TK50
COMPACTape. After running the COMPACTape through this utility,
the cartridge can then be used with the Field Service system
excerciser to do write testing of the TK50 subsystem. Cartridges
used with the system excerciser that do not have this special key
written on the media will do a read test only.
TEST 101 - Executes the Field Service mode system excerciser. This
test excercises each device once sequentially and then
excercises all devices concurrently. This sequence is executed
for two complete passes of all system devices present in the
configuration. Loopback connectors and test media are required to
optimize test coverage with this routine. This test automatically
stops after two complete passes and displays a test summary.
TEST 102 - Executes the Field Service mode system excerciser. It
excercises all devices in the system configuration in the same
sequence as described for Test 101. However, when Test 102 is
invoked, the sequence is repeated continuously until the user
types CONTROL/C at the system console. When CONTROL/C is typed,
the test terminates at the conclusion of the current test
pass and displays a test summary. Note that the user must allow
this test to run for at least two complete passes before typing
CONTROL/C.
TEST 80000106 - Allows the Field Service Engineer to select
individual device tests from the total test used in Test 102
described above. Whichever device tests are enabled and
executed run in a continuous loop until CONTROL/C is
typed at the system console. As with Test 102, the user must
allow this test run for at least two complete passes before
typing CONTROL/C.
Tim. (shoppa(a)triumf.ca)
and more info...
The Seven Sages Project has moved the mirror of the Vax Archive. It will
no longer work if you go to http://www.sevensages.org/vax/. You must now
go to http://vaxarchive.sevensages.org/ instead. If enough people
complain, I'll shorten that to vax.sevensages.org. Also, I'll also have
apache point from /vax/ to the new site.
Regards,
John Havard
Head Geek
The Seven Sages Project
OK, the PDP8/f is in California. As i mentioned before they want $600
for it. This is what it contains:
> 1 M8330
> 1 M8310
> 1 M8300
> 1 M837
> 1 M848
> 5 M1709
> 2 M8655 (NOT THE TWO LISTED BELOW)
> 1 M849
> 1 M8320
> AND 1 DATARAM DR118 CORE MEMORY
I'm still dealing with them over the PDP8 boards I want to buy, which is
why i'm hesitant to mention the company at the moment.
-Lawrence LeMay
Fred Cisin wrote:
>http://www.xenosoft.com/fmts.html#720K
>will give you a list of some of them.
Wow, an impressive list of formats. I'm disappointed that I don't
see the grandaddy of them all - IBM 3740 - explicitly listed, though!
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Okay, one final question before I drop this topic
forever (or until tomorrow, whichever comes first).
How is it possible that DD media could be of such
poor quality that it can't (reliably?) do 96 TPI,
while still being just fine at 48 TPI?
I mean, it is recording something like 3000 bits per
inch along each track, right? How could that same
media not have enough resolution to keep the bits of
adjacent tracks separate at less than 100 per inch?
Can somebody who believes this can happen give me a
mental model of what is going on there? I mean, in
terms of physics or geometry or mechanics or anything
measurable and specific.
It sounds to me like it must be the drive, and not
the media, that limits the number of tracks to
anything below 1500 TPI.
Thanks,
Bill.
>Ok, so not as much as at 7:00 this morning... HD media has a higher
>coercivity, thus requires more write current to put a bit on the
>disk. If you use that much write current with LD media (lower
>coercivity) you will get a larger bit. The larger bit will partially
>overwrite adjacent bits, leading to low amplitude, and read errors.
The "bit" size has more to do with the gap and physical construction of
the head, as I remember from my magnetics courses. Yes, the current
is obviously interrelated, but the primary factor is the head gap.
>Ok, I wasn't aware of any 96tpi drives except the HD ones... Were
>they ever used in the PC marketplace, or was it mostly a DEC thing?
Yes, there were a few not-quite-100%-PC-compatible clones that used
DD media at 96 TPI. There were even 100 TPI drives, just to be incompatible
with nearly everybody! (Well, they also eked out a bit more capacity
>from the same media, which was a selling point when few had hard drives.)
>After re-reading my uVAX manual about the RX50, I agree it is a
>96tpi single sided drive, though the manual says: "Use only formatted
>RX50 diskettes, available from DIGITAL or its licensed distributors"
>
>So there are four drives using the same media:
>SSDD 180K,48tpi,40tracks/side
>DSDD 360K,48tpi,40tracks/side
>RX50 360K,96tpi,80tracks/side
>???? 720K,96tpi,80tracks/side - What was (is) this called? DSQD?
Some aftermarket third-party DEC-compatible controllers have a
double-sided RX50 mode that they call "RX52".
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
The PDP 8/s is now completely running. It ran for over 10 hours (today and
yesterday) with no bugs - not flaky! yes. The high speed reader is *finally*
aligned and working well. The 8/s is running all kinds of MAINDEC programs
today before the real "binary loader" is run.
BTW: The PDP 8/S CPU has 1001 transistors in it (999 if you don't include
the two transistors on the core stack)
A few things amaze me about this machine. First, the signals are so *clean*
on the scope - No noise or rounded/poor waveforms I am use to seeing on TTL
units (slower switching rate obviously).
Second is the PC0 paper tape drive. DEC managed to get 300 cps through this
unit by merely strobing the data off the optical sensors DIRECTLY onto the
negibus (no flip flops!)... A real fun treat to align as the punched holes
have to appear directly over the sensors half way through the feed. Weirdest
thing I have ever seen.
The D/A converter is working well and the A/D unit has also been tested. I
am hooking up an ASR 33 to it tomorrow so I can start running some *serious*
programs on it.
Core memory and power supplies have been tuned.
I am going to put up a website for it by the end of the week with pictures
of this unit. Hopefully a telnet/camera link to it by the end of the month.
In total it had:
One bad connection on the W108 board (near core - caused from heat)
One bad connection on SY R133 board - 2 hours to find that problem - serial
everything.. ugghh..(again, near core - heat)
One bad transistor on a 302 triple flip flop (my fault, I was actually tired
enough to try a spare module...not the way to fix this machine)
Alignment on the reader was out by a hair to cause poor data.
about 10 hours reading/ 10 hours working hand on.
I would like to thank the folks in this group who gave me advice about their
experiences with transistor computers which saved me many hours of work and
helped to make sure this unit would not be buggy.
-----
I am trimming my collection to focus on the real pieces I want to collect. I
have a CTS11-J backplane and cards for anyone here who wants to trade
anything for it or just plainly really needs it.
I also have an H213 core stack if anyone would like to trade some broken/not
broken R XXX series flip chips for it.
I am going back into storage over the next couple of weeks and should have
quite a bit of stuff to find good homes both here and on Ebay.
john